News for hackers. Stuff that matters.
Re:GitHub adds support for nested organization teams by masklinn on Tuesday June 13, 2017 @02:33PM (#14547343)
> 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.

Finally.

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

Ok that was worded weirdly, but it makes sense. I think the wording of "parent" and "child" teams is confusing, "super" and "sub" teams is much clearer, and it makes perfect sense that when you create a subteam it starts empty, the opposite would be completely broken since the entire point of subteams would be to increase access rights.

One thing they did not touch upon though: can you be a member of a team and one of its subteams? (that would be somewhat annoying).

Re:GitHub adds support for nested organization teams by greglindahl on Tuesday June 13, 2017 @03:12PM (#14547680)
That's the usual meaning of parent and child in computer science.
Re:GitHub adds support for nested organization teams by ChristianBundy on Tuesday June 13, 2017 @05:51PM (#14548976)
Correct, but we usually use it to mean categorical inheritance rather than membership inheritance.
Re:GitHub adds support for nested organization teams by farnsworth on Tuesday June 13, 2017 @08:04PM (#14549757)
What's the difference? An object in a category is a member of that category, right?