couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws)
Date Mon, 26 May 2014 20:53:55 GMT

On 21 May 2014, at 21:47 , Noah Slater <nslater@apache.org> wrote:

> On 11 May 2014 02:18, Andy Wenk <andy@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 <andy@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 <rok@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 <rok@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 <wohali@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 <wohali@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 <wohali@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 <wohali@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 <wohali@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 <wohali@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 <wohali@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 <wohali@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 <wohali@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 <jason.h.smith@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 <jason.h.smith@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 <jason.h.smith@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 <jason.h.smith@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 <jason.h.smith@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 <jmutton@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 <dch@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 <dch@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 <dch@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 <dch@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 <dch@jsonified.com> wrote:
>> "Decision Types" reads better to me. YMMV, FFTI.
> 
> Typo. Fixed.
> 
> On 20 May 2014 16:44, Dave Cottlehuber <dch@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 <jan@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 <jan@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 <jan@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 <jan@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 <jan@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 <jan@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 <jan@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 <jan@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 <jan@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 <rnewson@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 <rnewson@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 <rnewson@apache.org> wrote:
>> "people what hat you are wearing" — s/what/which/
> 
> Fixed.
> 
> On 21 May 2014 00:06, Robert Samuel Newson <rnewson@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 <rnewson@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 <rnewson@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 <rnewson@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 <rnewson@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 <rnewson@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 <rnewson@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 <jan@apache.org> wrote:
>> 
>>> 
>>> On 15 May 2014, at 17:49 , Noah Slater <nslater@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
>>>> <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
>>> 
>> 
> 
> 
> 
> -- 
> Noah Slater
> https://twitter.com/nslater


Mime
View raw message