You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Github now supports setting parents for teams. This seems like something that might be useful for us, e.g. the @nodejs/lts @nodejs/release WG issues (nodejs/Release#223).
This definitely could be quite useful. Do you happen to know if at-mentioning the parent team notifies the child teams? Are the members of the child teams shown as members of the parent also? (I guess I could go experiment with that myself ;-) ... just wondered if you already knew)
This definitely could be quite useful. Do you happen to know if at-mentioning the parent team notifies the child teams? Are the members of the child teams shown as members of the parent also? (I guess I could go experiment with that myself ;-) ... just wondered if you already knew)
I just heard about it from @gdams , haven't tried it myself either.
Child teams inherit their parent's access permissions, so repository permissions and @mentioning among nested teams work from top to bottom. If your team structure is Employees > Engineering > Application Engineering > Identity, granting Engineering write access to a repository means Application Engineering and Identity also get that access. And if you @mention the Identity Team or any other team at the bottom of the organization hierarchy, they're they only ones who will receive a notification.
Membership inheritance from parent to child teams isn't automatic. If you're a member of Engineering and someone creates a child team called Security, team members of Engineering aren't automatically direct team members of Security. Security and all other teams nested under the Engineering will inherit repository permissions and @mentions but nothing else.
This definitely looks compelling. Will have to experiment with this a bit.
I've gone through and organized a few of the teams into logical groups.
@nodejs/build ... if anyone can verify that changes to the hierarchy has no impact on any external permissions we have configured (e.g. jenkins access), then I can make a few more organizational changes that would definitely clean things up.
To kick off the experiment, I have made the @nodejs/backporting team a child of the @nodejs/lts team. Let's see how that goes.
@jasnell Just so you know, I think that accidentally (?) added me to @nodejs/lts … not that I care much, but it’s something we might want to be aware of.
edit: see @jasnell’s answer below for why it appears that way
@addaleax are you sure? You attended some LTS meetings, you may be there because of that. I can't find the teams to verify, maybe clutzy, maybe becaue I lack perms.
So, from the documentation and what I've been able to gather, making the Backporting team a child of LTS means that any at-mentions for @nodejs/lts will also notify @nodejs/backporting, and the members of the @nodejs/backporting team will be displayed as members of @nodejs/lts. Also, any repo permissions granted to the parent are applied to the child, but not vice-versa. In other words, it is possible to grant repo permissions to a child that are not propagated up to the parent.
Reacted by Anna Henningsen, Gibson Fahnestock and Michael Dawson
I've contacted GitHub support and that seems to be an issue that they are aware and trying to fix it.
In the case you describe you probably can mention @jasnell because he's an admin or a member of the parent team.
The bug can be found if you're using a structure like Team A > Team B > Team C, give permissions only to Team A and then trying to mention a member of the Team B or Team C (This user cannot be member of Team A)
and the members of the @nodejs/backporting team will be displayed as members of @nodejs/lts.
I thought from @jasnell's comment #13675 (comment) that people who were in the child team were automatically in the main team. For example @addaleax doesn't show up in @nodejs/lts, but she does in @nodejs/backporting.
Just a small note: i don't know how the jenkins auth plugin will handle this, but I'm guessing it acts strictly on name - so if we are to rename things make sure we sync this with @nodejs/jenkins-admins.
Activity
jasnell commentedon Jun 14, 2017
This definitely could be quite useful. Do you happen to know if at-mentioning the parent team notifies the child teams? Are the members of the child teams shown as members of the parent also? (I guess I could go experiment with that myself ;-) ... just wondered if you already knew)
gibfahn commentedon Jun 14, 2017
I just heard about it from @gdams , haven't tried it myself either.
jasnell commentedon Jun 14, 2017
From the docs :-)
This definitely looks compelling. Will have to experiment with this a bit.
jasnell commentedon Jun 14, 2017
To kick off the experiment, I have made the @nodejs/backporting team a child of the @nodejs/lts team. Let's see how that goes.
jasnell commentedon Jun 14, 2017
I've gone through and organized a few of the teams into logical groups.
@nodejs/build ... if anyone can verify that changes to the hierarchy has no impact on any external permissions we have configured (e.g. jenkins access), then I can make a few more organizational changes that would definitely clean things up.
addaleax commentedon Jun 15, 2017
@jasnell Just so you know, I think that accidentally (?) added me to @nodejs/lts … not that I care much, but it’s something we might want to be aware of.
edit: see @jasnell’s answer below for why it appears that way
sam-github commentedon Jun 15, 2017
@addaleax are you sure? You attended some LTS meetings, you may be there because of that. I can't find the teams to verify, maybe clutzy, maybe becaue I lack perms.
jasnell commentedon Jun 15, 2017
So, from the documentation and what I've been able to gather, making the Backporting team a child of LTS means that any at-mentions for @nodejs/lts will also notify @nodejs/backporting, and the members of the @nodejs/backporting team will be displayed as members of @nodejs/lts. Also, any repo permissions granted to the parent are applied to the child, but not vice-versa. In other words, it is possible to grant repo permissions to a child that are not propagated up to the parent.
nunorafaelrocha commentedon Jun 26, 2017
Did anyone notice that you can't directly mention a member of a child team?
gibfahn commentedon Jun 26, 2017
I'm not understanding what you mean. You can do @nodejs/lts (parent) and @nodejs/backporting (child), or @mention one of them (e.g. @jasnell).
nunorafaelrocha commentedon Jun 26, 2017
I've contacted GitHub support and that seems to be an issue that they are aware and trying to fix it.
In the case you describe you probably can mention @jasnell because he's an admin or a member of the parent team.
The bug can be found if you're using a structure like Team A > Team B > Team C, give permissions only to Team A and then trying to mention a member of the Team B or Team C (This user cannot be member of Team A)
gibfahn commentedon Jun 26, 2017
I thought from @jasnell's comment #13675 (comment) that people who were in the child team were automatically in the main team. For example @addaleax doesn't show up in @nodejs/lts, but she does in @nodejs/backporting.
jbergstroem commentedon Jun 27, 2017
Just a small note: i don't know how the jenkins auth plugin will handle this, but I'm guessing it acts strictly on name - so if we are to rename things make sure we sync this with @nodejs/jenkins-admins.
gibfahn commentedon Aug 12, 2017
Discussion has run its course, and we're already using subteams in the org, so closing.