I think we need to have a meta discussion about the goal for introducing a new
process. Your email mentions two reasons that I can see:
1) Clarity of the outcome? "For example they have been written up in jira
tickets, in a way that becomes quite difficult to unpack afterwards the
difference between the initial proposal and the actual agreed upon
design+implementation"
2) Community buy-in/input? "ideas that were largely fleshed out behind closed
(or hidden) doors and then only implemented in public"
The process seems orthogonal to (1) - this is a matter of imposing stricter
standards on docs before release, which we should mandate independently.
As to point (2), as formulated today ("When in doubt, if a committer thinks a
change needs an CEP, it does."), a "CEP" may be demanded by anybody with a
commit bit. It is problematic to me to ever _require_ this process, under any
circumstances, because it is unnecessarily restrictive about how members of the
community self-organise. It should be a voluntary process with clear benefits
to the participants to incentivise them.
(It's also not at all clear how you impose it retroactively - what if a
contributor didn't follow the processs, but has work to contribute?)
The contract should be simple: follow the process if you want progressive
feedback on your work, and a high chance of it being accepted without major
conceptual revisions at the final hurdle*. Otherwise, you risk the community
rejecting your work.
By not mandating it, we do not need to define where it is necessary; the larger
and more impactful the change, the greater the incentive to the author.
On a practical note, we should also be honest with ourselves, and others, that
this is experimental. Given the overall involvement of people on Jira and the
lists, I personally doubt any proposal will receive enough feedback during its
progress to materially mitigate the risk that members of the community chime in
at the final hurdle. If their concerns are valid, we have to listen to them,
even then. We cannot mandate that people participate incrementally in others'
work, because they have their own work to be doing, and if we curtail these
contributors' ability to provide feedback later, the project will only be the
poorer for it.
*The process may also provide legitimacy to decisions taken, so that matters
primarily of preference _may_ be decided in favour of participants if later
interlopers take exception.
On 16/09/2019, 19:03, "Mick Semb Wever" <m...@apache.org> wrote:
With the feature freeze for 4.0 getting a little closer to its end, and
after Scott's NGCC presentation on how Cassandra can be better at moving
forward, I'm keen to bring up the idea of a "Cassandra Enhancement Proposal"
(CEP) process.
Big changes in the past have not always been as transparent and clear as
they could have been in their initial stages. For example they have been
written up in jira tickets, in a way that becomes quite difficult to unpack
afterwards the difference between the initial proposal and the actual agreed
upon design+implementation, or a worse example, ideas that were largely fleshed
out behind closed (or hidden) doors and then only implemented in public.
A year ago a rough CEP (CIP) draft was put together, which was largely just
a copy of what Kafka and Spark do. Now Scott has done a bit of work in
formulating this into something that is higher-level and less
design-document-heavy.
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652201
Are they edits to the CEP, or its template, that folk would like to see?
Are we ready for such a CEP process?
Can we just take the jump and request that all new feature tickets link to
a CEP?
regards,
Mick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
