>
> What are you basing this harmful supposition on?
>
ascribing negative intentions or motives to others without good reason. It
> is not good for you, or the community.
>
I certainly don't want you worried about my wellbeing on account of this
dialog; it's always good to be reminded about our shared concern for each
other as humans and the project's health in interactions like this though!
Just so you don't need to worry about me and to hopefully help clarify for
readers: I personally strongly believe *everyone* on this thread's
intentions and motives are nothing more or less than the long-term
wellbeing of the project. Full stop. We definitely don't appear to all
agree on the best way to get there, but at least I personally don't
question that as being everyone's goal. If that's coming across in my
verbiage I'll happily work on improving that; DM's with pointers welcome.
To clarify a hypothetical in which I think discouraging contributions from
some sources would be very appropriate and not harmful in any way, "we
should discourage people who are 1st year in university who have never used
Java nor worked on infrastructure code from trying to contribute rewrites
of things like Gossip or our StorageEngine." This seems like a pretty
reasonable statement in my opinion. No negative intentions or motives, just
the constraints of reality. It's a continuum, and there's a lot of things
in this codebase that are more complex with longer histories than others,
and varying levels of skill (and perceptions of each others' level of
skill!) to further complicate things.
In the 6.5 years I've spent on the project, we have a strong and consistent
culture of both dropping gigantic multi-tens-of-thousands of line squashed
atomic changes on each other and then rewriting each others' code en masse
(sometimes before it's even released!) instead of working in small
increments and reverting when deemed appropriate [1]. I think a completely
rational way to try and mitigate the downsides of these patterns would be
for an individual to think and/or say "Hey, please hold off on writing that
until I can engage. I have a point of view but don't have time to engage
right now (or will have to stop working on other things I consider
critical) and I don't want to have to rewrite this stuff later to address
issues that I fear will be overlooked. Fixing after merge is 10x harder
than at design, and 10x harder when it's out in production, etc". Ergo,
people working on 4.0 would feel the obligation to dilute their investment
on 4.0 to engage on these other efforts. A very rational PoV IMO.
The more significant cost to the project is distracting contributors
> focused on 4.0. The project is bandwidth constrained right now. Feature
> development doesn't happen in a vacuum, and some of that bandwidth will
> have to go to participating in any new feature development. So, if feature
> development begins in earnest, the 4.0 ship date will slip
>
Structurally in terms of social dynamics, it seems like things mostly hinge
on whether or not committers trust each other to do the work to a high bar
of quality that they're focused on doing and accepting that there are
differing views on how to achieve our shared priority of Cassandra's
long-term success. Ultimately I would contend we haven't historically had
the coding hygiene, behavioral expectations, or quality tooling to make
this need for trust unnecessary, though we're making progress there.
That said, regardless of these dynamics there are fundamentals to how
Apache projects operate, and I think it's valuable to quote Jeff here:
> I think we all know it’s not reasonable to say what people can and can’t
> work on in any open source project. PMC members and committers get an
> opinion on what goes in the repo, but not what gets worked on or reviewed
> by other committers.
>
It's my earnest hope that continuing dialog like this proves constructive
for the project rather than destructive. Navigating the Innovator's Dilemma
[2] on a project as old and as widely adopted as Cassandra is a very real
challenge.
[1]: http://community.apache.org/committers/lazyConsensus.html
[2]: https://en.wikipedia.org/wiki/The_Innovator%27s_Dilemma
p.s. - sorry for being long-winded. Lots of complex stuff to cover here.
On Sat, Sep 12, 2020 at 5:46 PM Benedict Elliott Smith
wrote:
> > It's very possible others on this thread believe that
> > discouraging contribution from some sources is preferable for the health
> of
> > the project. That seems like it could be healthy to talk about openly
> if so.
>
> This is directly contrary to the evidence I have seen. Proponents of the
> status quo have expressly encouraged more contributions that are compatible
> with the freeze, and at most a postponement has been suggested for
> contributions that are incompatible with the freeze. What are you basing
> this harmful supposition on?
>
> I would ask you to try really hard to break this pattern, of ascribing
>
