couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Smith <jason.h.sm...@gmail.com>
Subject Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws)
Date Mon, 19 May 2014 17:50:36 GMT
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 <nslater@apache.org> wrote:

> Jan/Bob, can I get your review of this too please?
>
> On 13 May 2014 23:23, Sebastian Rothbucher
> <sebastianrothbucher@googlemail.com> wrote:
> > +1
> > As it is
> >
> > Von meinem iPhone gesendet
> >
> >> Am 11.05.2014 um 17:35 schrieb Noah Slater <nslater@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 <nslater@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 <nslater@apache.org> wrote:
> >>>>> On 5 May 2014 10:54, Benoit Chesneau <bchesneau@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message