I don't know about everyone else, but a big deterrent in contributing code to Cassandra for me (over the last 4 years or so) is the massive amount of ramp up that needs to happen in order to get started working on something meaningful. This comes in a variety of forms - understanding how test failures aren't actually failures (being corrected now), lack of comments (for example: https://github.com/PaytmLabs/cassandra/blob/master/src/java/org/apache/cassandra/db/compaction/LeveledCompactionStrategy.java), out of date wiki (now semi retired but still a source of misinformation), and class names that don't make sense. Historically there has been a massive amount of tribal knowledge required to contribute in a significant way. Going through JIRA history and asking people who wrote the feature is the only way to find out what is supposed to be going on. Let's not forget the fact that it's a distributed database, so add to all the above issues the fact that getting this thing right at all is a miraculous achievement. In order to get more people contributing to the project there needs to be a significant effort in making it more approachable.
I suspect that as the project continues to move faster, it'll become ever harder for new contributors to join unless they are paid to work on Cassandra full time. Very few people are deploying Tick Tock releases on purpose - 1 bug fix release doesn't exactly scream reassurance, sorry - so the folks that are going to scratch their own itch by fixing bugs and eventually contributing features they need is likely going to drop over time. This leaves full time paid positions such as those employed by DataStax as the logical place to go if you are interested in working on Cassandra. On Tue, Aug 16, 2016 at 10:47 AM Benedict Elliott Smith <bened...@apache.org> 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-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. > > > > > > > > >
