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 Sat, 03 May 2014 14:31:10 GMT
Modified the bit in the committer section to read:

"Committers are expected to work cooperatively and to have good people
skills. This is more important that any other sort of skill."

Reminder to folks: please review this. It is an exceptionally
important document, and I'd rather have commentary on it now, than
after we vote it in.

(And yep: I am aware of the irony of pressuring people to comment on a
document that says don't pressure people to comment. But it's
important that we bootstrap these expectations properly.)

If nobody comments in another three days, I will move this to a vote.
I have also decided that unless someone speaks up about it before
then, I'll start a thread after we vote this in asking what to do
about the chair. (i.e. Should we hold our first election, or do we
wait a year?)

On 30 April 2014 19:30, Noah Slater <nslater@apache.org> wrote:
> 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



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

Mime
View raw message