Add a proposal for review process guidelines #120
Conversation
This is mostly a reflection of GitHub's terms, though with an explicit bias to action.
CONTRIBUTING.md
Outdated
| ### Practicalities of Review | ||
|
|
||
| * Please do choose reviewers when opening a PR, ideally by subject matter but if | ||
| in doubt pick one of the maintainers and they can redirect |
There was a problem hiding this comment.
If maintainers = code owners, their review will be requested automatically
If it's not, how will someone know who the maintainers are?
There was a problem hiding this comment.
I was actually thinking of you & I as the maintainers of this and I'd originally thought that GitHub provided a way to see that about a repo, but it doesn't. Perhaps we should add that explicitly (somewhere)?
Yes Code Owners would be great to add, though I do expect that we'll have areas which may not have a Code Owner in the long term, hence the fallback to the maintainers.
There was a problem hiding this comment.
db4bbcc solves this for now.
Naming Jake & I here is hopefully temporary, at least until we can get something better set up (Code Owners is a likely candidate).
PeterJCLaw
force-pushed
the
review-process
branch
from
12d0420
to
db4bbcc
Compare
|
Is this intended exclusively for the runbook or for all SR projects? |
As written this is intended for this repo only. There are definitely aspects which I think would be good to adopt everywhere (agreeing a protocol on what Approved/Request changes means and the expectations thereafter for example), but also things which likely don't make sense in other contexts (such as strongly biasing towards getting things in fast and fixing later, which would likely be a bad fit for firmware development). |
|
I have not read this yet but I suggest discussion/implementation of this is held until after the trustee organised meeting regarding documentation. |
It's now been over a month since the trustees mooted the idea of such a meeting, yet nothing has happened. One of the core issues we have with documentation is a stagnation caused by allowing Perfect to be the enemy of the Good, which ironically is one of the things which these guidelines are aiming to resolve. Unless you feel strongly that the proposal here is actively taking us in the wrong direction (bear in mind where we are currently), I suggest we consider this on its own merits and request review in that light. cc @RealOrangeOne @trickeydan |
This is mostly a reflection of GitHub's terms, though with an explicit bias to action.
Frankly I'd hoped that much of this was obvious, though it seems not to be the case.
There are two things which this leads me to wonder about: