Project:Retirement/For developers

What does retirement imply?

The process of retirement means suspending the developer's account, as well as all related perks. This normally involves:

• Removing the developer from all packages and projects, and reassigning all bugs appropriately.
• Removing commit access to gentoo.git, project repositories and disabling the developer overlay.
• Disabling access to dev.gentoo.org and other Gentoo machines.
• Disabling access to the Gentoo mail system. The developer's mailbox remains active for up to 6 months (1 month for every year as developer, rounded up), either forwarding mail to another address or storing it for future retrieval. Please contact Infra to get your mails and/or change forwarding setup.
• Removing developer from all mailing lists.
• Disabling developer's Bugzilla account. You need to open a new account if you wish to continue using Bugzilla.
• Removing developer status and privileges from Forums and Wiki.
• Removing developer's blog from Planet/Universe, disabling Gentoo blogs account and disabling comments on any posts created using this account.
• Removing developer's IRC cloak (replaced with 'unaffiliated').

If you wish to change some of the above events (e.g. forward mail to a different address than in LDAP, become proxied maintainer for your packages, etc.), please contact the project members prior to retirement.

How do the project members determine activity?

For the purposes of inactivity retirement, the project members determine the activity of each developer individually. Generally, by activity we mean any work that benefits Gentoo users and that by quality and/or quantity exceeds the work done by an occasional contributor.

Examples of qualifying work include:

• gentoo.git or other user-oriented repository commits that meet quality requirements and quantity justifying direct push access (vs. committing via proxy),
• GLSA releases and security bug processing in significant quantity (in case of Security project members).

For developers with commit access, the primary venue of contributing is through commits. If you no longer maintain ebuilds but instead wish to focus on contributing through other venues, we can remove your commit access bit on request.

We attempt to collect activity information ourselves. However, we have limited time and we can't go around hunting for any signs of activity. Instead, if we can not establish your activity through the regular channels, please let us know how to determine it. However, please note that we need to be able to establish the quantity of your contributions (as well as some standard to compare it against) and verify them. If this information can not be provided automatically, we require the appropriate data to be submitted no rarer than monthly.

Developer unavailability (devaway)

If you expect to be unavailable for some time, please remember to set up devaway. A good devaway message includes:

• how you can be contacted if necessary,
• what to do with your packages,
• when do you expect to be back.

If you can't set up devaway yourself, feel free to ask us to do it for you. If you expect to be unavailable through a long period of time, you can also request us to temporarily disable your commit access (to be restored on request).

We naturally delay inactivity retirement while developer is explicitly away. However, please note that we are not going to honor devaway forever, and if developer is not able to return within reasonable time, we will proceed with retirement. If you have specific problems that justify longer devaway period, please tell us (no need for details but we need to distinguish personal problems from lack of time).

Retirement bugs and Retirement procedures

The project members rely on the specific state of developer bugs in their proceedings. Please don't change it yourself.

We check developers for inactivity periodically. As a result of this check, we reopen developer bugs, change their summaries and reassign them. Afterwards, we usually recheck your status at the next deadlines specified by the retirement procedure. If you became active again yet your bug is still open, don't panic — it just means we haven't got the opportunity to recheck yet. Please don't close the bug yourself or nag us— we will eventually get to it.

Once we notice that the developer is active again, we close the bug WONTFIX. Please do not reassign them back to Recruiters.

Appeals on Retirement decisions

We are just humans, we can make mistakes. If you believe that we're missed something or that we're wrong about something, please do not hesitate to contact us. However, if there is a clear disagreement between you and the project, you have the right to appeal our decisions.

1. The appeal is made to ComRel. If either of us disagree with ComRel's resolution, it can be further appealed to the Council.
2. Retirement team decisions can be appealed no earlier than one month before the planned execution date (i.e. after receiving the fourth mail).
3. Throughout the appeal process, the pending retirement is suspended. If the appeal is made after the developer is retired, the developer remains retired throught the process. The appeal process is considered finished if either:
   • the Council issues final decision,
   • the ComRel resolution is not appealed to the Council within 7 days,
   • both sides agree not to appeal further.
4. The appeal process resolves each case individually based on existing policies. While it may influence future policies, those need to be carried out via appropriate policy making channels.

Voluntary retirement

There are many ways to retire manually, and launch the retirement process on their own. For example, one can:

• write to their own developer bug while CCing retirement@g.o,
• send a direct (PGP-signed) e-mail to retirement@g.o,
• make a gentoo-core ML post about their retirement.

Everyone will be given 14 days to reconsider their decision, before the retirement is done immediately.

Reinstating Gentoo Developer status (return to duty)

Reinstating a developer status is a lot easier than gaining a new developer status. You'll still have to contact the recruiters; let them know you're an old developer. You'll need to know beforehand what you'll be working on as a returning developer, and have a small interview session with the recruiters. They will then set up your developer account.