Skip to content
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

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

Conversation

michaelcullum
Copy link
Member

No description provided.

Copy link
Member

@dbu dbu left a comment

Choose a reason for hiding this comment

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

looks good to me. a typo note and one question/proposal to make it simpler to read.

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

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
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

Copy link
Member

@Jean85 Jean85 left a comment

Choose a reason for hiding this comment

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

Overall LGTM, but we should refine a few edits.

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
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

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.
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).

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

@Jean85
Copy link
Member

Jean85 commented Apr 16, 2018

@michaelcullum do you want to push this further? Do you want to open a discussion somewhere else about this?

@Jean85
Copy link
Member

Jean85 commented Oct 30, 2018

I've applied all requested fixes as per review.

@pullapprove pullapprove bot requested a review from mbabker November 13, 2018 12:27
@pullapprove pullapprove bot requested review from iansltx and mstaples February 4, 2019 19:33
@vdelau vdelau requested review from vdelau and a team and removed request for mbabker, iansltx and mstaples January 26, 2022 13:20
@vdelau
Copy link
Member

vdelau commented Jan 26, 2022

@Jean85, do we want to continue with this?

@Jean85
Copy link
Member

Jean85 commented Jan 28, 2022

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
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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants