> -----Original Message----- > From: Eric Stevens [mailto:migh...@gmail.com] > Sent: Tuesday, August 16, 2016 06:10 > To: dev@cassandra.apache.org > Subject: Re: A proposal to move away from Jira-centric development > > I agree with Benedict that we really shouldn't be getting into a > legalese > debate on this subject, however "it didn't happen" has been brought up > as a > hammer in this conversation multiple times, and I think it's important > that > we put it to rest. It's pretty clear cut that projects are free to > disregard this advice. "It didn't happen" is a motto, not a rule. [orcmid]
<http://community.apache.org/apache-way/apache-project-maturity-model.html> Please read them all, but especially the sections on Community, Consensus Building, and Independence. Apache projects are expected to govern themselves, PMCs are responsible for it, and PMC Chairs (officers of the foundation) are accountable to the Board on how the project is striving toward maturity. On occasion, deviations are so notable that there is objection. It is not that folks run around policing the projects. But there are occasions where there are concerns that a project has gone astray. One maturity factor that might not be emphasized enough is Sustainability. It is about the transparency of project conduct, the inclusiveness of operation and visibility, and the ways that growth and turnover are accommodated. Since we are looking at mottos, "community over code" comes to mind. Project freedom is a bit like the freedom to drive at 100mph on an arterial highway. Occassionally, the infraction becomes worthy of attention and even a road block and spike strips. While individual preferences are being discussed here, and I agree it is more pertinent than top-posting versus bottom-posting, what is lacking is a broad discussion on community. Not incumbents and the karma-privileged, but the overall community and how one sustains a thriving project that strives for maturity. Folks who are concerned about managing the mail stream and choosing what matters to them might want to discuss ways of operating lists in support of those concerns. There are positions here and not enough questions about what might be workable inside of the practices and policies that are the waters Apache projects swim in. - Dennis > > Per ASF newbie FAQ referenced by someone else earlier [1]: > > > The section on ASF Mottos is especially useful as a reminder of the > way > things are in most ASF projects. This section includes such gems as: > > * Put community before code. > > * Let they that do the work make the decisions. > > * If it didn't happen on a mailing list, it didn't happen. > > * Don't feed the trolls. > > This is presented as a general guideline and not a hard rule, and as > Benedict points out even this is preceded by a guideline suggesting that > developers are free to seek alternatives. [orcmid] The alternatives must fit within the overall principles, however. Not deviate from or weaken them. This is not an opening for arbitrary conduct. If a major exception is required, it is up to the project to deliberate on the matter, agree on the desired exception and its justification, and take it to an appropriate venue for ratification. (It is useful to keep in mind that exceptions are not precedents for others to cherry-pick.) It is also the case that the PMC and, indeed the Chair (although consensus is always better), can set policies for the project. They must be explicit and documented and available to all. It would be really great to stop fighting city hall and, instead, start an inquiry into how the principles behind those practices are to be accomplished in the project's way of operating. > > Now since this is just a reference to the Incubator code of conduct's > list > of mottos (again, not ASF policy), which best source I could find [2], > mirrors the newbie FAQ, but provides the additional insight that the > objective of the motto is transparency. The spirit of this motto is not > meant to dictate a technology choice, but merely to indicate that > discussions should happen in open spaces where all are able to > participate. The motto was authored in a time when "the lists" was the > only real option. > > Jira absolutely meets the design goal of that motto, if that's the > direction the community chooses, and it's clear from both sources that > individual communities (they that do the work) are free to find the path > here that's best for them. > > [1] > https://community.apache.org/newbiefaq.html#NewbieFAQ- > IsthereaCodeofConductforApacheprojects > ? > [2] *https://wiki.apache.org/incubator/CodeOfConduct#ASF_Mottos > <https://wiki.apache.org/incubator/CodeOfConduct#ASF_Mottos>* > > On Tue, Aug 16, 2016 at 5:57 AM James Carman > <ja...@carmanconsulting.com> > wrote: > > > On Mon, Aug 15, 2016 at 10:23 AM Jonathan Ellis <jbel...@gmail.com> > wrote: > > > > > A long time ago, I was a proponent of keeping most development > > discussions > > > on Jira, where tickets can be self contained and the threadless > nature > > > helps keep discussions from getting sidetracked. > > > > > > But Cassandra was a lot smaller then, and as we've grown it has > become > > > necessary to separate out the signal (discussions of new features > and > > major > > > changes) from the noise of routine bug reports. > > > > > > I propose that we take advantage of the dev list to perform that > > > separation. Major new features and architectural improvements > should be > > > discussed first here, then when consensus on design is achieved, > moved to > > > Jira for implementation and review. > > > > > > > > +1! I think it's important to point out here that nobody is proposing > that > > folks have to send an email like: > > > > "I was thinking of naming my variable 'foo' here, what do you guys > think?" > > > > However, discussions and decisions that have an impact on Cassandra > and its > > direction/architecture (not an all-inclusive list here and we should > use > > reason to decide) should happen on the mailing list. The idea here is > > inclusiveness. We want everyone in the community to have a chance to > > contribute to these discussions. > >
