doc: update the repository management policy

[joyeecheung]

Refs: #257 (comment)

cc @Trott

[evanlucas]

I had always thought that any member could create a repository... is that not the case?

[joyeecheung]

@evanlucas I believe so, just trying to document the process because we generally want people to open an issue before performing the actual action.

[joyeecheung]

Also, I am trying to document the whole process in nodejs/admin#68

[Trott]

While we're making this change, I'd opt to remove simple majority of each group and replace it with language that respects the decision making process of each group. For example, in the TSC, we do not use simple majority. We use absolute majority (discounting abstentions from the final total). Using simple majority here puts this document into conflict with TSC governance docs.

Maybe instead of "A simple majority of each group rejecting the request is required to block the request", it can be "Both the TSC and CommComm must reject the request for it to be blocked."

Also, should we consider blocking if either TSC or CommComm rejects? That's the way it is now and I think I kind of prefer it that way. Making things a little easier to block means you avoid hypothetical situations like this:

• Someone proposes creating nodejs/foo.
• TSC supports creating repo nodejs/foo and CommComm opposes it. It gets created.
• Someone else proposes deleting nodejs/foo
• TSC opposed deleting the repo and CommComm supports it. It gets deleted.
• Go to first bullet point. Repeat forever.

If only one or the other entity is enough to block, then things stay with whatever the status quo is and there's no endless add/delete/add/delete cycle. Admittedly, it's a hypothetical situation that may never occur, but perhaps a worthwhile thought experiment on the importance of deferring to the status quo when there is conflict?

[gibfahn]

Also, should we consider blocking if either TSC or CommComm rejects?

+1

[Trott]

LGTM as is, and LEBTM ("looks even better to me") if it gets the changes I suggest. :-D

Thanks for doing this!

[gibfahn]

LGTM with @Trott 's suggestions

[joyeecheung]

Updated with @Trott 's suggestion. Good thought experiment :D

[joyeecheung]

Will land this tomorrow if there were not objections.

[gibfahn]

I think we should consider @Trott 's second suggestion as well (#495 (comment)):

Also, should we consider blocking if either TSC or CommComm rejects? That's the way it is now and I think I kind of prefer it that way. Making things a little easier to block means you avoid hypothetical situations like this:

• Someone proposes creating nodejs/foo.
• TSC supports creating repo nodejs/foo and CommComm opposes it. It gets created.
• Someone else proposes deleting nodejs/foo
• TSC opposed deleting the repo and CommComm supports it. It gets deleted.
• Go to first bullet point. Repeat forever.

If only one or the other entity is enough to block, then things stay with whatever the status quo is and there's no endless add/delete/add/delete cycle. Admittedly, it's a hypothetical situation that may never occur, but perhaps a worthwhile thought experiment on the importance of deferring to the status quo when there is conflict?

[Trott]

Yes, I'd prefer that this sentence...:

Both the TSC and CommComm must reject the request for it to be blocked.

...be changed to this:

If either the TSC or CommComm rejects the request, then the request is denied.

[richardlau]

The policy should really be moved over to https://github.com/nodejs/admin. We could then just have the document in this repo be a link.

[joyeecheung]

@Trott @gibfahn Updated, PTAL.

@richardlau Yeah...I'll do that after this document is updated.

[Trott]

Still LGTM!