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/05/07 21:07:57 UTC
[REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws)
Hello folks,
Please review our propose bylaws:
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=40511017
I'd like a few more eyeballs on this before I move to a vote.
Thanks,
On 5 May 2014 18:35, 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.
>
> 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
--
Noah Slater
https://twitter.com/nslater
Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws)
Posted by Andy Wenk <an...@nms.de>.
Hi,
I read the bylaws again.
3. Roles and Responsibilities -> last paragraph "Committers and PMC
members are never removed": this content feels a bit out of context. Maybe
move it to 3.3 and 3.5
3.3 Committers -> third paragraph "... it means you are committed to the
project ..." is double because it was already stated at the beginning of
the section.
The rest looks very good:)
Cheers
Andy
On 7 May 2014 21:07, Noah Slater <ns...@apache.org> wrote:
> Hello folks,
>
> Please review our propose bylaws:
>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=40511017
>
> I'd like a few more eyeballs on this before I move to a vote.
>
> Thanks,
>
>
> On 5 May 2014 18:35, 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.
> >
> > 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
>
>
>
> --
> 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: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws)
Posted by Klaus Trainer <kl...@posteo.de>.
Looks good to me.
On 05/07/2014 09:07 PM, Noah Slater wrote:
> Hello folks,
>
> Please review our propose bylaws:
>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=40511017
>
> I'd like a few more eyeballs on this before I move to a vote.
>
> Thanks,
>
>
> On 5 May 2014 18:35, 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.
>>
>> 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: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws)
Posted by Robert Kowalski <ro...@kowalski.gd>.
+1
As a fairly new committer I learned some from reading it and realized that
I have some "unknown unknowns".
Maybe we can add a line that there is a meeting every wednesday on
freenode, because I have the feeling that it is an integral part on how the
project is organizing itself.
2014-05-11 17:35 GMT+02:00 Noah Slater <ns...@apache.org>:
> Community,
>
> Please do take the time to review this document. It's not that long,
> or that complex. An online reading time calculator said it's about 14
> minutes long. Your input at this stage would be very beneficial for
> the project. (Anyone!)
>
>
>
> On 7 May 2014 21:07, Noah Slater <ns...@apache.org> wrote:
> > Hello folks,
> >
> > Please review our propose bylaws:
> >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=40511017
> >
> > I'd like a few more eyeballs on this before I move to a vote.
> >
> > Thanks,
> >
> >
> > On 5 May 2014 18:35, 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.
> >>
> >> 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
> >
> >
> >
> > --
> > Noah Slater
> > https://twitter.com/nslater
>
>
>
> --
> Noah Slater
> https://twitter.com/nslater
>
Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws)
Posted by Jason Smith <ja...@gmail.com>.
Noah, in section 3.4, Vetos:
> Any change to the source code that we distribute in our official releases
may be vetoed by casting a -1 vote on it.
Is that a -1 *binding* vote? Only committers can veto commits, right?
> The validity of a veto can be put to a vote.
Which kind of vote is this? It can't be majority. Majority must have no
binding -1 votes (thus a majority vote is in a sense something that can be
easily vetoed, like a release candidate). So the veto's validity itself can
be easily vetoed. In other words, any individual can veto a veto.
I don't see how it can be lazy majority or even lazy 2/3. That means that a
sizeable group of people can invalidate a veto. So...that's not exactly a
veto.
The only vetos I can imagine happening are for trivial stuff where the
committer cannot even muster 3 binding +1 votes. For anything major though,
wouldn't a "veto" quickly become a vote for a popularity contest?
Given the history of this project, I am actually comfortable with vetos
being rare and difficult. However my point today is: I'm not clear what
laws this section is actually making.
Thanks!
P.S. This is my first new wiki experience, and it is fantastic!
On Thu, May 15, 2014 at 10:49 PM, Noah Slater <ns...@apache.org> wrote:
> Jan/Bob, can I get your review of this too please?
>
> On 13 May 2014 23:23, Sebastian Rothbucher
> <se...@googlemail.com> wrote:
> > +1
> > As it is
> >
> > Von meinem iPhone gesendet
> >
> >> Am 11.05.2014 um 17:35 schrieb Noah Slater <ns...@apache.org>:
> >>
> >> Community,
> >>
> >> Please do take the time to review this document. It's not that long,
> >> or that complex. An online reading time calculator said it's about 14
> >> minutes long. Your input at this stage would be very beneficial for
> >> the project. (Anyone!)
> >>
> >>
> >>
> >>> On 7 May 2014 21:07, Noah Slater <ns...@apache.org> wrote:
> >>> Hello folks,
> >>>
> >>> Please review our propose bylaws:
> >>>
> >>>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=40511017
> >>>
> >>> I'd like a few more eyeballs on this before I move to a vote.
> >>>
> >>> Thanks,
> >>>
> >>>
> >>>> On 5 May 2014 18:35, 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.
> >>>>
> >>>> 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
> >>>
> >>>
> >>>
> >>> --
> >>> Noah Slater
> >>> https://twitter.com/nslater
> >>
> >>
> >>
> >> --
> >> Noah Slater
> >> https://twitter.com/nslater
>
>
>
> --
> Noah Slater
> https://twitter.com/nslater
>
Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws)
Posted by Noah Slater <ns...@apache.org>.
I'll have a think on this and come up with some new proposed text to
review. Thanks!
On 26 May 2014 23:34, Jan Lehnardt <ja...@apache.org> wrote:
>
> On 26 May 2014, at 23:17 , Noah Slater <ns...@apache.org> wrote:
>
>> Note that the doc I link to does explicitly say we welcome
>> contributions to design. It's listed under the Project section, as
>> branding and design. Again, the problem is that there are simply too
>> many ways to contribute.
>>
>> On 26 May 2014 23:01, Joan Touzet <jo...@lrtw.org> wrote:
>>
>>> I hadn't heard the acronym previously, and a quick web search doesn't turn up any other uses of it. Still, the list of "what we value," just like the list of "we don't discriminate against these things" should be ever-expanding. I am not opposed to spinning this lit out and instead saying something like:
>>
>> Then let's drop it and come up with something very generic about how
>> we value any sort of positive contribution.
>>
>>> "We value contributions that include, but are not limited to: community, project, documentation, code, visual design, internationalisation, ..." and then link to the contributor guide as a full resource.
>>
>> The problem here is that the list is too long.
>>
>> Here's an example:
>>
>> We value contributions, such as moderating discussions, recruiting new
>> contributors, organising events, providing user support (via the
>> mailing list or third-party support forums), helping with ticket
>> triage, product management, preparing or testing releases, quality
>> assurance, marketing, promotion, branding, design, documentation,
>> translation, writing cookbooks and tutorials, blogging, helping with
>> the wiki, giving talks, doing screencasts, interviewing people,
>> running meetings, contributing code, performing code reviews, helping
>> with tests, helping with continuous integration, working on CouchDB
>> tools and libraries, and packaging for third-party distros.
>>
>> This is too much. Heh. And it might look like I'm being pedantic, but
>> I actually spent an hour or more reformatting a list like this, trying
>> to group it and make it manageable, and in the end I just gave up.
>>
>> The problem is, we're basically listing every task and every job that
>> might conceivably be involved in shipping a product. Which is a very
>> long list and I have surely missed things. Like, uh, community
>> management!
>>
>> And I don't know how to cut it down without just shortening it to the
>> COPDOC list. I.e. "We value contributions to the community, project,
>> documentation, and code." And then we just punt this ever-increasing
>> list of stuff to a new doc, as I have done.
>>
>> (I'm not attached to the COPDOC acronym itself. I just thought it was
>> a neat concept.)
>
> Nothing wrong with the meta-list of areas and a link to the specific
> things, I’d just say that design is top-level important and worth
> mentioning in the bylaws :)
>
>
--
Noah Slater
https://twitter.com/nslater
Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws)
Posted by Jan Lehnardt <ja...@apache.org>.
On 26 May 2014, at 23:17 , Noah Slater <ns...@apache.org> wrote:
> Note that the doc I link to does explicitly say we welcome
> contributions to design. It's listed under the Project section, as
> branding and design. Again, the problem is that there are simply too
> many ways to contribute.
>
> On 26 May 2014 23:01, Joan Touzet <jo...@lrtw.org> wrote:
>
>> I hadn't heard the acronym previously, and a quick web search doesn't turn up any other uses of it. Still, the list of "what we value," just like the list of "we don't discriminate against these things" should be ever-expanding. I am not opposed to spinning this lit out and instead saying something like:
>
> Then let's drop it and come up with something very generic about how
> we value any sort of positive contribution.
>
>> "We value contributions that include, but are not limited to: community, project, documentation, code, visual design, internationalisation, ..." and then link to the contributor guide as a full resource.
>
> The problem here is that the list is too long.
>
> Here's an example:
>
> We value contributions, such as moderating discussions, recruiting new
> contributors, organising events, providing user support (via the
> mailing list or third-party support forums), helping with ticket
> triage, product management, preparing or testing releases, quality
> assurance, marketing, promotion, branding, design, documentation,
> translation, writing cookbooks and tutorials, blogging, helping with
> the wiki, giving talks, doing screencasts, interviewing people,
> running meetings, contributing code, performing code reviews, helping
> with tests, helping with continuous integration, working on CouchDB
> tools and libraries, and packaging for third-party distros.
>
> This is too much. Heh. And it might look like I'm being pedantic, but
> I actually spent an hour or more reformatting a list like this, trying
> to group it and make it manageable, and in the end I just gave up.
>
> The problem is, we're basically listing every task and every job that
> might conceivably be involved in shipping a product. Which is a very
> long list and I have surely missed things. Like, uh, community
> management!
>
> And I don't know how to cut it down without just shortening it to the
> COPDOC list. I.e. "We value contributions to the community, project,
> documentation, and code." And then we just punt this ever-increasing
> list of stuff to a new doc, as I have done.
>
> (I'm not attached to the COPDOC acronym itself. I just thought it was
> a neat concept.)
Nothing wrong with the meta-list of areas and a link to the specific
things, I’d just say that design is top-level important and worth
mentioning in the bylaws :)
Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws)
Posted by Noah Slater <ns...@apache.org>.
Note that the doc I link to does explicitly say we welcome
contributions to design. It's listed under the Project section, as
branding and design. Again, the problem is that there are simply too
many ways to contribute.
On 26 May 2014 23:01, Joan Touzet <jo...@lrtw.org> wrote:
> I hadn't heard the acronym previously, and a quick web search doesn't turn up any other uses of it. Still, the list of "what we value," just like the list of "we don't discriminate against these things" should be ever-expanding. I am not opposed to spinning this lit out and instead saying something like:
Then let's drop it and come up with something very generic about how
we value any sort of positive contribution.
> "We value contributions that include, but are not limited to: community, project, documentation, code, visual design, internationalisation, ..." and then link to the contributor guide as a full resource.
The problem here is that the list is too long.
Here's an example:
We value contributions, such as moderating discussions, recruiting new
contributors, organising events, providing user support (via the
mailing list or third-party support forums), helping with ticket
triage, product management, preparing or testing releases, quality
assurance, marketing, promotion, branding, design, documentation,
translation, writing cookbooks and tutorials, blogging, helping with
the wiki, giving talks, doing screencasts, interviewing people,
running meetings, contributing code, performing code reviews, helping
with tests, helping with continuous integration, working on CouchDB
tools and libraries, and packaging for third-party distros.
This is too much. Heh. And it might look like I'm being pedantic, but
I actually spent an hour or more reformatting a list like this, trying
to group it and make it manageable, and in the end I just gave up.
The problem is, we're basically listing every task and every job that
might conceivably be involved in shipping a product. Which is a very
long list and I have surely missed things. Like, uh, community
management!
And I don't know how to cut it down without just shortening it to the
COPDOC list. I.e. "We value contributions to the community, project,
documentation, and code." And then we just punt this ever-increasing
list of stuff to a new doc, as I have done.
(I'm not attached to the COPDOC acronym itself. I just thought it was
a neat concept.)
--
Noah Slater
https://twitter.com/nslater
Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project
bylaws)
Posted by Dave Cottlehuber <dc...@jsonified.com>.
Do you think a RACI table would be good at the end of the textual
descriptions of the roles?
I think it would be overkill, the current text is solid enough already.
dch
Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws)
Posted by Noah Slater <ns...@apache.org>.
Do you think a RACI table would be good at the end of the textual
descriptions of the roles?
On 27 May 2014 19:52, Joan Touzet <jo...@lrtw.org> wrote:
> A good template for specifying delgation of duties is RACI:
>
> Responsible
> Accountable
> Consulted
> Informed
>
> Often a RACI Matrix is made up, showing for each activity, the set of roles involved and the expected level of involvement (R A C I).
>
> Examples:
>
> http://racichart.org/
> https://en.wikipedia.org/wiki/Responsibility_assignment_matrix
>
> -Joan
>
> ----- Original Message -----
> From: "Dave Cottlehuber" <dc...@jsonified.com>
> To: dev@couchdb.apache.org
> Sent: Tuesday, May 27, 2014 4:38:15 AM
> Subject: Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws)
>
>> On 20 May 2014 23:43, Jan Lehnardt <ja...@apache.org> wrote:
>>> 2.4. I’d say handling security issues are the responsibility of the committers in a private forum. That bit should be moved to 2.3. At least that’s what we’ve been doing in the past, would be good to reflect that.
>>
>> Ultimately, it falls on the PMC to make sure this is addressed, with
>> non-required help from the committers. I propose to leave it as it is,
>> unless you have an edit for the committers section to mention that
>> they can be involved in security response procedures.
>
> Understood, I find it confusing that we define things here and then act differently, and I fear it might confuse future (and existing) contributors.
>
> Correct me if I am wrong, but I am seeing the bylaws as a specialised subclass of the rules we get from the ASF (and a formalisations of the various guidelines from the ASF as we deem them fit for this project). As per the ASF, the PMC is responsible for making sure security stuff is taken care of (same for releases), but in our bylaws, we can specify that the responsibility actually lies with the committers. Even though from an ASF perspective the PMC is responsible, the PMC delegates this one level down.
>
> A good way of describing this is to use accountability and responsibility.
>
> e.g. my children are responsible for tidying their rooms, but I remain accountable.
>
> You can’t delegate accountability, only responsibility. I think this is what you want.
>
> Also +1 to you & Joan’s comments wrt COPDOC. Let’s make this as acronym-free as practical, and a reasonably short list. Rule of thumb is what would happen if this list were wrong, too short etc? Not catastrophic.
>
> A+
> Dave
--
Noah Slater
https://twitter.com/nslater
Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project
bylaws)
Posted by Joan Touzet <jo...@lrtw.org>.
A good template for specifying delgation of duties is RACI:
Responsible
Accountable
Consulted
Informed
Often a RACI Matrix is made up, showing for each activity, the set of roles involved and the expected level of involvement (R A C I).
Examples:
http://racichart.org/
https://en.wikipedia.org/wiki/Responsibility_assignment_matrix
-Joan
----- Original Message -----
From: "Dave Cottlehuber" <dc...@jsonified.com>
To: dev@couchdb.apache.org
Sent: Tuesday, May 27, 2014 4:38:15 AM
Subject: Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws)
> On 20 May 2014 23:43, Jan Lehnardt <ja...@apache.org> wrote:
>> 2.4. I’d say handling security issues are the responsibility of the committers in a private forum. That bit should be moved to 2.3. At least that’s what we’ve been doing in the past, would be good to reflect that.
>
> Ultimately, it falls on the PMC to make sure this is addressed, with
> non-required help from the committers. I propose to leave it as it is,
> unless you have an edit for the committers section to mention that
> they can be involved in security response procedures.
Understood, I find it confusing that we define things here and then act differently, and I fear it might confuse future (and existing) contributors.
Correct me if I am wrong, but I am seeing the bylaws as a specialised subclass of the rules we get from the ASF (and a formalisations of the various guidelines from the ASF as we deem them fit for this project). As per the ASF, the PMC is responsible for making sure security stuff is taken care of (same for releases), but in our bylaws, we can specify that the responsibility actually lies with the committers. Even though from an ASF perspective the PMC is responsible, the PMC delegates this one level down.
A good way of describing this is to use accountability and responsibility.
e.g. my children are responsible for tidying their rooms, but I remain accountable.
You can’t delegate accountability, only responsibility. I think this is what you want.
Also +1 to you & Joan’s comments wrt COPDOC. Let’s make this as acronym-free as practical, and a reasonably short list. Rule of thumb is what would happen if this list were wrong, too short etc? Not catastrophic.
A+
Dave
Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project
bylaws)
Posted by Dave Cottlehuber <dc...@jsonified.com>.
> On 20 May 2014 23:43, Jan Lehnardt <ja...@apache.org> wrote:
>> 2.4. I’d say handling security issues are the responsibility of the committers in a private forum. That bit should be moved to 2.3. At least that’s what we’ve been doing in the past, would be good to reflect that.
>
> Ultimately, it falls on the PMC to make sure this is addressed, with
> non-required help from the committers. I propose to leave it as it is,
> unless you have an edit for the committers section to mention that
> they can be involved in security response procedures.
Understood, I find it confusing that we define things here and then act differently, and I fear it might confuse future (and existing) contributors.
Correct me if I am wrong, but I am seeing the bylaws as a specialised subclass of the rules we get from the ASF (and a formalisations of the various guidelines from the ASF as we deem them fit for this project). As per the ASF, the PMC is responsible for making sure security stuff is taken care of (same for releases), but in our bylaws, we can specify that the responsibility actually lies with the committers. Even though from an ASF perspective the PMC is responsible, the PMC delegates this one level down.
A good way of describing this is to use accountability and responsibility.
e.g. my children are responsible for tidying their rooms, but I remain accountable.
You can’t delegate accountability, only responsibility. I think this is what you want.
Also +1 to you & Joan’s comments wrt COPDOC. Let’s make this as acronym-free as practical, and a reasonably short list. Rule of thumb is what would happen if this list were wrong, too short etc? Not catastrophic.
A+
Dave
Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project
bylaws)
Posted by Joan Touzet <jo...@lrtw.org>.
On the "COPDOC" thing:
> > On 20 May 2014 23:43, Jan Lehnardt <ja...@apache.org> wrote:
> >> 2.3. would specifically invite designers, both visual and user interface designers. Not sure we need a name like COPDOC.
> >
> > I started down this path of listing things we're interested in, but it
> > got too long, so I spun it off into a new doc.
> >
> > https://cwiki.apache.org/confluence/display/COUCHDB/Contributor+Guide
>
> That’s good, but still lacking e.g. designers. The bylaws should include a summary, and/or a pointer to the
> Contributor Guide.
> > The COPDOC stuff has prior art:
> >
> > https://forrest.apache.org/committed.html
>
> I’m hearing this for the first time, I’d be afraid to sound overly complicated for no good reason and it
> doesn’t include some groups of folks that we (should) care about. “People that we care about contributing to
> CouchDB” doesn’t need an acronym to make any clearer what we mean.
I hadn't heard the acronym previously, and a quick web search doesn't turn up any other uses of it. Still, the list of "what we value," just like the list of "we don't discriminate against these things" should be ever-expanding. I am not opposed to spinning this lit out and instead saying something like:
"We value contributions that include, but are not limited to: community, project, documentation, code, visual design, internationalisation, ..." and then link to the contributor guide as a full resource.
My rule of thumb for something like bylaws is: if we have to change the bylaws ever, we made a mistake. That should happen every year or two *max*. If something is liable to change often, spin it out into another policy doc and go from there.
Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws)
Posted by Jan Lehnardt <ja...@apache.org>.
On 21 May 2014, at 21:47 , Noah Slater <ns...@apache.org> wrote:
> On 11 May 2014 02:18, Andy Wenk <an...@nms.de> wrote:
>> 3. Roles and Responsibilities -> last paragraph "Committers and PMC
>> members are never removed": this content feels a bit out of context. Maybe
>> move it to 3.3 and 3.5
>
> Removed the bit at the end and modified p2 and p3 to read:
>
>> Your role is assigned to you personally, and is bestowed on you by your peers in recognition of your past contributions to the project and your position of trust within the community. It is not tied to your job, your current employer, or your current activity level. We are interested in you as an individual and we understand that your interactions with the project may change over time.
>>
>> Roles are never rescinded because of inactivity, unless that inactivity is causing a problem for the project. Fortunately, our decision making process means that inactivity is very rarely a problem. Roles will be rescinded if the PMC believes the individual is no longer able to responsibly discharge the duty of the role.
>
> On 11 May 2014 02:18, Andy Wenk <an...@nms.de> wrote:
>> 3.3 Committers -> third paragraph "... it means you are committed to the
>> project ..." is double because it was already stated at the beginning of
>> the section.
>
> Replaced:
>
>> Being a committer does not mean you commit code, it means you are committed to the project.
>
> With:
>
>> Being a committer does not mean you have to commit code.
>
> On 11 May 2014 20:14, Robert Kowalski <ro...@kowalski.gd> wrote:
>> As a fairly new committer I learned some from reading it and realized that
>> I have some "unknown unknowns".
>
> Can you elaborate?
>
> On 11 May 2014 20:14, Robert Kowalski <ro...@kowalski.gd> wrote:
>> Maybe we can add a line that there is a meeting every wednesday on
>> freenode, because I have the feeling that it is an integral part on how the
>> project is organizing itself.
>
> I am not sure the bylaws are the correct place for this. But I could
> be convinced if someone has a compelling argument for it.
>
> On 12 May 2014 08:40, Joan Touzet <wo...@apache.org> wrote:
>> - Link the text "the Apache Way" instead of "a set of common principles."
>> - "community should be *A* fun and rewarding place to be for everyone involved."
>
> Fixed.
>
> On 12 May 2014 08:40, Joan Touzet <wo...@apache.org> wrote:
>> - Is there an ASF link for their definition of "hat?" This might be confusing to a non-English speaker. Even a glossary link - to explain that wearing a hat means playing a role, or acting within the expectations of that role.
>> - Possibly move the "hats" discussion to after you define all the different roles, I'm not sure.
>
> Replaced this para with:
>
>> We understand that you have many roles in life. We use a hat metaphor to talk about these roles. For instance, you might have your work hat as well as several ASF hats. 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 this is a serious dereliction of duty.
>
> On 12 May 2014 08:40, Joan Touzet <wo...@apache.org> wrote:
>> - For the PMC Chair term, we should clarify whether consecutive means "more than 2 in a row" (unlike the US President) and whether that is calendar year, fiscal year, etc.
>
> This seems like a quirk of the US constitution. To me, consecutive is
> unbounded. We could keep re-electing the same Chair over and over. Do
> you have a suggested wording? I can't think of anythign that isn't
> clunky.
>
> Calendar year and fiscal year are both 12 months, right? Not sure it
> makes a difference. What we really mean here is 12 months. Should we
> replace "year" with "12 months" to be clear on this point?
>
> On 12 May 2014 08:40, Joan Touzet <wo...@apache.org> wrote:
>> - Link to a definition of lazy consensus provided by the ASF or another project if available.
>
> Done.
>
> On 12 May 2014 08:40, Joan Touzet <wo...@apache.org> wrote:
>> - Bold "silence is assent." This is a key thing people need to understanda bout lazy consensus.
>
> I don't like bolding for emphasis. I have italicised instead.
>
> On 12 May 2014 08:40, Joan Touzet <wo...@apache.org> wrote:
>> - You might want to include the entire content of the +1/0/-1/fractions section from the apache.org link. Your definitions are different thana those stated.
>
> Yep. I wanted to purposefully avoid language like "stand in the way",
> because I believe it is unhealthy to encourage an atitutde that one
> can stand in the way of anything by casting a -1 vote. I have reworded
> the section now, and simplified the definitions so they're more inline
> with the ASF docs.
>
> +1, I like this
> +0, I don't feel strongly about it, but I'm okay with this
> -0, I won't get in the way, but I'd rather we didn't do this
> -1, I don't like this
>
> I also modified this, because rounding is hard:
>
> "For the purpose of tallying, values will be counted as one of the
> four values above, rounding to the lowest (i.e. closer to zero)
> standard value."
>
> On 12 May 2014 08:40, Joan Touzet <wo...@apache.org> wrote:
>> - Explain who is allowed to veto - any user? Committer? PMC member? Is this on any PR? Any line of code? Any email to dev@? user@? Can a crackpot come by and -1 the entire project with an email to user@, requiring a vote for validity? ;) The definition of "change to code" is too broad as it stands in this document. The table shows challenging a veto but not the veto itself.
>
> I moved the definition of "binding" to the section above this, so we
> can use that word here.
>
> This was hard to fix, but I replaced the top part of this section with:
>
>> We use the Commit-Then-Review (CTR) model of code collaboration. CTR is lazy consensus as it is applied to a source code repository. Each change represents a decision made by the committer.
>>
>> Notification of these changes are sent to the commits mailing list. It is expected that the rest of the community is regularly reviewing these changes. If a committer wants to object to a change, they have the option of casting a -1 vote. We call this a veto.
>>
>> Vetos can only be cast on changes made to the master branch of a source code repository that is shipped in an official release. Vetos can only be made for technical reasons. All vetoes must be justified and vetoes without justification are void. The validity of a veto can be challenged and the outcome is decided with a vote.
>>
>> A valid veto cannot be overruled and stands until withdrawn by the caster. If you disagree with a valid veto, you must lobby the person casting the veto to withdraw their veto. If a veto is not withdrawn, the commit must be reverted in a timely manner.
>
> Is this right? Are we using CTR for the master branches of our repos?
>
> On 12 May 2014 08:40, Joan Touzet <wo...@apache.org> wrote:
>> - Section 4.6 put "ASF Board approval" so it's clear what board we're talking about
>
> I've added a new section, 2.6 Board of Directors:
>
>> The Chair is responsible for the project to the Board of Directors (the Board) of the Apache Software Foundation. The Board is the nine-person legal governing body of the ASF, elected by the members of the foundation. The board provides the oversight of the Foundation's activities and operation, and has the responsibility of applying and enforcing the ASF's bylaws.
>
> On 12 May 2014 08:40, Joan Touzet <wo...@apache.org> wrote:
>> Recommend adding links once this is done in this document to the proposed Code of Conduct and Diversity statements so that they have additional weight by being referenced by the bylaws.
>
> +1 on that. I intended to patch the bylaws once those docs are done.
>
> On 19 May 2014 19:50, Jason Smith <ja...@gmail.com> wrote:
>> Is that a -1 *binding* vote? Only committers can veto commits, right?
>
> Fixed above.
>
> Though did take the time to update the decision table.
>
> Tehcnical decisions are now defined as:
>
>> A technical decision is any decision that involves changes to the master branch of a source code repository that is shipped in an official release
>>
>> Technical decisions should normally be made with lazy consensus via CRT.
>
> Non-technical decisions are defined as:
>
>> A non-technical decisions is any decision that is not a technical decision and is not covered by one of the other decision types.
>
> On 19 May 2014 19:50, Jason Smith <ja...@gmail.com> wrote:
>> Which kind of vote is this? It can't be majority. Majority must have no
>> binding -1 votes (thus a majority vote is in a sense something that can be
>> easily vetoed, like a release candidate). So the veto's validity itself can
>> be easily vetoed. In other words, any individual can veto a veto.
>
> This is covered in the decision table. Challenging a veto requires a
> lazy 2/3 majority. You cannot veto a lazy 2/3 majority.
>
> On 19 May 2014 19:50, Jason Smith <ja...@gmail.com> wrote:
>> I don't see how it can be lazy majority or even lazy 2/3. That means that a
>> sizeable group of people can invalidate a veto. So...that's not exactly a
>> veto.
>
> Makes sense to me. A valid veto stands, and cannot be overruled. But
> it seems reasonable to me that someone might try to cast an invalid
> veto. The vote only determines whether the veto is a veto, per our
> definition. I am using the word "valid" to mean this. Can you think of
> a better term?
>
> On 19 May 2014 19:50, Jason Smith <ja...@gmail.com> wrote:
>> The only vetos I can imagine happening are for trivial stuff where the
>> committer cannot even muster 3 binding +1 votes. For anything major though,
>> wouldn't a "veto" quickly become a vote for a popularity contest?
>
> See above. If a veto is judged to be a valid veto, then it stands.
>
> On 19 May 2014 19:50, Jason Smith <ja...@gmail.com> wrote:
>> Given the history of this project, I am actually comfortable with vetos
>> being rare and difficult. However my point today is: I'm not clear what laws
>> this section is actually making.
>
> Does the above clear it up for you?
>
> On 19 May 2014 23:19, Mutton, James <jm...@akamai.com> wrote:
>> "We expect you to know when to wear the appropriate hat, and when interacting with the project, to do so in *the* best interests of the…"
>
>> Decisions should be made on the mailing list associated with the decision. e.g. Marketing decisions happen on the marketing list.
>> * i.e. is read as "that is” and used as a restatement. e.g. (read as "for example”) is probably more appropriate here.
>
>> "All formal voting must be done in an email thread *with* the appropriate subject tag. “
>
> Fixed.
>
> On 20 May 2014 16:44, Dave Cottlehuber <dc...@jsonified.com> wrote:
>>> "An inactive chair can be replaced by the PMC"
>>
>> Doesn't this actually require board approval for replacement? Technically
>> this would be a recommendation of the PMC anyway to the board; do we need
>> to note the difference?
>
> Reworded this section above. This is no longer included.
>
> On 20 May 2014 16:44, Dave Cottlehuber <dc...@jsonified.com> wrote:
>>> "and that each and every release is the product of the community as a
>>> whole. That is key to our litigation protection mechanisms."
>>
>> It might be worth clarifying (somewhere, maybe here) that a key part of the
>> release process as PMC/committers is ensuring that the release contains only
>> ALv2 licenced, or other appropriate licenced material. I was originally not
>> aware of this important distinction.
>
> I have simplified this whole bit to:
>
>> The PMC must ensure that all relevant bylaws, policies, and procedures are adhered to.
>
> On 20 May 2014 16:44, Dave Cottlehuber <dc...@jsonified.com> wrote:
>>> "Any change to the source code that we distribute in our official
>>> releases".
>>
>> When is a veto a veto? e.g. if Q -1's my commit in (say) a proposed merge to
>> master, I'd assume that's a veto and then work with Q accordingly. Or is
>> this section only referring to a -1 during the release cycle (in which case
>> obv the RM would be waving a special flag).
>
> Please see my previous modifications here. I think this is addressed now.
>
> On 20 May 2014 16:44, Dave Cottlehuber <dc...@jsonified.com> wrote:
>> # Re "3.5. Approval Models"
>>
>>> "Votes on PMC decisions are binding if they are cast by a PMC member"
>>
>> What is a "PMC Decision"? I assume electing a new committer/PMC member/chair
>> only? Or does a release *also* fall into this category?
>
> This is defined in the decision table at the end of the document. Is
> this sufficient, or does it need repeating in the text? Jason
> indicates that he thought it was anything on the private@ list, but
> this is incorrect. See the table for the definitive list of PMC
> decisions.
>
> On 20 May 2014 16:44, Dave Cottlehuber <dc...@jsonified.com> wrote:
>> "Decision Types" reads better to me. YMMV, FFTI.
>
> Typo. Fixed.
>
> On 20 May 2014 16:44, Dave Cottlehuber <dc...@jsonified.com> wrote:
>> Is there a good reason for committers *not* to have a binding release vote?
>> It feels unfair.
>
> Yup. The ASF bylaws establish the PMC as the people with legal (under
> US corporation law) authority to vet releases. Do you think this needs
> including? I remove the stuff about litigation protection, because
> it's fairly esoteric stuff, and is addressed in ASF level documents.
>
Thanks Noah, good stuff! Some notes inline.
> On 20 May 2014 23:43, Jan Lehnardt <ja...@apache.org> wrote:
>> 1. last paragraph: “If you are participating on the mailing list you have the right to make decisions.” — *The* mailing list is undefined as of this part of the document. We should make that more clear.
>
> Changed to "mailing lists" plural.
It is still undefined, we should at least have a pointer to the lists, and explain that the project is conducted on mailing list, or point to a place that explains that.
>
> On 20 May 2014 23:43, Jan Lehnardt <ja...@apache.org> wrote:
>> 2.3. would specifically invite designers, both visual and user interface designers. Not sure we need a name like COPDOC.
>
> I started down this path of listing things we're interested in, but it
> got too long, so I spun it off into a new doc.
>
> https://cwiki.apache.org/confluence/display/COUCHDB/Contributor+Guide
That’s good, but still lacking e.g. designers. The bylaws should include a summary, and/or a pointer to the Contributor Guide.
> The COPDOC stuff has prior art:
>
> https://forrest.apache.org/committed.html
I’m hearing this for the first time, I’d be afraid to sound overly complicated for no good reason and it doesn’t include some groups of folks that we (should) care about. “People that we care about contributing to CouchDB” doesn’t need an acronym to make any clearer what we mean.
> On 20 May 2014 23:43, Jan Lehnardt <ja...@apache.org> wrote:
>> 2.4. I’d say handling security issues are the responsibility of the committers in a private forum. That bit should be moved to 2.3. At least that’s what we’ve been doing in the past, would be good to reflect that.
>
> Ultimately, it falls on the PMC to make sure this is addressed, with
> non-required help from the committers. I propose to leave it as it is,
> unless you have an edit for the committers section to mention that
> they can be involved in security response procedures.
Understood, I find it confusing that we define things here and then act differently, and I fear it might confuse future (and existing) contributors.
Correct me if I am wrong, but I am seeing the bylaws as a specialised subclass of the rules we get from the ASF (and a formalisations of the various guidelines from the ASF as we deem them fit for this project). As per the ASF, the PMC is responsible for making sure security stuff is taken care of (same for releases), but in our bylaws, we can specify that the responsibility actually lies with the committers. Even though from an ASF perspective the PMC is responsible, the PMC delegates this one level down.
Am I making sense? :)
> On 20 May 2014 23:43, Jan Lehnardt <ja...@apache.org> wrote:
>> Same for release management.
>
> Same again. The PMC bears the legal responsibility here, though we
> rely on committers to help us out by testing, etc.
Same as above :)
>
> On 20 May 2014 23:43, Jan Lehnardt <ja...@apache.org> wrote:
>> What are litigation protection mechanisms and why do we need them? (i.e. explain this a little, or link to a resource that does).
>
> The way the ASF bylaws are set up means that as long as the PMC
> follows procedure on preparing release artefacts and voting on them,
> then any legal responibility is transfered to the foundation itself.
> As mentioend above, I've removed this now. Think we can leave it out.
>
> On 20 May 2014 23:43, Jan Lehnardt <ja...@apache.org> wrote:
>> “The PMC operates at the discretion of the project chair.” I don’t understand what that means.
>
> It means that the Chair can disband the PMC at any point, according to
> the ASF bylaws. The PMC is not required, just customary. What I really
> mean is that the PMC is the Chair's committee.
>
> Changed to:
>
>> The PMC is the Chair's committee and operates at the behest of the Chair.
>
> Not sure how else to word it.
Works for now, thanks for the explanation!
> On 20 May 2014 23:43, Jan Lehnardt <ja...@apache.org> wrote:
>> 2.5. could include a pointer to PMC chair election process.
>
> I link to Apache STeVe later in the document. Will this suffice?
No harm in linking twice?
> On 20 May 2014 23:43, Jan Lehnardt <ja...@apache.org> wrote:
>> 3. “Our goal is to eschew permission culture” could be rephrased to be simpler for non-native speakers.
>
> Reworded as:
>
>> Our goal is to build a community of trust, reduce mailing list traffic, and deal with disagreements swiftly when they occur.
Excellent.
> On 20 May 2014 23:43, Jan Lehnardt <ja...@apache.org> wrote:
>> 4.1. bikeshed: would prefer tags to be lowercase.
>
> Sticking with uppercase for now.
BUT BUT BUT :)
Best
Jan
--
>
> On 21 May 2014 00:06, Robert Samuel Newson <rn...@apache.org> wrote:
>> "The foundation holds the trademark on the name CouchDB" — is this true?
>
> Reworded as:
>
>> Apache CouchDB, CouchDB, and the CouchDB logo are trademarks of the ASF. The CouchDB code and project resources are copyright the ASF.
>
> Per:
>
> http://www.apache.org/foundation/marks/list/
> http://couchdb.apache.org/
>
> (Note the distinction between registered and unregistered trademarks.
> Not important for this document.)
>
> On 21 May 2014 00:06, Robert Samuel Newson <rn...@apache.org> wrote:
>> "will be sorted out by a" — avoid idioms.
>
> Replaced with "will be seen to by a". Is that okay?
>
> On 21 May 2014 00:06, Robert Samuel Newson <rn...@apache.org> wrote:
>> "people what hat you are wearing" — s/what/which/
>
> Fixed.
>
> On 21 May 2014 00:06, Robert Samuel Newson <rn...@apache.org> wrote:
>> "chair" — should be capitalised throughout when it refers to the Chair of the PMC.
>>
>> ditto for "board".
>
> Fixed. And for "foundation" also.
>
>> "A contributor is someone who is contributing to the project in some way." — self-referential
>
> It is, but it's also valid. "Contributor" here is the title. I'm
> defining it quite simply by saying it is someone who contributes. :)
>
> On 21 May 2014 00:06, Robert Samuel Newson <rn...@apache.org> wrote:
>> "We prefer that decisions are made via:" is followed by three different decision forms that are incompatible with each other. We should clarify that they are listed here in preference order.
>
> Changed to:
>
>> In order of preference, we prefer that decisions are made via:
>
> On 21 May 2014 00:06, Robert Samuel Newson <rn...@apache.org> wrote:
>> "Any consensus that is achieved away from the lists" — No such thing can occur, by definition (the preceding sentence even says so). Change "consensus" here for something more appropriate.
>
> Changed to:
>
>> Any discussion that takes place away from the lists (for example on IRC or in person) must be brought to the lists before anything can be decided.
>
> On 21 May 2014 00:06, Robert Samuel Newson <rn...@apache.org> wrote:
>> Lazy consensus, as defined in 3.1, is too loose. The 3 day waiting period should be required, the exceptions to that rule would need to be explicit to gain my vote.
>
> Disagree. Lazy consensus is simply what we call the "It's easier to
> ask forgiveness than it is to get permission" principal. Another name
> we could pick would be the JFDI principal. :) It's only when you have
> doubts that you should feel the need to leave things open for three
> days. If you are sure about something, just go ahead and do it.
>
> On 21 May 2014 00:06, Robert Samuel Newson <rn...@apache.org> wrote:
>> "It is a very powerful tool that should be used to terminate a seemingly interminable discussion." — Reword this. The intention of falling back to a formal vote is to make progress. It doesn’t matter why progress had not been made before, and this sentence names only one example of that.
>
> It does, because in the previous section, I am trying to communicate
> that voting should be rare. We should be able to reach swift consensus
> through discussion. That's where the emphasis should be. Just trying
> to reenforce that.
>
> On 21 May 2014 00:06, Robert Samuel Newson <rn...@apache.org> wrote:
>> "All formal voting must be done in an email thread the appropriate subject tag." — is missing a "with".
>
> Fixed above.
>
> On 21 May 2014 00:06, Robert Samuel Newson <rn...@apache.org> wrote:
>> Hi,
>>
>> I finally reviewed this. It’s very good, congrats! My comments are principally about grammar;
>>
>> "The foundation holds the trademark on the name CouchDB" — is this true?
>>
>> "will be sorted out by a" — avoid idioms.
>>
>> "people what hat you are wearing" — s/what/which/
>>
>> "chair" — should be capitalised throughout when it refers to the Chair of the PMC.
>>
>> ditto for "board".
>>
>> "A contributor is someone who is contributing to the project in some way." — self-referential
>>
>> "We prefer that decisions are made via:" is followed by three different decision forms that are incompatible with each other. We should clarify that they are listed here in preference order.
>>
>> "Any consensus that is achieved away from the lists" — No such thing can occur, by definition (the preceding sentence even says so). Change "consensus" here for something more appropriate.
>>
>> Lazy consensus, as defined in 3.1, is too loose. The 3 day waiting period should be required, the exceptions to that rule would need to be explicit to gain my vote.
>>
>> "It is a very powerful tool that should be used to terminate a seemingly interminable discussion." — Reword this. The intention of falling back to a formal vote is to make progress. It doesn’t matter why progress had not been made before, and this sentence names only one example of that.
>>
>> "All formal voting must be done in an email thread the appropriate subject tag." — is missing a "with".
>>
>>
>> On 20 May 2014, at 22:43, Jan Lehnardt <ja...@apache.org> wrote:
>>
>>>
>>> On 15 May 2014, at 17:49 , Noah Slater <ns...@apache.org> wrote:
>>>
>>>> Jan/Bob, can I get your review of this too please?
>>>
>>> Sorry for the delay.
>>>
>>>
>>> 1. last paragraph: “If you are participating on the mailing list you have the right to make decisions.” — *The* mailing list is undefined as of this part of the document. We should make that more clear.
>>>
>>> 2.3. would specifically invite designers, both visual and user interface designers. Not sure we need a name like COPDOC.
>>>
>>> 2.4. I’d say handling security issues are the responsibility of the committers in a private forum. That bit should be moved to 2.3. At least that’s what we’ve been doing in the past, would be good to reflect that.
>>>
>>> Same for release management.
>>>
>>> What are litigation protection mechanisms and why do we need them? (i.e. explain this a little, or link to a resource that does).
>>>
>>> “The PMC operates at the discretion of the project chair.” I don’t understand what that means.
>>>
>>> 2.5. could include a pointer to PMC chair election process.
>>>
>>> 3. “Our goal is to eschew permission culture” could be rephrased to be simpler for non-native speakers.
>>>
>>> 4.1. bikeshed: would prefer tags to be lowercase.
>>>
>>>
>>>
>>>>
>>>> On 13 May 2014 23:23, Sebastian Rothbucher
>>>> <se...@googlemail.com> wrote:
>>>>> +1
>>>>> As it is
>>>>>
>>>>> Von meinem iPhone gesendet
>>>>>
>>>>>> Am 11.05.2014 um 17:35 schrieb Noah Slater <ns...@apache.org>:
>>>>>>
>>>>>> Community,
>>>>>>
>>>>>> Please do take the time to review this document. It's not that long,
>>>>>> or that complex. An online reading time calculator said it's about 14
>>>>>> minutes long. Your input at this stage would be very beneficial for
>>>>>> the project. (Anyone!)
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On 7 May 2014 21:07, Noah Slater <ns...@apache.org> wrote:
>>>>>>> Hello folks,
>>>>>>>
>>>>>>> Please review our propose bylaws:
>>>>>>>
>>>>>>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=40511017
>>>>>>>
>>>>>>> I'd like a few more eyeballs on this before I move to a vote.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>>
>>>>>>>> On 5 May 2014 18:35, 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.
>>>>>>>>
>>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Noah Slater
>>>>>>> https://twitter.com/nslater
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Noah Slater
>>>>>> https://twitter.com/nslater
>>>>
>>>>
>>>>
>>>> --
>>>> Noah Slater
>>>> https://twitter.com/nslater
>>>
>>
>
>
>
> --
> Noah Slater
> https://twitter.com/nslater
Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws)
Posted by Andy Wenk <an...@nms.de>.
Hi Noah,
I have read the whole bylaws. Awesome. Thanks a lot for that excellent
work. It is very understandable and I did not miss anything.
I have just a few minor issues:
---
"The CouchDB code and project resources are copyright the ASF."
shouldn't it read:
"The CouchDB code and project resources are copyright of the ASF." (added
'of')
---
"Code, and everything else that goes with it, will be seen to by a healthy
community over time."
I don't understand "... will be seen to by ..." - is that correct?
---
"Sometimes, you are not be sure about what the community would want."
shouldn't it read:
"Sometimes, you might not be sure about what the community would want."
(changed 'are' to 'might')
---
Cheers
Andy
On 26 May 2014 18:22, Noah Slater <ns...@apache.org> wrote:
> Changed to "12" months."
>
> Bob, Jan, Andy, Robert, Dave, Jason: please review my changes and
> comments. I took care to include your names next to all of my
> annotations, so it should be easy for you to home in on the bits that
> apply to you.
>
> Thanks folks. We're close to getting this official!
>
> On 21 May 2014 21:54, Joan Touzet <wo...@apache.org> wrote:
> > On Wed, May 21, 2014 at 09:47:29PM +0200, Noah Slater wrote:
> >> On 12 May 2014 08:40, Joan Touzet <wo...@apache.org> wrote:
> >> > - For the PMC Chair term, we should clarify whether consecutive
> means "more than 2 in a row" (unlike the US President) and whether that is
> calendar year, fiscal year, etc.
> >>
> >> This seems like a quirk of the US constitution. To me, consecutive is
> >> unbounded. We could keep re-electing the same Chair over and over. Do
> >> you have a suggested wording? I can't think of anythign that isn't
> >> clunky.
> >
> > Let it stand, not important enough to change.
> >
> >> Calendar year and fiscal year are both 12 months, right? Not sure it
> >> makes a difference. What we really mean here is 12 months. Should we
> >> replace "year" with "12 months" to be clear on this point?
> >
> > Replace year with "12 months".
> >
> >
> > [on vetos]
> >> This was hard to fix, but I replaced the top part of this section with:
> > [snip]
> >
> > Looks good to me, except:
> >
> >> Is this right? Are we using CTR for the master branches of our repos?
> >
> > I didn't think we were, I thought the commit was always on a branch,
> > then there was a review, and the outcome of the review resulted in a
> > merge to master. But I have been out of the loop on where we ended up;
> > much of that discussion predates my return to active status.
> >
> >> I've added a new section, 2.6 Board of Directors:
> >
> > Fantastic, thank you.
> >
> > --
> > Joan Touzet | joant@atypical.net | wohali everywhere else
>
>
>
> --
> 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: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws)
Posted by Noah Slater <ns...@apache.org>.
Changed to "12" months."
Bob, Jan, Andy, Robert, Dave, Jason: please review my changes and
comments. I took care to include your names next to all of my
annotations, so it should be easy for you to home in on the bits that
apply to you.
Thanks folks. We're close to getting this official!
On 21 May 2014 21:54, Joan Touzet <wo...@apache.org> wrote:
> On Wed, May 21, 2014 at 09:47:29PM +0200, Noah Slater wrote:
>> On 12 May 2014 08:40, Joan Touzet <wo...@apache.org> wrote:
>> > - For the PMC Chair term, we should clarify whether consecutive means "more than 2 in a row" (unlike the US President) and whether that is calendar year, fiscal year, etc.
>>
>> This seems like a quirk of the US constitution. To me, consecutive is
>> unbounded. We could keep re-electing the same Chair over and over. Do
>> you have a suggested wording? I can't think of anythign that isn't
>> clunky.
>
> Let it stand, not important enough to change.
>
>> Calendar year and fiscal year are both 12 months, right? Not sure it
>> makes a difference. What we really mean here is 12 months. Should we
>> replace "year" with "12 months" to be clear on this point?
>
> Replace year with "12 months".
>
>
> [on vetos]
>> This was hard to fix, but I replaced the top part of this section with:
> [snip]
>
> Looks good to me, except:
>
>> Is this right? Are we using CTR for the master branches of our repos?
>
> I didn't think we were, I thought the commit was always on a branch,
> then there was a review, and the outcome of the review resulted in a
> merge to master. But I have been out of the loop on where we ended up;
> much of that discussion predates my return to active status.
>
>> I've added a new section, 2.6 Board of Directors:
>
> Fantastic, thank you.
>
> --
> Joan Touzet | joant@atypical.net | wohali everywhere else
--
Noah Slater
https://twitter.com/nslater
Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project
bylaws)
Posted by Joan Touzet <wo...@apache.org>.
On Wed, May 21, 2014 at 09:47:29PM +0200, Noah Slater wrote:
> On 12 May 2014 08:40, Joan Touzet <wo...@apache.org> wrote:
> > - For the PMC Chair term, we should clarify whether consecutive means "more than 2 in a row" (unlike the US President) and whether that is calendar year, fiscal year, etc.
>
> This seems like a quirk of the US constitution. To me, consecutive is
> unbounded. We could keep re-electing the same Chair over and over. Do
> you have a suggested wording? I can't think of anythign that isn't
> clunky.
Let it stand, not important enough to change.
> Calendar year and fiscal year are both 12 months, right? Not sure it
> makes a difference. What we really mean here is 12 months. Should we
> replace "year" with "12 months" to be clear on this point?
Replace year with "12 months".
[on vetos]
> This was hard to fix, but I replaced the top part of this section with:
[snip]
Looks good to me, except:
> Is this right? Are we using CTR for the master branches of our repos?
I didn't think we were, I thought the commit was always on a branch,
then there was a review, and the outcome of the review resulted in a
merge to master. But I have been out of the loop on where we ended up;
much of that discussion predates my return to active status.
> I've added a new section, 2.6 Board of Directors:
Fantastic, thank you.
--
Joan Touzet | joant@atypical.net | wohali everywhere else
Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws)
Posted by Robert Kowalski <ro...@kowalski.gd>.
Hi Noah,
I just added my answers:
> On 11 May 2014 20:14, Robert Kowalski <ro...@kowalski.gd> wrote:
> > As a fairly new committer I learned some from reading it and realized
> that
> > I have some "unknown unknowns".
>
> Can you elaborate?
>
Sure! I call "unknown unknown" everything where I did not even know that I
did not know them (quite meta). I can say "I don't know how to speak
Spanish" and in this situation I am knowing that I have an Unknown
(speaking Spanish). But sometimes,e.g. when it comes to specific knowledge
in an area, I don't even know, that I did not know this. Therefore I can
not ask anybody about it, because I am not aware that I don't know it. I
think I got the terms "unknown unknown" and "known unknown" from knowledge
management, a colleague wrote his diploma in this area.
Some examples: I was not aware that one can vote with a +0 or -0, I also
did not know all the different models for an approval. I also did not know
some details of the decision types.
I really like the fact that there is now a document that is easy to find to
give people all the informations and an overview!
Great work Noah!
> On 11 May 2014 20:14, Robert Kowalski <ro...@kowalski.gd> wrote:
> > Maybe we can add a line that there is a meeting every wednesday on
> > freenode, because I have the feeling that it is an integral part on how
> the
> > project is organizing itself.
>
> I am not sure the bylaws are the correct place for this. But I could
> be convinced if someone has a compelling argument for it.
>
>
Looking at it in retrospective it is not fitting really into the bylaws,
you are right
Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws)
Posted by Noah Slater <ns...@apache.org>.
On 11 May 2014 02:18, Andy Wenk <an...@nms.de> wrote:
> 3. Roles and Responsibilities -> last paragraph "Committers and PMC
> members are never removed": this content feels a bit out of context. Maybe
> move it to 3.3 and 3.5
Removed the bit at the end and modified p2 and p3 to read:
> Your role is assigned to you personally, and is bestowed on you by your peers in recognition of your past contributions to the project and your position of trust within the community. It is not tied to your job, your current employer, or your current activity level. We are interested in you as an individual and we understand that your interactions with the project may change over time.
>
> Roles are never rescinded because of inactivity, unless that inactivity is causing a problem for the project. Fortunately, our decision making process means that inactivity is very rarely a problem. Roles will be rescinded if the PMC believes the individual is no longer able to responsibly discharge the duty of the role.
On 11 May 2014 02:18, Andy Wenk <an...@nms.de> wrote:
> 3.3 Committers -> third paragraph "... it means you are committed to the
> project ..." is double because it was already stated at the beginning of
> the section.
Replaced:
> Being a committer does not mean you commit code, it means you are committed to the project.
With:
> Being a committer does not mean you have to commit code.
On 11 May 2014 20:14, Robert Kowalski <ro...@kowalski.gd> wrote:
> As a fairly new committer I learned some from reading it and realized that
> I have some "unknown unknowns".
Can you elaborate?
On 11 May 2014 20:14, Robert Kowalski <ro...@kowalski.gd> wrote:
> Maybe we can add a line that there is a meeting every wednesday on
> freenode, because I have the feeling that it is an integral part on how the
> project is organizing itself.
I am not sure the bylaws are the correct place for this. But I could
be convinced if someone has a compelling argument for it.
On 12 May 2014 08:40, Joan Touzet <wo...@apache.org> wrote:
> - Link the text "the Apache Way" instead of "a set of common principles."
> - "community should be *A* fun and rewarding place to be for everyone involved."
Fixed.
On 12 May 2014 08:40, Joan Touzet <wo...@apache.org> wrote:
> - Is there an ASF link for their definition of "hat?" This might be confusing to a non-English speaker. Even a glossary link - to explain that wearing a hat means playing a role, or acting within the expectations of that role.
> - Possibly move the "hats" discussion to after you define all the different roles, I'm not sure.
Replaced this para with:
> We understand that you have many roles in life. We use a hat metaphor to talk about these roles. For instance, you might have your work hat as well as several ASF hats. 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 this is a serious dereliction of duty.
On 12 May 2014 08:40, Joan Touzet <wo...@apache.org> wrote:
> - For the PMC Chair term, we should clarify whether consecutive means "more than 2 in a row" (unlike the US President) and whether that is calendar year, fiscal year, etc.
This seems like a quirk of the US constitution. To me, consecutive is
unbounded. We could keep re-electing the same Chair over and over. Do
you have a suggested wording? I can't think of anythign that isn't
clunky.
Calendar year and fiscal year are both 12 months, right? Not sure it
makes a difference. What we really mean here is 12 months. Should we
replace "year" with "12 months" to be clear on this point?
On 12 May 2014 08:40, Joan Touzet <wo...@apache.org> wrote:
> - Link to a definition of lazy consensus provided by the ASF or another project if available.
Done.
On 12 May 2014 08:40, Joan Touzet <wo...@apache.org> wrote:
> - Bold "silence is assent." This is a key thing people need to understanda bout lazy consensus.
I don't like bolding for emphasis. I have italicised instead.
On 12 May 2014 08:40, Joan Touzet <wo...@apache.org> wrote:
> - You might want to include the entire content of the +1/0/-1/fractions section from the apache.org link. Your definitions are different thana those stated.
Yep. I wanted to purposefully avoid language like "stand in the way",
because I believe it is unhealthy to encourage an atitutde that one
can stand in the way of anything by casting a -1 vote. I have reworded
the section now, and simplified the definitions so they're more inline
with the ASF docs.
+1, I like this
+0, I don't feel strongly about it, but I'm okay with this
-0, I won't get in the way, but I'd rather we didn't do this
-1, I don't like this
I also modified this, because rounding is hard:
"For the purpose of tallying, values will be counted as one of the
four values above, rounding to the lowest (i.e. closer to zero)
standard value."
On 12 May 2014 08:40, Joan Touzet <wo...@apache.org> wrote:
> - Explain who is allowed to veto - any user? Committer? PMC member? Is this on any PR? Any line of code? Any email to dev@? user@? Can a crackpot come by and -1 the entire project with an email to user@, requiring a vote for validity? ;) The definition of "change to code" is too broad as it stands in this document. The table shows challenging a veto but not the veto itself.
I moved the definition of "binding" to the section above this, so we
can use that word here.
This was hard to fix, but I replaced the top part of this section with:
> We use the Commit-Then-Review (CTR) model of code collaboration. CTR is lazy consensus as it is applied to a source code repository. Each change represents a decision made by the committer.
>
> Notification of these changes are sent to the commits mailing list. It is expected that the rest of the community is regularly reviewing these changes. If a committer wants to object to a change, they have the option of casting a -1 vote. We call this a veto.
>
> Vetos can only be cast on changes made to the master branch of a source code repository that is shipped in an official release. Vetos can only be made for technical reasons. All vetoes must be justified and vetoes without justification are void. The validity of a veto can be challenged and the outcome is decided with a vote.
>
> A valid veto cannot be overruled and stands until withdrawn by the caster. If you disagree with a valid veto, you must lobby the person casting the veto to withdraw their veto. If a veto is not withdrawn, the commit must be reverted in a timely manner.
Is this right? Are we using CTR for the master branches of our repos?
On 12 May 2014 08:40, Joan Touzet <wo...@apache.org> wrote:
> - Section 4.6 put "ASF Board approval" so it's clear what board we're talking about
I've added a new section, 2.6 Board of Directors:
> The Chair is responsible for the project to the Board of Directors (the Board) of the Apache Software Foundation. The Board is the nine-person legal governing body of the ASF, elected by the members of the foundation. The board provides the oversight of the Foundation's activities and operation, and has the responsibility of applying and enforcing the ASF's bylaws.
On 12 May 2014 08:40, Joan Touzet <wo...@apache.org> wrote:
> Recommend adding links once this is done in this document to the proposed Code of Conduct and Diversity statements so that they have additional weight by being referenced by the bylaws.
+1 on that. I intended to patch the bylaws once those docs are done.
On 19 May 2014 19:50, Jason Smith <ja...@gmail.com> wrote:
> Is that a -1 *binding* vote? Only committers can veto commits, right?
Fixed above.
Though did take the time to update the decision table.
Tehcnical decisions are now defined as:
> A technical decision is any decision that involves changes to the master branch of a source code repository that is shipped in an official release
>
> Technical decisions should normally be made with lazy consensus via CRT.
Non-technical decisions are defined as:
> A non-technical decisions is any decision that is not a technical decision and is not covered by one of the other decision types.
On 19 May 2014 19:50, Jason Smith <ja...@gmail.com> wrote:
> Which kind of vote is this? It can't be majority. Majority must have no
> binding -1 votes (thus a majority vote is in a sense something that can be
> easily vetoed, like a release candidate). So the veto's validity itself can
> be easily vetoed. In other words, any individual can veto a veto.
This is covered in the decision table. Challenging a veto requires a
lazy 2/3 majority. You cannot veto a lazy 2/3 majority.
On 19 May 2014 19:50, Jason Smith <ja...@gmail.com> wrote:
> I don't see how it can be lazy majority or even lazy 2/3. That means that a
> sizeable group of people can invalidate a veto. So...that's not exactly a
> veto.
Makes sense to me. A valid veto stands, and cannot be overruled. But
it seems reasonable to me that someone might try to cast an invalid
veto. The vote only determines whether the veto is a veto, per our
definition. I am using the word "valid" to mean this. Can you think of
a better term?
On 19 May 2014 19:50, Jason Smith <ja...@gmail.com> wrote:
> The only vetos I can imagine happening are for trivial stuff where the
> committer cannot even muster 3 binding +1 votes. For anything major though,
> wouldn't a "veto" quickly become a vote for a popularity contest?
See above. If a veto is judged to be a valid veto, then it stands.
On 19 May 2014 19:50, Jason Smith <ja...@gmail.com> wrote:
> Given the history of this project, I am actually comfortable with vetos
> being rare and difficult. However my point today is: I'm not clear what laws
> this section is actually making.
Does the above clear it up for you?
On 19 May 2014 23:19, Mutton, James <jm...@akamai.com> wrote:
> "We expect you to know when to wear the appropriate hat, and when interacting with the project, to do so in *the* best interests of the…"
> Decisions should be made on the mailing list associated with the decision. e.g. Marketing decisions happen on the marketing list.
> * i.e. is read as "that is” and used as a restatement. e.g. (read as "for example”) is probably more appropriate here.
> "All formal voting must be done in an email thread *with* the appropriate subject tag. “
Fixed.
On 20 May 2014 16:44, Dave Cottlehuber <dc...@jsonified.com> wrote:
>> "An inactive chair can be replaced by the PMC"
>
> Doesn't this actually require board approval for replacement? Technically
> this would be a recommendation of the PMC anyway to the board; do we need
> to note the difference?
Reworded this section above. This is no longer included.
On 20 May 2014 16:44, Dave Cottlehuber <dc...@jsonified.com> wrote:
>> "and that each and every release is the product of the community as a
>> whole. That is key to our litigation protection mechanisms."
>
> It might be worth clarifying (somewhere, maybe here) that a key part of the
> release process as PMC/committers is ensuring that the release contains only
> ALv2 licenced, or other appropriate licenced material. I was originally not
> aware of this important distinction.
I have simplified this whole bit to:
> The PMC must ensure that all relevant bylaws, policies, and procedures are adhered to.
On 20 May 2014 16:44, Dave Cottlehuber <dc...@jsonified.com> wrote:
>> "Any change to the source code that we distribute in our official
>> releases".
>
> When is a veto a veto? e.g. if Q -1's my commit in (say) a proposed merge to
> master, I'd assume that's a veto and then work with Q accordingly. Or is
> this section only referring to a -1 during the release cycle (in which case
> obv the RM would be waving a special flag).
Please see my previous modifications here. I think this is addressed now.
On 20 May 2014 16:44, Dave Cottlehuber <dc...@jsonified.com> wrote:
> # Re "3.5. Approval Models"
>
>> "Votes on PMC decisions are binding if they are cast by a PMC member"
>
> What is a "PMC Decision"? I assume electing a new committer/PMC member/chair
> only? Or does a release *also* fall into this category?
This is defined in the decision table at the end of the document. Is
this sufficient, or does it need repeating in the text? Jason
indicates that he thought it was anything on the private@ list, but
this is incorrect. See the table for the definitive list of PMC
decisions.
On 20 May 2014 16:44, Dave Cottlehuber <dc...@jsonified.com> wrote:
> "Decision Types" reads better to me. YMMV, FFTI.
Typo. Fixed.
On 20 May 2014 16:44, Dave Cottlehuber <dc...@jsonified.com> wrote:
> Is there a good reason for committers *not* to have a binding release vote?
> It feels unfair.
Yup. The ASF bylaws establish the PMC as the people with legal (under
US corporation law) authority to vet releases. Do you think this needs
including? I remove the stuff about litigation protection, because
it's fairly esoteric stuff, and is addressed in ASF level documents.
On 20 May 2014 23:43, Jan Lehnardt <ja...@apache.org> wrote:
> 1. last paragraph: “If you are participating on the mailing list you have the right to make decisions.” — *The* mailing list is undefined as of this part of the document. We should make that more clear.
Changed to "mailing lists" plural.
On 20 May 2014 23:43, Jan Lehnardt <ja...@apache.org> wrote:
> 2.3. would specifically invite designers, both visual and user interface designers. Not sure we need a name like COPDOC.
I started down this path of listing things we're interested in, but it
got too long, so I spun it off into a new doc.
https://cwiki.apache.org/confluence/display/COUCHDB/Contributor+Guide
The COPDOC stuff has prior art:
https://forrest.apache.org/committed.html
On 20 May 2014 23:43, Jan Lehnardt <ja...@apache.org> wrote:
> 2.4. I’d say handling security issues are the responsibility of the committers in a private forum. That bit should be moved to 2.3. At least that’s what we’ve been doing in the past, would be good to reflect that.
Ultimately, it falls on the PMC to make sure this is addressed, with
non-required help from the committers. I propose to leave it as it is,
unless you have an edit for the committers section to mention that
they can be involved in security response procedures.
On 20 May 2014 23:43, Jan Lehnardt <ja...@apache.org> wrote:
> Same for release management.
Same again. The PMC bears the legal responsibility here, though we
rely on committers to help us out by testing, etc.
On 20 May 2014 23:43, Jan Lehnardt <ja...@apache.org> wrote:
> What are litigation protection mechanisms and why do we need them? (i.e. explain this a little, or link to a resource that does).
The way the ASF bylaws are set up means that as long as the PMC
follows procedure on preparing release artefacts and voting on them,
then any legal responibility is transfered to the foundation itself.
As mentioend above, I've removed this now. Think we can leave it out.
On 20 May 2014 23:43, Jan Lehnardt <ja...@apache.org> wrote:
> “The PMC operates at the discretion of the project chair.” I don’t understand what that means.
It means that the Chair can disband the PMC at any point, according to
the ASF bylaws. The PMC is not required, just customary. What I really
mean is that the PMC is the Chair's committee.
Changed to:
> The PMC is the Chair's committee and operates at the behest of the Chair.
Not sure how else to word it.
On 20 May 2014 23:43, Jan Lehnardt <ja...@apache.org> wrote:
> 2.5. could include a pointer to PMC chair election process.
I link to Apache STeVe later in the document. Will this suffice?
On 20 May 2014 23:43, Jan Lehnardt <ja...@apache.org> wrote:
> 3. “Our goal is to eschew permission culture” could be rephrased to be simpler for non-native speakers.
Reworded as:
> Our goal is to build a community of trust, reduce mailing list traffic, and deal with disagreements swiftly when they occur.
On 20 May 2014 23:43, Jan Lehnardt <ja...@apache.org> wrote:
> 4.1. bikeshed: would prefer tags to be lowercase.
Sticking with uppercase for now.
On 21 May 2014 00:06, Robert Samuel Newson <rn...@apache.org> wrote:
> "The foundation holds the trademark on the name CouchDB" — is this true?
Reworded as:
> Apache CouchDB, CouchDB, and the CouchDB logo are trademarks of the ASF. The CouchDB code and project resources are copyright the ASF.
Per:
http://www.apache.org/foundation/marks/list/
http://couchdb.apache.org/
(Note the distinction between registered and unregistered trademarks.
Not important for this document.)
On 21 May 2014 00:06, Robert Samuel Newson <rn...@apache.org> wrote:
> "will be sorted out by a" — avoid idioms.
Replaced with "will be seen to by a". Is that okay?
On 21 May 2014 00:06, Robert Samuel Newson <rn...@apache.org> wrote:
> "people what hat you are wearing" — s/what/which/
Fixed.
On 21 May 2014 00:06, Robert Samuel Newson <rn...@apache.org> wrote:
> "chair" — should be capitalised throughout when it refers to the Chair of the PMC.
>
> ditto for "board".
Fixed. And for "foundation" also.
> "A contributor is someone who is contributing to the project in some way." — self-referential
It is, but it's also valid. "Contributor" here is the title. I'm
defining it quite simply by saying it is someone who contributes. :)
On 21 May 2014 00:06, Robert Samuel Newson <rn...@apache.org> wrote:
> "We prefer that decisions are made via:" is followed by three different decision forms that are incompatible with each other. We should clarify that they are listed here in preference order.
Changed to:
> In order of preference, we prefer that decisions are made via:
On 21 May 2014 00:06, Robert Samuel Newson <rn...@apache.org> wrote:
> "Any consensus that is achieved away from the lists" — No such thing can occur, by definition (the preceding sentence even says so). Change "consensus" here for something more appropriate.
Changed to:
> Any discussion that takes place away from the lists (for example on IRC or in person) must be brought to the lists before anything can be decided.
On 21 May 2014 00:06, Robert Samuel Newson <rn...@apache.org> wrote:
> Lazy consensus, as defined in 3.1, is too loose. The 3 day waiting period should be required, the exceptions to that rule would need to be explicit to gain my vote.
Disagree. Lazy consensus is simply what we call the "It's easier to
ask forgiveness than it is to get permission" principal. Another name
we could pick would be the JFDI principal. :) It's only when you have
doubts that you should feel the need to leave things open for three
days. If you are sure about something, just go ahead and do it.
On 21 May 2014 00:06, Robert Samuel Newson <rn...@apache.org> wrote:
> "It is a very powerful tool that should be used to terminate a seemingly interminable discussion." — Reword this. The intention of falling back to a formal vote is to make progress. It doesn’t matter why progress had not been made before, and this sentence names only one example of that.
It does, because in the previous section, I am trying to communicate
that voting should be rare. We should be able to reach swift consensus
through discussion. That's where the emphasis should be. Just trying
to reenforce that.
On 21 May 2014 00:06, Robert Samuel Newson <rn...@apache.org> wrote:
> "All formal voting must be done in an email thread the appropriate subject tag." — is missing a "with".
Fixed above.
On 21 May 2014 00:06, Robert Samuel Newson <rn...@apache.org> wrote:
> Hi,
>
> I finally reviewed this. It’s very good, congrats! My comments are principally about grammar;
>
> "The foundation holds the trademark on the name CouchDB" — is this true?
>
> "will be sorted out by a" — avoid idioms.
>
> "people what hat you are wearing" — s/what/which/
>
> "chair" — should be capitalised throughout when it refers to the Chair of the PMC.
>
> ditto for "board".
>
> "A contributor is someone who is contributing to the project in some way." — self-referential
>
> "We prefer that decisions are made via:" is followed by three different decision forms that are incompatible with each other. We should clarify that they are listed here in preference order.
>
> "Any consensus that is achieved away from the lists" — No such thing can occur, by definition (the preceding sentence even says so). Change "consensus" here for something more appropriate.
>
> Lazy consensus, as defined in 3.1, is too loose. The 3 day waiting period should be required, the exceptions to that rule would need to be explicit to gain my vote.
>
> "It is a very powerful tool that should be used to terminate a seemingly interminable discussion." — Reword this. The intention of falling back to a formal vote is to make progress. It doesn’t matter why progress had not been made before, and this sentence names only one example of that.
>
> "All formal voting must be done in an email thread the appropriate subject tag." — is missing a "with".
>
>
> On 20 May 2014, at 22:43, Jan Lehnardt <ja...@apache.org> wrote:
>
>>
>> On 15 May 2014, at 17:49 , Noah Slater <ns...@apache.org> wrote:
>>
>>> Jan/Bob, can I get your review of this too please?
>>
>> Sorry for the delay.
>>
>>
>> 1. last paragraph: “If you are participating on the mailing list you have the right to make decisions.” — *The* mailing list is undefined as of this part of the document. We should make that more clear.
>>
>> 2.3. would specifically invite designers, both visual and user interface designers. Not sure we need a name like COPDOC.
>>
>> 2.4. I’d say handling security issues are the responsibility of the committers in a private forum. That bit should be moved to 2.3. At least that’s what we’ve been doing in the past, would be good to reflect that.
>>
>> Same for release management.
>>
>> What are litigation protection mechanisms and why do we need them? (i.e. explain this a little, or link to a resource that does).
>>
>> “The PMC operates at the discretion of the project chair.” I don’t understand what that means.
>>
>> 2.5. could include a pointer to PMC chair election process.
>>
>> 3. “Our goal is to eschew permission culture” could be rephrased to be simpler for non-native speakers.
>>
>> 4.1. bikeshed: would prefer tags to be lowercase.
>>
>>
>>
>>>
>>> On 13 May 2014 23:23, Sebastian Rothbucher
>>> <se...@googlemail.com> wrote:
>>>> +1
>>>> As it is
>>>>
>>>> Von meinem iPhone gesendet
>>>>
>>>>> Am 11.05.2014 um 17:35 schrieb Noah Slater <ns...@apache.org>:
>>>>>
>>>>> Community,
>>>>>
>>>>> Please do take the time to review this document. It's not that long,
>>>>> or that complex. An online reading time calculator said it's about 14
>>>>> minutes long. Your input at this stage would be very beneficial for
>>>>> the project. (Anyone!)
>>>>>
>>>>>
>>>>>
>>>>>> On 7 May 2014 21:07, Noah Slater <ns...@apache.org> wrote:
>>>>>> Hello folks,
>>>>>>
>>>>>> Please review our propose bylaws:
>>>>>>
>>>>>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=40511017
>>>>>>
>>>>>> I'd like a few more eyeballs on this before I move to a vote.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>>
>>>>>>> On 5 May 2014 18:35, 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.
>>>>>>>
>>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Noah Slater
>>>>>> https://twitter.com/nslater
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Noah Slater
>>>>> https://twitter.com/nslater
>>>
>>>
>>>
>>> --
>>> Noah Slater
>>> https://twitter.com/nslater
>>
>
--
Noah Slater
https://twitter.com/nslater
Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws)
Posted by Robert Samuel Newson <rn...@apache.org>.
Hi,
I finally reviewed this. It’s very good, congrats! My comments are principally about grammar;
"The foundation holds the trademark on the name CouchDB" — is this true?
"will be sorted out by a" — avoid idioms.
"people what hat you are wearing" — s/what/which/
"chair" — should be capitalised throughout when it refers to the Chair of the PMC.
ditto for "board".
"A contributor is someone who is contributing to the project in some way." — self-referential
"We prefer that decisions are made via:" is followed by three different decision forms that are incompatible with each other. We should clarify that they are listed here in preference order.
"Any consensus that is achieved away from the lists" — No such thing can occur, by definition (the preceding sentence even says so). Change "consensus" here for something more appropriate.
Lazy consensus, as defined in 3.1, is too loose. The 3 day waiting period should be required, the exceptions to that rule would need to be explicit to gain my vote.
"It is a very powerful tool that should be used to terminate a seemingly interminable discussion." — Reword this. The intention of falling back to a formal vote is to make progress. It doesn’t matter why progress had not been made before, and this sentence names only one example of that.
"All formal voting must be done in an email thread the appropriate subject tag." — is missing a "with".
On 20 May 2014, at 22:43, Jan Lehnardt <ja...@apache.org> wrote:
>
> On 15 May 2014, at 17:49 , Noah Slater <ns...@apache.org> wrote:
>
>> Jan/Bob, can I get your review of this too please?
>
> Sorry for the delay.
>
>
> 1. last paragraph: “If you are participating on the mailing list you have the right to make decisions.” — *The* mailing list is undefined as of this part of the document. We should make that more clear.
>
> 2.3. would specifically invite designers, both visual and user interface designers. Not sure we need a name like COPDOC.
>
> 2.4. I’d say handling security issues are the responsibility of the committers in a private forum. That bit should be moved to 2.3. At least that’s what we’ve been doing in the past, would be good to reflect that.
>
> Same for release management.
>
> What are litigation protection mechanisms and why do we need them? (i.e. explain this a little, or link to a resource that does).
>
> “The PMC operates at the discretion of the project chair.” I don’t understand what that means.
>
> 2.5. could include a pointer to PMC chair election process.
>
> 3. “Our goal is to eschew permission culture” could be rephrased to be simpler for non-native speakers.
>
> 4.1. bikeshed: would prefer tags to be lowercase.
>
>
>
>>
>> On 13 May 2014 23:23, Sebastian Rothbucher
>> <se...@googlemail.com> wrote:
>>> +1
>>> As it is
>>>
>>> Von meinem iPhone gesendet
>>>
>>>> Am 11.05.2014 um 17:35 schrieb Noah Slater <ns...@apache.org>:
>>>>
>>>> Community,
>>>>
>>>> Please do take the time to review this document. It's not that long,
>>>> or that complex. An online reading time calculator said it's about 14
>>>> minutes long. Your input at this stage would be very beneficial for
>>>> the project. (Anyone!)
>>>>
>>>>
>>>>
>>>>> On 7 May 2014 21:07, Noah Slater <ns...@apache.org> wrote:
>>>>> Hello folks,
>>>>>
>>>>> Please review our propose bylaws:
>>>>>
>>>>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=40511017
>>>>>
>>>>> I'd like a few more eyeballs on this before I move to a vote.
>>>>>
>>>>> Thanks,
>>>>>
>>>>>
>>>>>> On 5 May 2014 18:35, 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.
>>>>>>
>>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Noah Slater
>>>>> https://twitter.com/nslater
>>>>
>>>>
>>>>
>>>> --
>>>> Noah Slater
>>>> https://twitter.com/nslater
>>
>>
>>
>> --
>> Noah Slater
>> https://twitter.com/nslater
>
Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws)
Posted by Jan Lehnardt <ja...@apache.org>.
On 15 May 2014, at 17:49 , Noah Slater <ns...@apache.org> wrote:
> Jan/Bob, can I get your review of this too please?
Sorry for the delay.
1. last paragraph: “If you are participating on the mailing list you have the right to make decisions.” — *The* mailing list is undefined as of this part of the document. We should make that more clear.
2.3. would specifically invite designers, both visual and user interface designers. Not sure we need a name like COPDOC.
2.4. I’d say handling security issues are the responsibility of the committers in a private forum. That bit should be moved to 2.3. At least that’s what we’ve been doing in the past, would be good to reflect that.
Same for release management.
What are litigation protection mechanisms and why do we need them? (i.e. explain this a little, or link to a resource that does).
“The PMC operates at the discretion of the project chair.” I don’t understand what that means.
2.5. could include a pointer to PMC chair election process.
3. “Our goal is to eschew permission culture” could be rephrased to be simpler for non-native speakers.
4.1. bikeshed: would prefer tags to be lowercase.
>
> On 13 May 2014 23:23, Sebastian Rothbucher
> <se...@googlemail.com> wrote:
>> +1
>> As it is
>>
>> Von meinem iPhone gesendet
>>
>>> Am 11.05.2014 um 17:35 schrieb Noah Slater <ns...@apache.org>:
>>>
>>> Community,
>>>
>>> Please do take the time to review this document. It's not that long,
>>> or that complex. An online reading time calculator said it's about 14
>>> minutes long. Your input at this stage would be very beneficial for
>>> the project. (Anyone!)
>>>
>>>
>>>
>>>> On 7 May 2014 21:07, Noah Slater <ns...@apache.org> wrote:
>>>> Hello folks,
>>>>
>>>> Please review our propose bylaws:
>>>>
>>>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=40511017
>>>>
>>>> I'd like a few more eyeballs on this before I move to a vote.
>>>>
>>>> Thanks,
>>>>
>>>>
>>>>> On 5 May 2014 18:35, 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.
>>>>>
>>>>> 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
>>>>
>>>>
>>>>
>>>> --
>>>> Noah Slater
>>>> https://twitter.com/nslater
>>>
>>>
>>>
>>> --
>>> Noah Slater
>>> https://twitter.com/nslater
>
>
>
> --
> Noah Slater
> https://twitter.com/nslater
Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws)
Posted by Noah Slater <ns...@apache.org>.
Jan/Bob, can I get your review of this too please?
On 13 May 2014 23:23, Sebastian Rothbucher
<se...@googlemail.com> wrote:
> +1
> As it is
>
> Von meinem iPhone gesendet
>
>> Am 11.05.2014 um 17:35 schrieb Noah Slater <ns...@apache.org>:
>>
>> Community,
>>
>> Please do take the time to review this document. It's not that long,
>> or that complex. An online reading time calculator said it's about 14
>> minutes long. Your input at this stage would be very beneficial for
>> the project. (Anyone!)
>>
>>
>>
>>> On 7 May 2014 21:07, Noah Slater <ns...@apache.org> wrote:
>>> Hello folks,
>>>
>>> Please review our propose bylaws:
>>>
>>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=40511017
>>>
>>> I'd like a few more eyeballs on this before I move to a vote.
>>>
>>> Thanks,
>>>
>>>
>>>> On 5 May 2014 18:35, 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.
>>>>
>>>> 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
>>>
>>>
>>>
>>> --
>>> Noah Slater
>>> https://twitter.com/nslater
>>
>>
>>
>> --
>> Noah Slater
>> https://twitter.com/nslater
--
Noah Slater
https://twitter.com/nslater
Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws)
Posted by Sebastian Rothbucher <se...@googlemail.com>.
+1
As it is
Von meinem iPhone gesendet
> Am 11.05.2014 um 17:35 schrieb Noah Slater <ns...@apache.org>:
>
> Community,
>
> Please do take the time to review this document. It's not that long,
> or that complex. An online reading time calculator said it's about 14
> minutes long. Your input at this stage would be very beneficial for
> the project. (Anyone!)
>
>
>
>> On 7 May 2014 21:07, Noah Slater <ns...@apache.org> wrote:
>> Hello folks,
>>
>> Please review our propose bylaws:
>>
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=40511017
>>
>> I'd like a few more eyeballs on this before I move to a vote.
>>
>> Thanks,
>>
>>
>>> On 5 May 2014 18:35, 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.
>>>
>>> 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
>>
>>
>>
>> --
>> Noah Slater
>> https://twitter.com/nslater
>
>
>
> --
> Noah Slater
> https://twitter.com/nslater
Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws)
Posted by Jason Smith <ja...@gmail.com>.
On Tue, May 20, 2014 at 9:44 PM, Dave Cottlehuber <dc...@jsonified.com> wrote:
>
> > On May 11, 2014, at 8:35, Noah Slater wrote:
> >
> > > Community,
> > >
> > > Please do take the time to review this document. It's not that long,
> > > or that complex. An online reading time calculator said it's about 14
> > > minutes long. Your input at this stage would be very beneficial for
> > > the project. (Anyone!)
>
> Thank-you to everybody who’s already contributed, it’s superb. I’ve a few
> small questions below. BTW pretty markdwon if you prefer that at
> https://gist.github.com/dch/5af1d123893b17a5d1ce .
> # ByLaws
>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=40511017
>
> # Re "2. Roles and Responsibilities"
>
> > "An inactive chair can be replaced by the PMC"
>
> Doesn't this actually require board approval for replacement? Technically
> this would be a recommendation of the PMC anyway to the board; do we need
> to note the difference?
>
> # Re "2.4. Project Management Committee"
>
> > "and that each and every release is the product of the community as a
> > whole. That is key to our litigation protection mechanisms."
>
> It might be worth clarifying (somewhere, maybe here) that a key part of the
> release process as PMC/committers is ensuring that the release contains
> only
> ALv2 licenced, or other appropriate licenced material. I was originally not
> aware of this important distinction.
>
> # Re "3.4. Vetos"
>
> > "Any change to the source code that we distribute in our official
> > releases".
>
> When is a veto a veto? e.g. if Q -1's my commit in (say) a proposed merge
> to
> master,
I believe the system is still commit-then-review, hence the wording about a
revert being necessary if the veto "passes."
> I'd assume that's a veto and then work with Q accordingly. Or is
> this section only referring to a -1 during the release cycle (in which case
> obv the RM would be waving a special flag).
>
My reading of it (which might be wrong) is basically any Git or Subversion
commit, i.e. anything that would make its way into a release artifact.
>
> # Re "3.5. Approval Models"
>
> > "Votes on PMC decisions are binding if they are cast by a PMC member"
>
> What is a "PMC Decision"? I assume electing a new committer/PMC
> member/chair
> only? Or does a release *also* fall into this category?
>
I interpreted this as anything labeled [VOTE] in the PMC discussion list.
Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project
bylaws)
Posted by Dave Cottlehuber <dc...@jsonified.com>.
> On May 11, 2014, at 8:35, Noah Slater wrote:
>
> > Community,
> >
> > Please do take the time to review this document. It's not that long,
> > or that complex. An online reading time calculator said it's about 14
> > minutes long. Your input at this stage would be very beneficial for
> > the project. (Anyone!)
Thank-you to everybody who’s already contributed, it’s superb. I’ve a few
small questions below. BTW pretty markdwon if you prefer that at
https://gist.github.com/dch/5af1d123893b17a5d1ce .
# ByLaws
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=40511017
# Re "2. Roles and Responsibilities"
> "An inactive chair can be replaced by the PMC"
Doesn't this actually require board approval for replacement? Technically
this would be a recommendation of the PMC anyway to the board; do we need
to note the difference?
# Re "2.4. Project Management Committee"
> "and that each and every release is the product of the community as a
> whole. That is key to our litigation protection mechanisms."
It might be worth clarifying (somewhere, maybe here) that a key part of the
release process as PMC/committers is ensuring that the release contains only
ALv2 licenced, or other appropriate licenced material. I was originally not
aware of this important distinction.
# Re "3.4. Vetos"
> "Any change to the source code that we distribute in our official
> releases".
When is a veto a veto? e.g. if Q -1's my commit in (say) a proposed merge to
master, I'd assume that's a veto and then work with Q accordingly. Or is
this section only referring to a -1 during the release cycle (in which case
obv the RM would be waving a special flag).
# Re "3.5. Approval Models"
> "Votes on PMC decisions are binding if they are cast by a PMC member"
What is a "PMC Decision"? I assume electing a new committer/PMC member/chair
only? Or does a release *also* fall into this category?
# Re "3.6. Decisions Types"
"Decision Types" reads better to me. YMMV, FFTI.
Is there a good reason for committers *not* to have a binding release vote?
It feels unfair.
— Dave Cottlehuber
dch@jsonified.com
Sent from my Couch
Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project
bylaws)
Posted by "Mutton, James" <jm...@akamai.com>.
Just read the current version, some small suggestions.
Section 2 (recommend add word identified by *)
"We expect you to know when to wear the appropriate hat, and when interacting with the project, to do so in *the* best interests of the…"
Section 3
Decisions should be made on the mailing list associated with the decision. e.g. Marketing decisions happen on the marketing list.
* i.e. is read as "that is” and used as a restatement. e.g. (read as "for example”) is probably more appropriate here.
Section 3.3 (recommend add word identified by *)
"All formal voting must be done in an email thread *with* the appropriate subject tag. “
Overall +1. The above are only minor, the content is great.
</JamesM>
On May 11, 2014, at 8:35, Noah Slater <ns...@apache.org> wrote:
> Community,
>
> Please do take the time to review this document. It's not that long,
> or that complex. An online reading time calculator said it's about 14
> minutes long. Your input at this stage would be very beneficial for
> the project. (Anyone!)
>
>
>
> On 7 May 2014 21:07, Noah Slater <ns...@apache.org> wrote:
>> Hello folks,
>>
>> Please review our propose bylaws:
>>
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=40511017
>>
>> I'd like a few more eyeballs on this before I move to a vote.
>>
>> Thanks,
>>
>>
>> On 5 May 2014 18:35, 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.
>>>
>>> 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
>>
>>
>>
>> --
>> Noah Slater
>> https://twitter.com/nslater
>
>
>
> --
> Noah Slater
> https://twitter.com/nslater
Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project
bylaws)
Posted by Joan Touzet <wo...@apache.org>.
I sent these to Noah during the mail server outage. Cc'ing the ML for
posterity.
Section 2:
- Link the text "the Apache Way" instead of "a set of common principles."
- "community should be *A* fun and rewarding place to be for everyone involved."
Section 3:
- Is there an ASF link for their definition of "hat?" This might be confusing to a non-English speaker. Even a glossary link - to explain that wearing a hat means playing a role, or acting within the expectations of that role.
- Possibly move the "hats" discussion to after you define all the different roles, I'm not sure.
- For the PMC Chair term, we should clarify whether consecutive means "more than 2 in a row" (unlike the US President) and whether that is calendar year, fiscal year, etc.
Section 4:
- Link to a definition of lazy consensus provided by the ASF or another project if available.
- Bold "silence is assent." This is a key thing people need to understanda bout lazy consensus.
- You might want to include the entire content of the +1/0/-1/fractions section from the apache.org link. Your definitions are different thana those stated.
- Explain who is allowed to veto - any user? Committer? PMC member? Is this on any PR? Any line of code? Any email to dev@? user@? Can a crackpot come by and -1 the entire project with an email to user@, requiring a vote for validity? ;) The definition of "change to code" is too broad as it stands in this document. The table shows challenging a veto but not the veto itself.
- Section 4.6 put "ASF Board approval" so it's clear what board we're talking about
Recommend adding links once this is done in this document to the proposed Code of Conduct and Diversity statements so that they have additional weight by being referenced by the bylaws.
-Joan
----- Original Message -----
From: "Noah Slater" <ns...@apache.org>
To: "Noah Slater" <ns...@apache.org>
Cc: dev@couchdb.apache.org
Sent: Sunday, May 11, 2014 11:35:21 AM
Subject: Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws)
Community,
Please do take the time to review this document. It's not that long,
or that complex. An online reading time calculator said it's about 14
minutes long. Your input at this stage would be very beneficial for
the project. (Anyone!)
On 7 May 2014 21:07, Noah Slater <ns...@apache.org> wrote:
> Hello folks,
>
> Please review our propose bylaws:
>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=40511017
>
> I'd like a few more eyeballs on this before I move to a vote.
>
> Thanks,
>
>
> On 5 May 2014 18:35, 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.
>>
>> 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
>
>
>
> --
> Noah Slater
> https://twitter.com/nslater
--
Noah Slater
https://twitter.com/nslater
Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws)
Posted by Noah Slater <ns...@apache.org>.
Community,
Please do take the time to review this document. It's not that long,
or that complex. An online reading time calculator said it's about 14
minutes long. Your input at this stage would be very beneficial for
the project. (Anyone!)
On 7 May 2014 21:07, Noah Slater <ns...@apache.org> wrote:
> Hello folks,
>
> Please review our propose bylaws:
>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=40511017
>
> I'd like a few more eyeballs on this before I move to a vote.
>
> Thanks,
>
>
> On 5 May 2014 18:35, 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.
>>
>> 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
>
>
>
> --
> Noah Slater
> https://twitter.com/nslater
--
Noah Slater
https://twitter.com/nslater
Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws)
Posted by Benoit Chesneau <bc...@gmail.com>.
On Thu, Jun 5, 2014 at 11:47 AM, Alexander Shorin <kx...@gmail.com> wrote:
> On Thu, Jun 5, 2014 at 10:17 AM, Joan Touzet <wo...@apache.org> wrote:
> > Proof by counterexample: I have been involved in a private gaming
> > community for a long time where the only rule was "be polite" / "don't
> > be an asshole". Recently it has been made painfully clear that, to some
> > people, being polite means it's OK to be sexist, racist, disparage
> > people who don't agree with you, villainize foreigners, and worse that
> > I won't bring to bear on this list.
>
> I'll quote myself:
>
> Being polite is a matter of etiquette; it's about respect, and being
> considerate of people's feelings, culture, and values. Polite and
> mannerly imply consideration for others and the adherence to
> conventional social standards of good behavior.
>
> This definition is from English Oxford dictionary explicitly conflicts with
> "being polite means it's OK to be sexist, racist, disparage people
> who don't agree with you, villainize foreigners, and worse that", so
> that's NOT OK or someone didn't understand words he says. Otherwise I
> could say the same about any statement of CoC: "sorry, I don't see any
> harassments, sexual attacks or disrespect in my words - you imagined
> all these problems by yourself because you psychologically prone to
> see these problems". But we all know that's not right way to go.
>
> Anyway, won't to insist on anything: just wanted to point on idea to
> provide simple and short rules description for people who knows what
> they doing and saying and who are on the same wave as we are. As for
> others the detailed explanation below is always available below which
> defines what we means under "being polite".
>
>
+1
Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project
bylaws)
Posted by Joan Touzet <wo...@apache.org>.
Look up "damning with faint praise." That is technically polite but is
unacceptable behaviour for our project. It is a way of acting that, on
the surface, is completely "considerate of people's feelings, culture
and values" leaving "plausible denyability" but has malicious intent.
Something that is on the surface polite but has undertones of disrespect
is unacceptable.
-Joan
On Thu, Jun 05, 2014 at 01:47:11PM +0400, Alexander Shorin wrote:
> On Thu, Jun 5, 2014 at 10:17 AM, Joan Touzet <wo...@apache.org> wrote:
> > Proof by counterexample: I have been involved in a private gaming
> > community for a long time where the only rule was "be polite" / "don't
> > be an asshole". Recently it has been made painfully clear that, to some
> > people, being polite means it's OK to be sexist, racist, disparage
> > people who don't agree with you, villainize foreigners, and worse that
> > I won't bring to bear on this list.
>
> I'll quote myself:
>
> Being polite is a matter of etiquette; it's about respect, and being
> considerate of people's feelings, culture, and values. Polite and
> mannerly imply consideration for others and the adherence to
> conventional social standards of good behavior.
>
> This definition is from English Oxford dictionary explicitly conflicts with
> "being polite means it's OK to be sexist, racist, disparage people
> who don't agree with you, villainize foreigners, and worse that", so
> that's NOT OK or someone didn't understand words he says. Otherwise I
> could say the same about any statement of CoC: "sorry, I don't see any
> harassments, sexual attacks or disrespect in my words - you imagined
> all these problems by yourself because you psychologically prone to
> see these problems". But we all know that's not right way to go.
>
> Anyway, won't to insist on anything: just wanted to point on idea to
> provide simple and short rules description for people who knows what
> they doing and saying and who are on the same wave as we are. As for
> others the detailed explanation below is always available below which
> defines what we means under "being polite".
>
>
> --
> ,,,^..^,,,
--
Joan Touzet | joant@atypical.net | wohali everywhere else
Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws)
Posted by Alexander Shorin <kx...@gmail.com>.
On Thu, Jun 5, 2014 at 10:17 AM, Joan Touzet <wo...@apache.org> wrote:
> Proof by counterexample: I have been involved in a private gaming
> community for a long time where the only rule was "be polite" / "don't
> be an asshole". Recently it has been made painfully clear that, to some
> people, being polite means it's OK to be sexist, racist, disparage
> people who don't agree with you, villainize foreigners, and worse that
> I won't bring to bear on this list.
I'll quote myself:
Being polite is a matter of etiquette; it's about respect, and being
considerate of people's feelings, culture, and values. Polite and
mannerly imply consideration for others and the adherence to
conventional social standards of good behavior.
This definition is from English Oxford dictionary explicitly conflicts with
"being polite means it's OK to be sexist, racist, disparage people
who don't agree with you, villainize foreigners, and worse that", so
that's NOT OK or someone didn't understand words he says. Otherwise I
could say the same about any statement of CoC: "sorry, I don't see any
harassments, sexual attacks or disrespect in my words - you imagined
all these problems by yourself because you psychologically prone to
see these problems". But we all know that's not right way to go.
Anyway, won't to insist on anything: just wanted to point on idea to
provide simple and short rules description for people who knows what
they doing and saying and who are on the same wave as we are. As for
others the detailed explanation below is always available below which
defines what we means under "being polite".
--
,,,^..^,,,
Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws)
Posted by Benoit Chesneau <bc...@gmail.com>.
just for the sake sanity, forgetting the "philosophical" approach which is
not totally the point here. I think i would be for having the following
order in handling communities interactions:
CoC > By laws
Where I would relegate the "by laws" as a contributing guide document. I am
actually -0 on the current form.
The content of the current document is ok for me though I would remove the
notion of empathy and simply link to the coc and diversity guidelines
removing any attempts in the future for people to define who is more
empathic than the other. I would also add a part to manage discussions by
themselves and define how/when they should close in a graceful manner. (I
proposed that in an early mail).
Thoughts?
- benoit
On Thu, Jun 5, 2014 at 11:11 AM, Benoit Chesneau <bc...@gmail.com>
wrote:
>
>
>
> On Thu, Jun 5, 2014 at 10:49 AM, Benoit Chesneau <bc...@gmail.com>
> wrote:
>
>>
>>
>>
>> On Thu, Jun 5, 2014 at 8:17 AM, Joan Touzet <wo...@apache.org> wrote:
>>
>>> ----- Original Message -----
>>> From: "Alexander Shorin" <kx...@gmail.com>
>>>
>>> > Well, mostly all CoC points could be replaced by single sentence: "Be
>>> polite.":
>>>
>>> Being polite is insufficiently rich to describe what we expect from
>>> people. I also explained why I didn't use polite in a previous thread
>>> as well (or it might have been IRC, I forget now.)
>>>
>>> Proof by counterexample: I have been involved in a private gaming
>>> community for a long time where the only rule was "be polite" / "don't
>>> be an asshole". Recently it has been made painfully clear that, to some
>>> people, being polite means it's OK to be sexist, racist, disparage
>>> people who don't agree with you, villainize foreigners, and worse that
>>> I won't bring to bear on this list.
>>>
>>> This is even worse when people are "polite" on a mailing list but still
>>> harbor ill will behind a surface of politeness.
>>>
>>
>> This question always raised the question about who is right on naming
>> thing. Who has more empathy than the others. If you really think that by
>> laws will solve that you're wrong. However only politeness and respect of
>> the other will make it possible to discuss between each other. Even though
>> who disagree with. And this is why it's important to have the respect of
>> the other made as a rule, a conduct. Empathy is too emotionally charged and
>> doesn't take in consideration the ego (in its pure definition) of each
>> parts. It is also creating a new way to control people and reject the
>> differences by applying a varnish on it, saying that diversity is about
>> having people at the same level.
>>
>> There is a lot of literature about it. First by reading "brave new world"
>> from Huxkley. This paper also summarise it:
>>
>
> huxley of course...
>
>> > P.S. the word "polite" mentioned zero times on code of conduct page.
>>>
>>> See above. Saying "be polite" is only the start of a longer
>>> conversation, one we've been having for years now in various places --
>>> and one that shows that not everyone has the same level of understanding.
>>>
>>> I am -1 on any reductionist single-sentence approach as it
>>> will simply leave too many loopholes. We should not be placed in a
>>> position where we must have semantic arguments about what I think
>>> polite means vs. what you think polite means. Given the difficulties
>>> CouchDB has had as a community over the years, we must necessarily be
>>> explicit in the list of what we do and do not tolerate. If that list
>>> proves insufficient we need to grow it over time.
>>>
>>> -Joan
>>>
>>
>>
>> A quick note about that but all the discussion in communities about
>> having by-laws and rules have finished by agreeing in a short version of
>> them. Most of the time by only using a Coc as a way to define the social
>> agreement and a list of guidelines aside on how to manage discussions and
>> other stuff related to the project. Most of the time in the form of an
>> extensive contributing document.
>>
>
>
> I wanted to say "most of the discussions" , all in the communities i am a
> member (even the PSF) or i joined.
>
> - benoit
>
Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws)
Posted by Benoit Chesneau <bc...@gmail.com>.
On Thu, Jun 5, 2014 at 10:49 AM, Benoit Chesneau <bc...@gmail.com>
wrote:
>
>
>
> On Thu, Jun 5, 2014 at 8:17 AM, Joan Touzet <wo...@apache.org> wrote:
>
>> ----- Original Message -----
>> From: "Alexander Shorin" <kx...@gmail.com>
>>
>> > Well, mostly all CoC points could be replaced by single sentence: "Be
>> polite.":
>>
>> Being polite is insufficiently rich to describe what we expect from
>> people. I also explained why I didn't use polite in a previous thread
>> as well (or it might have been IRC, I forget now.)
>>
>> Proof by counterexample: I have been involved in a private gaming
>> community for a long time where the only rule was "be polite" / "don't
>> be an asshole". Recently it has been made painfully clear that, to some
>> people, being polite means it's OK to be sexist, racist, disparage
>> people who don't agree with you, villainize foreigners, and worse that
>> I won't bring to bear on this list.
>>
>> This is even worse when people are "polite" on a mailing list but still
>> harbor ill will behind a surface of politeness.
>>
>
> This question always raised the question about who is right on naming
> thing. Who has more empathy than the others. If you really think that by
> laws will solve that you're wrong. However only politeness and respect of
> the other will make it possible to discuss between each other. Even though
> who disagree with. And this is why it's important to have the respect of
> the other made as a rule, a conduct. Empathy is too emotionally charged and
> doesn't take in consideration the ego (in its pure definition) of each
> parts. It is also creating a new way to control people and reject the
> differences by applying a varnish on it, saying that diversity is about
> having people at the same level.
>
> There is a lot of literature about it. First by reading "brave new world"
> from Huxkley. This paper also summarise it:
>
huxley of course...
> > P.S. the word "polite" mentioned zero times on code of conduct page.
>>
>> See above. Saying "be polite" is only the start of a longer
>> conversation, one we've been having for years now in various places --
>> and one that shows that not everyone has the same level of understanding.
>>
>> I am -1 on any reductionist single-sentence approach as it
>> will simply leave too many loopholes. We should not be placed in a
>> position where we must have semantic arguments about what I think
>> polite means vs. what you think polite means. Given the difficulties
>> CouchDB has had as a community over the years, we must necessarily be
>> explicit in the list of what we do and do not tolerate. If that list
>> proves insufficient we need to grow it over time.
>>
>> -Joan
>>
>
>
> A quick note about that but all the discussion in communities about having
> by-laws and rules have finished by agreeing in a short version of them.
> Most of the time by only using a Coc as a way to define the social
> agreement and a list of guidelines aside on how to manage discussions and
> other stuff related to the project. Most of the time in the form of an
> extensive contributing document.
>
I wanted to say "most of the discussions" , all in the communities i am a
member (even the PSF) or i joined.
- benoit
Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws)
Posted by Jan Lehnardt <ja...@apache.org>.
What Joan said.
On 05 Jun 2014, at 12:23 , Joan Touzet <wo...@apache.org> wrote:
> On Thu, Jun 05, 2014 at 10:49:49AM +0200, Benoit Chesneau wrote:
>> This question always raised the question about who is right on naming
>> thing. Who has more empathy than the others. If you really think that by
>> laws will solve that you're wrong.
>
> CoC aren't about stopping people. They are for outlining what is
> acceptable and uancceptable behaviour. They are a ruler against which,
> when conflict occurs, human action can be compared. Just because thye
> exist will not stop people from acting badly, but that does not mean the
> exercise of writing them or enforcing them is pointless.
>
>> However only politeness and respect of
>> the other will make it possible to discuss between each other. Even though
>> who disagree with. And this is why it's important to have the respect of
>> the other made as a rule, a conduct.
>
> There is the concept of respect already in the text. If people feel
> strongly they want to add politeness, fine, but it should not be the
> *only* word used.
>
>> Empathy is too emotionally charged and
>
> But humans are emotional. We need text in the CoC that addresses what to
> do when people get emotional. Respect is often limited to a logical
> approach to a situation and does not begin to cover emotional awareness
> and understanding. As a result we need to go farther than just
> politeness or respect and include the concept of empathy.
>
>> It is also creating a new way to control people and reject the
>> differences by applying a varnish on it, saying that diversity is about
>> having people at the same level.
>
> I'm not sure I follow here. Emotional awareness is not control, it is a
> reminder to people in the community that emotion is a part of human
> interaction, and that it must be taken into consideration when making
> public statements. Working positively necessarily requires understanding
> of the emotional state of those you're talking to; we cannot presume to
> have interaction devoid of normal (or abnormal!) human behaviour.
>
>> There is a lot of literature about it. First by reading "brave new world"
>> from Huxkley.I
>
> I have indeed read Huxley. I am not suggesting that everyone be happy
> all the time, or that we avoid conflict, or that we intentionally drug
> people into positive mental attitude or browbeat people into acceptance
> of everything. I am stating that recognition of emotional state is
> critical to supportive discussion.
>
> This paper also summarise it:
>> http://www.newyorker.com/arts/critics/atlarge/2013/05/20/130520crat_atlarge_bloom?currentPage=all
>
> From that same article:
>
> "That’s not a call for a world without empathy. The problem with those
> who are devoid of empathy is that, although they may recognize what’s
> right, they have no motivation to act upon it. Some spark of
> fellow-feeling is needed to convert intelligence into action."
>
> "Where empathy really does matter is in our personal relationships.
> Nobody wants to live like Thomas Gradgrind—Charles Dickens’s caricature
> utilitarian, who treats all interactions, including those with his
> children, in explicitly economic terms. Empathy is what makes us human;
> it’s what makes us both subjects and objects of moral concern. Empathy
> betrays us only when we take it as a moral guide."
>
> Again I am not suggesting that list members *only* use empathy to guide
> their moral compass. I am stating that we cannot operate without empathy
> lest callous attitudes defined on purely logical approaches trample
> valid concerns that are, at their foundation, emotional and not logical.
> Just because it's software doesn't mean that everything about it, in
> code, documentation, design and usage, is also just 1s and 0s. We are
> not robots, nor are we Star Trek's Mr. Spock. We should not aspire to
> interact on this mailing list as if we were purely emotionless beings.
> If that is true, then awareness of others' emotional state, and use of
> that to be open, welcoming, friendly, patient, collaborative, concise,
> careful in how we speak and yes, respectful is critical.
>
>> A quick note about that but all the discussion in communities about having
>> by-laws and rules have finished by agreeing in a short version of them.
>
> I am -0 on that but -1 on reducing it to a single sentence. If you feel
> strongly about having a shorter version of the bylaws or of the CoC,
> please propose some text.
>
> --
> Joan Touzet | joant@atypical.net | wohali everywhere else
Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws)
Posted by Noah Slater <ns...@apache.org>.
I will add a few bullet points that capture the "spirit" of the
bylaws, but are not concrete enough to be mistaken for rules. Let's
see how that looks and decide whether we want to keep them.
On 5 June 2014 14:01, Robert Samuel Newson <rn...@apache.org> wrote:
> I see Benoit’s point about "empathy" though not because it is "emotionally charged" but because it is somewhat ambiguous. I have no objection to the text of item in the CoC which uses the term, though. I am interested in seeing proposed alternate text, though.
>
> B.
>
> P.S As he’s one of my favourite authors, and this is one of his best books (Island is his best), Huxley was no more advocating against empathy than the Savage was advocating for venereal disease.
>
>
> On 5 Jun 2014, at 12:22, Benoit Chesneau <bc...@gmail.com> wrote:
>
>> On Thu, Jun 5, 2014 at 12:23 PM, Joan Touzet <wo...@apache.org> wrote:
>>
>>> On Thu, Jun 05, 2014 at 10:49:49AM +0200, Benoit Chesneau wrote:
>>>> This question always raised the question about who is right on naming
>>>> thing. Who has more empathy than the others. If you really think that by
>>>> laws will solve that you're wrong.
>>>
>>> CoC aren't about stopping people. They are for outlining what is
>>> acceptable and uancceptable behaviour. They are a ruler against which,
>>> when conflict occurs, human action can be compared. Just because thye
>>> exist will not stop people from acting badly, but that does not mean the
>>> exercise of writing them or enforcing them is pointless.
>>>
>>>> However only politeness and respect of
>>>> the other will make it possible to discuss between each other. Even
>>> though
>>>> who disagree with. And this is why it's important to have the respect of
>>>> the other made as a rule, a conduct.
>>>
>>> There is the concept of respect already in the text. If people feel
>>> strongly they want to add politeness, fine, but it should not be the
>>> *only* word used.
>>>
>>>> Empathy is too emotionally charged and
>>>
>>> But humans are emotional. We need text in the CoC that addresses what to
>>> do when people get emotional. Respect is often limited to a logical
>>> approach to a situation and does not begin to cover emotional awareness
>>> and understanding. As a result we need to go farther than just
>>> politeness or respect and include the concept of empathy.
>>>
>>>> It is also creating a new way to control people and reject the
>>>> differences by applying a varnish on it, saying that diversity is about
>>>> having people at the same level.
>>>
>>> I'm not sure I follow here. Emotional awareness is not control, it is a
>>> reminder to people in the community that emotion is a part of human
>>> interaction, and that it must be taken into consideration when making
>>> public statements. Working positively necessarily requires understanding
>>> of the emotional state of those you're talking to; we cannot presume to
>>> have interaction devoid of normal (or abnormal!) human behaviour.
>>
>>
>>>> There is a lot of literature about it. First by reading "brave new world"
>>>> from Huxkley.I
>>>
>>> I have indeed read Huxley. I am not suggesting that everyone be happy
>>> all the time, or that we avoid conflict, or that we intentionally drug
>>> people into positive mental attitude or browbeat people into acceptance
>>> of everything. I am stating that recognition of emotional state is
>>> critical to supportive discussion.
>>>
>>> This paper also summarise it:
>>>>
>>> http://www.newyorker.com/arts/critics/atlarge/2013/05/20/130520crat_atlarge_bloom?currentPage=all
>>>
>>> From that same article:
>>>
>>> "That’s not a call for a world without empathy. The problem with those
>>> who are devoid of empathy is that, although they may recognize what’s
>>> right, they have no motivation to act upon it. Some spark of
>>> fellow-feeling is needed to convert intelligence into action."
>>>
>>> "Where empathy really does matter is in our personal relationships.
>>> Nobody wants to live like Thomas Gradgrind—Charles Dickens’s caricature
>>> utilitarian, who treats all interactions, including those with his
>>> children, in explicitly economic terms. Empathy is what makes us human;
>>> it’s what makes us both subjects and objects of moral concern. Empathy
>>> betrays us only when we take it as a moral guide."
>>>
>>> Again I am not suggesting that list members *only* use empathy to guide
>>> their moral compass. I am stating that we cannot operate without empathy
>>> lest callous attitudes defined on purely logical approaches trample
>>> valid concerns that are, at their foundation, emotional and not logical.
>>> Just because it's software doesn't mean that everything about it, in
>>> code, documentation, design and usage, is also just 1s and 0s. We are
>>> not robots, nor are we Star Trek's Mr. Spock. We should not aspire to
>>> interact on this mailing list as if we were purely emotionless beings.
>>> If that is true, then awareness of others' emotional state, and use of
>>> that to be open, welcoming, friendly, patient, collaborative, concise,
>>> careful in how we speak and yes, respectful is critical.
>>
>>
>>
>>>> A quick note about that but all the discussion in communities about
>>> having
>>>> by-laws and rules have finished by agreeing in a short version of them.
>>>
>>> I am -0 on that but -1 on reducing it to a single sentence. If you feel
>>> strongly about having a shorter version of the bylaws or of the CoC,
>>> please propose some text.
>>>
>>>
>> Who will be the more empathic in these discussions. The first one that
>> denounce a lack of empathy? Or the other one that disagree with the other?
>> Will it be because most active participant will declare it? See using a
>> vague concept of emotional awareness won't prevent the discussion of this
>> awareness Of who is the more aware. Where respect, trust of the other,
>> honesty, beeing polite make sure that people exchange in confidence. In
>> short thinking that the other discuss only for the good Which also imply
>> that you have to understand that the other may not be aware you're in a bad
>> mood and doesn't have too. I am not speaking about being logical or beeing
>> a robot but to respect the other and know he can disagree. Which imply to
>> let him his chance, trusting him, that he is thinking the good for the
>> project. People don't have to be your friends to speak about the project.
>> Especially over a mail or a chat.
>>
>> Anyway no need to discuss more. I wanted to point the danger of introducing
>> this vague concept of empathy. I see why it's introduced, but i am worried
>> it endanger more the community than anything in near future.
>>
>> I already proposed some additions to the text which can be
>> reviewed/discussed before i add anything but I will provide a diff
>> reflecting my thinking until monday.
>>
>>
>> - benoit.
>
--
Noah Slater
https://twitter.com/nslater
Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws)
Posted by Benoit Chesneau <bc...@gmail.com>.
On Sat, Jul 19, 2014 at 10:55 AM, Benoit Chesneau <bc...@gmail.com> wrote:
> Sorry for the delay. I don't have access to the confluence website
> neither I see a simple way to patch it so here is my proposal on the
> point 2. I would replace it with:
>
> Be honest, welcoming, friendly, and patient: We work together to
> resolve conflict, assume good intentions, and do our best to act in an
> empathetic fashion. We may all experience some frustration from time
> to time, but we do not allow frustration to turn into a personal
> attack. A community where people feel uncomfortable or threatened is
> not a productive one. We should be respectful when dealing with other
> community members as well as with people outside our community.
Sorry the full text is:
Be honest, welcoming, friendly, and patient: We work together to
resolve conflict, assume good intentions, and do our best to trust each others.
We may all experience some frustration from time
to time, but we do not allow frustration to turn into a personal
attack. A community where people feel uncomfortable or threatened is
not a productive one. We should be respectful when dealing with other
community members as well as with people outside our community.
Opening a new thread about that to discuss the proposal.
- benoit
Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws)
Posted by Benoit Chesneau <bc...@gmail.com>.
Sorry for the delay. I don't have access to the confluence website
neither I see a simple way to patch it so here is my proposal on the
point 2. I would replace it with:
Be honest, welcoming, friendly, and patient: We work together to
resolve conflict, assume good intentions, and do our best to act in an
empathetic fashion. We may all experience some frustration from time
to time, but we do not allow frustration to turn into a personal
attack. A community where people feel uncomfortable or threatened is
not a productive one. We should be respectful when dealing with other
community members as well as with people outside our community.
Note that I replaced empathy (which is a vague concept in many
culture) by honest. Imo the words "honest, welcoming, friendly, and
patient" are defining what could be empathy in many cultures and
doesn't rely on interpretation. The idea came from a conversation with
Katie Miller at the EUC, but never had time to post it here...
Is this OK for you?
The rest is fine for me.
- benoit
On Thu, Jun 5, 2014 at 2:01 PM, Robert Samuel Newson <rn...@apache.org> wrote:
> I see Benoit’s point about "empathy" though not because it is "emotionally charged" but because it is somewhat ambiguous. I have no objection to the text of item in the CoC which uses the term, though. I am interested in seeing proposed alternate text, though.
>
> B.
>
> P.S As he’s one of my favourite authors, and this is one of his best books (Island is his best), Huxley was no more advocating against empathy than the Savage was advocating for venereal disease.
>
>
> On 5 Jun 2014, at 12:22, Benoit Chesneau <bc...@gmail.com> wrote:
>
>> On Thu, Jun 5, 2014 at 12:23 PM, Joan Touzet <wo...@apache.org> wrote:
>>
>>> On Thu, Jun 05, 2014 at 10:49:49AM +0200, Benoit Chesneau wrote:
>>>> This question always raised the question about who is right on naming
>>>> thing. Who has more empathy than the others. If you really think that by
>>>> laws will solve that you're wrong.
>>>
>>> CoC aren't about stopping people. They are for outlining what is
>>> acceptable and uancceptable behaviour. They are a ruler against which,
>>> when conflict occurs, human action can be compared. Just because thye
>>> exist will not stop people from acting badly, but that does not mean the
>>> exercise of writing them or enforcing them is pointless.
>>>
>>>> However only politeness and respect of
>>>> the other will make it possible to discuss between each other. Even
>>> though
>>>> who disagree with. And this is why it's important to have the respect of
>>>> the other made as a rule, a conduct.
>>>
>>> There is the concept of respect already in the text. If people feel
>>> strongly they want to add politeness, fine, but it should not be the
>>> *only* word used.
>>>
>>>> Empathy is too emotionally charged and
>>>
>>> But humans are emotional. We need text in the CoC that addresses what to
>>> do when people get emotional. Respect is often limited to a logical
>>> approach to a situation and does not begin to cover emotional awareness
>>> and understanding. As a result we need to go farther than just
>>> politeness or respect and include the concept of empathy.
>>>
>>>> It is also creating a new way to control people and reject the
>>>> differences by applying a varnish on it, saying that diversity is about
>>>> having people at the same level.
>>>
>>> I'm not sure I follow here. Emotional awareness is not control, it is a
>>> reminder to people in the community that emotion is a part of human
>>> interaction, and that it must be taken into consideration when making
>>> public statements. Working positively necessarily requires understanding
>>> of the emotional state of those you're talking to; we cannot presume to
>>> have interaction devoid of normal (or abnormal!) human behaviour.
>>
>>
>>>> There is a lot of literature about it. First by reading "brave new world"
>>>> from Huxkley.I
>>>
>>> I have indeed read Huxley. I am not suggesting that everyone be happy
>>> all the time, or that we avoid conflict, or that we intentionally drug
>>> people into positive mental attitude or browbeat people into acceptance
>>> of everything. I am stating that recognition of emotional state is
>>> critical to supportive discussion.
>>>
>>> This paper also summarise it:
>>>>
>>> http://www.newyorker.com/arts/critics/atlarge/2013/05/20/130520crat_atlarge_bloom?currentPage=all
>>>
>>> From that same article:
>>>
>>> "That’s not a call for a world without empathy. The problem with those
>>> who are devoid of empathy is that, although they may recognize what’s
>>> right, they have no motivation to act upon it. Some spark of
>>> fellow-feeling is needed to convert intelligence into action."
>>>
>>> "Where empathy really does matter is in our personal relationships.
>>> Nobody wants to live like Thomas Gradgrind—Charles Dickens’s caricature
>>> utilitarian, who treats all interactions, including those with his
>>> children, in explicitly economic terms. Empathy is what makes us human;
>>> it’s what makes us both subjects and objects of moral concern. Empathy
>>> betrays us only when we take it as a moral guide."
>>>
>>> Again I am not suggesting that list members *only* use empathy to guide
>>> their moral compass. I am stating that we cannot operate without empathy
>>> lest callous attitudes defined on purely logical approaches trample
>>> valid concerns that are, at their foundation, emotional and not logical.
>>> Just because it's software doesn't mean that everything about it, in
>>> code, documentation, design and usage, is also just 1s and 0s. We are
>>> not robots, nor are we Star Trek's Mr. Spock. We should not aspire to
>>> interact on this mailing list as if we were purely emotionless beings.
>>> If that is true, then awareness of others' emotional state, and use of
>>> that to be open, welcoming, friendly, patient, collaborative, concise,
>>> careful in how we speak and yes, respectful is critical.
>>
>>
>>
>>>> A quick note about that but all the discussion in communities about
>>> having
>>>> by-laws and rules have finished by agreeing in a short version of them.
>>>
>>> I am -0 on that but -1 on reducing it to a single sentence. If you feel
>>> strongly about having a shorter version of the bylaws or of the CoC,
>>> please propose some text.
>>>
>>>
>> Who will be the more empathic in these discussions. The first one that
>> denounce a lack of empathy? Or the other one that disagree with the other?
>> Will it be because most active participant will declare it? See using a
>> vague concept of emotional awareness won't prevent the discussion of this
>> awareness Of who is the more aware. Where respect, trust of the other,
>> honesty, beeing polite make sure that people exchange in confidence. In
>> short thinking that the other discuss only for the good Which also imply
>> that you have to understand that the other may not be aware you're in a bad
>> mood and doesn't have too. I am not speaking about being logical or beeing
>> a robot but to respect the other and know he can disagree. Which imply to
>> let him his chance, trusting him, that he is thinking the good for the
>> project. People don't have to be your friends to speak about the project.
>> Especially over a mail or a chat.
>>
>> Anyway no need to discuss more. I wanted to point the danger of introducing
>> this vague concept of empathy. I see why it's introduced, but i am worried
>> it endanger more the community than anything in near future.
>>
>> I already proposed some additions to the text which can be
>> reviewed/discussed before i add anything but I will provide a diff
>> reflecting my thinking until monday.
>>
>>
>> - benoit.
>
Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws)
Posted by Robert Samuel Newson <rn...@apache.org>.
I see Benoit’s point about "empathy" though not because it is "emotionally charged" but because it is somewhat ambiguous. I have no objection to the text of item in the CoC which uses the term, though. I am interested in seeing proposed alternate text, though.
B.
P.S As he’s one of my favourite authors, and this is one of his best books (Island is his best), Huxley was no more advocating against empathy than the Savage was advocating for venereal disease.
On 5 Jun 2014, at 12:22, Benoit Chesneau <bc...@gmail.com> wrote:
> On Thu, Jun 5, 2014 at 12:23 PM, Joan Touzet <wo...@apache.org> wrote:
>
>> On Thu, Jun 05, 2014 at 10:49:49AM +0200, Benoit Chesneau wrote:
>>> This question always raised the question about who is right on naming
>>> thing. Who has more empathy than the others. If you really think that by
>>> laws will solve that you're wrong.
>>
>> CoC aren't about stopping people. They are for outlining what is
>> acceptable and uancceptable behaviour. They are a ruler against which,
>> when conflict occurs, human action can be compared. Just because thye
>> exist will not stop people from acting badly, but that does not mean the
>> exercise of writing them or enforcing them is pointless.
>>
>>> However only politeness and respect of
>>> the other will make it possible to discuss between each other. Even
>> though
>>> who disagree with. And this is why it's important to have the respect of
>>> the other made as a rule, a conduct.
>>
>> There is the concept of respect already in the text. If people feel
>> strongly they want to add politeness, fine, but it should not be the
>> *only* word used.
>>
>>> Empathy is too emotionally charged and
>>
>> But humans are emotional. We need text in the CoC that addresses what to
>> do when people get emotional. Respect is often limited to a logical
>> approach to a situation and does not begin to cover emotional awareness
>> and understanding. As a result we need to go farther than just
>> politeness or respect and include the concept of empathy.
>>
>>> It is also creating a new way to control people and reject the
>>> differences by applying a varnish on it, saying that diversity is about
>>> having people at the same level.
>>
>> I'm not sure I follow here. Emotional awareness is not control, it is a
>> reminder to people in the community that emotion is a part of human
>> interaction, and that it must be taken into consideration when making
>> public statements. Working positively necessarily requires understanding
>> of the emotional state of those you're talking to; we cannot presume to
>> have interaction devoid of normal (or abnormal!) human behaviour.
>
>
>>> There is a lot of literature about it. First by reading "brave new world"
>>> from Huxkley.I
>>
>> I have indeed read Huxley. I am not suggesting that everyone be happy
>> all the time, or that we avoid conflict, or that we intentionally drug
>> people into positive mental attitude or browbeat people into acceptance
>> of everything. I am stating that recognition of emotional state is
>> critical to supportive discussion.
>>
>> This paper also summarise it:
>>>
>> http://www.newyorker.com/arts/critics/atlarge/2013/05/20/130520crat_atlarge_bloom?currentPage=all
>>
>> From that same article:
>>
>> "That’s not a call for a world without empathy. The problem with those
>> who are devoid of empathy is that, although they may recognize what’s
>> right, they have no motivation to act upon it. Some spark of
>> fellow-feeling is needed to convert intelligence into action."
>>
>> "Where empathy really does matter is in our personal relationships.
>> Nobody wants to live like Thomas Gradgrind—Charles Dickens’s caricature
>> utilitarian, who treats all interactions, including those with his
>> children, in explicitly economic terms. Empathy is what makes us human;
>> it’s what makes us both subjects and objects of moral concern. Empathy
>> betrays us only when we take it as a moral guide."
>>
>> Again I am not suggesting that list members *only* use empathy to guide
>> their moral compass. I am stating that we cannot operate without empathy
>> lest callous attitudes defined on purely logical approaches trample
>> valid concerns that are, at their foundation, emotional and not logical.
>> Just because it's software doesn't mean that everything about it, in
>> code, documentation, design and usage, is also just 1s and 0s. We are
>> not robots, nor are we Star Trek's Mr. Spock. We should not aspire to
>> interact on this mailing list as if we were purely emotionless beings.
>> If that is true, then awareness of others' emotional state, and use of
>> that to be open, welcoming, friendly, patient, collaborative, concise,
>> careful in how we speak and yes, respectful is critical.
>
>
>
>>> A quick note about that but all the discussion in communities about
>> having
>>> by-laws and rules have finished by agreeing in a short version of them.
>>
>> I am -0 on that but -1 on reducing it to a single sentence. If you feel
>> strongly about having a shorter version of the bylaws or of the CoC,
>> please propose some text.
>>
>>
> Who will be the more empathic in these discussions. The first one that
> denounce a lack of empathy? Or the other one that disagree with the other?
> Will it be because most active participant will declare it? See using a
> vague concept of emotional awareness won't prevent the discussion of this
> awareness Of who is the more aware. Where respect, trust of the other,
> honesty, beeing polite make sure that people exchange in confidence. In
> short thinking that the other discuss only for the good Which also imply
> that you have to understand that the other may not be aware you're in a bad
> mood and doesn't have too. I am not speaking about being logical or beeing
> a robot but to respect the other and know he can disagree. Which imply to
> let him his chance, trusting him, that he is thinking the good for the
> project. People don't have to be your friends to speak about the project.
> Especially over a mail or a chat.
>
> Anyway no need to discuss more. I wanted to point the danger of introducing
> this vague concept of empathy. I see why it's introduced, but i am worried
> it endanger more the community than anything in near future.
>
> I already proposed some additions to the text which can be
> reviewed/discussed before i add anything but I will provide a diff
> reflecting my thinking until monday.
>
>
> - benoit.
Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws)
Posted by Benoit Chesneau <bc...@gmail.com>.
On Thu, Jun 5, 2014 at 12:23 PM, Joan Touzet <wo...@apache.org> wrote:
> On Thu, Jun 05, 2014 at 10:49:49AM +0200, Benoit Chesneau wrote:
> > This question always raised the question about who is right on naming
> > thing. Who has more empathy than the others. If you really think that by
> > laws will solve that you're wrong.
>
> CoC aren't about stopping people. They are for outlining what is
> acceptable and uancceptable behaviour. They are a ruler against which,
> when conflict occurs, human action can be compared. Just because thye
> exist will not stop people from acting badly, but that does not mean the
> exercise of writing them or enforcing them is pointless.
>
> > However only politeness and respect of
> > the other will make it possible to discuss between each other. Even
> though
> > who disagree with. And this is why it's important to have the respect of
> > the other made as a rule, a conduct.
>
> There is the concept of respect already in the text. If people feel
> strongly they want to add politeness, fine, but it should not be the
> *only* word used.
>
> > Empathy is too emotionally charged and
>
> But humans are emotional. We need text in the CoC that addresses what to
> do when people get emotional. Respect is often limited to a logical
> approach to a situation and does not begin to cover emotional awareness
> and understanding. As a result we need to go farther than just
> politeness or respect and include the concept of empathy.
>
> > It is also creating a new way to control people and reject the
> > differences by applying a varnish on it, saying that diversity is about
> > having people at the same level.
>
> I'm not sure I follow here. Emotional awareness is not control, it is a
> reminder to people in the community that emotion is a part of human
> interaction, and that it must be taken into consideration when making
> public statements. Working positively necessarily requires understanding
> of the emotional state of those you're talking to; we cannot presume to
> have interaction devoid of normal (or abnormal!) human behaviour.
> > There is a lot of literature about it. First by reading "brave new world"
> > from Huxkley.I
>
> I have indeed read Huxley. I am not suggesting that everyone be happy
> all the time, or that we avoid conflict, or that we intentionally drug
> people into positive mental attitude or browbeat people into acceptance
> of everything. I am stating that recognition of emotional state is
> critical to supportive discussion.
>
> This paper also summarise it:
> >
> http://www.newyorker.com/arts/critics/atlarge/2013/05/20/130520crat_atlarge_bloom?currentPage=all
>
> From that same article:
>
> "That’s not a call for a world without empathy. The problem with those
> who are devoid of empathy is that, although they may recognize what’s
> right, they have no motivation to act upon it. Some spark of
> fellow-feeling is needed to convert intelligence into action."
>
> "Where empathy really does matter is in our personal relationships.
> Nobody wants to live like Thomas Gradgrind—Charles Dickens’s caricature
> utilitarian, who treats all interactions, including those with his
> children, in explicitly economic terms. Empathy is what makes us human;
> it’s what makes us both subjects and objects of moral concern. Empathy
> betrays us only when we take it as a moral guide."
>
> Again I am not suggesting that list members *only* use empathy to guide
> their moral compass. I am stating that we cannot operate without empathy
> lest callous attitudes defined on purely logical approaches trample
> valid concerns that are, at their foundation, emotional and not logical.
> Just because it's software doesn't mean that everything about it, in
> code, documentation, design and usage, is also just 1s and 0s. We are
> not robots, nor are we Star Trek's Mr. Spock. We should not aspire to
> interact on this mailing list as if we were purely emotionless beings.
> If that is true, then awareness of others' emotional state, and use of
> that to be open, welcoming, friendly, patient, collaborative, concise,
> careful in how we speak and yes, respectful is critical.
> > A quick note about that but all the discussion in communities about
> having
> > by-laws and rules have finished by agreeing in a short version of them.
>
> I am -0 on that but -1 on reducing it to a single sentence. If you feel
> strongly about having a shorter version of the bylaws or of the CoC,
> please propose some text.
>
>
Who will be the more empathic in these discussions. The first one that
denounce a lack of empathy? Or the other one that disagree with the other?
Will it be because most active participant will declare it? See using a
vague concept of emotional awareness won't prevent the discussion of this
awareness Of who is the more aware. Where respect, trust of the other,
honesty, beeing polite make sure that people exchange in confidence. In
short thinking that the other discuss only for the good Which also imply
that you have to understand that the other may not be aware you're in a bad
mood and doesn't have too. I am not speaking about being logical or beeing
a robot but to respect the other and know he can disagree. Which imply to
let him his chance, trusting him, that he is thinking the good for the
project. People don't have to be your friends to speak about the project.
Especially over a mail or a chat.
Anyway no need to discuss more. I wanted to point the danger of introducing
this vague concept of empathy. I see why it's introduced, but i am worried
it endanger more the community than anything in near future.
I already proposed some additions to the text which can be
reviewed/discussed before i add anything but I will provide a diff
reflecting my thinking until monday.
- benoit.
Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws)
Posted by Alexander Shorin <kx...@gmail.com>.
On Thu, Jun 5, 2014 at 2:23 PM, Joan Touzet <wo...@apache.org> wrote:
>> A quick note about that but all the discussion in communities about having
>> by-laws and rules have finished by agreeing in a short version of them.
>
> I am -0 on that but -1 on reducing it to a single sentence. If you feel
> strongly about having a shorter version of the bylaws or of the CoC,
> please propose some text.
No need to reduce, just to provide TL;DR version as 500px did. That's
was initial idea (: But I see nobody feels good for it.
We have in anyway provide explanation of good conduct like license
agreements have to provide very detailed explanation of rights and
responsibilities.
--
,,,^..^,,,
Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project
bylaws)
Posted by Joan Touzet <wo...@apache.org>.
On Thu, Jun 05, 2014 at 10:49:49AM +0200, Benoit Chesneau wrote:
> This question always raised the question about who is right on naming
> thing. Who has more empathy than the others. If you really think that by
> laws will solve that you're wrong.
CoC aren't about stopping people. They are for outlining what is
acceptable and uancceptable behaviour. They are a ruler against which,
when conflict occurs, human action can be compared. Just because thye
exist will not stop people from acting badly, but that does not mean the
exercise of writing them or enforcing them is pointless.
> However only politeness and respect of
> the other will make it possible to discuss between each other. Even though
> who disagree with. And this is why it's important to have the respect of
> the other made as a rule, a conduct.
There is the concept of respect already in the text. If people feel
strongly they want to add politeness, fine, but it should not be the
*only* word used.
> Empathy is too emotionally charged and
But humans are emotional. We need text in the CoC that addresses what to
do when people get emotional. Respect is often limited to a logical
approach to a situation and does not begin to cover emotional awareness
and understanding. As a result we need to go farther than just
politeness or respect and include the concept of empathy.
> It is also creating a new way to control people and reject the
> differences by applying a varnish on it, saying that diversity is about
> having people at the same level.
I'm not sure I follow here. Emotional awareness is not control, it is a
reminder to people in the community that emotion is a part of human
interaction, and that it must be taken into consideration when making
public statements. Working positively necessarily requires understanding
of the emotional state of those you're talking to; we cannot presume to
have interaction devoid of normal (or abnormal!) human behaviour.
> There is a lot of literature about it. First by reading "brave new world"
> from Huxkley.I
I have indeed read Huxley. I am not suggesting that everyone be happy
all the time, or that we avoid conflict, or that we intentionally drug
people into positive mental attitude or browbeat people into acceptance
of everything. I am stating that recognition of emotional state is
critical to supportive discussion.
This paper also summarise it:
> http://www.newyorker.com/arts/critics/atlarge/2013/05/20/130520crat_atlarge_bloom?currentPage=all
>From that same article:
"That’s not a call for a world without empathy. The problem with those
who are devoid of empathy is that, although they may recognize what’s
right, they have no motivation to act upon it. Some spark of
fellow-feeling is needed to convert intelligence into action."
"Where empathy really does matter is in our personal relationships.
Nobody wants to live like Thomas Gradgrind—Charles Dickens’s caricature
utilitarian, who treats all interactions, including those with his
children, in explicitly economic terms. Empathy is what makes us human;
it’s what makes us both subjects and objects of moral concern. Empathy
betrays us only when we take it as a moral guide."
Again I am not suggesting that list members *only* use empathy to guide
their moral compass. I am stating that we cannot operate without empathy
lest callous attitudes defined on purely logical approaches trample
valid concerns that are, at their foundation, emotional and not logical.
Just because it's software doesn't mean that everything about it, in
code, documentation, design and usage, is also just 1s and 0s. We are
not robots, nor are we Star Trek's Mr. Spock. We should not aspire to
interact on this mailing list as if we were purely emotionless beings.
If that is true, then awareness of others' emotional state, and use of
that to be open, welcoming, friendly, patient, collaborative, concise,
careful in how we speak and yes, respectful is critical.
> A quick note about that but all the discussion in communities about having
> by-laws and rules have finished by agreeing in a short version of them.
I am -0 on that but -1 on reducing it to a single sentence. If you feel
strongly about having a shorter version of the bylaws or of the CoC,
please propose some text.
--
Joan Touzet | joant@atypical.net | wohali everywhere else
Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws)
Posted by Benoit Chesneau <bc...@gmail.com>.
On Thu, Jun 5, 2014 at 8:17 AM, Joan Touzet <wo...@apache.org> wrote:
> ----- Original Message -----
> From: "Alexander Shorin" <kx...@gmail.com>
>
> > Well, mostly all CoC points could be replaced by single sentence: "Be
> polite.":
>
> Being polite is insufficiently rich to describe what we expect from
> people. I also explained why I didn't use polite in a previous thread
> as well (or it might have been IRC, I forget now.)
>
> Proof by counterexample: I have been involved in a private gaming
> community for a long time where the only rule was "be polite" / "don't
> be an asshole". Recently it has been made painfully clear that, to some
> people, being polite means it's OK to be sexist, racist, disparage
> people who don't agree with you, villainize foreigners, and worse that
> I won't bring to bear on this list.
>
> This is even worse when people are "polite" on a mailing list but still
> harbor ill will behind a surface of politeness.
>
This question always raised the question about who is right on naming
thing. Who has more empathy than the others. If you really think that by
laws will solve that you're wrong. However only politeness and respect of
the other will make it possible to discuss between each other. Even though
who disagree with. And this is why it's important to have the respect of
the other made as a rule, a conduct. Empathy is too emotionally charged and
doesn't take in consideration the ego (in its pure definition) of each
parts. It is also creating a new way to control people and reject the
differences by applying a varnish on it, saying that diversity is about
having people at the same level.
There is a lot of literature about it. First by reading "brave new world"
from Huxkley. This paper also summarise it:
http://www.newyorker.com/arts/critics/atlarge/2013/05/20/130520crat_atlarge_bloom?currentPage=all
>
> > P.S. the word "polite" mentioned zero times on code of conduct page.
>
> See above. Saying "be polite" is only the start of a longer
> conversation, one we've been having for years now in various places --
> and one that shows that not everyone has the same level of understanding.
>
> I am -1 on any reductionist single-sentence approach as it
> will simply leave too many loopholes. We should not be placed in a
> position where we must have semantic arguments about what I think
> polite means vs. what you think polite means. Given the difficulties
> CouchDB has had as a community over the years, we must necessarily be
> explicit in the list of what we do and do not tolerate. If that list
> proves insufficient we need to grow it over time.
>
> -Joan
>
A quick note about that but all the discussion in communities about having
by-laws and rules have finished by agreeing in a short version of them.
Most of the time by only using a Coc as a way to define the social
agreement and a list of guidelines aside on how to manage discussions and
other stuff related to the project. Most of the time in the form of an
extensive contributing document.
- benoit
Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws)
Posted by Andy Wenk <an...@nms.de>.
Alex thanks for bringing up this idea (again like Joan already followed
this approach).
I see problems on both sides.
* reading a long text is exhausting - especially for non native speaking
people. So the danger that one will not read it is high.
* bylaws packed in a short text is dangerous because, why should one write
a long text, when one can write it also in a short text?
So what is the bigger problem? Assuming a person is not following the
bylaws / CoC (it's mixed in the thread above) and we have to "judge" her,
we can say "well, it is written in the bylaws / CoC. If you don't read
them, it's your problem. Please follow them."
Assuming a person is reading the short version and is not following the
bylaws / CoC and we have to "judge" her, he could say "hey I understood it
this way. If that's not correct, you should explain it better".
Imho the bylaws are good as they are. But I can imagine, that we "could
maybe" provide a not official shorter version with a very clear
explanation, that is just a summary and we never rely on the short version
but the long "official" one. Maybe the word "version" is not correct but it
should read "content summary".
I believe this would be very much work to make it really good. I personally
want to stay with the bylaws as they are and would be -0 on a "summary
version".
Cheers
Andy
On 5 June 2014 08:19, Joan Touzet <wo...@apache.org> wrote:
> Oh! One good essay about why "Don't do bad things" isn't enough:
>
> http://satifice.com/octofice/2014/01/01/on-the-dont-do-bad-things-maxim/
>
> -Joan
>
>
> ----- Original Message -----
> From: "Joan Touzet" <wo...@apache.org>
> To: dev@couchdb.apache.org
> Sent: Thursday, June 5, 2014 2:17:35 AM
> Subject: Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project
> bylaws)
>
> ----- Original Message -----
> From: "Alexander Shorin" <kx...@gmail.com>
>
> > Well, mostly all CoC points could be replaced by single sentence: "Be
> polite.":
>
> Being polite is insufficiently rich to describe what we expect from
> people. I also explained why I didn't use polite in a previous thread
> as well (or it might have been IRC, I forget now.)
>
> Proof by counterexample: I have been involved in a private gaming
> community for a long time where the only rule was "be polite" / "don't
> be an asshole". Recently it has been made painfully clear that, to some
> people, being polite means it's OK to be sexist, racist, disparage
> people who don't agree with you, villainize foreigners, and worse that
> I won't bring to bear on this list.
>
> This is even worse when people are "polite" on a mailing list but still
> harbor ill will behind a surface of politeness.
>
> > P.S. the word "polite" mentioned zero times on code of conduct page.
>
> See above. Saying "be polite" is only the start of a longer
> conversation, one we've been having for years now in various places --
> and one that shows that not everyone has the same level of understanding.
>
> I am -1 on any reductionist single-sentence approach as it
> will simply leave too many loopholes. We should not be placed in a
> position where we must have semantic arguments about what I think
> polite means vs. what you think polite means. Given the difficulties
> CouchDB has had as a community over the years, we must necessarily be
> explicit in the list of what we do and do not tolerate. If that list
> proves insufficient we need to grow it over time.
>
> -Joan
>
--
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: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project
bylaws)
Posted by Joan Touzet <wo...@apache.org>.
Oh! One good essay about why "Don't do bad things" isn't enough:
http://satifice.com/octofice/2014/01/01/on-the-dont-do-bad-things-maxim/
-Joan
----- Original Message -----
From: "Joan Touzet" <wo...@apache.org>
To: dev@couchdb.apache.org
Sent: Thursday, June 5, 2014 2:17:35 AM
Subject: Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws)
----- Original Message -----
From: "Alexander Shorin" <kx...@gmail.com>
> Well, mostly all CoC points could be replaced by single sentence: "Be polite.":
Being polite is insufficiently rich to describe what we expect from
people. I also explained why I didn't use polite in a previous thread
as well (or it might have been IRC, I forget now.)
Proof by counterexample: I have been involved in a private gaming
community for a long time where the only rule was "be polite" / "don't
be an asshole". Recently it has been made painfully clear that, to some
people, being polite means it's OK to be sexist, racist, disparage
people who don't agree with you, villainize foreigners, and worse that
I won't bring to bear on this list.
This is even worse when people are "polite" on a mailing list but still
harbor ill will behind a surface of politeness.
> P.S. the word "polite" mentioned zero times on code of conduct page.
See above. Saying "be polite" is only the start of a longer
conversation, one we've been having for years now in various places --
and one that shows that not everyone has the same level of understanding.
I am -1 on any reductionist single-sentence approach as it
will simply leave too many loopholes. We should not be placed in a
position where we must have semantic arguments about what I think
polite means vs. what you think polite means. Given the difficulties
CouchDB has had as a community over the years, we must necessarily be
explicit in the list of what we do and do not tolerate. If that list
proves insufficient we need to grow it over time.
-Joan
Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project
bylaws)
Posted by Joan Touzet <wo...@apache.org>.
----- Original Message -----
From: "Alexander Shorin" <kx...@gmail.com>
> Well, mostly all CoC points could be replaced by single sentence: "Be polite.":
Being polite is insufficiently rich to describe what we expect from
people. I also explained why I didn't use polite in a previous thread
as well (or it might have been IRC, I forget now.)
Proof by counterexample: I have been involved in a private gaming
community for a long time where the only rule was "be polite" / "don't
be an asshole". Recently it has been made painfully clear that, to some
people, being polite means it's OK to be sexist, racist, disparage
people who don't agree with you, villainize foreigners, and worse that
I won't bring to bear on this list.
This is even worse when people are "polite" on a mailing list but still
harbor ill will behind a surface of politeness.
> P.S. the word "polite" mentioned zero times on code of conduct page.
See above. Saying "be polite" is only the start of a longer
conversation, one we've been having for years now in various places --
and one that shows that not everyone has the same level of understanding.
I am -1 on any reductionist single-sentence approach as it
will simply leave too many loopholes. We should not be placed in a
position where we must have semantic arguments about what I think
polite means vs. what you think polite means. Given the difficulties
CouchDB has had as a community over the years, we must necessarily be
explicit in the list of what we do and do not tolerate. If that list
proves insufficient we need to grow it over time.
-Joan
Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws)
Posted by Alexander Shorin <kx...@gmail.com>.
On Thu, Jun 5, 2014 at 6:23 AM, Joan Touzet <wo...@apache.org> wrote:
> I believe the response from him (or possibly someone else on the PMC)
> was that people would try and go by the abbreviated rules and never
> read the complete ones.
In this case what would make them read long rules? TL;DR isn't only life motto.
> And that people would either rely on that as
> a loophole, or worse, think our rules were more lax and cause issues.
> This could be unintentional or intentional; either way it allows
> for interpretation on the short rules that could cause issues.
Well, mostly all CoC points could be replaced by single sentence: "Be polite.":
polite (pəˈlaɪt) adj
1. showing regard for others, in manners, speech, behaviour, etc; courteous
Being polite is a matter of etiquette; it's about respect, and being
considerate of people's feelings, culture, and values. Polite and
mannerly imply consideration for others and the adherence to
conventional social standards of good behavior.
Simple and clear what the community expects from you.
P.S. the word "polite" mentioned zero times on code of conduct page.
--
,,,^..^,,,
Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project
bylaws)
Posted by Joan Touzet <wo...@apache.org>.
I'd suggested something like this earlier to Noah. I'm now -0
on the idea now.
I believe the response from him (or possibly someone else on the PMC)
was that people would try and go by the abbreviated rules and never
read the complete ones. And that people would either rely on that as
a loophole, or worse, think our rules were more lax and cause issues.
This could be unintentional or intentional; either way it allows
for interpretation on the short rules that could cause issues.
-Joan
----- Original Message -----
From: "Alexander Shorin" <kx...@gmail.com>
To: dev@couchdb.apache.org
Sent: Wednesday, June 4, 2014 3:51:03 PM
Subject: Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws)
Hi,
I have an idea that I like to share with you about bylaws and code of
conduct. I'll be short:
http://500px.com/terms
Here I'll be a bit longer: the idea is to provide shortener summary of
all these statements on the page. Easy to read, easy to understand the
base things, easy to reference, no need to dive into loooong texts
searching for simple things, unless you're seeking for details or
wording. We can launch short version as an whole page ideas quiescence
in any time while keep fighting for words, terms and phrases in full
texts without interrupting the process.
What do you think about?
--
,,,^..^,,,
On Wed, May 7, 2014 at 11:07 PM, Noah Slater <ns...@apache.org> wrote:
> Hello folks,
>
> Please review our propose bylaws:
>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=40511017
>
> I'd like a few more eyeballs on this before I move to a vote.
>
> Thanks,
>
>
> On 5 May 2014 18:35, 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.
>>
>> 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
>
>
>
> --
> Noah Slater
> https://twitter.com/nslater
Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws)
Posted by Alexander Shorin <kx...@gmail.com>.
Hi,
I have an idea that I like to share with you about bylaws and code of
conduct. I'll be short:
http://500px.com/terms
Here I'll be a bit longer: the idea is to provide shortener summary of
all these statements on the page. Easy to read, easy to understand the
base things, easy to reference, no need to dive into loooong texts
searching for simple things, unless you're seeking for details or
wording. We can launch short version as an whole page ideas quiescence
in any time while keep fighting for words, terms and phrases in full
texts without interrupting the process.
What do you think about?
--
,,,^..^,,,
On Wed, May 7, 2014 at 11:07 PM, Noah Slater <ns...@apache.org> wrote:
> Hello folks,
>
> Please review our propose bylaws:
>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=40511017
>
> I'd like a few more eyeballs on this before I move to a vote.
>
> Thanks,
>
>
> On 5 May 2014 18:35, 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.
>>
>> 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
>
>
>
> --
> Noah Slater
> https://twitter.com/nslater