diff --git a/en/internal/new-account.sgml b/en/internal/new-account.sgml index 7d78e4108b..a7a2ed7acc 100644 --- a/en/internal/new-account.sgml +++ b/en/internal/new-account.sgml @@ -1,120 +1,124 @@ - + ]> &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 their account works, the mentor - activates the new committer's commit bit and guides them through the - rest of the initial process.

+

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.

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;