Add CommComm Director to the list of Owners

[dshaw]

The Community Committee now has a Director role. Adding new members, new initiatives and and new working groups require a team member with Owner privileges. Today, the CommComm has a single-point of privilege with the CommComm Chair. This has already proven challenging for CommComm Initiatives. Since we added a new leadership role to the by-laws for the CommComm, assigning that individual, who is elected by the CommComm to represent the CommComm, Owner privileges would help support the growing needs of our top-level committee.

[dshaw]

Since our current CommComm Director is already an owner, this will be a no-op in terms of actions needing to be taken. This PR is for future representatives.

[Trott]

@nodejs/tsc

[Trott]

@nodejs/community-committee

[refack]

Since our current CommComm Director is already an owner, this will be a no-op in terms of actions needing to be taken. This PR is for future representatives.

This might be a technical noop, but more importantly this is an actual change in policy since as mod-team member the owner status is under explicit limitations.

The Community Committee now has a Director role. That role should have Owner rights.

What is the rational? Why not other all Board members? Why haven't the individual member directors been owners until now? Why not the whole of the CommComm?

[gibfahn]

What is the rational? Why not other all Board members? Why haven't the individual member directors been owners until now? Why not the whole of the CommComm?

Has this been discussed anywhere?

[Bamieh]

@gibfahn AFAIK there is no open issue about this specific topic in the commcomm

[Trott]

What is the rational? Why not other all Board members? Why haven't the individual member directors been owners until now? Why not the whole of the CommComm?

Has this been discussed anywhere?

@refack @gibfahn I could be wrong, but I suspect people are reluctant to address this because it is perceived of as a topic that could trigger some potentially-bitter disagreement. However, a straightforward question deserves a straightforward answer, and as I've been messing up plenty in the admin repo lately, I might as well continue my streak.

• The exact rationale may vary, but I'm pretty sure it is typically something along the lines of this: CommComm needs to effectively manage large aspects of the GitHub organization. Restricting their ability to do so to just the Chair is an obstacle to effective and efficient work. The Board member is a trusted and empowered individual, so they are a sensible second person on CommComm to have the Owner role.

• Why not other all Board members?: Because this is about CommComm, not the Board.

• Why not the whole of the CommComm?: I suspect for some who support this, the whole of CommComm would be included ideally. However, this change needs TSC buy-in and it's likely that one or more members of the TSC would object and/or that such a larger granting of the role would stall this proposal much longer, whereas this narrower proposal can likely happen soon and help CommComm out relatively quickly.

IMO (and reasonable people disagree, notably @bnb), the current TSC and CommComm charters are such that the TSC is ultimately responsible for GitHub org management. The language is imprecise, but I do think it's the obvious interpretation, especially given the history. I may ultimately be wrong about that, but that's how I see things based on what I know at the moment. From that perspective, the CommComm role in GitHub org management exists because the TSC has agreed to it (via the document that this PR proposes a modification to). If the charters were being written today together, the Board might make both groups responsible for GitHub management and not just TSC. That's one of the things that nodejs/TSC#569 and nodejs/community-committee#354 attempt to clarify/resolve. TBH, I'm surprised that component of those PRs has not attracted more comment/attention because that was what I expected to be controversial about them.

[dshaw]

@refack This has nothing to do with Board members and Board membership. It is recognizing another individual how has the authority to represent and take responsibility for critical decisions that impact the organization.

[jasnell]

@nodejs/tsc @nodejs/community-committee .. ptal

[jasnell]

As a policy decision, this needs agreement from both TSC and Community Committee

[codeekage]

Is there a reason why CommComm members are restricted to ownership rights like the TSC?

Inasmuch the CommComm carries out administrative task the same access level should be granted, except otherwise where the CommComm is not recognized as being one of the two top-level Committees of the Node.js Org. (IMO).

Correct me if I’m wrong.

[Trott]

Inasmuch the CommComm carries out administrative task the same access level should be granted, except otherwise where the CommComm is not recognized as being one of the two top-level Committees of the Node.js Org. (IMO).

Owner role should not be granted as a signifier of trust or being a top-level committee. Owner role should be granted to people who need it to do work. (I may be misunderstanding here, in which case, apologies in advance!)

I support the change proposed in this pull request because I think it makes sense, in the interest of efficiency and effectiveness, for more than just the CommCom Chair to be able to (for example) add members to translation teams.

[codeekage]

@Trott thank you for clarification.

Will it make sense for WG champions under CommComm, should have rights to be able to add new folks as collaborators other than the process of waiting on Chairs/Directors?

Although, I do understand that this might not be relevant, since the Chair or Director is supposed (not so sure about this) to know about a new collaborator.

[Trott]

Will it make sense for WG champions under CommComm, should have rights to be able to add new folks as collaborators other than the process of waiting on Chairs/Directors?

@codeekage Individuals who manage GitHub teams that correspond to WGs can be given the Maintainer role on the specific GitHub teams. That will allow them to add/remove folks who are already in the org. Adding folks who aren't yet otherwise in the org will still require an Owner to invite them.

[Trott]

This has an objection from a CommComm member and it seems unlikely that more conversation and time will change that. Is this going to be put on the CommComm agenda for a vote? (Or does CommComm have a different process?)

[gibfahn]

@refack @gibfahn I could be wrong, but I suspect people are reluctant to address this because it is perceived of as a topic that could trigger some potentially-bitter disagreement. However, a straightforward question deserves a straightforward answer, and as I've been messing up plenty in the admin repo lately, I might as well continue my streak.

Thanks for the clarification @Trott , I guess my question was really whether this was a question that had already been decided, or something that would need more discussion.

I think it makes sense, in the interest of efficiency and effectiveness, for more than just the CommCom Chair to be able to (for example) add members to translation teams.

So the CommCom director should be able to act as a backup to the CommCom chair? I think that's reasonable.

I'm sorry but this seems like an arbitrary change to me.

@refack I think @Trott's justification makes sense (although without it I agree that the change seems arbitrary). Does that change your opinion?

It would be nice if we had more process around adding owners, like requiring a concrete justification for tasks they would need to carry out, and explanation of why the existing owners were not adequate for those tasks. However as we don't, and given @Trott's justification, I'm +1 on this.

Why not the whole of the CommComm?

Definitely seems like a discussion for a separate issue (I'm surprised there hasn't already been at least one).

[Trott]

I added the cc-agenda label in the hopes that Community Committee can approve this (in which case we can clear the objection from @refack) or else reject it (in which case we can close it).

[refack]

This has an objection from a CommComm member and it seems unlikely that more conversation and time will change that. Is this going to be put on the CommComm agenda for a vote? (Or does CommComm have a different process?)

I don't think that that is necessary.
For the record, IMHO we should have had this discussion before the incumbent was elected, while the role was being codified.

[dshaw]

This issue has only come up recently as we have been expanding the Initiatives and growing the collaborator base. We realized the resolution for all organizational issues were flowing through @bitandbang. That raised some concerns because Tierney already does so much. In the CommComm, we have been reviewing our practices and processes as we grow.

As @Trott has mentioned above, parity with TSC and CommComm member privileges probably makes the most sense.

Today, we need to expanded coverage to support our growing member base.