Skip to content

Update CONTRIBUTING.md #1011

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.

Sign up for GitHub

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

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Update CONTRIBUTING.md #1011

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
23a0305
Update CONTRIBUTING.md
michaelcullum Feb 18, 2018
7a2fb68
Apply fixes as per reviews
Jean85 Oct 30, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 6 additions & 7 deletions CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Copy link
Contributor

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?

Copy link
Contributor

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?

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/retrain/retain?

Copy link
Member

Choose a reason for hiding this comment

The 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.
Expand All @@ -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
Copy link
Member

Choose a reason for hiding this comment

The 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..."

Copy link
Member

Choose a reason for hiding this comment

The 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
Expand All @@ -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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would reverse the two pieces, to make more sense (temporally):

[..] ideally on PSR approval and after every subsequent merge (or batch of merges).


Versioning should follow semantic versioning and primarily just be simple patch
fix increments (following semantic versioning). The first 1.0.0 tag should be
Expand Down