Return-Path: X-Original-To: apmail-couchdb-dev-archive@www.apache.org Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 0EEF9116F9 for ; Tue, 20 May 2014 21:43:40 +0000 (UTC) Received: (qmail 37988 invoked by uid 500); 20 May 2014 21:43:39 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 37935 invoked by uid 500); 20 May 2014 21:43:39 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 37927 invoked by uid 99); 20 May 2014 21:43:39 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 20 May 2014 21:43:39 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy includes SPF record at spf.trusted-forwarder.org) Received: from [80.244.253.218] (HELO mail.traeumt.net) (80.244.253.218) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 20 May 2014 21:43:35 +0000 Received: from [10.0.0.10] (91-64-37-180-dynip.superkabel.de [91.64.37.180]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.traeumt.net (Postfix) with ESMTPSA id 36F08205EB for ; Tue, 20 May 2014 23:43:16 +0200 (CEST) From: Jan Lehnardt Content-Type: multipart/signed; boundary="Apple-Mail=_A0C938C4-8CE5-4F99-9827-CE2F04C48F7D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws) Date: Tue, 20 May 2014 23:43:09 +0200 References: To: dev@couchdb.apache.org In-Reply-To: X-Mailer: Apple Mail (2.1874) X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail=_A0C938C4-8CE5-4F99-9827-CE2F04C48F7D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 15 May 2014, at 17:49 , Noah Slater wrote: > Jan/Bob, can I get your review of this too please? Sorry for the delay. 1. last paragraph: =93If you are participating on the mailing list you = have the right to make decisions.=94 =97 *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=92d 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=92s what we=92ve 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). =93The PMC operates at the discretion of the project chair.=94 I don=92t = understand what that means. 2.5. could include a pointer to PMC chair election process. 3. =93Our goal is to eschew permission culture=94 could be rephrased to = be simpler for non-native speakers. 4.1. bikeshed: would prefer tags to be lowercase. >=20 > On 13 May 2014 23:23, Sebastian Rothbucher > wrote: >> +1 >> As it is >>=20 >> Von meinem iPhone gesendet >>=20 >>> Am 11.05.2014 um 17:35 schrieb Noah Slater : >>>=20 >>> Community, >>>=20 >>> 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!) >>>=20 >>>=20 >>>=20 >>>> On 7 May 2014 21:07, Noah Slater wrote: >>>> Hello folks, >>>>=20 >>>> Please review our propose bylaws: >>>>=20 >>>> = https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=3D4051101= 7 >>>>=20 >>>> I'd like a few more eyeballs on this before I move to a vote. >>>>=20 >>>> Thanks, >>>>=20 >>>>=20 >>>>> On 5 May 2014 18:35, Noah Slater wrote: >>>>>> On 5 May 2014 10:54, Benoit Chesneau wrote: >>>>>>=20 >>>>>> 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: >>>>>=20 >>>>> The bylaws of the foundation are here: >>>>>=20 >>>>> http://apache.org/foundation/bylaws.html >>>>>=20 >>>>> They cover a completely different set of things at the foundation >>>>> level. And say very little about how projects must function. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> What our bylaws are doing is saying that we have specifically = chosen >>>>> these interpretations, and that as a community we consider them >>>>> binding. >>>>>=20 >>>>>> - 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" . >>>>>>=20 >>>>>> The passage from a lazy consensus to a discussion is not clear. = How it >>>>>> is decided? Who is deciding it? >>>>>=20 >>>>> Good catch. >>>>>=20 >>>>> I have updated the wording to: >>>>>=20 >>>>> "If lazy consensus fails (i.e. someone objects) you can start a >>>>> discussion or you can abandon the proposal." >>>>>=20 >>>>> Does this address your concerns? >>>>>=20 >>>>>> - 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." . >>>>>>=20 >>>>>> 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? >>>>>=20 >>>>> Interesting comment. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> Two people spend an hour arguing, and person A convinces person B = of >>>>> their opinion. Typically, we would say that person A has won. >>>>>=20 >>>>> 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? >>>>>=20 >>>>> 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. >>>>>=20 >>>>>> Rather what is a bad opinion for the project (i.e. an expression = of an >>>>>> idea) there? How do you put the limit? >>>>>=20 >>>>> It's not opinions that are bad. Instead: modes of discussion. >>>>>=20 >>>>>> - 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>>> - 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. >>>>>=20 >>>>> What benefits would this bring? >>>>>=20 >>>>>> - The same for a chair. We could make it renewable more often. = For >>>>>> example each 3 or 5 years. >>>>>=20 >>>>> I've included this in the draft already. I am proposing that the = chair >>>>> is reelected every year. >>>>>=20 >>>>> Thanks, >>>>>=20 >>>>> -- >>>>> Noah Slater >>>>> https://twitter.com/nslater >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> Noah Slater >>>> https://twitter.com/nslater >>>=20 >>>=20 >>>=20 >>> -- >>> Noah Slater >>> https://twitter.com/nslater >=20 >=20 >=20 > --=20 > Noah Slater > https://twitter.com/nslater --Apple-Mail=_A0C938C4-8CE5-4F99-9827-CE2F04C48F7D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTe8xtAAoJENnuAeR4Uq7keO0P/j94HCnNgz3xDaH7Jk8vvDtI 3ueU3OXl5hbt54YT1kpAkjkG9PUjyTErMqsFsHiUpKrzdpEHnS9pQcL4+Wj1UtBK KPbI+trQVLpeJQmQ0c3uH5CxTcg33iWrGVOyPVCzBFCsFxg2X0A6RvHfot9dsMqi dd2Zk1fFIMF2O4BPYUjqbEAqyjT/CrJchrCDt/rK3k+2Kc5jlfVPzttlwkAg6ggL wnql45OuwWqLMNsoKyV8OCneHMo63FbLGe0zFX6oSvpWkYEhaFLbvLGWtYzD7Eah R84nOjq1tduLLno5vLkvei4y5ucZRHAdxZNbYWErDz53+G7bAdrHpfgWIiE1GF+a GJNxwMz4Nnv33CL3ptB1ECOG3Mq4/7eiZiCgtzcw8qQJiDAuqsumPtco9Jw1OeAg Mnl59s03TxB542VTqUuzXZt27q+1K4lcMNeDRtqOmOmvZlVZodIC9HSuEhMsE6qZ 41JB1AwAK+OI0AFS2KW/FXKFkay/edJI/ZIpV5OXVMcdQZRk9IGCSi3+P8EdDASt 7zZd+J7L+kNMpkuNWlqoM+JCNti4GJXXR3gpYVwn6fgvD1SNbxRB82r37ql3UG4N +MlrwXo/Lr5a6/t6Rsq3HR5VBlTDf17j6oFOS+SEkf6voYtYjNFs8adOooLxEG7p NELj4UBl3iD2xd+28TZo =slVC -----END PGP SIGNATURE----- --Apple-Mail=_A0C938C4-8CE5-4F99-9827-CE2F04C48F7D--