couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: [DISCUSS] Project by-laws
Date Wed, 30 Apr 2014 17:30:55 GMT
Modified the roles and responsibilities bit again:

"Hats are an important concept at the ASF. You might have your work
hat and your committer hat, for instance. We expect you to know when
to wear the appropriate hat, and when interacting with the project, to
do so in best interests of the foundation. Failure to do either of
these things is considered a serious dereliction of duty."

https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=40511017

On 30 April 2014 18:34, Noah Slater <nslater@apache.org> wrote:
> If you have not read my draft yet, just ignore this email and read it
> from the start.
>
> If you have, this email summarises my changes.
>
> On 29 April 2014 23:28, Andy Wenk <andy@nms.de> wrote:
>
>> -> why not explicitly writing "... can contribute to the Apache CouchDB
>> project ..." ?
>
> Fixed.
>
>> -> there is a word missing I think: " by being involved IN the community"?
>
> Fixed.
>
>> "Users can also participate in the project by being involved the community,
>> either at the ASF or elsewhere."
>>
>> -> the intention of this sentence is not completely clear to me ... can you
>> explain it?
>>
>> "Users who participate in the project through any mechanism are
>> contributors."
>>
>> -> this sounds like there is no difference between Users and Contributors
>> ... what is fine for me but is this what it should say here? Maybe it
>> should read:
>> "Users who participate in the project through any mechanism are ALSO
>> contributors."
>
> I have reworded this whole bit to:
>
> "Users can participate in the project by talking about it, providing
> feedback, and helping others.  This can be done at the ASF or
> elsewhere, and includes being active on the user mailing list,
> third-party support forms, blogs, and social media. Users who
> participate in this way automatically become contributors."
>
> Does this capture it better?
>
>> First paragraph: in the first sentence singular is used and in the
>> following sentence plural for committer. This is a bit confusing. But maybe
>> this is correct and my lack of knowledge of the English language.
>
> Fixed.
>
>> "... to all of public project infrastructure ..."
>>
>> should read:
>>
>> "... to all of public THE project infrastructure ..."
>
> Fixed.
>
>> 3.4. Project Management Committee
>>
>> -> maybe write "3.4. Project Management Committee (PMC)"
>
> Fixed.
>
>> "This includes:"
>> -> maybe add responsible to take action, if CoC violations are coming to
>> the PMC's attention
>
> This is included under "community management" for now. My intention
> here is that with the CoC we will make a patch to our bylaws to
> include specific rules about how infractions are handled.
>
>> " must be brought for the lists for the decision making process to take
>> place in the open. "
>>
>> -> I don't understand this completely ... can you explain this? Or should
>> it read:
>
> Changed to:
>
> "Any consensus that is achieved away from the lists (for example on
> IRC or in person) must be brought to the lists before anything is
> decided. We have a saying: if it's not on the lists, it didn't happen.
> We take this approach so that the most amount of people have a chance
> to participate."
>
>> "As long as you do your work in the open the community has plenty of
>> opportunity to object."
>>
>> comma after "open" and I think it should read "plenty of opportunities"?
>
> Fixed.
>
>> 4.2. Discussion
>>
>> "Voting is to be considered a failure mode of discussion."
>>
>> -> hm - are there really no situations where a vote is sth. someone wants
>> to have? As far as I understood, voting is the main way to get a clear
>> consensus.
>
> Yeah, I'm trying to get away from that. Voting is permission culture.
> JFDI should be our default mode. Having to take a vote is an
> indication that either this is either a) important, or b)
> controversial.
>
> Changed to:
>
> "Voting is a failure mode of discussion. That doesn't mean you should
> avoid it. It is a very powerful tool that should be used to terminate
> a seemingly interminable discussion. Knowing when to end a discussion
> and call a vote is one of the most useful skills a contributor can
> master."
>
> Also adjusted this text:
>
> "Occasionally people choose to vote with larger amounts to indicate
> extreme feelings, or in fractional amounts to convey strong reluctance
> without the full weight of -1 vote. For the purpose of tallying votes,
> values must be counted as one of the four values above."
>
>> 4.5. Approval Models
>>
>> "The ASF has a voting tool specifically designed to enable this process."
>>
>> -> we should link to a resource here
>
> Fixed.
>
>>
>> 5.1. Subject Tags
>>
>> -> should we add the tag [NEWS] into the list?
>
> Nah, I don't think so. I am not even sure what we use that for yet.
> But we can always patch the doc later.
>
> I have also made the following changes:
>
> To the PMC section, I added:
>
> "From a foundation perspective, the role of the PMC is oversight. The
> PMC must ensure that all legal issues are addressed, that procedure is
> followed, and that each and every release is the product of the
> community as a whole. That is key to our litigation protection
> mechanisms."
>
> "Secondly, the role of the PMC is to further the long term development
> and health of the community as a whole, and to ensure that balanced
> and diverse peer review and collaboration does happen. For this
> reason, one of the most basic tasks of the PMC is the recruitment and
> retainment of project contributors. As a volunteer organisation,
> volunteer time is our most precious resource. And we believe that the
> size, diversity, and health of the community is essential for the
> quality, stability, and robustness of both code and long term social
> structures."
>
> Also changed this bit:
>
> "PMC members are held to a much higher standard than regular community
> members. This includes strict hat wearing, equitable decision making,
> and exemplary conduct."
>
> Added these bits to the chair section:
>
> "It is not a technical leadership position, meaning the chair has no
> special say in ordinary project decisions. But we do think of it as a
> cultural leadership position. Accordingly, position on cultural issues
> is something to consider when electing a chair."
>
> "The chair is the eyes and ears of the board, and reports quarterly on
> developments within the project."
>
> "As an officer of the foundation, the chair has extraordinary powers,
> up-to and including the disbandment of the entire PMC. While the use
> of such powers if obviously not expected, if it could be justified to
> the board, the Chair has the power to enact any sort of change."
>
> Added this to the start of the roles and responsibilities section:
>
> "Your role at the ASF is one assigned to you personally, and is
> bestowed on you by your peers. It is not tied to your job or your
> current employer."
>
> "Hats are key concept at the ASF. You might have your employee hat and
> your personal hat, for instance. We expect committers (and PMC members
> especially) to know when to wear the appropriate hat. Failure to do so
> is a serious dereliction of duty."
>
> "Sometimes it is a good idea to tell people what hat you are wearing.
> For instance, the chair might start an informal email by stating they
> they are not wearing the chair hat, just to be clear about how the
> statements ought to be interpreted."
>
> "Committers and PMC members are never removed because of inactivity.
> Because of the way our decision making works, inactive committers and
> PMC members pose no problem to the project as long as we have enough
> active people for votes to pass. Committers and PMC members will only
> be removed if the position they hold is actively causing problems for
> the project. The chair is one exception to this. An inactive chair can
> be replaced by the PMC, as the chair has certain responsibilities that
> cannot be fulfilled by anyone else."
>
> In the contributor section, I shortened the description to:
>
> "A contributor is someone who is contributing to the project in some
> way. Contributions are not limited to code. Anything that helps to
> promote and improve the project or community counts."
>
> In favour of beefing out the committer section with some additional
> stuff about COPDOC (which I've borrowed from Apache Forrest). And I've
> created a stub contributor guide, as all the details I found myself
> adding about how to contribute started to feel like it should be
> something fluid and not encoded in our bylaws.
>
> https://cwiki.apache.org/confluence/display/COUCHDB/Contributor+Guide
>
> (Big WIP right now. But let's flesh this out as we go.)
>
> I also added:
>
> "Committers are expected to work cooperatively with other
> contributors, and to mentor new contributors if possible. Our
> committers make up the bulk of our active community, and as such, we
> rely on them to help us build and maintain that community."
>
> To lazy consensus, I added:
>
> "It also means that if you make a proposal to the list and nobody
> responds, that should be interpreted as implicit support for your
> idea, and not a lack of interest. This can be hard to get used to but
> is an important part of how we do things."
>
> Under approval models, I added this:
>
> "However, it is important to remember that all participants on a list
> get a vote. And you are encouraged to to vote, even if your vote is
> not binding. This is a good way to get involved in the project and
> helps to inform the decision-making process."
>
> --
> Noah Slater
> https://twitter.com/nslater



-- 
Noah Slater
https://twitter.com/nslater

Mime
View raw message