diff options
| author | Sergio Carlavilla Delgado <carlavilla@FreeBSD.org> | 2021-01-25 23:31:29 +0000 |
|---|---|---|
| committer | Sergio Carlavilla Delgado <carlavilla@FreeBSD.org> | 2021-01-25 23:31:29 +0000 |
| commit | 989d921f5d4ac8d8b7c831c13b8954ad1901be24 (patch) | |
| tree | a5d768f9af4b55422fdf5b17064879ae1c7ce032 /en_US.ISO8859-1/htdocs/internal/new-account.xml | |
| parent | 0cff342f42461c5081b98bce7581f43df319e4f4 (diff) | |
| download | doc-989d921f5d4ac8d8b7c831c13b8954ad1901be24.tar.gz doc-989d921f5d4ac8d8b7c831c13b8954ad1901be24.zip | |
Migrate doc to Hugo/AsciiDoctor
I'm very pleased to announce the release of
our new website and documentation using
the new toolchain with Hugo and AsciiDoctor.
To get more information about the new toolchain
please read the FreeBSD Documentation Project Primer[1],
Hugo docs[2] and AsciiDoctor docs[3].
Acknowledgment:
Benedict Reuschling <bcr@>
Glen Barber <gjb@>
Hiroki Sato <hrs@>
Li-Wen Hsu <lwhsu@>
Sean Chittenden <seanc@>
The FreeBSD Foundation
[1] https://docs.FreeBSD.org/en/books/fdp-primer/
[2] https://gohugo.io/documentation/
[3] https://docs.asciidoctor.org/home/
Approved by: doceng, core
Diffstat (limited to 'en_US.ISO8859-1/htdocs/internal/new-account.xml')
| -rw-r--r-- | en_US.ISO8859-1/htdocs/internal/new-account.xml | 147 |
1 files changed, 0 insertions, 147 deletions
diff --git a/en_US.ISO8859-1/htdocs/internal/new-account.xml b/en_US.ISO8859-1/htdocs/internal/new-account.xml deleted file mode 100644 index 04dba1be41..0000000000 --- a/en_US.ISO8859-1/htdocs/internal/new-account.xml +++ /dev/null @@ -1,147 +0,0 @@ -<?xml version="1.0" encoding="iso-8859-1"?> -<!DOCTYPE html PUBLIC "-//FreeBSD//DTD XHTML 1.0 Transitional-Based Extension//EN" -"http://www.FreeBSD.org/XML/share/xml/xhtml10-freebsd.dtd" [ -<!ENTITY title "New Account Creation Procedure"> -]> - -<html xmlns="http://www.w3.org/1999/xhtml"> - <head> - <title>&title;</title> - - <cvs:keyword xmlns:cvs="http://www.FreeBSD.org/XML/CVS">$FreeBSD$</cvs:keyword> - </head> - - <body class="navinclude.docs"> - - <h2>Proposing a new committer</h2> - - <p>If you want to propose a new committer, you should send the following - information to the appropriate entity: - </p> - <ul> - <li>Information on what established (FreeBSD) track record the - nominee has. This is <em>not</em> optional.</li> - <li>Who has volunteered to become the mentor for the new - committer.</li> - <li>The email address of the nominee (remarkably often this - is omitted).</li> - </ul> - - <p>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. For some guidelines on how the - proposal itself should be written, please see <a - href="proposing-committers.html">a brief summary</a>. - </p> - - <p>Responsible party for this procedure is:</p> - <ul> - <li>src --> core@</li> - <li>doc --> doceng@</li> - <li>ports --> portmgr@</li> - </ul> - - <p> You will get ACK after the message is seen, and core@, doceng@ and portmgr@ - will give you a response after voting is finished or when the timeout is hit. - The timeout for core@ and portmgr@ is set to 7 days while for doceng@ it is - 14 days, however, as indicated, this is just a worst case and team members - may finish voting earlier.</p> - - <h2>Authorizing A New Account</h2> - - <p>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.</p> - - <p>New account approvals are only valid from these PGP entities:</p> - - <ul> - <li><p>core-secretary (for src commit bits)</p></li> - <li><p>portmgr-secretary (for ports commit bits)</p></li> - <li><p>doceng-secretary (for doc commit bits)</p></li> - </ul> - - <p><i>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.</i></p> - - <h2>Information Needed From The Mentor</h2> - - <p>The person assigned as the new committers' mentor needs to collect - and send the following information to accounts@:</p> - - <ul> - <li><p>username (lowercase a-z and 0-9)</p></li> - <li><p>Full Name (as would go in a GECOS field; UTF-8 encoded)</p></li> - <li><p>optional additional GECOS information (phone, location etc)</p></li> - <li><p>shell (sh, csh/tcsh, bash, zsh are available)</p></li> - <li><p>ssh V2 public key</p></li> - </ul> - - <p>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.</p> - - <h2>accounts@ Creates New Account</h2> - - <p>accounts@ creates the new account with the above - information on the FreeBSD.org cluster and notifies the mentor and - the new committer.</p> - - <h2>Mentor Activates New Committer's Commit Bit</h2> - - <p>After the new committer confirms that the account works, the mentor - adds the new committer to the correct <tt>access</tt> file, - using an appropriate commit message. The commit message should at least - contain the committer's full name and username, the mentor's - name and what area the new committer will start to work in. - An entry should also be added to the <tt>mentors</tt> file in - the respective Subversion repository to indicate - the mentor relationship. Having done all that, - the new committer and mentor jointly go through the first commit - operations.</p> - - <h2>Additional Services</h2> - - <p>The mentor should add the new committer to the <a - href="https://wiki.freebsd.org/DevelopersGroup">Developers - group</a> on the wiki and to the <a - href="https://reviews.freebsd.org/project/view/3/">committer</a> - project on Phabricator.</p> - - <p>Reading the <a - href="&base;/doc/en_US.ISO8859-1/articles/committers-guide/index.html">Committer's - Guide</a> is considered a good first step for new committers, especially - the <a - href="&base;/doc/en_US.ISO8859-1/articles/committers-guide/conventions.html">Conventions - and Traditions</a> section.</p> - - <h2>End Of Mentorship</h2> - - <p>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 by removing the entry from the <tt>mentors</tt> file in - SVN.</p> - - <h2>Transfer Of Mentorship</h2> - - <p>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. - In Subversion, the <tt>mentors</tt> file should be updated.</p> - - </body> -</html> |