We have to be very careful here in my opinion. While the process may provide
some moral authority, particularly on matters of taste or opinion, we cannot
mandate participation, else accept the decisions that arise. People are
legitimately busy, and have to steal their spare time to participate - which
can be draining. Particularly for large undertakings, where context and
headspace can be costly, even more so when you have your own projects to
deliver.
I only personally endorse giving the _benefit of the doubt_ to participants in
a CEP/CIP. It cannot be carte blanche, or even a presumption of a decision
being made in its favour. A CEP/CIP should still aim to bring the _most
likely_ to be accepted proposal to the whole project for its endorsement, or
for further revision.
Our goal here should be to mitigate risk for all parties, without disrupting
the governance of the project. Everyone should be _incentivised_ to behave in
desirable way, but we should not penalise too heavily any individual (or the
project, by ignoring them) for failing to do so.
It seems to follow that a full PMC vote could be held to accept or reject the
result of any CEP/CIP, rather than the normal +1/-1 of a single committer/PMC
member. I would favour this meaning there no veto is possible at this stage,
which would provide a further incentive to authors. In this case we only need
to agree guidance for how a completed CEP/CIP should be received for such a
vote, since we cannot bind a future PMC anyway.
On 17/09/2019, 18:19, "sankalp kohli" <kohlisank...@gmail.com> wrote:
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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
