> > I have to disagree with people here and point out that just creating > JIRA's and (trying to) have discussions about these issues will not lead to > change in any reasonable timeframe, because everyone who could do the work > has an endless list of bigger fish to fry. I strongly encourage you to get > involved and write some code, or pay someone to do it, because to put it > bluntly, it's *very* unlikely your JIRA's will get actioned unless you > contribute significantly to them yourself. >
Though I don't truly disagree with the overall point that getting into code is the surest way to get something you care about see progress, I'd love for this to not be understood as "we don't care about your idea unless you bring code". There has been tons of JIRA tickets in the past suggesting improvements where some contributor said "you know what, that's a good idea" and implemented it. I've certainly see it happen numerous times and trust I did it a lot as well (and sure, it happens dis-proportionally more for small improvement than for lets-rewrite-the-whole-database ones, for obvious reasons hopefully). So if you have a relatively concrete idea for an improvement, I'd say, please, share it. Don't get me wrong though, please do your homework first and take a few minutes googling/JIRA searching to see if that hasn't been discussed first; don't assume your time is more valuable than that of other contributors. It's rude to assume so (I'd say in general, but even more so because it's a free-as-in-beer software). That said, and to paraphrase what others have said, one should always come to this with a few understandings: - For all that people may like your idea and have the time to help it get in, there is not guarantee here. And yes, more often than not, contributors already have a list of things they want to fix and only a finite amount of time for contributions, so the bar for your idea to make it in some other contributor "list" is probably high. And remember that behavior science strongly suggests that you thinking your ideas are obviously the most important ones likely involves a fair amount of bias. That's why contributing the code yourself, if possible, definitively helps a lot. - A distributed database is not exactly a simple software. In particular, Cassandra make the choice to be fully distributed, which is a clear trade-off: it gives it very interesting properties (scalability, fault tolerance, ...) almost for free, but it makes some things quite a bit more challenging. My point being, some things may look like easy problem to solve on the surface, but are in fact more complex than they appear (which in turns means solving them take much more time that it seems, and we get back to contribution time/efforts not be infinite). So it's imo a good idea to seek first to understand why things are a certain way rather than assume than contributors don't care. - Cassandra is not perfect, no software is, but don't assume contributors are not aware of the weaknesses. We are for the most part. So if those weaknesses are still there, it's generally (there is of course exceptions) due to some combination of 1) a lack of time, 2) the difficulties of solving those weaknesses (without creating new, worth ones) and 3) some actually well though trade-off (we accept that weakness as the price for other strengths). As such, if you come simply pointing deficiencies, you may feel like you are pointing things nobody knows, but chances are, you aren't. You're probably just reminding contributors how frustrating it is they don't have time to solve everything. Pointing deficiencies is ok, but unless you take the time to offer some constructive steps to improve as well, it's often useless to be honest. -- Sylvain
