Differential D10413 Diff 28164 en_US.ISO8859-1/htdocs/internal/members.xml

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>
				jhbUnsubmitted Done Inline Actions I think you can drop this paragraph entirely. 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>

				jhbUnsubmitted Done Inline Actions I 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 Actions Perhaps drop this paragraph now? jhb: Perhaps drop this paragraph now?
				matthewAuthorUnsubmitted Done Inline Actions I 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 Actions To 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 Actions Oh, 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
				jhbUnsubmitted Done Inline Actions Aren'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>
	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>
	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>
	status, should review that status at least once annually and
	retire inactive accounts. There is no minimum level of
	contribution required, Core and the designated teams may use their
	own discretion.</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 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>
				jhbUnsubmitted Done Inline Actions Tweak: "Committer Benefits:" to match formatting of earlier <h2> for Member Benefits. jhb: Tweak: "Committer Benefits:" to match formatting of earlier <h2> for Member Benefits.

				<p>Member status is conferred by a ballot of Core members, or by
				jhbUnsubmitted Done Inline Actions s/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…
				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>
				jhbUnsubmitted Done Inline Actions Trailing colon here as well? jhb: Trailing colon here as well?

				<p>Core, or groups designated by Core that award Member status,
				should review that status at least once annually and retire
				inactive accounts. There is no formal definition of inactive
				accounts. Core and the designated teams may use their own
				discretion.</p>
				jhbUnsubmitted Done Inline Actions I 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…
				jhbUnsubmitted Done Inline Actions For 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…

	<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>