I kind of agree with your levels of trust there, but one thing I notice (that Mike/mmcgrath has pointed out before) is that we get a lot of people who show interest, get access to some subset of systems (like -noc, or -test), and then never use it, and just fade out. Or they send out their introduction email, but never join on IRC and never actually get involved.
I realize -test is kind of more public than the rest, but I think we should occasionally go through -test and -noc and see who all has faded out/not used their access. I'd rather people come back in a month asking to be re-sponsored into a group than have access to things just hanging there, and never be used. The more access, the more entryways into the servers, and the more security risk.
One other thing, I wouldn't put -hosted in the same group as -noc and -test. -hosted has access to all of fedorahosted.org which hosts quite a lot of projects and gets quite a lot of hits.
Anyway, those are just my thoughts on moving forward. I really like how open we are to people helping out, and joining the team, I just wish there was a way to filter those who are interested/will stick around against those who will fade away in two weeks.
- Ricky Elrod
On Sat, Dec 4, 2010 at 6:36 PM, David Nalley david@gnsa.us wrote:
On Fri, Dec 3, 2010 at 11:36 PM, Stephen John Smoogen smooge@gmail.com wrote:
Ok I am not doing a good job of greeting new people and helping to get them oriented. For the many people on this list I apologize.
My time for getting people into the group has been overloaded and it keeps getting put back. So it is time for a new approach... currently we have a page for getting started, what to expect, and how to get sponsored... but we have not been good about greeting people and finding places where their skills match.
http://fedoraproject.org/wiki/How_to_be_a_successful_contributor http://fedoraproject.org/wiki/Infrastructure/GettingStarted http://fedoraproject.org/wiki/Infrastructure/GettingSponsored
We also need to show the separation between groups, sysadmin, sysadmin-noc, sysadmin-test, sysadmin-main etc. Some groups are going to take a while for someone to get into (sysadmin-releng and sysadmin-main) mainly because it is a matter of trust and work. Other groups are 'easier' to get into but still require trust. Anyway, I would like to get ideas on how e can do this better and move forward.
Well it strikes me that we have a bit of a chicken and egg problem in many ways. We want people to prove themselves, and gain trust in both their intentions and competency before we grant access, and yet at the same time, the core way of getting many things done (puppet) is locked away and requires access.
So, perhaps that means there needs to be a more formal hierarchy, that provides a way to show competency and garner trust. Perhaps newcomers should be required to show up in IRC and watch the flow, and also orient themselves to the ticket queue. Following there selection of a FIG, they attract the attention of a sponsor and get the read-only privileges (similiar to a subset of sysadmin-noc) for that FIG, and start working on tickets. That level of access is given more freely. This culminates in the sponsor seeing their work is good and granting them membership to the FIGs. This effectively creates a senior sysadmin /junior sysadmin relationship (or perhaps making the sponsors effective leads that essentially oversee the work of the people being sponsored until they are sponsored) This is what I have actually seen happening in many cases, but it's not formalized. This does mean that sponsors would likely be doing less real work, and more supervising, which might not appeal to them.
We also probably need to formalize the strata of things, my choice of colors for this bikeshed would be:
The top level groups are: sysadmin-main, sysadmin-dba, sysadmin-releng
The intermediate level: sysadmin-web, sysadmin-cvs, sysadmin-devel, sysadmin-tools, sysadmin-build
The lowest level: sysadmin-hosted, sysadmin-test, sysadmin-noc
The levels I've selected are somewhat arbitrary, but it's my perception, not of the level of work, but rather the level of trust that must be earned before being granted permission to start actively contributing.
For such a system to be effective, though, we also need to be growing the sponsors list. I queried zodbot on the sponsors for everything but the top level. You'll notice there are really only 12 people, most who are sponsors of multiple FIGs - which means that without growing sponsors, we'll likely be in the same place.
18:30 <ke4qqq> .sponsors sysadmin-noc 18:30 <zodbot> Sponsors for sysadmin-noc: @mmcgrath nb smooge @susmit 18:30 <ke4qqq> .sponsors sysadmin-hosted 18:30 <zodbot> Sponsors for sysadmin-hosted: @mmcgrath ricky 18:30 <ke4qqq> .sponsors sysadmin-test 18:30 <zodbot> Sponsors for sysadmin-test: jkeating lmacken mdomsch @mmcgrath nb ricky @skvidal smooge toshio 18:31 <ke4qqq> .sponsors sysadmin-web 18:31 <zodbot> Sponsors for sysadmin-web: jstanley lmacken mdomsch @mmcgrath nb skvidal @smooge toshio 18:31 <ke4qqq> .sponsors sysadmin-tools 18:31 <zodbot> Sponsors for sysadmin-tools: @ausil jstanley @mmcgrath nb ricky 18:31 <ke4qqq> .sponsors sysadmin-build 18:31 <zodbot> Sponsors for sysadmin-build: @ausil 18:31 <ke4qqq> .sponsors sysadmin-devel 18:32 <zodbot> Sponsors for sysadmin-devel: lmacken @mmcgrath ricky toshio 18:32 <ke4qqq> .sponsors sysadmin-cvs 18:32 <zodbot> Sponsors for sysadmin-cvs: @ausil @mmcgrath notting _______________________________________________ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure