Re: [PHP-DEV] Defining the PHP Group

This is only part of a thread. view whole thread
September 16, 2019 08:17 (Stanislav Malyshev)

> Because it's a waste of everyone's time. The RFC process is the only one > we have.
So? There was time where we had none. Processes are not some precious jewels that we occasionally happen to find by chance but can't have any more. We can create them.
> To clarify, I wasn't trying to impose anything new by changing the > introduction, I was only trying to give a formal description of how the > project actually does work, and what role the RFC process plays in that.
I don't think I agree that the project works that way, at least the way I understood what you wrote. Maybe my understanding did not match your intent, but then we need a formulation that would express that intent more clearly, so that myself and others would understand it properly and we could agree on it.
> Your suggestion implies that *if* there was no consensus about how the > project is governed that it would be our only option to continue without > a way to resolve that question.
No, it's not the only option. I am just saying that having an RFC vote as defined in RFC process is not the only option, and it's not the preferable option. We can seek others.
> In reality, there is a consensus about how the project is governed. Some > contributors may be unhappy, and far too loud about expressing their > opinions on this, but they are a small minority.
Your definition of "consensus" is very different from mine then. And how do you know those who disagree with you are "small minority"? Small compared to what? Minority compared to whom?
> The vast majority of contributors are quite happy to use the RFC process > in all the ways we have been using it.
Vast majority of contributors also probably have very little interest in project governance as long as it delivers the results - i.e. features get implemented, patches get merged, bugs get fixes, code keeps running. But when there's disagreement about the overall direction the project should take, and how to solve it, I don't think anybody ever asked "vast majority of contributors" about how to solve it and I doubt that vast majority spent significant time on evaluating the merits of potential solutions to that. In fact, I am not even convinced "vast majority of contributors" are those who need to decide that - is it really right that whoever contributed a docs fix or a test couple of times, or maybe supported one extension, has the same voice on the project direction as somebody who implemented large pieces of code and spent decades in the project? That's one of the questions that needs to be considered. There are likely more. -- Stas Malyshev