Re: [PHP-DEV] Defining the PHP Group

This is only part of a thread. view whole thread
  107145
September 16, 2019 08:01 krakjoe@gmail.com (Joe Watkins)
Stas,

> Not can't, shouldn't be. And I don't see any reason why we should stop saying that.
Because it's a waste of everyone's time. The RFC process is the only one we have.
> RFC process was not created to be sole governing body for PHP project and something that makes every vote mandatory for the whole project.
I'm not sure exactly what this means. 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 already conceded that my words were loose and I done a pretty poor job of doing that.
> but if there's no consensus about some thing like project governance, then just holding a vote for two weeks in random point of
time among those who happens to read the list at that time is not a good governance model. 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. 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. The vast majority of contributors are quite happy to use the RFC process in all the ways we have been using it. Cheers Joe On Mon, 16 Sep 2019 at 09:52, Stanislav Malyshev <smalyshev@gmail.com> wrote:
> Hi! > > > I'd like it if we could stop saying the RFC process can't be used for one > > thing or another, it's patently false. > > Not can't, shouldn't be. And I don't see any reason why we should stop > saying that. > > > To say it's not suitable for these things is a total nonsense, we already > > use it for these things. > > Contrary to popular belief, saying the magic word "nonsense" doesn't > actually prove anything and doesn't replace actual argument. > > RFC process was not created to be sole governing body for PHP project > and something that makes every vote mandatory for the whole project. If > there's a consensus about certain decision, sure, it can be confirmed by > a vote, but if there's no consensus about some thing like project > governance, then just holding a vote for two weeks in random point of > time among those who happens to read the list at that time is not a good > governance model. > > RFC process is fine for committing features because worst thing we > commit some bad code, and revert/amend it later. It's a bit dangerous > for deep language features since rolling that back would be hard. But I > do not think governing the project can be done in this way. Fortunately, > PHP project actually doesn't need a lot of "governing", but when the > need arises, just holding a two-week vote among whoever happens to read > the list in those two weeks - I don't think that would work very well. > -- > Stas Malyshev > smalyshev@gmail.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
  107147
September 16, 2019 08:17 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> 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 smalyshev@gmail.com