Reduce Dependence on wiki.php.net

[jrchamp]

Thank you for your consideration. I hope these ideas are helpful. ❤️

While wiki.php.net serves as a useful, historical, "point-in-time" view of the RFC process, this repository seems to have been created to act as the "living" set of documents that reflect the current policy.

As such, references to wiki.php.net should only serve as historical context or when directing users to follow current processes (such as the RFC process which still uses wiki.php.net as of March 2024), not as links to the "current" policy.

The specific example is the Voting Process.

policies/release-process.rst

Lines 137 to 151 in 020ebcb

	The change to what we have now is the voting process. It will not happen
	anymore on the mailing list but in the RFCs directly, for php.net members, in
	a public way.
	See also `the voting RFC <https://wiki.php.net/rfc/voting>`_.
	The question for this section is about who will be allowed to vote:
	- php-src (yes, no)
	- php-doc (yes, no)
	- qa, phpt (yes, no)
	- other sub projects like pear (yes, no)
	We have voting plugin for dokuwiki (doodle2) that allows voting on the wiki
	(installed).

1. The Voting Process should probably have its own file within this policies repository.
2. If the link is still needed, the Release Process should link to the new Voting Process policy document.
3. The Release Process, and documents like it, should avoid:
   1. Referencing older processes that are no longer in use.
   2. Detailing/duplicating content from other process documents.
   3. Containing unanswered questions.

I would also suggest that "complete" RFCs be ingested into this repository. This will further reduce dependence upon the wiki and limit the risk of after-the-fact edits being made to completed documents.

[derickr]

The initial "release" of this repository just copied files over. It definitely needs editing, and links to the wiki should indeed be removed/replaced/put in context, where needed.

We however, have no intention of moving non-policy RFCs into this repository. They will stay on the wiki. As we can see history, there is virtually no risk of people updating content to "argue" or something like that.