couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Kowalski <...@kowalski.gd>
Subject Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws)
Date Sun, 11 May 2014 18:14:07 GMT
+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 <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
>

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