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 <[email protected]> wrote: > On Fri, Dec 3, 2010 at 11:36 PM, Stephen John Smoogen <[email protected]> > 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 > [email protected] > https://admin.fedoraproject.org/mailman/listinfo/infrastructure >
_______________________________________________ infrastructure mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/infrastructure
