Update CONTRIBUTING.md #1011
Update CONTRIBUTING.md #1011
Conversation
CONTRIBUTING.md
Outdated
| and interface repositories and retrain this even after acceptance; subject to secretary | ||
| discretion. | ||
| All Editors and Sponsors of specifications have push access to utility and interface | ||
| repositories and retrain this even after acceptance; subject to secretary discretion. |
CONTRIBUTING.md
Outdated
| other than those you are on a working group for; you should request a secretary | ||
| or member of that working group (mention @php-fig/psr-x) do so | ||
| other than those you are on a working group for unless you are a secretary; you should | ||
| request a secretary or member of that working group (mention @php-fig/psr-x) do so |
There was a problem hiding this comment.
before, it was implicitly obvious, now its more complicated. or is that a change of policy that secretaries are now allowed to merge things they have not been allowed to? maybe split it into "Secretaries are allowed to merge any pull requests" and "Editors and sponsors may only merge pull requests that exclusively affects files of their working group(s); for other pull requests, they should request..."
There was a problem hiding this comment.
IMHO that specification is not needed; it's basically implicit because the secretaries have by definition admin rights on any PHP-FIG repo, so they act as gatekeepers. There are bylaws in place that already define what or what not a secretary may merge without second guessing... Basically just typos and the like, see: https://www.php-fig.org/bylaws/psr-amendments/#32-formatting--typos
CONTRIBUTING.md
Outdated
| other than those you are on a working group for; you should request a secretary | ||
| or member of that working group (mention @php-fig/psr-x) do so | ||
| other than those you are on a working group for unless you are a secretary; you should | ||
| request a secretary or member of that working group (mention @php-fig/psr-x) do so |
There was a problem hiding this comment.
IMHO that specification is not needed; it's basically implicit because the secretaries have by definition admin rights on any PHP-FIG repo, so they act as gatekeepers. There are bylaws in place that already define what or what not a secretary may merge without second guessing... Basically just typos and the like, see: https://www.php-fig.org/bylaws/psr-amendments/#32-formatting--typos
CONTRIBUTING.md
Outdated
| @@ -66,7 +65,7 @@ access. Merge access is a privilege and not a right. | |||
| # Tagging | |||
|
|
|||
| Tagging on utility and interface repository should be done regularly, ideally after | |||
| every merge, or every batch of merges after PSR approval. | |||
| every merge, or every batch of merges after PSR approval; and on PSR approval. | |||
There was a problem hiding this comment.
I would reverse the two pieces, to make more sense (temporally):
[..] ideally on PSR approval and after every subsequent merge (or batch of merges).
CONTRIBUTING.md
Outdated
| and interface repositories and retrain this even after acceptance; subject to secretary | ||
| discretion. | ||
| All Editors and Sponsors of specifications have push access to utility and interface | ||
| repositories and retrain this even after acceptance; subject to secretary discretion. |
|
@michaelcullum do you want to push this further? Do you want to open a discussion somewhere else about this? |
|
I've applied all requested fixes as per review. |
|
@Jean85, do we want to continue with this? |
|
It would need a rework due to the newer bylaws updates. I'll try. |
| @@ -20,13 +20,12 @@ given according to the current bylaws of this group. | |||
|
|
|||
| # Merge & Access Policy | |||
|
|
|||
| All Editors, Coordinators and Sponsors of specifications in draft & review stage | |||
| All Editors, Sponsors and WG members of specifications in draft & review stage | |||
There was a problem hiding this comment.
Is this the only piece that's not accurate based on the bylaw changes since the PR was submitted? Do we just need to drop WG members here?
I don't immediately see any issues with the remaining changes... or does @Jean85 's last comment from Jan mean the whole doc itself needs reworked?
There was a problem hiding this comment.
Is this the only piece that's not accurate based on the bylaw changes since the PR was submitted? Do we just need to drop WG members here?
I don't immediately see any issues with the remaining changes... or does @Jean85 's last comment from Jan mean the whole doc itself needs reworked?
No description provided.