Changeset View
Standalone View
en_US.ISO8859-1/htdocs/internal/members.xml
- This file was copied from en_US.ISO8859-1/htdocs/internal/associates.xml.
<?Xml version="1.0" encoding="iso-8859-1"?> | <?Xml version="1.0" encoding="iso-8859-1"?> | ||||
<!DOCTYPE html PUBLIC "-//FreeBSD//DTD XHTML 1.0 Transitional-Based Extension//EN" | <!DOCTYPE html PUBLIC "-//FreeBSD//DTD XHTML 1.0 Transitional-Based Extension//EN" | ||||
"http://www.FreeBSD.org/XML/share/xml/xhtml10-freebsd.dtd" [ | "http://www.FreeBSD.org/XML/share/xml/xhtml10-freebsd.dtd" [ | ||||
<!ENTITY title "FreeBSD Project Associates"> | <!ENTITY title "FreeBSD Project Members"> | ||||
]> | ]> | ||||
<html xmlns="http://www.w3.org/1999/xhtml"> | <html xmlns="http://www.w3.org/1999/xhtml"> | ||||
<head> | <head> | ||||
<title>&title;</title> | <title>&title;</title> | ||||
<cvs:keyword xmlns:cvs="http://www.FreeBSD.org/XML/CVS">$FreeBSD: head/en_US.ISO8859-1/htdocs/internal/associates.xml 50193 2017-04-22 13:45:46Z matthew $</cvs:keyword> | <cvs:keyword xmlns:cvs="http://www.FreeBSD.org/XML/CVS">$FreeBSD: head/en_US.ISO8859-1/htdocs/internal/associates.xml 50193 2017-04-22 13:45:46Z matthew $</cvs:keyword> | ||||
</head> | </head> | ||||
<body class="navinclude.docs"> | <body class="navinclude.docs"> | ||||
<h1>FreeBSD Project Associate</h1> | <h1>FreeBSD Project Members</h1> | ||||
jhb: I think you can drop this paragraph entirely. | |||||
<p>An Associate is an individual who has made a notable contribution | <p>A FreeBSD Project Member is an individual who has made a | ||||
to the FreeBSD project. That may be in the form of new code, | notable contribution to the FreeBSD Project. That may be in the | ||||
documentation, or patches to existing code and documentation | form of new code, documentation, or patches to existing code and | ||||
committed through a currently valid Committer, or in other ways | documentation, or in other ways that the Core Team designates, | ||||
that the Core Team designates, including community management and | including community management and advocacy.</p> | ||||
advocacy. Associates do not have any voting rights or | |||||
responsibilities to the project other than to ensure their | |||||
contributed material adheres to the project's standards and | |||||
practices, that the work is original to the author and is made | |||||
available under the standard, FreeBSD license.</p> | |||||
<h2>Associates receive:<h2> | <h3>Committers</h3> | ||||
<p>Committers are those Project members who have been granted | |||||
commit access (a "commit bit") to one or more of the Project's | |||||
repositories.</p> | |||||
Done Inline ActionsI would simplify this (and use some of the language from your first paragraph above) to say: Committers are members who have been granted commit access (a "commit bit") to one or more of the Project's repositories. Committers are expected... jhb: I would simplify this (and use some of the language from your first paragraph above) to say… | |||||
<h2>Member Benefits:</h2> | |||||
<p>All members receive:</p> | |||||
jhbUnsubmitted Done Inline ActionsPerhaps drop this paragraph now? jhb: Perhaps drop this paragraph now? | |||||
matthewAuthorUnsubmitted Done Inline ActionsI disagree here -- the @FreeBSD.org address is probably the most attractive benefit of becoming a Project Member -- it's the one thing that the rest of the world will be able to see. It's the public acknowledgement of their contribution to the Project. matthew: I disagree here -- the @FreeBSD.org address is probably the most attractive benefit of becoming… | |||||
jhbUnsubmitted Done Inline ActionsTo be clear, by "paragraph" I mean the literal "<p>All members receive:</p>" as it is redundant with the heading in the line above, not to remove the list of benefits. jhb: To be clear, by "paragraph" I mean the literal "<p>All members receive:</p>" as it is… | |||||
matthewAuthorUnsubmitted Done Inline ActionsOh, I see. Sorry for the misunderstanding. Yes, I guess that line could go. matthew: Oh, I see. Sorry for the misunderstanding. Yes, I guess that line could go. | |||||
<ul> | <ul> | ||||
<li>an @freebsd.org email address which also gives them regular | <li>an @freebsd.org email address which also gives them regular | ||||
Done Inline ActionsAren't all members required to abide by the CoC? Also, in the original language, this list of requirements about licensing was required of associates as well. I think perhaps instead we should have a separate itemized list of "obligations" to match the list of "benefits" and move everything starting with "comitters are expected..." into that section and have it apply to all members. That would mean structuring this as: A FreeBSD Project Member is... Comitters are members who have been granted commit access... <h2>Member Responsibilities</h2> <li>Contributed material adheres to project's standards and practices. <li>Contributed material is correctly attributed to its authors <li>Contributed material has appropriate licensing <h2>Member Benefits</h2> /* existing "receives" list */ <h2> Committer Benefits</h2> In addition to member benefits, active committers can vote. Members MUST create SSH and PGP... jhb: Aren't all members required to abide by the CoC? Also, in the original language, this list of… | |||||
Bugzilla and Phabricator logins</li> | Bugzilla and Phabricator logins</li> | ||||
<li>permission to assign bugs to themselves in bugzilla</li> | <li>permission to assign bugs to themselves in bugzilla</li> | ||||
<li>access to freefall and the universe build machines</li> | <li>access to freefall and the universe build machines</li> | ||||
<li>access to the test clusters</li> | <li>access to the test clusters</li> | ||||
<li>the right to attend developer summits</li> | <li>the right to attend developer summits</li> | ||||
<li>access to the developers@ mailing list</li> | <li>access to the developers@ mailing list</li> | ||||
</ul> | </ul> | ||||
<p>Associates MUST create SSH and PGP keys in exactly the same way | <h2>Committer benefits</h2> | ||||
jhbUnsubmitted Done Inline ActionsTweak: "Committer Benefits:" to match formatting of earlier <h2> for Member Benefits. jhb: Tweak: "Committer Benefits:" to match formatting of earlier <h2> for Member Benefits. | |||||
that a committer would to gain access to project resources.</p> | |||||
<p>Associates are bound by the Code of Conduct of the FreeBSD Project.</p> | <p>In addition to the Ordinary Member benefits, active | ||||
Committers (those who have made a commit within the previous | |||||
year) are able to vote in Core elections.</p> | |||||
<p>Associate status is conferred by a ballot of Core members, or | <h2>Member Responsibilities</h2> | ||||
jhbUnsubmitted Done Inline ActionsTrailing colon here as well? jhb: Trailing colon here as well? | |||||
by other groups that Core may designate such as Portmgr or Doceng. | |||||
Any FreeBSD committer or associate may propose candidates for | |||||
associate status.</p> | |||||
<p>Core, or groups that core may designate, that award associate | <p>All Members should ensure that all contributed material:</p> | ||||
<ul> | |||||
<li>adheres to the Project's standards and practices.</li> | |||||
<li>is correctly attributed to its authors.</li> | |||||
<li>has appropriate licensing. Where this is the original | |||||
work of the Project Member, the standard FreeBSD license is | |||||
preferred.</li> | |||||
</ul> | |||||
<p>Members MUST create SSH and PGP keys in exactly the same way | |||||
jhbUnsubmitted Done Inline ActionsI would drop "in exactly the same way as Committers have done previously" as that detail only matters temporarily. jhb: I would drop "in exactly the same way as Committers have done previously" as that detail only… | |||||
as Committers have done previously in order to gain access to | |||||
Project resources.</p> | |||||
<p>Members are bound by the Project's Code of Conduct, | |||||
particularly when representing the Project in external fora.</p> | |||||
<p>Member status is conferred by a ballot of Core members, or by | |||||
a ballot of other groups that Core may designate such as Portmgr | |||||
or Doceng. Any FreeBSD Committer or Member may propose | |||||
candidates for member status.</p> | |||||
<p>Core, or groups that Core may designate, that award Member | |||||
jhbUnsubmitted Done Inline Actionss/designate, that/designate to/. I think this reads a bit clearer as if you drop the clause in commas you get "Core ... should review.." jhb: s/designate, that/designate to/. I think this reads a bit clearer as if you drop the clause in… | |||||
status, should review that status at least once annually and | status, should review that status at least once annually and | ||||
retire inactive accounts. There is no minimum level of | retire inactive accounts. There is no minimum level of | ||||
contribution required, Core and the designated teams may use their | contribution required, Core and the designated teams may use | ||||
jhbUnsubmitted Done Inline ActionsFor this last sentence perhaps "There is no formal definition of inactive accounts. Core and the designated teams will use their own discretion to determine inactivity." jhb: For this last sentence perhaps "There is no formal definition of inactive accounts. Core and… | |||||
own discretion.</p> | their own discretion.</p> | ||||
<hr/> | <hr/> | ||||
<h2>FAQ:</h2> | <h2>FAQ:</h2> | ||||
<dl> | <dl> | ||||
<dt>Assigning a buddy (or group of buddies) to the | <dt>Is a mentor assigned to each newly created Project Member?</dt> | ||||
associate.</dt> | <dd>Project Members are only assigned a mentor if they become | ||||
<dd>No. Associates will be assigned a mentor when they reach a | a committer, or if they have a commit bit reactivated after a | ||||
level to upgrade from Associate to Committer. Until that time, | significant period of inactivity. This only applies to | ||||
they can use the mailing lists and the phabricator review | Committers since the primary purpose of a mentor is to review | ||||
groups.</dd> | what the mentee intends to commit.</dd> | ||||
<dt>Do committers who have given up their commit bits | <dd>No such formal arrangement is required when someone is | ||||
effectively become associates?</dt> | made into an ordinary Project Member, but it is expected that | ||||
<dd>No, they become Alumni.</dd> | the people that sponsor a new Member will assist them with | ||||
setting up their accounts and gaining access to Project | |||||
resources and so forth.</dd> | |||||
<dt>Do you have to become an Ordinary Member before you can be | |||||
granted a commit bit?</dt> | |||||
<dd>No. There is no requirement for prospective Committers to | |||||
have spent time as Ordinary Members. However it is | |||||
anticipated that this will become a common practice as part of | |||||
the route towards committer-hood.</dd> | |||||
<dt>Do Committers who have given up their commit bits | |||||
effectively become just Ordinary Members?</dt> | |||||
<dd>All Committers are Project members, but former Committers | |||||
are considered Committer Alumni. Alumni may revert back to | |||||
active Committers simply by requesting reinstatement of their | |||||
commit access.</dd> | |||||
<dt>How does this affect the existing 3rd Party Developer | <dt>How does this affect the existing 3rd Party Developer | ||||
status?</dt> | status?</dt> | ||||
<dd>Existing 3rd party developers will be promoted to | <dd>Existing 3rd Party Developers will be promoted to | ||||
Associates.</dd> | Project Members.</dd> | ||||
</dl> | </dl> | ||||
</body> | </body> | ||||
</html> | </html> |
I think you can drop this paragraph entirely.