Re: Questions about CouchDB bylaws
Hi Joan, Thank you for such a thoughtful response, very much appreciated. It would take me some time to go over the material you shared. I will certainly come back and ask more questions if I have any. I would not be attending ApacheCon in Montreal, however a group of Beam community members will be there. Some of them are greatly interested in this discussion, I will encourage them to attend your talk. Ahmet On Fri, Aug 10, 2018 at 3:03 PM, Joan Touzet wrote: > 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/f824e8d3c490460c739f6d769e1de0 > 2b24bf09fa2863e88116cb0577@1398714830@%3Cdev.couchdb.apache.org%3E > > And continued here: > > https://lists.apache.org/thread.html/40d49b259170f43c0908706c09cf5b > 16e703365b7989ba79a1b8d9e6@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/e270c4fbb4374ae98ed73583ff9ff5 > d6a1660374f7a8084c1d795ea8@1399528340@%3Cdev.couchdb.apache.org%3E > https://lists.apache.org/thread.html/03fdda4b8ec8cd7926f95daa5dfe94 > b7af5c568d39abda2e75918d87@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/aa6d6ace4be652f3b4bb380b92ee92 > 48d84dece7fd3281406446ca05@%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/18f059c0582a4700992cbb302c2539 > d235215226cad69d82abdc9444@1398713334@%3Cdev.couchdb.apache.org%3E > https://lists.apache.org/thread.html/0cf65d2715348229f87e4b572d1765 > 802857755fab94ff9d8cd1924f@1400368799@%3Cdev.couchdb.apache.org%3E > https://lists.apache.org/thread.html/c3f5e3a462a0ab1ded3af5eec0ac37 > 4aa647f3c1e55e7cd7e6ba8d5d@1400531457@%3Cdev.couchdb.apache.org%3E > > And the vote thread: > > https://lists.apache.org/thread.html/f1621bfe5bbf4dbf6e799e338e440a > fb58cf58b6b91bc42a9f7622b4@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
Re: Questions about CouchDB bylaws
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" > To: dev@couchdb.apache.org > Sent: Friday, August 10, 2018 4:27:33 PM > Subject: Questions about CouchDB bylaws > >
