update charter

[Trott]

Move shared responsibilities with TSC to a special section.

Minor formatting updates.

This will need to be approved by the board. They will need to approve the corresponding CommComm charter changes at the same time.

[Trott]

Corresponding CommComm charter changes: nodejs/community-committee#354

[WaleedAshraf]

I assume GitHub repository hosting is replaced by Management of the nodejs GitHub organization

Right?

[Trott]

Yes. "GitHub repository hosting" is not what TSC was ever responsible for in the first place. It would have been more accurate to say "GitHub repository management" but I think "Management of the nodejs GitHub organization" is a superset of that.

[Trott]

One thing for TSC to consider: Approving apps. TSC has traditionally been more conservative about wanting/approving apps than CommComm. This may no longer be A Thing because of nodejs-private, but maybe it is?

[WaleedAshraf]

nit: Add link to responsibilities on both side.

Replace:
Node.js Community Committee ("CommComm") for"

With

Node.js Community Committee ("CommComm") Charter for:

[mcollina]

I will need to think about this as it might be a bit too broad. I think the TSC should retain full control over processes that are technical in nature (security, releases, etc).

[mhdawson]

@mcollina would Non-technical project governance and process work for you?

[mcollina]

I would prefer a positive definition, but that would work.

[mcollina]

I'm ok with the current wording. In fact, this is already present in the https://github.com/nodejs/community-committee/blob/master/Community-Committee-Charter.md charter. I'm not 100% sure how this could have been in the commcomm charter and here as well at the same time.

I think the commcomm charter would need to be amended about the shared responsibility.

[mhdawson]

I'm not sure the board is signed up for being the tie breaker, but I don't have a better suggestion so I'm ok as long as the board approves.

[Trott]

I agree that it would be nice if there was a non-Board option. On the other hand, this just formalizes what is already the case. If TSC and CommComm disagree, nothing changes. If someone wants to appeal to a higher authority, it's the Board or nothing. So, even if we haven't written it down until now, this accurately describes the situation and doesn't really introduce anything new.

[mcollina]

Does this represent the current, informal, situation? I do not think so. I would prefer to keep the board out of our decision making process.

[Trott]

Does this represent the current, informal, situation? I do not think so.

OK, so in your view, what is the current process should the following situation arise: TSC and CommComm disagree on a policy change being debated in the admin repo. TSC wants one thing, and CommComm wants something else. Both agree that the status quo is unacceptable. An impasse is reached. Neither group will compromise on what they say the new policy must be. What happens now?

I'm of the opinion that such a situation would be escalated to the board. I would hope we never get to such a situation. But should it arise, I'm unaware of any other resolution mechanism.

[mcollina]

TSC and CommComm disagree on a policy change being debated in the admin repo. TSC wants one thing, and CommComm wants something else. Both agree that the status quo is unacceptable. An impasse is reached. Neither group will compromise on what they say the new policy must be. What happens now?

As per the admin repo governance, status quo remains, see https://github.com/nodejs/admin#governance-and-current-members.

I'm -1 on giving any power to the board on our internal governance. The TSC charter was written in this specific way to grant the project the largest autonomy. We should not relinquish that.

cc @rvagg

[mhdawson]

After discussion in the TSC meeting today I agree we can just leave it as the status quo remains if the TSC and CommComm cannot agree. ie there is no resolution mechanism, either we get agreement or there is no policy change.

[mcollina]

Just making my -1 explicit.

[jasnell]

I agree fully with @mcollina.

[Trott]

@mcollina @jasnell I've removed the sentence about escalation to the board. PTAL

[mcollina]

LGTM.

[gibfahn]

I know it was here before, but what exactly does the "additional" bit in "additional collaborators" mean?

[Trott]

I guess Collaborators who are not on the TSC.

[Trott]

This needs board approval before it can land, but ahead of that, it would be great if we can get a lot of TSC approvals so that there's no doubt that this is the form we want to land. @nodejs/tsc

[addaleax]

I’m okay with this but I agree with @mcollina’s concern.

I think there’s a doc somewhere that explains what the TSC is responsible for and what the CommComm is responsible for. Could we add a note to the charter that such a policy, which specifies each committee’s responsibilities, must exist?

[Trott]

I’m okay with this but I agree with @mcollina’s concern.

@addaleax Do you mean the concern about escalating deadlocks to the board or something else?

[addaleax]

@Trott sorry, should have been more specific – I was talking about this comment: #569 (comment)

[Trott]

I think there’s a doc somewhere that explains what the TSC is responsible for and what the CommComm is responsible for.

I would love to add a link to such a document if anyone knows where it is?

[WaleedAshraf]

Not sure if this is the section @addaleax is talking about.
Same as I asked above about adding the link to relevant docs.

Responsibilities of the TSC
Responsibilities of the CommComm

[mhdawson]

LGTM

[Trott]

Not sure if this is the section @addaleax is talking about.
Same as I asked above about adding the link to relevant docs.

Responsibilities of the TSC
Responsibilities of the CommComm

Where would be a relatively seamless place to insert a link to the other group's responsibilities? I'm wondering if the best thing to do is create a "See Also" section at the bottom and place it there. All the inline locations seem to have their own downsides.

[Trott]

Charter changes are a big deal. Any chance a few more @nodejs/tsc folks can chime in?

[Trott]

R=@MylesBorins

[WaleedAshraf]

Not blocking.
"See Also" section sounds good to me. 👍 This change is just to make it more reader-friendly / easy to navigate. And much better if we add this section on both sides.

[thefourtheye]

Nit: This slightly overlaps with the responsibilities of CommComm.

Facilitation with external open source projects, select consortiums and other outside groups

[MylesBorins]

LGTM

[jasnell]

Given that this policy would mean that CommComm members would have the same ownership level over the GitHub organization as the TSC members, I would like to see a more rigorously documented process around How Folks Become a CommComm member and therefore get those ownership privileges. The reason here is because there are definite security ramifications around expanding who has ownership permissions. We need to make sure that the CommComm practices are as rigorously focused security as the TSC processes are.

[MylesBorins]

If anyone has explicit objections to this please make this known and ping me. The next board meeting is next week and this is slated to be on the agenda as there appeared to be consensus on this + the commcomm change

…

On Wed, Aug 29, 2018, 5:41 PM James M Snell ***@***.***> wrote: Given that this policy would mean that CommComm members would have the same ownership level over the GitHub organization as the TSC members, I would like to see a more rigorously documented process around How Folks Become a CommComm member and therefore get those ownership privileges. The reason here is because there are definite security ramifications around expanding who has ownership permissions. We need to make sure that the CommComm practices are as rigorously focused security as the TSC processes are. — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#569 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAecVxZ2rKGU3J1c9n_lRyI5hfI-_Jlrks5uVsRNgaJpZM4VPtRV> .

[Trott]

Given that this policy would mean that CommComm members would have the same ownership level over the GitHub organization as the TSC members, I would like to see a more rigorously documented process around How Folks Become a CommComm member and therefore get those ownership privileges.

@jasnell Would it be correct to interpret your comment as approval pending such documentation?

If the documentation at https://github.com/nodejs/community-committee/blob/9464378167f6c088eedb4c614930629305322157/GOVERNANCE.md does not meet your requirements, can you explain what's missing?

[Trott]

If anyone has explicit objections to this please make this known and ping
me. The next board meeting is next week and this is slated to be on the
agenda as there appeared to be consensus on this + the commcomm change

@MylesBorins I raised in the meeting this week that I would want this to go to the board with unanimous TSC support or else a vote over objections from members who at least had a chance to state their concerns. This contains a large and potentially-irreversible responsibility shift. I support it, but I don't want any TSC member to be surprised by this after-the-fact.

I'll email and otherwise ping people who have not approved this yet.

[rvagg]

I'm already on the record as opposing the TSC ceding responsibility for management of GitHub and matters of its own governance and processes. These are all matters for project contributors / collaborators, and that bubbles up to the TSC, not the CommComm. So -1 from me.

[Fishrock123]

For the purposes of this governance doc, “project” is a little unclear to me.

The project governance & policy item move seems fine to me when referring to the whole of “the node.js project” but if this refers to what is essentially an individual technical (sub-?)project, I believe we are (and should be) the next in the decision hierarchy.

Similarly, I think we should disambiguate that we are solely responsible for TSC governance and policy, and I expect the CommComm to be the same.

[Fishrock123]

Blocking in particular on that last point I mentioned. I think that needs adjustment although I would like us to clarify the other point.

(hopefully I’m making sense, it’s pretty early in the morning)

[Trott]

Removing tsc-agenda label and adding stalled. This isn't going to happen unless someone else champions it, which I would welcome.

Issues at this point, from least serious to most serious:

• @Fishrock123 left some concerns that seem reasonable and addressable. Make some stuff that's implied explicit. Should be pretty straightforward.

• @jasnell indicates that his approval is pending better (more complete? stricter?) explicit requirements from CommComm about requirements for membership on CommComm. This could be (but obviously doesn't have to be) a problematic rabbit-hole. TSC's documented requirements aren't significantly more explicit than CommComm's (and may in fact be less so). So it's unclear (to me, at least) what the sought-after degree of explicitness is sought because there's no model. Others have seconded @jasnell's requirement, so even if CommComm adopts something that he approves, there's no guarantee it will meet the requirements of others. It might all be quite simple. It has the potential to consume time and never achieve resolution. I don't think @jasnell's concerns are unreasonable. I'm just not sure how much is involved in resolving that issue.

• @rvagg objects to the GitHub org ownership sharing. This is the key change here. So getting this through to the board will likely require a TSC vote. (I'm assuming that @rvagg's concerns are not widely shared on the TSC now that he has articulated them. If that assumption is wrong, this proposal may be a non-starter, of course.)

[ChALkeR]

@Trott it doesn't look to me that @rvagg's argument could be reduced to just GitHub org ownership. It stated:

responsibility for management of GitHub and matters of its own governance and processes

---

This message is neither an agreement nor disagreement to that argument, just trying to keep track of things.

[Trott]

@Trott it doesn't look to me that @rvagg's argument could be reduced to just GitHub org ownership.

@ChALkeR Yes, that's true. I intentionally reduced it to GitHub ownership because that's the key practical change here, at least in my opinion. The matters-of-governance-and-process would (hopefully) be addressed (or at least mitigated?) by addressing @Fishrock123's comments.

[Trott]

Because I don't see a way to unanimity on this, I'm going to close it. If someone wants to pick it up to work on and/or bring it to a vote rather than let it drop due to a minority of voices objecting, feel free to re-open, comment, etc.