You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Noah Slater <ns...@apache.org> on 2014/04/28 21:53:50 UTC
[DISCUSS] Project by-laws
I'd like to propose that we vote in a set of project by-laws.
This document will define the specific roles in this community, as
well as the decision making procedures we use.
Right now, most of the rules are in my head. The reasons for this are
historical. Our mentors were absent, and we sort of figure out a
rudimentary set for ourselves. Later, when I joined the incubator, I
started to pick up lots of things we were missing.
Instead of me repeating things and being a single point of failure
here, I'd like to get everything down "on paper" and make it official.
I propose something very similar to, if not identical to, CloudStack's by-laws:
https://cloudstack.apache.org/bylaws.html
(Which I helped draft.)
--
Noah Slater
https://twitter.com/nslater
Re: [DISCUSS] Project by-laws
Posted by Benoit Chesneau <bc...@gmail.com>.
I saw the review thread, but inline answer look more appropriate. Anyway,
feel free to forward to it if needed.
On Mon, May 5, 2014 at 6:35 PM, Noah Slater <ns...@apache.org> wrote:
> On 5 May 2014 10:54, Benoit Chesneau <bc...@gmail.com> wrote:
> >
> > I am not sure to see the interest of these by-laws. They look redundant
> > to the the *practices* documented inside the apache foundation
> > documentation:
>
> The bylaws of the foundation are here:
>
> http://apache.org/foundation/bylaws.html
>
> They cover a completely different set of things at the foundation
> level. And say very little about how projects must function.
>
This is why I didn't link this one. I was specifically referring to the
by-laws defined on the wiki which are based on all the links I provided.
> The resources you linked to are, at best, recommendations. They are
> not binding. And in some cases they are contradictory. These represent
> past efforts to distil common practice across many different projects.
>
> What our bylaws are doing is saying that we have specifically chosen
> these interpretations, and that as a community we consider them
> binding.
>
I understood that. Linking for me is like binding, but like I said I have
no objections to another doc.
>
> > - In 4.1 : the sentence "Objecting too far down the road will cause
> > problems.", and in 4.2 "If lazy consensus is not possible, you can
> > move to a discussion" .
> >
> > The passage from a lazy consensus to a discussion is not clear. How it
> > is decided? Who is deciding it?
>
> Good catch.
>
> I have updated the wording to:
>
> "If lazy consensus fails (i.e. someone objects) you can start a
> discussion or you can abandon the proposal."
>
> Does this address your concerns?
>
We should grade the level of the proposal. Or at least give some examples.
There are case where discussing first is more appropriate and maybe we they
should be highlighted. While the default stay the lazy consensus.
> > - In 4.2, there is "Proposals should be explained clearly and come with
> > adequate justification. Disagreements should be constructive and
> > ideally come with alternative proposals. The goal is to reach a positive
> > outcome for the project, not convince others of your opinion." .
> >
> > Sorry but I don't understand that part. How can you expect that people
> > deeply attached to a project can't have an opinion on how it should
> > works or be seen by the others? Also what is the point of a discussion
> > if it's not to convince others that your idea is OK?
>
> Interesting comment.
>
> If you enter into a discussion with the objective of trying to
> convince the other person, and they do the same, all that will happen
> is that you argue with each other until one person runs out of energy.
>
> I am more interested in the sort of discussion where both people put
> aside preconceived notions, swap facts, debate points, and
> cooperatively work towards a greater shared understanding of what is
> being discussed.
>
> The goal then is not "winning" (i.e. convincing the other) but
> expanding knowledge. Even if that means that you have been convinced
> by the other person.
>
> Two people spend an hour arguing, and person A convinces person B of
> their opinion. Typically, we would say that person A has won.
>
> Try modelling that discussion so that knowledge and time spent are
> considered valuable, instead of pride. Both A and B spend time, but
> only B receives new knowledge. So who is the real winner?
>
> This is important for the project because the first type of discussion
> is not very valuable for us. The second is. That's why I put that the
> end goal should be to reach a positive outcome for the project.
>
>
I didn't speak about winning a discussion. A discussion is in my opinion
the way to find the point where people agree or disagree and took
appropriate actions based on it. This is not a question of energy.
Disagreement is part of a discussion and people should be ready to accept
it. I don't see any negativity in convincing someone. Conviction shows that
how deep the other is invested in the project. If all of the discussion
follow a gentlemen's agreement or CoC everything is fine.
But I agree that a discussion should not continue indefinitely and this is
why I proposed a solution commonly used in such case. I think it worth to
work on such solution, so a discussion can end gracefully.
> > Rather what is a bad opinion for the project (i.e. an expression of an
> > idea) there? How do you put the limit?
>
> It's not opinions that are bad. Instead: modes of discussion.
>
Maybe that could be made more clear?
> > - In 3.3 you added the notion of having "good people skills" for
> > commiters. How do you define "having good people skills"? This notion
> > completely depends on the culture of the people interacting in the
> > project. I propose to remove that sentence. It suffices to say that
> > all contributors of the projects obey to the Code Of Conduct and make
> > the Code Of Conduct enough generic.
>
> How do you define good technical skills? This stuff is always
> dependant on individual interpretation. My goal here is to make it
> explicit that as a project we value people skills over technical
> skills.
>
> I would rather have someone who is helpful and cooperative on our
> lists and who is only an average programmer, than someone who is
> unhelpful and uncooperative who is an excellent programmer.
>
> This is not usually the case for OSS projects. But I believe it is
> important. Which is why I want to bake it inout our bylaws.
>
My point is not technical skills vs people skills, but about using a notion
vaguely defined and not present in most parts of the world and
dictionaries. However nothing in the by-laws refer to the CoC. I think that
the CoC + Diversity texts suffice to cover this concept and rather than
using a vague notion, we should link to them.
>
> > - What about having the PMC members renewed each years by a vote of the
> > community? So they will be the choice of the community? PMC members
> > could be proposed during a period by the community and then a vote will
> > happen.
>
> What benefits would this bring?
>
By doing it the community control the board and you don't let members using
a private ml co-opting themselves. It doesn't have to be each years though.
>
> > - The same for a chair. We could make it renewable more often. For
> > example each 3 or 5 years.
>
> I've included this in the draft already. I am proposing that the chair
> is reelected every year.
>
ok.
Re: [DISCUSS] Project by-laws
Posted by Noah Slater <ns...@apache.org>.
On 5 May 2014 10:54, Benoit Chesneau <bc...@gmail.com> wrote:
>
> I am not sure to see the interest of these by-laws. They look redundant
> to the the *practices* documented inside the apache foundation
> documentation:
The bylaws of the foundation are here:
http://apache.org/foundation/bylaws.html
They cover a completely different set of things at the foundation
level. And say very little about how projects must function.
The resources you linked to are, at best, recommendations. They are
not binding. And in some cases they are contradictory. These represent
past efforts to distil common practice across many different projects.
What our bylaws are doing is saying that we have specifically chosen
these interpretations, and that as a community we consider them
binding.
> - In 4.1 : the sentence "Objecting too far down the road will cause
> problems.", and in 4.2 "If lazy consensus is not possible, you can
> move to a discussion" .
>
> The passage from a lazy consensus to a discussion is not clear. How it
> is decided? Who is deciding it?
Good catch.
I have updated the wording to:
"If lazy consensus fails (i.e. someone objects) you can start a
discussion or you can abandon the proposal."
Does this address your concerns?
> - In 4.2, there is "Proposals should be explained clearly and come with
> adequate justification. Disagreements should be constructive and
> ideally come with alternative proposals. The goal is to reach a positive
> outcome for the project, not convince others of your opinion." .
>
> Sorry but I don't understand that part. How can you expect that people
> deeply attached to a project can't have an opinion on how it should
> works or be seen by the others? Also what is the point of a discussion
> if it's not to convince others that your idea is OK?
Interesting comment.
If you enter into a discussion with the objective of trying to
convince the other person, and they do the same, all that will happen
is that you argue with each other until one person runs out of energy.
I am more interested in the sort of discussion where both people put
aside preconceived notions, swap facts, debate points, and
cooperatively work towards a greater shared understanding of what is
being discussed.
The goal then is not "winning" (i.e. convincing the other) but
expanding knowledge. Even if that means that you have been convinced
by the other person.
Two people spend an hour arguing, and person A convinces person B of
their opinion. Typically, we would say that person A has won.
Try modelling that discussion so that knowledge and time spent are
considered valuable, instead of pride. Both A and B spend time, but
only B receives new knowledge. So who is the real winner?
This is important for the project because the first type of discussion
is not very valuable for us. The second is. That's why I put that the
end goal should be to reach a positive outcome for the project.
> Rather what is a bad opinion for the project (i.e. an expression of an
> idea) there? How do you put the limit?
It's not opinions that are bad. Instead: modes of discussion.
> - In 3.3 you added the notion of having "good people skills" for
> commiters. How do you define "having good people skills"? This notion
> completely depends on the culture of the people interacting in the
> project. I propose to remove that sentence. It suffices to say that
> all contributors of the projects obey to the Code Of Conduct and make
> the Code Of Conduct enough generic.
How do you define good technical skills? This stuff is always
dependant on individual interpretation. My goal here is to make it
explicit that as a project we value people skills over technical
skills.
I would rather have someone who is helpful and cooperative on our
lists and who is only an average programmer, than someone who is
unhelpful and uncooperative who is an excellent programmer.
This is not usually the case for OSS projects. But I believe it is
important. Which is why I want to bake it inout our bylaws.
> - What about having the PMC members renewed each years by a vote of the
> community? So they will be the choice of the community? PMC members
> could be proposed during a period by the community and then a vote will
> happen.
What benefits would this bring?
> - The same for a chair. We could make it renewable more often. For
> example each 3 or 5 years.
I've included this in the draft already. I am proposing that the chair
is reelected every year.
Thanks,
--
Noah Slater
https://twitter.com/nslater
Re: [DISCUSS] Project by-laws
Posted by Benoit Chesneau <bc...@gmail.com>.
On Sat, May 3, 2014 at 4:31 PM, Noah Slater <ns...@apache.org> wrote:
> 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?)
>
>
I am not sure to see the interest of these by-laws. They look redundant
to the the *practices* documented inside the apache foundation
documentation:
https://www.apache.org/foundation/voting.html
http://community.apache.org/
https://www.apache.org/foundation/governance/pmcs.html
Why not simply link to them? Anyway I am not against repeating them in
another place. However the current form looks a little too much
procedural and complicated (looks like the by-laws inside some
administrative places there), something can be done with it.
I have a couple of observations and questions on these by-laws that
hopefully can be addressed before any vote:
- In 4.1 : the sentence "Objecting too far down the road will cause
problems.", and in 4.2 "If lazy consensus is not possible, you can
move to a discussion" .
The passage from a lazy consensus to a discussion is not clear. How it
is decided? Who is deciding it?
I can see the intent here: having long discussion that goes nowhere or
are blocking the project. In some others organisations, there are some
practice that could limit the effects of profound disagreements (which
are quite normal and expected): The place to discussion happen in a
very limited time and have a deadline. If at the end of the deadline no
consensus emerge, someone (generally a person chosen at the beginning of
the discussion) decide to either:
- propose a vote
- continue the discussion on some points where some consensus can be
found
- postpone the idea for later
- ...
I think it would be good to add such procedure to the discussion
handling, so any conflict can be handled gracefully with little place to
the frustration.
Of course we shouldn't have always a discussion,especially when the lazy
consensus is needed for code. I think we should distinct some cases. Or
describe how/when a lazy consensus should be the default, and other
cases where the discussion should happen before anything else so the the
conflict could be handled gracefully.
- In 4.2, there is "Proposals should be explained clearly and come with
adequate justification. Disagreements should be constructive and
ideally come with alternative proposals. The goal is to reach a positive
outcome for the project, not convince others of your opinion." .
Sorry but I don't understand that part. How can you expect that people
deeply attached to a project can't have an opinion on how it should
works or be seen by the others? Also what is the point of a discussion
if it's not to convince others that your idea is OK?
Rather what is a bad opinion for the project (i.e. an expression of an
idea) there? How do you put the limit?
I think we should remove that part is can trigger to more conflict that
it try to solves or make it more specific.
- In 3.3 you added the notion of having "good people skills" for
commiters. How do you define "having good people skills"? This notion
completely depends on the culture of the people interacting in the
project. I propose to remove that sentence. It suffices to say that
all contributors of the projects obey to the Code Of Conduct and make
the Code Of Conduct enough generic.
Also If we are going to the path of defining by-laws, I think we should
take this opportunity to innovate a little and make the project reflects
more the community:
- What about having the PMC members renewed each years by a vote of the
community? So they will be the choice of the community? PMC members
could be proposed during a period by the community and then a vote will
happen.
- The same for a chair. We could make it renewable more often. For
example each 3 or 5 years.
What people think about it?
- benoit
Re: [DISCUSS] Project by-laws
Posted by Noah Slater <ns...@apache.org>.
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 <ns...@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 <ns...@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 <an...@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
Re: [DISCUSS] Project by-laws
Posted by Noah Slater <ns...@apache.org>.
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 <ns...@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 <an...@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
Re: [DISCUSS] Project by-laws
Posted by Noah Slater <ns...@apache.org>.
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 <an...@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
Re: [DISCUSS] Project by-laws
Posted by Andy Wenk <an...@nms.de>.
Hi Noah,
awesome! thanks a lot. Here are some comments:
3.1. Users
"Users can contribute to Apache projects by providing feedback"
-> why not explicitly writing "... can contribute to the Apache CouchDB
project ..." ?
"Users can also participate in the project by being involved the community,
either at " ...
-> there is a word missing I think: " by being involved IN the community"?
"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."
3.3. Committers
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.
"... to all of public project infrastructure ..."
should read:
"... to all of public THE project infrastructure ..."
3.4. Project Management Committee
-> maybe write "3.4. Project Management Committee (PMC)"
"This includes:"
-> maybe add responsible to take action, if CoC violations are coming to
the PMC's attention
4. Decision Making
second paragraph:
" 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:
" must be brought TO the lists for the decision making process to take
place in the open. " ?
4.1. Lazy Consensus
"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"?
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.
4.5. Approval Models
"The ASF has a voting tool specifically designed to enable this process."
-> we should link to a resource here
5.1. Subject Tags
-> should we add the tag [NEWS] into the list?
That's all so far from my side after the first read ...
Again - thanks for this!
Cheers
Andy
On 29 April 2014 21:50, Noah Slater <ns...@apache.org> wrote:
> Okay folks. I've prepared a first draft of our bylaws. Concrit very
> much appreciated.
>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=40511017
>
> On 28 April 2014 23:48, Joan Touzet <jo...@atypical.net> wrote:
> > My line of thinking was along the lines of what Ellis and Stroustrup did
> in The Annotated C++ Language Reference Manual[1]. It often helps to have a
> human being explain what some things mean through the use of examples or
> extra text. A crisp legal-ish statement of the rule followed by some
> explanatory text would be most helpful, and friendlier for new people to
> get their heads around.
> >
> > -Joan
> >
> > [1] http://www.stroustrup.com/arm.html
> >
> > ----- Original Message -----
> > From: "Robert Samuel Newson" <rn...@apache.org>
> > To: dev@couchdb.apache.org
> > Cc: andy@nms.de
> > Sent: Monday, April 28, 2014 5:13:06 PM
> > Subject: Re: [DISCUSS] Project by-laws
> >
> >
> > It does seem justified though, it’s obviously to make it easy to refer
> unambiguously to a particular item, that doesn’t mean to say we can’t
> render it better than this. I would rather not have a document that states
> everything twice if we can avoid it.
> >
> > B.
> >
> > On 28 Apr 2014, at 22:09, Joan Touzet <jo...@atypical.net> wrote:
> >
> >> I have form issues with these bylaws, primarily that they are
> intimidating
> >> in their layout and structure. Legal-style #.#.#.# can be especially
> hard
> >> to read and encodes a viewpoint that is grounded in the American legal
> >> system. The HTML formatting in this specific example is also difficult
> >> to read
> >>
> >> That said, perhaps it is appropriate that our bylaws be this way at
> least
> >> in part. Would anyone object to a plain-language summary up top in
> addition
> >> to the legal #.#.#.# commentary?
> >>
> >> -Joan
> >
>
>
>
> --
> Noah Slater
> https://twitter.com/nslater
>
--
Andy Wenk
Hamburg - Germany
RockIt!
http://www.couchdb-buch.de
http://www.pg-praxisbuch.de
GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588
https://people.apache.org/keys/committer/andywenk.asc
Re: [DISCUSS] Project by-laws
Posted by Noah Slater <ns...@apache.org>.
Okay folks. I've prepared a first draft of our bylaws. Concrit very
much appreciated.
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=40511017
On 28 April 2014 23:48, Joan Touzet <jo...@atypical.net> wrote:
> My line of thinking was along the lines of what Ellis and Stroustrup did in The Annotated C++ Language Reference Manual[1]. It often helps to have a human being explain what some things mean through the use of examples or extra text. A crisp legal-ish statement of the rule followed by some explanatory text would be most helpful, and friendlier for new people to get their heads around.
>
> -Joan
>
> [1] http://www.stroustrup.com/arm.html
>
> ----- Original Message -----
> From: "Robert Samuel Newson" <rn...@apache.org>
> To: dev@couchdb.apache.org
> Cc: andy@nms.de
> Sent: Monday, April 28, 2014 5:13:06 PM
> Subject: Re: [DISCUSS] Project by-laws
>
>
> It does seem justified though, it’s obviously to make it easy to refer unambiguously to a particular item, that doesn’t mean to say we can’t render it better than this. I would rather not have a document that states everything twice if we can avoid it.
>
> B.
>
> On 28 Apr 2014, at 22:09, Joan Touzet <jo...@atypical.net> wrote:
>
>> I have form issues with these bylaws, primarily that they are intimidating
>> in their layout and structure. Legal-style #.#.#.# can be especially hard
>> to read and encodes a viewpoint that is grounded in the American legal
>> system. The HTML formatting in this specific example is also difficult
>> to read
>>
>> That said, perhaps it is appropriate that our bylaws be this way at least
>> in part. Would anyone object to a plain-language summary up top in addition
>> to the legal #.#.#.# commentary?
>>
>> -Joan
>
--
Noah Slater
https://twitter.com/nslater
Re: [DISCUSS] Project by-laws
Posted by Joan Touzet <jo...@atypical.net>.
My line of thinking was along the lines of what Ellis and Stroustrup did in The Annotated C++ Language Reference Manual[1]. It often helps to have a human being explain what some things mean through the use of examples or extra text. A crisp legal-ish statement of the rule followed by some explanatory text would be most helpful, and friendlier for new people to get their heads around.
-Joan
[1] http://www.stroustrup.com/arm.html
----- Original Message -----
From: "Robert Samuel Newson" <rn...@apache.org>
To: dev@couchdb.apache.org
Cc: andy@nms.de
Sent: Monday, April 28, 2014 5:13:06 PM
Subject: Re: [DISCUSS] Project by-laws
It does seem justified though, it’s obviously to make it easy to refer unambiguously to a particular item, that doesn’t mean to say we can’t render it better than this. I would rather not have a document that states everything twice if we can avoid it.
B.
On 28 Apr 2014, at 22:09, Joan Touzet <jo...@atypical.net> wrote:
> I have form issues with these bylaws, primarily that they are intimidating
> in their layout and structure. Legal-style #.#.#.# can be especially hard
> to read and encodes a viewpoint that is grounded in the American legal
> system. The HTML formatting in this specific example is also difficult
> to read
>
> That said, perhaps it is appropriate that our bylaws be this way at least
> in part. Would anyone object to a plain-language summary up top in addition
> to the legal #.#.#.# commentary?
>
> -Joan
Re: [DISCUSS] Project by-laws
Posted by Robert Samuel Newson <rn...@apache.org>.
It does seem justified though, it’s obviously to make it easy to refer unambiguously to a particular item, that doesn’t mean to say we can’t render it better than this. I would rather not have a document that states everything twice if we can avoid it.
B.
On 28 Apr 2014, at 22:09, Joan Touzet <jo...@atypical.net> wrote:
> I have form issues with these bylaws, primarily that they are intimidating
> in their layout and structure. Legal-style #.#.#.# can be especially hard
> to read and encodes a viewpoint that is grounded in the American legal
> system. The HTML formatting in this specific example is also difficult
> to read
>
> That said, perhaps it is appropriate that our bylaws be this way at least
> in part. Would anyone object to a plain-language summary up top in addition
> to the legal #.#.#.# commentary?
>
> -Joan
Re: [DISCUSS] Project by-laws
Posted by Joan Touzet <jo...@atypical.net>.
I have form issues with these bylaws, primarily that they are intimidating
in their layout and structure. Legal-style #.#.#.# can be especially hard
to read and encodes a viewpoint that is grounded in the American legal
system. The HTML formatting in this specific example is also difficult
to read
That said, perhaps it is appropriate that our bylaws be this way at least
in part. Would anyone object to a plain-language summary up top in addition
to the legal #.#.#.# commentary?
-Joan
Re: [DISCUSS] Project by-laws
Posted by Andy Wenk <an...@nms.de>.
Noah, thanks for putting this together and the approach. I really like the
Cloudstack by-laws. I think we could just copy them with some minor
changes. Here are some questions or comments (on
https://cloudstack.apache.org/bylaws.html):
2.4.1.2. I am not sure if the PMC has to approve the releases. In our case
it is a vote on dev@.
2.4.6. As for today, we do not have a chair rotation but iirc, we have
already spoken about this as a possibility
3.1.2.4 I was not aware that a -1 needs an explanation
3.2. Approvals - maybe we have to adjust the numbers. 3 is kinda low I
think compared to how many PMC members and committers we have
3.3. Vetoes - this point is fairly new to me and I would love to see areal
example
3.4.1. Technical Decisions - it first states that technical decisions
should made by voting but later it is described how it should be done when
a vote was started. It's a bit contrary. In 3.4.2 there is a reason
described for the need of a vote if there is a dispute of finding consensus.
Then I am not sure if we "live" this already but I like it "Any user,
contributor, committer, or PMC member can initiate a technical decision
making process.".
3.4.4. Product Release - if we follow our now active process, this has to
be changed imo.
3.4.5. Adoption of New Codebase this would be new for CouchDB but is maybe
a good idea
I am not sure if the CoC acceptance has to mentioned in this paper also.
Cheers
Andy
On 28 April 2014 21:53, Noah Slater <ns...@apache.org> wrote:
> I'd like to propose that we vote in a set of project by-laws.
>
> This document will define the specific roles in this community, as
> well as the decision making procedures we use.
>
> Right now, most of the rules are in my head. The reasons for this are
> historical. Our mentors were absent, and we sort of figure out a
> rudimentary set for ourselves. Later, when I joined the incubator, I
> started to pick up lots of things we were missing.
>
> Instead of me repeating things and being a single point of failure
> here, I'd like to get everything down "on paper" and make it official.
>
> I propose something very similar to, if not identical to, CloudStack's
> by-laws:
>
> https://cloudstack.apache.org/bylaws.html
>
> (Which I helped draft.)
>
> --
> Noah Slater
> https://twitter.com/nslater
>
--
Andy Wenk
Hamburg - Germany
RockIt!
http://www.couchdb-buch.de
http://www.pg-praxisbuch.de
GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588
https://people.apache.org/keys/committer/andywenk.asc