diff --git a/en/internal/new-account.sgml b/en/internal/new-account.sgml index a7a2ed7acc..284976bb9b 100644 --- a/en/internal/new-account.sgml +++ b/en/internal/new-account.sgml @@ -1,124 +1,131 @@ - + ]> &header;

Proposing a new committer

If you want to propose a new committer, you should send the following information to the appropriate entity:

Any commit bit requests that do not follow the guidelines outlined above will be delayed (at best) or earn you negative vibrations from the respective team / team secretary.

Responsible party for this procedure is:

You will get ACK after the message is seen, and core@ and doceng@ will give you a response in <= 7 days. For them, timeout is set at 7 days. Timeout for portmgr@ is set at 14 days. If voting finishes earlier then the nominator/nominee are informed earlier.

Authorizing A New Account

Someone from the list below sends a PGP-signed email to accounts@, the person assigned as the mentor to the new committer, and copied to core@FreeBSD.org confirming the approval of the new account. This email should include a link to this document so the mentor/mentee know what is expected of them.

New account approvals are only valid from these PGP entities:

NOTE: New account requests from anyone other than these entities or requests signed with PGP keys other than from these entities will not be acted upon. No exceptions. In case of a new ports or doc committer the account request email should be CC:-ed to core.

Information Needed From The Mentor

The person assigned as the new committers' mentor needs to collect and send the following information to accounts@:

The mentor is responsible for obtaining this information from the new committer in a secure fashion, and providing it to accounts@ in a secure fashion. PGP-signed email, with the mentor's public key already committed to the Handbook, is the preferred method for the mentor to send the information to accounts@. If this is impossible for some reason an acceptable substitute is for the mentor to place the account information in their home directory on freefall and then tell accounts@ where to find it. We need to be sure the account information really is coming from the Mentor and unsigned email is not sufficient for this these days. Since accounts@ has no way to verify anything from the new Committer this information needs to be sent to accounts@ by the Mentor, not the new Committer.

accounts@ Creates New Account

accounts@ creates the new account with the above information on the FreeBSD.org cluster and notifies the mentor and the new committer.

Mentor Activates New Committer's Commit Bit

After the new committer confirms that the account works, the mentor adds the new committer to the correct access file, using an appropriate commit message. The commit message should at least contain the committer's full name, the mentor's name and what area the new committer will start to work in. Having done all that, the new committer and mentor jointly go through the first commit operations.

+

Reading the Committer's + Guide is considered a good first step for new committers, especially + the Conventions + and Traditions section.

+

End Of Mentorship

There is no pre-set duration for a mentorship. Once the mentor feels the mentee is ready to 'fly solo' the mentor notifies the developer community via a forced commit to access with an appropriate commit message.

Transfer Of Mentorship

Should a need arise to transfer mentorship for a committer please email the responsible party, as described for a new account proposal. Typically this request is rubberstamped as-is. A forced commit to access with an appropriate commit message is to be used to inform the world of the transfer.

&footer;