Hi Ahmet, Thanks for the kind words!
Our bylaws were established in 2014 after some concern that the ASF itself didn't have specific enough rules for all of the various types of decisions our project needed to reach, as well as those rules being hard to parse and locate on the websites. We wanted to make it easier for contributors, committers and the PMC to understand how we intend to run the CouchDB project, and to have a clear reference for the future. As a community, we were in a time of great change. Two major code contributions were on their way into the code base that would result in CouchDB 2.0 after significant refactoring and some backward incompatibility. There was dissent within our development community about the direction of the product: were we primarily a "two-tier" development environment, or a database with an HTTP API and JSON data format? And we would soon be changing over from Subversion to Git, something our developers really wanted, but ASF Infrastructure was slow to adopt and embrace. We had to fight long and hard, and became the first project in the ASF to be allowed to use git officially. As part of this process we decided to move from Commit-Then-Review (CTR) to Review-Then-Commit (RTC), based on the popularity of the GitHub Pull Request model. This allows us to keep the master branch of our repo always release-able, something we struggled with for years prior. The discussion started here: https://lists.apache.org/thread.html/f824e8d3c490460c739f6d769e1de02b24bf09fa2863e88116cb0577@1398714830@%3Cdev.couchdb.apache.org%3E And continued here: https://lists.apache.org/thread.html/40d49b259170f43c0908706c09cf5b16e703365b7989ba79a1b8d9e6@1399489677@%3Cdev.couchdb.apache.org%3E We then had a small amendment to the bylaws to correct an oversight: https://lists.apache.org/thread.html/e270c4fbb4374ae98ed73583ff9ff5d6a1660374f7a8084c1d795ea8@1399528340@%3Cdev.couchdb.apache.org%3E https://lists.apache.org/thread.html/03fdda4b8ec8cd7926f95daa5dfe94b7af5c568d39abda2e75918d87@1405991529@%3Cdev.couchdb.apache.org%3E We have had, to my knowledge, only one other modification to the bylaws since then, which was to clarify how API deprecations will be handled in future versions by requiring their announcement on our dev@ list (actual commits only go to notifications@): https://lists.apache.org/thread.html/aa6d6ace4be652f3b4bb380b92ee9248d84dece7fd3281406446ca05@%3Cdev.couchdb.apache.org%3E Finally, we also discussed, voted on, and adopted our Code of Conduct, drawn from those written by many similar communities around the open source world. A few short months later, that CoC would be adopted by the ASF at large. The CoC is not a cudgel, it's a way for us to ensure that the values that brought the team together in the first place persist past the founders' direct involvement in the project. Not sure it's worth rehashing the CoC discussion now that it's ASF-wide, but if you are interested in the gory details, here they are: https://lists.apache.org/thread.html/18f059c0582a4700992cbb302c2539d235215226cad69d82abdc9444@1398713334@%3Cdev.couchdb.apache.org%3E https://lists.apache.org/thread.html/0cf65d2715348229f87e4b572d1765802857755fab94ff9d8cd1924f@1400368799@%3Cdev.couchdb.apache.org%3E https://lists.apache.org/thread.html/c3f5e3a462a0ab1ded3af5eec0ac374aa647f3c1e55e7cd7e6ba8d5d@1400531457@%3Cdev.couchdb.apache.org%3E And the vote thread: https://lists.apache.org/thread.html/f1621bfe5bbf4dbf6e799e338e440afb58cf58b6b91bc42a9f7622b4@1407028730@%3Cdev.couchdb.apache.org%3E I think investment in community pays off over the long haul. Take the time to discuss and debate the reasons for your bylaws. One key point for us was: how would vetos work? Did we feel right about a single person being able to veto a technical code change or release? And in what situations would the PMC be empowered to override the community (though in general, they don't ever want to do that!) Discuss how the ASF CoC can and should be used in your community to ensure good faith, positive discussions. It shouldn't be seen as a scary document, but something that helps remind people to be nice to each other, and to work towards the betterment of the project. The discussions together will highlight the areas in which you need work, and should spawn a series of actions that continuously improve your community. I'll be speaking at this year's ApacheCon in Montreal about other communities from which the ASF maybe can learn a thing or two. If you're able to attend, I'd love you to come! The talk is on Thursday. If you're not coming, the talk should be on YouTube a month or two later. If you have any lingering questions about our bylaws, or the process by which we adopted them, please feel free to ask. -Joan "good rules make good collaborators" Touzet ----- Original Message ----- > From: "Ahmet Altay" <al...@google.com.INVALID> > To: dev@couchdb.apache.org > Sent: Friday, August 10, 2018 4:27:33 PM > Subject: Questions about CouchDB bylaws > > Hi all, > > There was a recent discussion on Apache Beam related to adding bylaws > to > that project. I wanted to look around to other projects with > published > bylaws and found CouchDB bylaws [1] to be a well written document. I > would > like to learn from your experience. > > Would you be able to share some context about how did you come to > this > version? What kind of considerations you had? What was tradeoffs? And > how > the community built consensus around it? > > Please feel free to point me to any existing notes. > > Thank you, > Ahmet > > [1] http://couchdb.apache.org/bylaws.html >
