This was very much not my intention to imply. I thought I had crafted the email carefully to not imply that at all. This topic is complex, and fully exploring all of the detail would be onerous over email. DataStax, in my opinion, consciously tries to be a good citizen. However there are emergent properties of a system with this imbalance that are not conscious, and are suboptimal, and it is not unreasonable for the Apache apparatus to try to "rectify" the imbalance. I personally support that *in principle*, but I think they're not going about it brilliantly right now. I also doubt the success of any such endeavour, given how difficult the problem is.
I do, however, think the project could improve how welcoming it is. Both in the areas Jon mentions, but also in how much effort is put into mentoring newcomers and responding to technical questions. The project is far from *unwelcoming, *but mentoring is (very) costly, and when success at your dayjob is measured in the code you contribute, this clearly takes priority. I don't know how to change that - again, as far as conscious actions are concerned, I have personally witnessed DataStax try to put more effort into this, as well as trying to drum up new external contributors through bootcamps. But these efforts have had limited success. On 16 August 2016 at 19:04, Dave Brosius <dbros...@mebigfatguy.com> wrote: > While i agree with this generally, it's misleading. > > It comes across like Datastax is dictating and excluding others from > participating, or perhaps discouraging others or whatever. > > The truth is, whenever someone comes along who is independent, and > interested in developing Apache Cassandra, they are welcomed, and do > participate, and do develop...., and soon after become Datastax employees. > Not always of course, but a common pattern. It only makes sense for > Datastax to hire people who are interested in and capable of developing > Apache Cassandra. But the truth is a whole lot less sinister than the > inference. > > --dave > [not associated with Datastax] > > > > On 2016-08-16 13:47, Benedict Elliott Smith wrote: > >> 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-matur >>> ity-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. >>> > > >>> >>> >>>
