Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC] Collecting All Policies Into One Repository »

[RFC] Collecting All Policies Into One Repository

php.internals

Derick Rethans

2 years ago
Hi! A while ago I started looking into all the documents (RFCs etc) that we have that relate to all sort of policies. From RFCs, to who can vote, naming, and security classifications as a result of a discussion with the foundations folk. Now there was another small confusion during a recent vote, we came up with the idea to actually go forwards with this, and make all our lives easier by having one place where all these documents are located. Hence I have created a (beta) repository and collected that information: https://github.com/php/policies The contents are copied verbitim from RFCs, without any editing. Some RFCs made it into a single file as IMO they belonged together. I have also created an RFC to establish this location, as changing policies and RFCs require an RFC: https://wiki.php.net/rfc/policy-repository The contents are probably not exhaustive, and it is entirely possible that it does not include all information. I would therefore be greatful if you could have a look at the RFC, the collated documents, and let me know whether I missed anything, or whether you are missing something we might not even have written down yet. I am hoping that the discussion to establish this repository is straightforwards. Further steps will include: editing the documents so that they read as documents, and not copy-pasted content with RFC language, and including our existing coding standards. cheers, Derick
-- https://derickrethans.nl | https://xdebug.org | https://dram.io Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support Host of PHP Internals News: https://phpinternals.news mastodon: @derickr@phpc.social @xdebug@phpc.social twitter: @derickr and @xdebug

Larry Garfield

2 years ago
On Tue, Dec 5, 2023, at 11:06 AM, Derick Rethans wrote:
> Hi! > > A while ago I started looking into all the documents (RFCs etc) that we > have that relate to all sort of policies. From RFCs, to who can vote, > naming, and security classifications as a result of a discussion with > the foundations folk. > > Now there was another small confusion during a recent vote, we came up > with the idea to actually go forwards with this, and make all our lives > easier by having one place where all these documents are located. > > Hence I have created a (beta) repository and collected that information: > https://github.com/php/policies > > The contents are copied verbitim from RFCs, without any editing. Some > RFCs made it into a single file as IMO they belonged together. > > I have also created an RFC to establish this location, as changing > policies and RFCs require an RFC: > https://wiki.php.net/rfc/policy-repository > > The contents are probably not exhaustive, and it is entirely possible > that it does not include all information. I would therefore be greatful > if you could have a look at the RFC, the collated documents, and let me > know whether I missed anything, or whether you are missing something we > might not even have written down yet. > > I am hoping that the discussion to establish this repository is > straightforwards. Further steps will include: editing the documents so > that they read as documents, and not copy-pasted content with RFC > language, and including our existing coding standards. > > > cheers, > Derick
Thank you for this, Derick! I very much support this initiative and look forward to it.
> Should the historical information in “release process” be moved out of release-process to a dedicated file?
I would say yes. The ideal structure of the document (once edited down) would be a snapshot of "how things work right now." Historical alternatives should either be just git history or a separate non-normaitive set of files. I would also ask, does this mean future changes to process would be submitted and reviewed as a PR against this repo, with the RFC for it being mostly a placeholder for "vote on this PR", with explanation? I would assume so, but it would be good to make that explicit. --Larry Garfield

Derick Rethans

2 years ago
On Tue, 5 Dec 2023, Larry Garfield wrote:
> On Tue, Dec 5, 2023, at 11:06 AM, Derick Rethans wrote: > > Hi! > > > > A while ago I started looking into all the documents (RFCs etc) that we > > have that relate to all sort of policies. From RFCs, to who can vote, > > naming, and security classifications as a result of a discussion with > > the foundations folk. > > > > Now there was another small confusion during a recent vote, we came up > > with the idea to actually go forwards with this, and make all our lives > > easier by having one place where all these documents are located. > > > > Hence I have created a (beta) repository and collected that information: > > https://github.com/php/policies > > > > The contents are copied verbitim from RFCs, without any editing. Some > > RFCs made it into a single file as IMO they belonged together. > > > > I have also created an RFC to establish this location, as changing > > policies and RFCs require an RFC: > > https://wiki.php.net/rfc/policy-repository > > > > The contents are probably not exhaustive, and it is entirely possible > > that it does not include all information. I would therefore be greatful > > if you could have a look at the RFC, the collated documents, and let me > > know whether I missed anything, or whether you are missing something we > > might not even have written down yet. > > > > I am hoping that the discussion to establish this repository is > > straightforwards. Further steps will include: editing the documents so > > that they read as documents, and not copy-pasted content with RFC > > language, and including our existing coding standards. > > Thank you for this, Derick! I very much support this initiative and > look forward to it. > > > Should the historical information in “release process” be moved out > > of release-process to a dedicated file? > > I would say yes. The ideal structure of the document (once edited > down) would be a snapshot of "how things work right now." Historical > alternatives should either be just git history or a separate > non-normaitive set of files.
Fair enough. I also tended to go that way.
> I would also ask, does this mean future changes to process would be > submitted and reviewed as a PR against this repo, with the RFC for it > being mostly a placeholder for "vote on this PR", with explanation? > I would assume so, but it would be good to make that explicit.
The RFC currently has "RFCs to add or amend to policy would then target additions or modification of the documents in this repository, instead of having them just as RFC text." so that was my intention. I've updated the text to make this a little clearer though. cheers, Derick
-- https://derickrethans.nl | https://xdebug.org | https://dram.io Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support Host of PHP Internals News: https://phpinternals.news mastodon: @derickr@phpc.social @xdebug@phpc.social twitter: @derickr and @xdebug

Derick Rethans

2 years ago
Hi, On Tue, 5 Dec 2023, Derick Rethans wrote:
> A while ago I started looking into all the documents (RFCs etc) that we > have that relate to all sort of policies. From RFCs, to who can vote, > naming, and security classifications as a result of a discussion with > the foundations folk.
A heads-up, as I posted this just over two weeks ago, and there was little discussion. I am intending to open the voting on this in the next few days. With the intention of running it until January 5th due to the holiday season. cheers, Derick

Joerg Sowa

2 years ago
Hey Derick, Thank you for proposing this change. As a author of comment you mentioned I believe this will help new maintainers to get all the information about the RFC process from one place. I have one question regarding the future changes. Do you see it would be possible to make amendment to the accepted RFCs by the Pull Requests (and formal RFC approach) making changes the existing policies or adding the new policy replacing the old ones? In other words, this repository would server as the collection of all ever accepted policies or it would contain the unified policy documentation? I'm asking because I saw the directory `archive`, and it contains expired RFC. I don't think this would help new contributors. For the history purposes it would be nice to have it in the git history, but for the PHP development process is not relevant anymore and is little overhead. Kind regards, Jorg

Derick Rethans

2 years ago
On Mon, 18 Dec 2023, Jorg Sowa wrote:
> I have one question regarding the future changes. Do you see it would > be possible to make amendment to the accepted RFCs by the Pull > Requests (and formal RFC approach) making changes the existing > policies or adding the new policy replacing the old ones? In other > words, this repository would server as the collection of all ever > accepted policies or it would contain the unified policy > documentation?
It should contain the consolidated unified policy documentation that is "currently" active. The other option is what we currently have, and I am proposing to go away from. So the idea is that this repository is not a collection of the accepted policy *amendments* (or *replacements*), as that's what the RFCs / PRs are still for.
> I'm asking because I saw the directory `archive`, and it contains > expired RFC. I don't think this would help new contributors. For the > history purposes it would be nice to have it in the git history, but > for the PHP development process is not relevant anymore and is little > overhead.
I didn't really know what to do with these documents in archive, as they were sortof related to the release process/timeline document. I suppose we don't need them, but they are not *wrong* or *outdated*. Simply no longer needed as the time frame has passed. cheers, Derick

Joerg Sowa

2 years ago
> It should contain the consolidated unified policy documentation that is > "currently" active.
> The other option is what we currently have, and I am proposing to go > away from. So the idea is that this repository is not a > collection of the accepted policy *amendments* (or *replacements*), > as that's what the RFCs / PRs are still for.
Thank you for the explanation. That's exactly what I was hoping for. Kind regards, Jorg