Proposal process for TSC implementing wider-ranging process changes

[zkat]

Aside from its local management and enforcement abilities, this WG may also need to propose wider-ranging changes to the TSC and other Working Groups, related to inclusivity in the community. I would like to have an agenda item where we can talk through and understand what the Node Foundation's established policies are as far as Working groups proposing these, what the scope of them can be, and the specific processes that must be followed in order for this WG to have an effect outside of itself, with the community's consent.

[Fishrock123]

You'll probably want @mikeal for this one.

[mikeal]

Is the question here "what is the process for proposing/implementing things that extend beyond this WG" or is it "what is are the limitations of the TSC can propose/implement" or both?

The answers to all of these are these are quite long so I'd like to know a few more specifics before writing some very long answers.

[zkat]

Maybe talking about the intention behind the question makes more sense: If this WG wants to propose (and help enact) new organization-wide policies, what's available to us from that perspective, and what's the process available for that? We don't need to quite choose what to do right now, as I assume that would rely entirely on what we happen to be looking for in future situations, but I would like to make sure we have some understanding of the abilities and limitations this WG would have and make sure we have that documented in an easy-to-refer-to place.

[jasnell]

The process is straightforward really:

1. All proposed governance or process changes are submitted as Pull Requests.
2. If the proposed changes involve changes to the TSC Charter, TSC assigned responsibilities, TSC membership or overall governance of the Node.js GitHub organization, the PR should be opened in either the main nodejs/node or nodejs/TSC repositories and the @nodejs/tsc should be mentioned. The issue can be labeled tsc-agenda to request that it be put on the agenda for the next TSC meeting.
3. If the proposed changes involve the responsibilities, charter or processes of any individual Working Group, including the CTC (Core Technical Committee), then the PR should be opened in the primary repository for that Working Group and the relevant working group team should be mentioned (e.g. anything affecting the Node.js core would be opened in nodejs/node and @nodejs/ctc would be mentioned; anything affecting the HTTP WG would be opened in nodejs/http and @node/http would be mentioned.
4. Acceptance or Rejection of the Proposal falls under the relevant governance of the Working Group in question. Any proposed changes to the TSC or CTC processes, for instance, fall under the decision making process outlined in the TSC Charter. Proposed changes to specific WG fall under the decision making processes for those individual Working Groups.
5. Bottom line is: the Inclusivity Working Group cannot require any other working group or the organization as a whole to enact any proposed change.

[mikeal]

So, in all of this the most important questions are:

• Where does this responsibility currently fall?
• Where is this responsibility currently chartered?

There's often a disparity between those two things. Individual groups end up having to take on whatever comes their way but if those responsibilities weren't actually in their charter the TSC (or CTC depending on where the group is and what the responsibility is) may decide to delegate that responsibility to a new group or impose a new org or project wide policy regarding it.

This recent bout of moderation is a good example. Individual groups obviously moderate any trolling content or spam but we never specifically chartered them to do so. Once we received enough of this to necessitate a policy it was clear that we needed to retain some moderation rights in the TSC and also enable individual groups to moderate themselves.

However, a big consideration the TSC would have when changing policies that fall on individual groups would be what the people previously doing that work think of the proposed changes and if there is buyin from the contributors effected by a change.

To throw another level of complexity into this, the Foundation Board of Directors also retains certain rights (legal considerations being the primary one) and can impose those org wide or specifically on a project.

In Practice

So, if you want an org-wide policy you would submit that to the TSC repo as a PR. If that dealt with a responsibility not currently in project or working group charters then the TSC could just pass it. If it happens to be the case that the policy alters responsibilities currently held in charters at Top Level Projects or Working Groups the TSC could pass a resolution recommending those groups change their charters. If a group refused the only recourse the TSC has is to revoke the entire charter, effectively destroying that group and returning all responsibilities it had to the TSC.

If there are legal considerations then the board would need to get looped in and could add certain requirements.

[Trott]

@jasnell or @mikeal: Are there decent guidelines around whether to use nodejs/node or nodejs/TSC when opening a PR for a proposed project-wide change to the way things are done? Or is it currently kind of squishy and there's often not a single right answer?

[jasnell]

At this point it's squishy. The key is that the discussion must be public
and visible for the community to see and weigh in on. Obviously we would
need PRs in the TSC repo to add or change anything there (as I did with the
moderation policy) but the discussion can happen in either repository.
On Dec 18, 2015 7:59 PM, "Rich Trott" notifications@github.com wrote:

@jasnell https://github.com/jasnell or @mikeal
https://github.com/mikeal: Are there decent guidelines around whether
to use nodejs/node or nodejs/TSC when opening a PR for a proposed
project-wide change to the way things are done? Or is it currently kind of
squishy and there's often not a single right answer?

—
Reply to this email directly or view it on GitHub
#43 (comment).

[Trott]

This repo is inactive. Closing this. :-(