Well, as I see it, you should have your different services documented, each service could essentially have different kind of levels of access. Depending on that service.<div><br></div><div>Isnt someone "responsible" for each service, they should be able to specify what different levels they'd like to offer to different people.</div>
<div><br></div><div>- - </div><div><br></div><div>Regarding the point of "verifying" a user, I guess it'd be good to have some sort of "mentorship" or "apprenticeship"-thing where someone will be their contact person in the desired project/group they get involved with. This person is responsible to approve/disapprove the new person. To verify both their knowledge and wether or not they can be "trusted". Not that the information in oVirt perhaps is something secretive but yeah, I think you get it.</div>
<div><br></div><div>- - </div><div><br></div><div>Now, who has root? Well, essentially, this ought to be a very limited set of users. Now, I've got lots of experience from organisations of different sizes. And it truly goes the wrong way as the number of people with root access increases. Mainly because some just arent knowledgeable enough to be entrusted with such an access. They put the systems at risk all the time. Which is bad.</div>
<div><br></div><div>- -</div><div><br></div><div>... Well, these are just my thoughts on the subject. I guess I fall into the category of people that want to be accepted into the "infra team". But still, the above is the basis I'd like to see in any organisation. </div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Dec 17, 2012 at 4:13 PM, Karsten 'quaid' Wade <span dir="ltr"><<a href="mailto:kwade@redhat.com" target="_blank">kwade@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What should our process be for:<br>
<br>
* When a new person is interested in helping on the Infra team?<br>
* When that new person is ready for more more responsibility?<br>
* When that new person is now an experienced person and can be handed<br>
one or more root account accesses?<br>
<br>
Ideally we'll use sudo and groups to segment what people can do, so that<br>
means:<br>
<br>
* What are the logical groups we should make for sudo?<br>
** One for each service we want to split out?<br>
<span class="HOEnZb"><font color="#888888"><br>
- Karsten<br>
--<br>
Karsten 'quaid' Wade, Sr. Analyst - Community Growth<br>
<a href="http://TheOpenSourceWay.org" target="_blank">http://TheOpenSourceWay.org</a> .^\ <a href="http://community.redhat.com" target="_blank">http://community.redhat.com</a><br>
@quaid (<a href="http://identi.ca/twitter/IRC" target="_blank">identi.ca/twitter/IRC</a>) \v' gpg: AD0E0C41<br>
<br>
</font></span><br>_______________________________________________<br>
Infra mailing list<br>
<a href="mailto:Infra@ovirt.org">Infra@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/infra" target="_blank">http://lists.ovirt.org/mailman/listinfo/infra</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>/Alexander Rydekull<br>
</div>