Re: Better managing PHP 8.1 updates

On Wed, May 19, 2021, at 6:08 AM, Christoph M. Becker wrote: > On 18.05.2021 at 22:40, Larry Garfield wrote: > > > 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? > > The problem I see with this approach is that we would have to open > issues for php/doc-en, and I presume that we will get quite some issue > reports regarding doc bugs. They aren't? I didn't realize that wasn't already the case. I think that's fine, though. At least, it's better for bug reports to come into GitHub than comments on the site, no? > Maybe it would be better to label PRs for php/php-src which need > documentation with "documentation needed" (or so)? > > Christoph Possibly, but then we have to go digging through already-closed PRs for tagged issues, and then it's a different set of people that have access to add/remove the tags as appropriate. --Larry Garfield