Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

doc: update the repository management policy #495

Merged
merged 3 commits into from
Feb 24, 2018
Merged
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
34 changes: 20 additions & 14 deletions GitHub-Org-Management-Policy.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ Community Committee (CommComm).

## Node.js Admin Repository

The [Node.js admin repository](https://github.com/nodejs/admin) serves as the
The [Node.js admin repository][nodejs/admin] serves as the
central location for managing Node.js GitHub Organization administrative
activities. Only Node.js GitHub Organization owners, TSC members, and Community
Committee members have write permissions to the Node.js admin repository.
Expand Down Expand Up @@ -43,23 +43,27 @@ members to the organization when requested by a Working Group or team.

## Repositories

Any organization member may request the creation of a new repository within the
Node.js Foundation GitHub Organization by opening an issue in the Node.js admin
repository. Provided there are no objections from any TSC or CommComm members,
such requests are approved automatically after 72 hours. If any objection is
made, the request may be moved to a vote in each of the Technical Steering and
Community Committees. A simple majority of each group *rejecting* the creation
of the repository is required to block creating the repository. Such requests
must be posted as issues in the Node.js admin repository.

Any repository created under the Node.js GitHub Organization is considered to be
a project under the ownership of the Node.js Foundation, and thereby subject
to the Intellectual Property and Governance policies of the Foundation.

No repository may be deleted, transferred into, or transferred out of the
Node.js Foundation GitHub Organization without a simple majority of both the
TSC and CommComm in favor of the action. In certain cases, Node.js Foundation
Board of Directors approval may also be required.
Any organization member may request the management of repositories within the
Node.js Foundation GitHub Organization by opening an issue in the
[Node.js admin repository][nodejs/admin]. The actions requested could be:

- Creating a new repository
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

- Deleting an existing repository
- Archiving an existing repository
- Transferring a repository into or out of the organization

Provided there are no objections from any TSC or CommComm members raised in
the issue, such requests are approved automatically after 72 hours. If any
objection is made, the request may be moved to a vote in each of the
Technical Steering and Community Committees. Both the TSC and CommComm must
reject the request for it to be blocked.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


In certain cases, Node.js Foundation Board of Directors approval may also be
required.

## Removing or Blocking Individuals

Expand All @@ -84,3 +88,5 @@ be approved by the TSC and CommComm and are subject to regular security audits.
Bots that perform actions on behalf of the project (such as moderation or membership
management actions) are required to maintain a log, accessible to all individuals
granted Owner permissions, of all actions taken.

[nodejs/admin]: https://github.com/nodejs/admin