Docs: Update governance policy #66
Conversation
Updates governance policy to better match how we are actually operating.
|
@ilyavolodin @btmills @lo1tuma @xjamundx @gyandeeps please take a moment to review these changes. I think this better describes what we are actually doing. |
| * May merge their own pull requests once they have collected the feedback they deem necessary. | ||
| * Can label issues as they are submitted (but must not add the "accepted" label). | ||
| * May merge external pull requests for accepted issues upon reviewing and approving the changes. | ||
| * May merge their own pull requests once they have collected the feedback they deem necessary. (No pull request should be merged without at least one Committer/Reviewer comment stating they've looked at the code.) |
There was a problem hiding this comment.
Do you think it would be OK, to specify that that applies mostly to ESLint repository itself? (I merge my changes into website quite a bit without feedback, cause nobody looks at website repo:-) And also, maybe a clause to say that if the change is blocking/urgent it can be merged without review?
There was a problem hiding this comment.
I'd rather keep this generic so it makes sense for all repos. I kind of consider you the project lead for the website, so you have superpowers there.
I'd purger even blocking/urgent changes have a review as well. We can always make exceptions in certain cases, but I think a second set of eyes is always preferable.
|
Sounds good to me 👍 |
|
Looks good. 👍 |
|
No objections here. |
|
Can you also document which role is responsible for closing issues? Apart from that LGTM. |
|
@lo1tuma good idea. |
|
Updated, please review one more time. |
|
LGTM |
| @@ -34,7 +34,8 @@ Committers: | |||
| * May submit small changes (documentation updates, changes to tests or code comments, configuration changes) without pull requests. | |||
| * Must submit pull requests for any non-trivial changes. | |||
| * Have their work reviewed by Reviewers before acceptance into the repository. | |||
| * Can label issues as they are submitted (but must not add the "accepted" label). | |||
| * May label issues as they are submitted ("accepted" label should only be added for bugs, and only if the committer verified the bug as valid). | |||
There was a problem hiding this comment.
would it be fine to add the "accepted" label if we verify the bug our self and not through the official committer?
There was a problem hiding this comment.
Yes, that's what this says. You, the committer, can verify the bug and mark as accepted.
There was a problem hiding this comment.
lol. I dont know why i kept reading it as contributor.
My bad.
|
LGTM |
nzakas
force-pushed
the
master
branch
2 times, most recently
from
b38dd29
to
f4e74ca
Compare
|
@nzakas I think this can be merged. |
|
Oops, thanks for the reminder |
Updates governance policy to better match how we are actually operating.