meta: github organization management policy #219

jasnell · 2017-02-25T18:33:55Z

@nodejs/tsc: This is the beginnings of a work-in-progress github organization management policy. The intent is to outline the governance of user roles within the organization, formalization of repository management, and so forth. There have been a number of issues opened (and as yet unresolved) as to who has organization ownership and there have been some recent discussions around this.

Consider this an incomplete proposal for the time being. Input is requested.

Trott · 2017-02-26T04:02:34Z

Github-Org-Management-Policy.md

+
+Individual users within a GitHub organization may be granted one of three
+distinct roles: Member, Owner, or Billing manager. The permissions granted
+to each role are documented in the GitHub documentated [Permission levels for


Nit: hyphenate as GitHub-documented or (better, in my opinion) just remove that as it's not really relevant: documented at https://help.github.com/articles/permission-levels-for-an-organization/.

agree with removing, this was confusing to read

Trott · 2017-02-26T04:04:40Z

Github-Org-Management-Policy.md

+All voting members of the Node.js TSC shall have Owner permissions within the
+Node.js Foundation GitHub Organization. Additional users may be granted Owner
+permissions at the discretion of the TSC through normal TSC motion and simple
+majority vote.


This is a change from the current situation. Right now, all members of the CTC are Owners. Is this an intentional change? If so, what's the reason for changing things?

Nope, just put something down so it can be discussed. We have never had a formalized policy on this so it's a point we need to decide on.

Is the goal here to document where we're currently at, or where we want to go? I recall chats with various folks about beefing up the bot so that there is less of a need to hand out owner permissions, which I think is a good thing. That said, we're not to that point yet with the bot.

@nebrius ... both :-) The goal is primarily to have a set policy in place. Part of that may be establishing a guideline where one does not currently exist, or improving on existing practice to make it more robust.

kk. Down the road, I think it would be good to sort of create our own roles that correspond to access levels within the bot, and then start getting really stringent on who we give ownership rights too (like, not even TSC by default)...but we're not ready for that yet, so it's probably premature to bake that language in now, given that we want to do both.

All CTC members are not Org owners at this time. Some are but most were added before the TSC/CTC split.

What exactly do we want people to have access to that they only have if they are org owners?

What worries me about these 1-to-1 mappings are that they end up increasing the barrier to adding people to these groups and load them up with concerns unrelated to why they may be wanted on the TSC/CTC.

All CTC members are not Org owners at this time.

Current Org owners are all 19 members of the CTC + @mikeal. https://github.com/orgs/nodejs/people?utf8=%E2%9C%93&query=role%3Aowner

I'd like to also mention the CommComm here again. As a group with equal organizational standing under the board, ownership should not be exclusive to TSC and CTC members.

Judging from nodejs/CTC#97, it seems to make sense to have CTC members as org owners; and reading through our moderation policy, it seems like TSC members should be owners too, since they are the ones that are allowed to take github org-wide actions (“Only a TSC member may Remove or Ban an individual from the Node.js GitHub Organization”).

I’m not sure how that works for the CommComm anyway… it would currently fall under TSC moderation, right? That doesn’t seem intended.

Well, the moderation policy and other bits existed before the CommComm did so it was impossible to take those into consideration really. The intent prior to the formation of the CommComm was for the Github organization to be directed operationally by the TSC in nearly every aspect. This notion that it would be co-managed by both is new and is not something that I think has been fully digested. We need to take some time to understand what exactly it means and what the ramifications are. I'm sure there are also concerns. For instance, what happens if the CommComm adopts a different moderation policy than the TSC, which one applies in any given instance if the GitHub organization is being managed by both? It can be a tricky exercise.

One suggestion that has been made in a couple of conversations I've had is that it may be easiest for the Community Committee to actually maintain it's own separate GitHub organization, much the same way that the Express project and libuv maintain their own GitHub organizations. There's absolutely nothing that requires the CommComm to use the existing github.com/nodejs organization. It may be the easiest and least controversial approach to take.

Trott · 2017-02-26T04:06:08Z

Github-Org-Management-Policy.md

+### Members
+
+GitHub users may be granted Member status in the Node.js Foundation GitHub
+Organization by any Owner.


This makes it sound like Owners can add Members at their whim. I'd prefer there be criteria, especially if we're going to continue the practice of providing all Members with access to the moderation repo.

Ok. What criteria?

Right now, as far as I know, people are added as members when they need to be added to a GitHub team within the organization.

For the collaborators team, that happens when they are being onboarded as a Collaborator.

For teams that correspond to working groups, that happens when they've been accepted as members of the working group.

For teams that correspond to localization groups, that happens basically when they ask to join. "Hey, you want to join the Freedonian Localization team? DONE!" (Aside: How active are the localization groups? I don't get the impression that they're very active, but maybe some of them are and it's just not visible to me?)

Need to see if we can formalize this into specific policy language. Perhaps...

GitHub users may be granted Member status in the Node.js Foundation GitHub Organization by any Owner when: * The user is being onboarded as a Collaborator in any Node.js Foundation repository * The user is accepted as a member of any Node.js Working Group or team.

Mostly 👍 on that. Just a nit on the first bullet point: The Collaborator role is specific to the main repo as far as I know, so we can just specify that repo.

The second bullet point seems to accurately reflect current practice as best as I can tell.

I agree that the second bullet point is what happens. It's quite informal in respect to how people are added to some teams so we might say:

The user is accepted as a member of any Node.js Working group or added to any of our github teams.

First of all, all of the comments are out of line with the existing processes.

Second, we allow individual WGs to define their own criteria and process for adding members (which in-turn become org members). What we should not do is define a process here that restricts their ability to continue to define and add members at their own discretion.

If the document is to remain purely administrative it would say something along the lines of "GitHub users are added to the org when they are added to a Working Group. Org Owners should add new members to orgs/teams when requested by a WG."

Trott · 2017-02-26T04:08:33Z

Github-Org-Management-Policy.md

+## Repositories
+
+Any organization member may create new repositories within the Node.js
+Foundation GitHub Organization. Any such repository is considered to be a


Nit: remove considered to be. Either it is actually under the ownership of the Node.js Foundation or it is not.

bnoordhuis · 2017-02-27T12:58:57Z

Github-Org-Management-Policy.md

+
+All Billing managers for the Node.js Foundation GitHub Organization shall
+be determined by the Node.js Foundation Board of Directors with notification
+given to the TSC.


Billing manager == someone who pays the bills?

Yes, this is a role specifically defined by GitHub. The Node.js Foundation org account currently does not have anyone assigned to this role.

Our org is free, comp'd because we are a non-profit (and because we sort of helped out GitHub in beta testing their new orgs a year or so back).

This email address may still be used if you're trying to recover an org someone has taken over but that may be an outdated notion, possibly before the new orgs system, because any Owner can swap out that value now so it wouldn't make a very good recovery attribute.

nebrius · 2017-02-27T18:33:37Z

Github-Org-Management-Policy.md

+Foundation GitHub Organization. Any such repository 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 under
+the operational direction of the TSC.


I read this as all repos are automatically under the TSC, however in practice we have some repos that are not under the TSC (community, board, etc). How does this play in to the scope of the TSC? What if one of these new repos doesn't fit into that scope?

I wonder if it would make more sense to have them default to falling under the board, and then officially brought under the TSC via some sort of explicit process (vote in a meeting?) so that we can vet them for scope.

@williamkapke I'm especially curious to hear your thoughts on this.

I see no conflict here with regards to those. They are essentially just spaces carved out to help with general operation of Foundation initiatives. The TSC essentially delegates responsibility for those repositories to the Foundation. If the Foundation needs operational oversight of those (for instance, if the Foundation needs to designate someone with owner permissions in the Org specifically for those repositories), then a simple request to the TSC is made to add that owner.

The goal here should be to:

Reduce barriers to spinning off existing work into a sub-project.

Reduce barriers to spinning up new organizational efforts (non-code repos).

But also restrict new out-of-scope code projects from being taken on within the org and verify they follow the right legal process when they do.

It's hard to do all of these simultaneously.

nebrius · 2017-02-27T18:35:34Z

Github-Org-Management-Policy.md

+Organization without standard TSC motion and simple majority vote. In certain
+cases, Node.js Foundation Board of Director approval may also be required.
+
+All repositories must have a README that clearly identifies the purpose of the


Maybe link here to https://github.com/nodejs/TSC/blob/master/WORKING_GROUPS.md and add a blurb about starting a WG?

Would be great if we could get some guidelines written up and what every README should include so people aren't just trying to figure this out as they go.

nit: Board of Directors*

mhdawson · 2017-02-27T22:29:31Z

Github-Org-Management-Policy.md

+### Members
+
+GitHub users may be granted Member status in the Node.js Foundation GitHub
+Organization by any Owner.


I agree that the second bullet point is what happens. It's quite informal in respect to how people are added to some teams so we might say:

The user is accepted as a member of any Node.js Working group or added to any of our github teams.

mhdawson · 2017-02-27T22:31:46Z

Github-Org-Management-Policy.md

+the operational direction of the TSC.
+
+No repository may be transfered into the Node.js Foundation GitHub Organization
+without standard TSC motion and simple majority vote.


I think we had agreed that there would be some level of board consultation when transferring in, with at least a FYI for smaller components/projects

I think where we landed on that was:

Anything outside the new "TSC Scope" would be reviewed by the board prior to being moved in.

Anything within the "TSC Scope" can happen without a board approval but the board should still be notified.

mhdawson · 2017-02-27T22:33:52Z

Github-Org-Management-Policy.md

+All repositories must have a README that clearly identifies the purpose of the
+repository, and governance documentation that details how the repository is
+managed.
+


I think we should also be explicit here that it needs to have a license covering the content in the repo and that the license should be in the 'Ok' list unless there is approval from the TSC prior to the repo being created/pulled in.

@mhdawson Many repos have no content and are only used for their Issue tracker. If a repo has code in it we definitely need a license but also need a bunch of other stuff (DCO, Governance, etc).

mhdawson · 2017-02-27T22:37:31Z

Github-Org-Management-Policy.md

+All voting members of the Node.js TSC shall have Owner permissions within the
+Node.js Foundation GitHub Organization. Additional users may be granted Owner
+permissions at the discretion of the TSC through normal TSC motion and simple
+majority vote.


I'd lean towards leaving it at CTC+TSC members and then narrow down once we have the required automation in place.

mikeal · 2017-02-27T23:36:31Z

I have some high level concerns about this document.

It seems like we're writing a policy that maps governance bodies, which have direct responsibilities to parts of the project, to current GitHub permission architectures.

For instance, "GitHub users may be granted Member status in the Node.js Foundation GitHub Organization by any Owner." That's just an explanation of the current GitHub permission system, not a statement of what our current or intended policy is for adding people to the org. In reality, people are proposed to be added to WGs all the time and, once that WG agrees to add them, all of those people are added to the WG team and the org. Currently, this is a manual process but it could, and definitely should, be automated.

We have two repositories, security and secrets, which we should limit access to as much as possible. The secrets repo in particular should have the bare minimum number of users with access. The more org owners we add the more people have access to that repository.

I don't think we want to be in a situation where adding people to the TSC has a side effect of multiplying attack vectors on the project's infrastructure. I don't think we want to view increasing the membership of the TSC as decreasing the security of the project.

I also don't think that we want to outline how the project should function, in terms of process and governance, and bind it so directly to how GitHub operates. If we can automate or work around GitHubs processes and permission structure we should do just that (and in fact we already do this all the time).

If we take a step back and think about how we ideally want to see the org function I don't think it would look like this document. Instead, it would look like something that isn't immediately achievable with GitHub's permission system and with which we have to implement a few workarounds and automation, but that's not too difficult and in many cases is something we are already doing in practice.

Trott · 2017-04-16T01:42:15Z

Github-Org-Management-Policy.md

+
+## Repositories
+
+Any organization member may create new repositories within the Node.js


This seemingly conflicts with the TSC README which seems to indicate that TSC folks create repositories. Does this really mean that any of the hundreds of people in the nodejs org should feel empowered to create new repositories within the Node.js GitHub org? If not, revise the wording for more clarity on that.

My current thinking is that any collaborator should be able to create a repository so long as there are no objections from CTC or TSC. Essentially, the collaborator who wants to create a repository would open an issue in either nodejs/ctc or nodejs/tsc and ask. If there are no objections after 48 hours, then go forth and create.

Maybe this PR should update the List of TSC Responsibilities section of the main README.md to change this:

Creating new repositories and projects under the nodejs GitHub organization as required

...to something more like:

Reviewing and approving proposed repositories and projects under the nodejs GitHub organization as required

ashleygwilliams

Thanks for kicking this off @jasnell! I made a few remarks. Mostly, I would like to indicate that the CommComm was missing from this. Additionally, I think this should also include (at least brief mention) of the implications that these permissions levels have for moderation.

ashleygwilliams · 2017-04-17T03:13:51Z

Github-Org-Management-Policy.md

+
+The Node.js Foundation Github Organization (https://github.com/nodejs) is
+provided as a development resource by the Node.js Foundation under the
+operational direction of the Node.js Technical Steering Committee (TSC).


This line would suggest that operations are directed exclusively by the TSC, however, since the CommComm is on equal footing under the Board and also uses the GitHub repo, I feel like it should be listed here. I also wonder if that relationship is part of what this document is sussing out, and something we should further discuss!

That is part of it yes. This is intended specifically to begin tracing out those lines and figuring out how things should evolve. This initial take was meant just to give us some wording to kick around as we fill in the details.

ashleygwilliams · 2017-04-17T03:14:29Z

Github-Org-Management-Policy.md

+
+Individual users within a GitHub organization may be granted one of three
+distinct roles: Member, Owner, or Billing manager. The permissions granted
+to each role are documented in the GitHub documentated [Permission levels for


agree with removing, this was confusing to read

ashleygwilliams · 2017-04-17T03:16:14Z

Github-Org-Management-Policy.md

+All voting members of the Node.js TSC shall have Owner permissions within the
+Node.js Foundation GitHub Organization. Additional users may be granted Owner
+permissions at the discretion of the TSC through normal TSC motion and simple
+majority vote.


I'd like to also mention the CommComm here again. As a group with equal organizational standing under the board, ownership should not be exclusive to TSC and CTC members.

ashleygwilliams · 2017-04-17T03:16:49Z

Github-Org-Management-Policy.md

+Organization without standard TSC motion and simple majority vote. In certain
+cases, Node.js Foundation Board of Director approval may also be required.
+
+All repositories must have a README that clearly identifies the purpose of the


nit: Board of Directors*

jasnell · 2017-04-17T14:57:10Z

@nodejs/tsc @nodejs/community-committee ... fairly sizable update on this based on the feedback. Again, this is intended to give language that we can kick around until we get something that works. This captures both existing policy and new policy that needs to be carefully thought through. If there are bits in here that simply do not work, please speak up and say so. It is most helpful if such comments also include suggestions for improvement ;-). Thanks all.

addaleax · 2017-04-17T16:11:31Z

Github-Org-Management-Policy.md

+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, transfered in to, or transfered out of, the


typo: transferred?

nebrius · 2017-04-17T17:00:16Z

Github-Org-Management-Policy.md

+The Node.js Foundation Github Organization (https://github.com/nodejs) is
+provided as a development resource by the Node.js Foundation under the
+joint operational direction of the Node.js Technical Steering Committee (TSC)
+and Node.js Foundation Community Committee (CommComm).


Since we're listing out owners, I believe this should be "Node.js Technical Steering Committee (TSC), Node.js Foundation Community Committee (CommComm), and the Node.js Foundation Board," since there are a few repos (nodejs/board, nodejs/live.nodejs.org, others?) that are directly operated by the board.

nebrius · 2017-04-17T17:04:59Z

Github-Org-Management-Policy.md

+after 72 hours. If any objection is made, the request may be moved to a single
+vote in which a simple majority of both the TSC and CommComm is required to
+approve. Such requests must be posted as issues to either the nodejs/TSC or
+nodejs/community-committee repositories.


Is the idea here that people would request access via the TSC or CommComm based on who is closer to their area? e.g. a CTC or TSC member would request through the TSC, while a CommComm member would request through CommComm? Should the other committee be notified when one committee receives a request? (I can see arguments both ways)

I don't think we should formalize any of this in this doc (I'd prefer to keep it more generic and flexible), I just want to make sure I understand the idea behind it.

If we do this we should likely document the process in a CTC onboarding doc

nebrius · 2017-04-17T17:06:34Z

Github-Org-Management-Policy.md

+organization shall be maintained *unless* the individual is also no longer a
+voting member of either the TSC or Community Committee.
+
+An individuals Owner permissions shall be automatically removed if they are no


nit: need an apostrophe in individual's

nebrius · 2017-04-17T17:09:26Z

Github-Org-Management-Policy.md

+after 72 hours. If any objection is made, the request may be removed to a single
+vote in which a simple majority of both the TSC and CommComm is required to
+approve. Such requests must be posted as issues to either the nodejs/TSC or
+nodejs/community-committee repositories.


When someone makes a request, is the idea that the committee who received the request would become the owner of that repo? I may be overthinking this, but do we need to be concerned with someone requesting a new repo from one committee, getting turned down, and then requesting from the other committee as a way to get around the first?

nebrius · 2017-04-17T17:10:49Z

Github-Org-Management-Policy.md

+All repositories must have a README that clearly identifies the purpose of the
+repository, governance documentation that details how the repository is managed,
+and an indication of whether the repository falls under the operational
+direction of either the TSC or CommComm. 


I believe this should read "TSC, CommComm, or the CTC" since the CTC can have working groups under it.

@nebrius iiuc CTC activities are just delegated from the TSC, from an outside or board view all of that falls under TSC responsibility, so I think the phrasing here is correct as it is

MylesBorins · 2017-04-17T19:57:15Z

Github-Org-Management-Policy.md

+after 72 hours. If any objection is made, the request may be moved to a single
+vote in which a simple majority of both the TSC and CommComm is required to
+approve. Such requests must be posted as issues to either the nodejs/TSC or
+nodejs/community-committee repositories.


If we do this we should likely document the process in a CTC onboarding doc

MylesBorins · 2017-04-17T19:58:43Z

Github-Org-Management-Policy.md

+Upon the completion of the TSC Director, TSC Facilitator, or elected individual
+member representative's terms, their Owner permissions within the GitHub
+organization shall be maintained *unless* the individual is also no longer a
+voting member of either the TSC or Community Committee.


this and the below paragraph seem to contradict each other if an elect individual member is also on CTC

MylesBorins · 2017-04-17T19:59:44Z

Github-Org-Management-Policy.md

+
+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.


Should we specify license expectation here?

MylesBorins · 2017-04-17T20:00:02Z

Github-Org-Management-Policy.md

+after 72 hours. If any objection is made, the request may be removed to a single
+vote in which a simple majority of both the TSC and CommComm is required to
+approve. Such requests must be posted as issues to either the nodejs/TSC or
+nodejs/community-committee repositories.


This should be documented in Collaborators guide

MylesBorins · 2017-04-17T20:00:33Z

Github-Org-Management-Policy.md

+No repository may be deleted, transfered in to, or transfered out of, the
+Node.js Foundation GitHub Organization without a simple majority vote of both
+the TSC and CommComm. In certain cases, Node.js Foundation Board of Directors
+approval may also be required.


should there be a caveat for repo's created not following this process?

Trott · 2017-04-17T20:07:26Z

If/when this lands, it should be communicated out to all collaborators somehow. Most of them don't pay attention to this repo. (I myself unsubscribe from issues in it all the time.)

Sorry if I'm repeating something that's already been brought up. I admit to only skimming the issue at this point.

jasnell · 2017-04-17T20:41:44Z

Both issues should be addressed by this PR and can be closed when this lands.

Refs: #101
Refs: #125

MylesBorins

Lgtm

MylesBorins

Lgtm

jasnell · 2017-08-21T23:19:16Z

@nodejs/tsc ... please review.

mhdawson

LGTM

jasnell · 2017-08-21T23:57:06Z

If there are no TSC objections after 48 hours I will land this.

jasnell · 2017-08-22T23:04:13Z

one final ping to @nodejs/tsc

jasnell · 2017-08-23T14:17:47Z

Ping @nodejs/ctc ... please take a look at this and weigh in. Landing this policy change will mean that the owner permissions for all current github account owners will be modified in accordance with the new policy.

@williamkapke ... I know you previously had done some work on a bot for automating administrative tasks and I know that I had some general concerns around the security of that. I'd like to see if we can revisit that issue. If (a) the bot can be hosted on secured foundation infrastructure and (b) the permissions for the bot can be limited to a specific set of actions such as adding/removing/banning, etc, then I think my concerns around the security can be addressed.

jasnell · 2017-08-23T14:25:46Z

@nodejs/community-committee ... please take a look at this as well. This policy change impacts the Community Committee also by providing a clear guidelines by which CommComm members can become part of the administrative team.

@nodejs/ctc and @nodejs/community-committee ... I'd like everyone to pay particular attention to the part that this policy says that members of either committee who request owner permissions will get those automatically after 72 hours if there are no objections. In other words, if this policy change lands, it will be important for TSC/CommComm members to be actively engaged in reviewing these requests. The CTC/TSC will need to be particularly careful given that owner permissions grant access to the nodejs/node-private repo used to triage security issues.

If anyone has any alternative suggestions on that part, please offer them but please be more specific than, "I don't like this part" because vague feedback does not help me make it better. Thank you.

sam-github · 2017-08-23T17:43:30Z

@mcollina:

I'm only concerned about the security aspects. Maybe (and just maybe), can we move the private repo to another org? It will solve so many issues.

Another way of solving this would be just removing the security repo, and moving to a purpose-built security issue solution, like HackerOne, see commentary here: nodejs/security-wg#38 (comment)

cc: @nodejs/security

jasnell · 2017-08-23T22:21:41Z

@mcollina .. updated

All.. I tweaked this just a bit to add that the Node.js Foundation Executive Director is also granted owner permissions in the organization. This is largely a formality. I also made the auto-acceptance period 7 days instead of 72 hours to give more time for review.

jasnell · 2017-08-29T03:53:31Z

Updated based on feedback received. @nodejs/tsc @nodejs/ctc please take a final look. If there are no objections by Wednesday I will get this landed.

jasnell · 2017-08-30T02:57:38Z

@mhdawson, can I please ask you to take this pr over?

hackygolucky · 2017-08-30T16:18:47Z

@mhdawson This looks like it is ready to merge, and I'm happy to make a plan with you about next steps for this.

hackygolucky · 2017-08-31T05:06:15Z

And I -just- realized that one of those first next steps that I'm sure a lot of folks are waiting on is the Travel Fund!!!! We need to hop on this so people can request.

Trott · 2017-08-31T06:08:14Z

Github-Org-Management-Policy.md

+
+### Owners
+
+The Node.js Foundation Executive Directory, Node.js TSC Director, TSC Chair,


Typo: Directory - Director

Trott · 2017-08-31T06:08:56Z

Github-Org-Management-Policy.md

+### Owners
+
+The Node.js Foundation Executive Directory, Node.js TSC Director, TSC Chair,
+and Community Committee Chair, Node.js Foundation Executive Director, and


Typo: remove first and

Copy/paste error: Remove Node.js Foundation Executive Director as they're already on the list earlier.

mhdawson · 2017-09-06T15:43:40Z

@nodejs/tsc one final call for comments/concerns before we land. (Of course after integrating the outstanding nits)

mhdawson · 2017-09-06T15:45:07Z

@ashleygwilliams can you confirm if your comments have been addressed either with new comments or by clearing your previous request for changes.

ashleygwilliams · 2017-09-06T15:48:40Z

@mhdawson thanks for the ping. updated my review.

jasnell · 2017-09-06T15:50:39Z

@nodejs/tsc this is an significant change to current policy. Please review and weigh in

richardlau · 2017-09-07T07:31:54Z

Github-Org-Management-Policy.md

@@ -0,0 +1,81 @@
+# Node.js GitHub Organization Management Policy
+
+The Node.js Foundation Github Organization (https://github.com/nodejs) is


Nit: GitHub

jasnell · 2017-09-12T10:48:47Z

Ping @nodejs/tsc once again.

thefourtheye · 2017-09-12T15:57:45Z

Github-Org-Management-Policy.md

+
+No repository may be deleted, transferred in to, 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


Even if the repository is managed by only one the parties (TSC or CommComm), both of them have to agree?

thefourtheye · 2017-09-12T15:59:06Z

Github-Org-Management-Policy.md

+To remove any current member from the GitHub organization, an issue must be
+opened in the nodejs/admin repository. If, after 72 hours, there are no
+objections from the other Owners, removal becomes automatic. If there are
+objections, then a simple majority vote of each of the Technical Steering and


If the motion fails in either of the committees then the ban will not established, right?

Also, if there is a tie, (one party agrees and the other one disagrees), what would happen to the ban request?

Correct. A tie (one committee agrees, the other doesn't) would mean that it fails. It must be a simple majority in both.

jasnell · 2017-09-14T14:31:22Z

@nodejs/tsc and @nodejs/community-committee ... there have been no objections raised on this. I'm assuming that means there is consensus. I will merge this a bit later this morning.

jasnell · 2017-09-14T14:37:00Z

Actually... I take that back, there were a few typos I had to fix and one substantive change... when it comes to banning/blocking existing members, objections may be raised by any TSC/CommComm member which would require a vote. Previously it was any owner, but since the owners are now restricted to a smaller group, it makes sense to allow any CommComm/TSC member to object. Given that change, I'll give it until Monday to land.

thefourtheye · 2017-09-15T02:14:47Z

Github-Org-Management-Policy.md

+
+No repository may be deleted, transferred in to, 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


"In certain cases" - Did you have any such cases in mind?

When bringing in a completely new top level project, for instance.

thefourtheye · 2017-09-15T02:16:12Z

Github-Org-Management-Policy.md

+Repositories that are under the operational direction of the Community Committee
+are subject to CommComm oversight.
+
+## Removing or Banning Individuals


I feel like removing and banning are overlapping with @nodejs/moderation team's responsibilities.

No, only org owners can ban. If the moderation team determines that a ban is necessary, they would ask one of the owners to actually do the ban.

Specifically, mod team does not have owner status in the org

Thanks for clarifying @jasnell 👍

jasnell · 2017-09-15T14:08:02Z

Ping @mhdawson and @williamkapke ... I've updated to allow all TSC/CommComm members write access in the nodejs/admin repo.

refack · 2017-09-15T14:48:01Z

Github-Org-Management-Policy.md

+Repositories that are under the operational direction of the Community Committee
+are subject to CommComm oversight.
+
+## Removing or Banning Individuals


Maybe /s/ban/block which is the GitHub terminology (https://help.github.com/articles/blocking-a-user-from-your-organization/).
Else maybe define/referance semantics of ban?

We can hit that in a separate PR.

Fixes: nodejs#101 Fixes: nodejs#125 Fixes: nodejs#269 Fixes: nodejs#285 Fixes: nodejs#289 Fixes: nodejs#295 Fixes: nodejs#328

mhdawson · 2017-09-15T17:26:37Z

@jasnell thanks for updating to reflect access to the admin repo as I think that makes sense.

jasnell · 2017-09-18T22:59:19Z

Landing given the lack of objections.

jasnell · 2017-09-18T22:59:50Z

Ping @hackygolucky ... this has landed!

Trott reviewed Feb 26, 2017

View reviewed changes

bnoordhuis reviewed Feb 27, 2017

View reviewed changes

nebrius reviewed Feb 27, 2017

View reviewed changes

mhdawson reviewed Feb 27, 2017

View reviewed changes

Trott reviewed Apr 16, 2017

View reviewed changes

ashleygwilliams suggested changes Apr 17, 2017

View reviewed changes

jasnell force-pushed the github-org-policy branch from 341894c to 8f1199a Compare April 17, 2017 14:13

addaleax reviewed Apr 17, 2017

View reviewed changes

nebrius reviewed Apr 17, 2017

View reviewed changes

MylesBorins reviewed Apr 17, 2017

View reviewed changes

MylesBorins approved these changes Aug 21, 2017

View reviewed changes

hackygolucky mentioned this pull request Aug 21, 2017

Discussion: CoC Violations & Accountability : Node's future nodejs/community-committee#111

Closed

jasnell force-pushed the github-org-policy branch from 4c1fdd2 to f01bf1e Compare August 21, 2017 23:18

mhdawson approved these changes Aug 21, 2017

View reviewed changes

jasnell mentioned this pull request Aug 22, 2017

Re-merge TSC and CTC #312

Closed

stephenburgess8 mentioned this pull request Aug 22, 2017

meta: merge the TSC and CTC back into a single entity #317

Merged

jasnell mentioned this pull request Aug 29, 2017

Form an Admin team / subcommittee #328

Closed

Trott reviewed Aug 31, 2017

View reviewed changes

ashleygwilliams approved these changes Sep 6, 2017

View reviewed changes

richardlau reviewed Sep 7, 2017

View reviewed changes

ofrobots approved these changes Sep 12, 2017

View reviewed changes

thefourtheye reviewed Sep 12, 2017

View reviewed changes

thefourtheye reviewed Sep 15, 2017

View reviewed changes

refack reviewed Sep 15, 2017

View reviewed changes

meta: github organization management policy

ea7e417

Fixes: nodejs#101 Fixes: nodejs#125 Fixes: nodejs#269 Fixes: nodejs#285 Fixes: nodejs#289 Fixes: nodejs#295 Fixes: nodejs#328

jasnell force-pushed the github-org-policy branch from 06bad58 to ea7e417 Compare September 15, 2017 15:24

mhdawson mentioned this pull request Sep 15, 2017

Update README for new use nodejs/admin#9

Closed

jasnell merged commit 8ff3224 into nodejs:master Sep 18, 2017


		## Repositories

		Any organization member may create new repositories within the Node.js


		### Owners

		The Node.js Foundation Executive Directory, Node.js TSC Director, TSC Chair,

		@@ -0,0 +1,81 @@
		# Node.js GitHub Organization Management Policy

		The Node.js Foundation Github Organization (https://github.com/nodejs) is

meta: github organization management policy #219

meta: github organization management policy #219

Conversation

jasnell commented Feb 25, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mikeal commented Feb 27, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Trott Apr 16, 2017 • edited Loading

Choose a reason for hiding this comment

ashleygwilliams left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jasnell commented Apr 17, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Trott commented Apr 17, 2017

jasnell commented Apr 17, 2017

MylesBorins left a comment

Choose a reason for hiding this comment

MylesBorins left a comment

Choose a reason for hiding this comment

jasnell commented Aug 21, 2017

mhdawson left a comment

Choose a reason for hiding this comment

jasnell commented Aug 21, 2017

jasnell commented Aug 22, 2017

jasnell commented Aug 23, 2017

jasnell commented Aug 23, 2017

sam-github commented Aug 23, 2017 • edited Loading

jasnell commented Aug 23, 2017

Trott Apr 16, 2017 •

edited

Loading

sam-github commented Aug 23, 2017 •

edited

Loading

mhdawson commented Sep 6, 2017 •

edited

Loading