This is a much more useful focusing of the discussion, in my opinion. It seemed to me that city hall was focusing on a very narrow definition of project health.
I would be the first to say the project need to improve here, but doing so will be challenging; I'm not sure anyone really knows how to go about it. Which is why we end up in these local minima of discussions about the minutiae of JIRA replication. What this project really needs, and the board is chomping at the bit about, is diversity. The fact is, right now DataStax does 95% of the substantive development on the project, and so they make all the decisions. As such, their internal community outweighs the Apache community. I will emphasise clearly for my ex-colleagues, I'm not making any value judgement about this, just clarifying the crux of the discussion that everyone seems to be dancing around. The question is, what can be done about it? The project needs a lot of new highly productive and independent contributors who are capable of meaningfully shaping project direction. The problem is we don't know how to achieve that. On 16 August 2016 at 17:24, Dennis E. Hamilton <dennis.hamil...@acm.org> wrote: > > > > -----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. > > > > >
