<div dir="ltr">I'm a big fan of "getting out of the way between people and what they want to do" and our ops resources is precious and should be focused on strategic things as much as possible.<div><br></div><div>IIUC, what you are proposing is very much in line with that. So I think it's great.</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jan 3, 2019 at 5:47 AM Olblak <<a href="mailto:me@olblak.com">me@olblak.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>





<div><div>Hi Everybody,<br></div>
<div><br></div>
<div>First of all I wish you a happy new Year.<br></div>
<div><br></div>
<div>I am looking for feedback for the best way to manage user permission on the Github jenkins-infra organization.<br></div>
<div><br></div>
<div>The current process is "someone" open a jira ticket requesting for specific repository permission like <a href="https://issues.jenkins-ci.org/browse/INFRA-1925" target="_blank">INFRA-1925</a> and then a jenkins-infra admin validate and grant that permission.<br></div>
<div><br></div>
<div>While I think opening a jira ticket is still important for visibility, only few people can grant organization access and so It can take a lot of time between the moment the permission is requested and approved and it's time consuming to verify if a request is legitimate or not.<br></div>
<div><br></div>
<div>So I am wondering the best way to delegate that decision to SIG maintainers without compromising the organization. <br></div>
<div>Therefore I suggest the follow approach:<br></div>
<div><br></div>
<div>One parent team based on the SIG group name with the same maintainer than the sig group defined from <a href="https://jenkins.io/sigs/platform/" target="_blank">jenkins.io/sig</a> and with no repository permission configured at that level is allowed to configured and managed sub teams.<br></div>
<div>And then each child teams is configured with specific members and specific repositories permission.<br></div>
<div>The reason why the parent team shouldn't configure repository access, is because child team inherit parent repository permission.<br></div>
<div><br></div>
<div>An example is <a href="https://github.com/orgs/jenkins-infra/teams/java11-support" target="_blank">java11-support</a> where baptiste and oleg have admin permission on java11-support including child teams. java11-support has two child teams, java11-support-maintainer and java11-support-reviewer, with respectively write and read permission on different repositories. This approach delegates permission management to java11-support maintainers.<br></div>
<div>Remark: A maintainer can only add repository that he has access to the team he managed.<br></div>
<div><br></div>
<div>Another element that regularly come back and doesn't make sense to me is that we have teams which only have read permission in order to make PR reviews but those reviews can't be taken into account when we want to merge Pull request with branch protection enabled, as those reviewers need write permission. <br></div>
<div>So I wonder if we really need those read only teams .<br></div>
<div>More information <a href="https://help.github.com/articles/about-required-reviews-for-pull-requests/" target="_blank">here</a><br></div>
<div><br></div>
<div>Cheers,<br></div>
<div><br></div>
<div><br></div>
<div>---<br></div>
<div>-> gpg --keyserver <a href="http://keys.gnupg.net" target="_blank">keys.gnupg.net</a> --recv-key 52210D3D<br></div>
<div>---<br></div>
</div>

_______________________________________________<br>
Jenkins-infra mailing list<br>
<a href="mailto:Jenkins-infra@lists.jenkins-ci.org" target="_blank">Jenkins-infra@lists.jenkins-ci.org</a><br>
<a href="http://lists.jenkins-ci.org/mailman/listinfo/jenkins-infra" rel="noreferrer" target="_blank">http://lists.jenkins-ci.org/mailman/listinfo/jenkins-infra</a><br>
</blockquote></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Kohsuke Kawaguchi</div></div></div>