Morning internals, I've got some good feedback here, my suggested words were indeed rather loose.
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. The RFC process introduced itself, amends itself, is used for deprecation, addition, and removal. To say it's not suitable for these things is a total nonsense, we already use it for these things. I think maybe my use of the word "commit" was misunderstood. It is the case that a positive result means we are in some sense committed to merging the change (when a patch becomes available as in the case of null coalesce assign). I went to the effort of mentioning the specific case where an implementation is not suitable. Obviously other cases may arise where the decision is reversed by a follow up RFC, I thought this possibility was implicit. A note on the group issue: When I said it's not well defined, I didn't mean we don't have a list of names, quite the opposite, we have a list of names that are mostly unconnected to the project today. What we don't have is a definition of the role of the Group, specifically one that fits the project as it is today. This undeniably causes confusion and a certain amount of friction, both during interactions between internals members and in the wider community. Thanks for all the input, I'll give this some more thought ... Cheers Joe On Mon, 16 Sep 2019 at 05:36, Kalle Sommer Nielsen <ka...@php.net> wrote: > Hi Joe > > Den søn. 15. sep. 2019 kl. 08.48 skrev Joe Watkins <krak...@php.net>: > > > > Morning internals, > > > > There is confusion among the community, and contained in the documented > > history of PHP on the wider internet. > > > > The Wikipedia states that PHP is developed by the PHP Group, in saying > this > > it is (must be) referring to internals as a whole, but our own > > documentation names members of the group - who aren't even around mostly. > > > > I think we need to clarify what exactly is the purpose of the PHP Group > > today, does anyone want to attempt to do that ? > > This is speculation/my interpretation, so take this with a grain of > salt; I think The PHP Group was the project governance back in the > day, but with PHP's ever so vastness and expansion, new developers > come in, old developers go all the time, I don't think this ever got > to be what it was meant to be. Now a days it mostly seems to serve as > a legacy of the past. > > Given the recent clarification from Rasmus, I do not think the name > has any meaning anymore besides being a fancy name that holds the > copyright, whereas the copyright probably should be updated to be: > "Copyright (C) The PHP Project", on the PHP.net website, license et > al. Besides this I cannot think of a place where I have seen a > definition of "The PHP Group" or seen it active besides its recent > mention of being an "authoritative" power (which clearly is not the > case as there is no legal ramification to hold this statement true). > > (I picked "The PHP Project" over "The PHP Development Team" which is > also commonly used to include everyone who contributes time and > resources to PHP). > > > Whatever it's purpose, if it has one, we need to make clear at this time > > that there are no vetos: As Rasmus clarified, PHP is driven by the people > > who write PHP: No member of any group or company, historical or > otherwise, > > has any veto powers, they cannot, and they must not behave as if they do. > > > > I would like to update the introduction to the Voting RFC: > > > > The development of PHP is community driven by the RFC process described > in > > this document. Anyone may initiate an RFC for any subject. At the end of > > the RFC process a vote is held among PHP developers to determine if the > > proposal is to be accepted. > > > > Should a proposal be accepted, the developers of PHP are committed to > > making the change. > > > > In some circumstances, merging an implementation into the source code of > > PHP may be delayed because of shortcomings in that implementation. In > these > > cases, resolution of these shortcomings is the responsibility of the > > proposer. > > > > Should a proposal be accepted without an implementation, it is the > > responsibility of the proposer to provide one. > > > > Does anyone object to any of those words ? > > > > Do we need to vote on changing the introduction (I'm happy to start an > rfc > > for this, if necessary) ? > > I got no objection to adding it, but perhaps an RFC should be more in > the direction of a "Mission statement" of sorts, stating what the > project is, what our goals are, who steers the direction etc. This > could be a decent start to sorting out the strings. > > > > -- > regards, > > Kalle Sommer Nielsen > ka...@php.net >
