On 11.08.2024 at 22:21, Juliette Reinders Folmer wrote: > Thanks Christoph! I was tempted to update the RFCs myself, but thought > it was against protocol for anyone but the RFC owner to do so ? hence my > email.
Changing an open RFC without consent of the RFC author(s) is certainly against protocol. However, in my opinion it is perfectly fine to update such "meta" information for closed RFCs (i.e. RFCs which have been implemented or declined or withdrawn). Especially implemented RFCs which are linked from UPGRADING *should* be updated in this regard as soon as possible to avoid readers being confused where to find the implementation (and such readers might be those who want to write documentation, and sometimes need to look up the implementation or its discussion). And it's equally important to update declined RFCs; understandably, authors of such RFCs might not want to spend more time on the gory details of the RFC process. :) > If you need links to PRs/commits, I've got them, as I've been looking > them up for the initial PHPCompatibility package updates. Please feel free to update the necessary information yourself. Unless you tick the "minor changes" checkbox (what you probably shouldn't do for such updates, unless when moving RFCs on the overview page to the correct sections), a notification is available as public RSS feed, so everyone can follow this, and going back to an older version of the RFC would be a matter of a couple of clicks. And frankly, I don't think an RFC author would have an issue if somebody else catches up on what they just might have forgotten. > For fpow(), these are the relevant ones (and include the fpow() function > in contrast to the text in the PR description - PR was updated after it > was originally pulled): Jorg has updated the RFC in the meantime (thanks!) Christoph
