doc: add WG "bootstrap kit" #26
Conversation
Separate out the templates for bootstrapping a WG process
|
Yes! Issues will shake out as people use it, but it only needs to be good enough to be usable and not perfect or complete. Yes! |
|
other than what i outlined in my comments (which are nitpicks, sort of), i think it's a good thing! +1 from me |
|
All occurrences of the word |
|
@Trott ah, makes sense |
Link to WORKING_GROUPS.md files
| the [Node.js Code of Conduct][], but Working Groups can choose to | ||
| define their own alternative policy. If the Working Group does choose | ||
| it's own Code of Conduct, it must be documented in a `CODE_OF_CONDUCT.md` | ||
| file located in the root of any repository under their stewardship. |
There was a problem hiding this comment.
The CoC can't do less than the Node.js Code of Conduct. Or shouldn't be able to.
i.e This can't be used to bypass one, or if we overlooked that, we need to change things so it can't be.
There was a problem hiding this comment.
How do you define "bypass" though? That's really hard and you're opening up the language in every lower level CoC to be under a strange bikeshed where people re-interpret the language in the base CoC.
There's really only two ways you can phrase this to be enforcable and sustainable:
- Make the base CoC apply to all WGs and TLPs not matter what, allowing only additional terms to be added by independent bodies.
- Allow the CoC to be replaced entirely and if the TSC is upset enough about it they can yank the charter (extreme and doubtful but is quite literally the fallback mechanism we have for all other policies and it seems to be working so far).
|
My apologies in advance, the current actual state of governance is a little behind what is documented. Additionally, we've been talking about a variety of improvements because some of these approaches haven't worked. Unfortunately this means that when you do the good work of documenting things properly you're going to get far more feedback than is fair :/ First off, I don't think we should use the term "bootstrap." We need to move away from that as it has been something of a failure. Most new working groups do not copy/paste the necessary policies. Also, those policies end up in a state of disrepair as improvements are made to the original policies and never make their way into the copies. I would call the directory simply "Policies." In the README and in the policies we should move to a "copy on write" process. Basically, when you spin up a new WG you should just reference the base policies in your README and copy the CONTRIBUTING.md file (this is an unfortunate requirement because the DCO is in there and that file is special and referenced when sending a PR). If a WG or TLP wants to iterate on a policy they should copy it and edit it with PRs, running those changes through their standard governance process. If they haven't copied it they fall under the base policies. This is a far more sustainable practice. It also makes it infinitely easier for us to iterate on base policies as we learn. |
|
In case it wasn't clear in my inline comment, I'm +1 on removing the entire section about meetings. |
|
Ok, pushed a commit that makes several changes:
|
| basic operation of the Working Group. This must be documented in the repository | ||
| and referenced by the `README.md`. | ||
|
|
||
| ## Template: *[insert WG name]* Working Group Governance |
There was a problem hiding this comment.
Just for clarification, this is CONTRIBUTING.md, correct? Would it make sense to explicitly mention this template goes in CONTRIBUTING.md?
There was a problem hiding this comment.
Perhaps but I'm not sure that's a hard requirement.
ghost
mentioned this pull request
|
@nodejs/tsc ... can I ask for another review on this? |
|
|
||
| _Note:_ If you make a significant contribution and are not considered | ||
| for commit-access log an issue or contact a WG member directly and it | ||
| will be brought up in the next WG meeting. |
There was a problem hiding this comment.
This paragraph seems like it could use a bit more polish. Maybe something like this?
Individuals who have made significant contributions and who wish to be considered for commit-access may create an issue or contact a WG member directly. It is not necessary to wait for a WG member to nominate the individual.
|
Nit: Some files are in ALL_CAPS_WITH_UNDERSCORES and some are NotInAllCapsWihtUnderscores. Might be nice to be consistent, allowing for |
|
@Trott .. thank you. I'm about to push a few edits based on the feedback. The difference in the uppercase vs. lowercase file names is to maintain consistency with existing documents, which, unfortunately have been handled inconsistently up to this point :-) |
|
@Trott @sup @nebrius @juliepagano @mikeal @node/tsc ... I'd like to go ahead and get this landed. I'm sure there's more edits that can be made but can I get a couple LGTM's to get it landed? |
|
LGTM! |
|
LGTM too! |
|
Landed in b0533ea |
|
sorry i didn't have the bandwidth to participate on this, but looking at it now and i think it is great :) thanks for this @jasnell |
Separate out the templates for bootstrapping a WG process...
Related to #24 . This is not intended as an alternative to #24 but an adjunct to it. The idea is to separate things out a bit more to make the process easier to maintain and update. We ought to be able to point the nodejs/node WORKING_GROUPS.md file to these templates also as opposed to maintaining to separate set of bootstrap templates in the two separate WORKING_GROUPS.md files.
/cc @mikeal @sup @ashleygwilliams @nodejs/tsc @nodejs/ctc