Better managing PHP 8.1 updates

Hello, docuzitiens. A proposal. We generally wait to document anything in a new PHP version until sometime in the betas, often RCs, to avoid confusing people with future functionality. OK, fine, but that does create a problem of tracking changes so we don't forget anything. For 8.0, there was a manually maintained big punch list: https://github.com/php/php-tasks/issues/26 . That required manual updates by Girgias, and assumed we remembered everything. I think we can do better for PHP 8.1. Proposal: Instead, let's go ahead and create issue tickets on the docs repo now for any future-8.1 documentation tasks. Every RFC would need one, plus other stuff that bypasses RFCs. That's a low-enough barrier that we can also ask/beg/plead people working on core directly to file such tickets too, although we'll likely need to flesh them out a bit. Anyone with access to manage issues can then tag them for "8.1" (or some name like that). When filing PRs in the future, then, the PR can include "Resolves #whatever" to auto-close that issue when it gets merged, which will happen directly on GitHub now so the built-in automation all works. Advantages: * A GH issue lets us put in more todo-information than just a bulleted list. * The punch list is just a list of all issues with the 8.1 tag, and is then self-updating. No need to harass Girgias. * We can start building a task list now, in advance, when stuff is fresh in the appropriate person's memory. * We can assign issues to people (including ourselves) to indicate intent to work on it. * Easier for drive-by contributors to see what needs doing. Odds are they won't know to go look at the php-tasks repository. Thoughts? -- Larry Garfield larry@garfieldtech.com