-
Notifications
You must be signed in to change notification settings - Fork 2.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update CONTRIBUTING.md #1011
base: master
Are you sure you want to change the base?
Update CONTRIBUTING.md #1011
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -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 | ||
have access to push to this (php-fig/fig-standards) repository; subject to | ||
secretary discretion | ||
|
||
All Editors, Coordinators and Sponsors of specifications have push access to utility | ||
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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. s/retrain/retain? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yep, that's a typo. |
||
|
||
The master branch of all repositories are protected and therefore cannot be forced | ||
pushed to. | ||
|
@@ -43,8 +42,8 @@ directly (excluding inital commits on new interface/util repositories) to master | |
comment) or merged by the PSR Editor, except in the review phase when the coordinator | ||
should seek commment from the editor, but merging is at the coordinator's discretion | ||
* You must never merge a pull request that affects any file in the repository | ||
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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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 |
||
* You should never merge your own pull request | ||
* A change should never be merged to an accepted PSR without approval from | ||
secretaries, who will attempt to seek confirmation from the former Editors | ||
|
@@ -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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would reverse the two pieces, to make more sense (temporally):
|
||
|
||
Versioning should follow semantic versioning and primarily just be simple patch | ||
fix increments (following semantic versioning). The first 1.0.0 tag should be | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?