Another thing which it should solve is someone proposing an alternate very late into development which could be provided sooner. If someone has a good feedback which could not have been given at the time of CEP then that is good. We don't want situations where contributors have done the CEP and then worked on implementation of it and then someone who has not read the CEP comes in and starts giving feedback. This feedback should come at the time of CEP if CEP has covered that area. To be clear, I am not saying people should not give feedback later just that they dont ignore the whole thing and wake up later in the process. This causes huge productivity and morale loss to code contributors who are in minority right now in the community.
On Tue, Sep 17, 2019 at 3:44 AM Benedict Elliott Smith <bened...@apache.org> wrote: > Can we modify the document to make this really explicit then? Right now, > the language suggests the process is mandated, rather than encouraged and > beneficial. > > It would be nice to frame it as a positive and incentivised undertaking by > authors, and to list the intended advantages, as well as the potential > disadvantages of not undertaking it, while making it clear it is left > entirely to their own judgement whether or not to do so. > > To be really clear, I do not refer to the flexible definition of the > process, but to whether participation in even a modest interpretation of > the process is necessary at all. This is a form of pre-registration for > work, to achieve community buy-in. If you want to go ahead and do > something on your own, you only risk difficulty and delays when obtaining > community buy-in after the fact. Let's not dissuade hobbyists, part-timers > or scratching an itch by suggesting their work will be discounted because > it wasn't pre-registered. > > > On 17/09/2019, 06:46, "Mick Semb Wever" <m...@apache.org> wrote: > > > > > I think we need to have a meta discussion about the goal for > > introducing a new process. > > > Indeed, and these were only two brief examples that came to me. > Another, using the sidecar proposal as an example, is simply to ensure a > little patience is taken during the initial brainstorming and navigation > phase, to give more open collaboration a better chance. What's in the > landscape, where's the value, who might be interested in getting involved > in this, etc etc. I think the C* community has typically been pretty > amazing at this, but it would be nice to see it formalised a bit better. > > > > 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. > > > This is what Scott highlighted well. > Sure, a CEP could be opened with nothing but a title to begin with. > And where it goes from there is up to the working group that materialises. > Just to have a landing space for new features that's not Jira, I believe > would be of value. > > And in no way should the CEP be a return to waterfall. As you say, > late discoveries and feedback (as annoying as it can be) is all part of the > agile game. > > > > --------------------------------------------------------------------- > 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 > >
