Hi Everyone, I totally agree that merging #1183 was an overstep on my part, the bylaws are clear that it should be a secretary managing merging and not the editor of the PSR. I also agree that some of these changes would qualify for errata, I appreciate you paying attention and holding me accountable.
That said I think our bylaws are a little too open when it comes to managing these sorts of changes. Once a PSR is accepted, secretaries are charged with managing "typos, changes or errata" with the optional help of the editor: > If the Acceptance Vote passes, ... the Working Group is automatically dissolved, however the Editor’s input (or a nominated individual communicated to the secretaries) may be called upon in the future should typos, changes or Errata on the specification be raised. The "typos" and "changes" portion of that is classified more specifically in the Amendments bylaw as "formatting and typo" fixes: > If formatting is broken for any reason then changing formatting must not be considered a change to the document. These can be merged or pushed without hesitation by a secretary, as long as they don’t change anything of any meaning or syntax. So secretaries are expected to ensure modifications are "not ... considered a change to the document" and "don’t change anything of any meaning or syntax" with the occasional help of the Editor as needed. In practice, as demonstrated here these things are subjective and can be interpreted differently by different individuals. In this case, both the Editor of the PSR and current secretaries looked at these changes and agreed they could be merged without errata votes. I think we should consider changing the typos and formatting change process so that it's less subjective and more likely to result in stable specifications. Perhaps we could have a subcommittee in the CC that has to give blessing to merge changes to any approved specification. Thanks again for keeping an eye on these things Larry, Korvin On Wed, Sep 18, 2019 at 9:42 AM Larry Garfield <la...@garfieldtech.com> wrote: > Hi all. > > I noticed this morning that this PRs had been merged against PSR-12: > > https://github.com/php-fig/fig-standards/pull/1185 > https://github.com/php-fig/fig-standards/pull/1183 > > I do not believe the changes in them are appropriate for an > already-voted-on PSR. Changes post-vote are permitted in only very narrow > circumstances: > > https://www.php-fig.org/bylaws/psr-amendments/#3-acceptable-amendments > > The following changes in that PR go well beyond Annotations or Formatting > & Typos: > > https://github.com/php-fig/fig-standards/pull/1185/files > > Changing "would not" (a non-binding term) to a "MUST NOT" (an RFC defined > term with very specific meaning) is a substantive change. The original > "Would not" language is, in context, entirely adequate. > > > https://github.com/php-fig/fig-standards/pull/1183/files#diff-53ccbb40a68e167a66735993f78e0bb9L99 > > This block changes the meaning of the spec, and thus is not allowed. > > > https://github.com/php-fig/fig-standards/pull/1183/files#diff-53ccbb40a68e167a66735993f78e0bb9L369 > > Because capitalized MUST has a specific "legal" meaning, this is also > technically a substantive change. > > > https://github.com/php-fig/fig-standards/pull/1183/files#diff-53ccbb40a68e167a66735993f78e0bb9L439 > > Substantive change, and isn't even explained. > > > https://github.com/php-fig/fig-standards/pull/1183/files#diff-53ccbb40a68e167a66735993f78e0bb9L464 > > While this is a net-zero impact change because the language already > requires it, I would still say it's more than is allowed without an errata. > > > https://github.com/php-fig/fig-standards/pull/1183/files#diff-53ccbb40a68e167a66735993f78e0bb9L689 > > These buts don't really add anything. (Insert inappropriate joke here.) > > > https://github.com/php-fig/fig-standards/pull/1183/files#diff-53ccbb40a68e167a66735993f78e0bb9L885 > > This change is even noted in the comments as being a substantive change. > This is not acceptable post-vote. > > > https://github.com/php-fig/fig-standards/pull/1183/files#diff-53ccbb40a68e167a66735993f78e0bb9R918 > > I... don't even know what this is about at all. > > As a result, what is currently published as PSR-12 is not what was > approved by the Core Committee. That situation must be corrected. > > I ask the Secretaries to revert both PRs promptly. Additionally, I do not > believe PRs to approved specs should be merged by anyone other than the > Secretaries, as they are the ones nominally responsible for typo-fix level > changes. > > There are some non-substantive changes in the larger one that are fine > (adding newlines and fixing some commas or capitalization), which can be > resubmitted. Any substantive changes must go through an Errata vote, and > if approved added to the meta document. > > (Note: I am not making any statement here on the substance of those > changes, and whether they're good or bad for the spec. Just that they are > inappropriate at this time.) > > -- > Larry Garfield > la...@garfieldtech.com > > -- > You received this message because you are subscribed to the Google Groups > "PHP Framework Interoperability Group" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to php-fig+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/php-fig/48c58f56-2f61-4d02-9b04-ef7f71fd3de4%40www.fastmail.com > . > -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CANeXGWU6pXbEy-AiudZO%2BP7Cvu4nx8DKWWSe%2Bibpj48BFbCQMg%40mail.gmail.com.
