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.
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
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
On Sat, Dec 4, 2010 at 6:58 PM, Ricky Elrod codeblock@elrod.me wrote:
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.
I don't disagree
I guess I thought it just happened based on this:
http://fedoraproject.org/wiki/Infrastructure/GettingSponsored#Grounds_for_re...
Actually 6 months seems a bit 'long' to me. Perhaps that should change to 1 or 2 months. Trust and competence are important, and aren't necessarily erased by a few months difference, but with the rate of change, things can significantly change in the environment, and that's worth the extra effort of getting 'reacquiainted' before getting access back.
Perhaps we also set a minimum time for people to get sponsored - eg, you get read only access, but that expires in 90 days - and we purge that access. You can reapply of course, but that would keep people from continuing to login perpetually with RO access.
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.
Speaking of AWOL, I was working with Mike on "job descriptions" for the FIGs (for lack of a better term) to help expand the publicly available information about the skills sets that were desired. I started this b/c I had some issues trying to figure out how and where to start contributing. We got about 1/4 of the way done before $DAYJOB ate my time and knocked me off IRC.
I'd be glad to pick these back up and get into the hierarchy discussion as well. You can see the current state if you hit the FIGs page and follow on to any of the FIG names that have links. I'd also like to get some input from FIG sponsors on the content.
https://fedoraproject.org/wiki/Infrastructure/FIGs https://fedoraproject.org/wiki/Infrastructure/FIGs/FIG_Build_job_descrip tion
I have a template for these that I can send round to anyone else who is interested.
-Matt
-------------------------------------------------------------------------- RHEL 6 has arrived. Are you ready? Get information on newly enhanced certifications and training options at http://www.dlt.com/redhat/training.
On Mon, Dec 6, 2010 at 07:26, Matt Micene matt.micene@dlt.com wrote:
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.
Speaking of AWOL, I was working with Mike on "job descriptions" for the FIGs (for lack of a better term) to help expand the publicly available information about the skills sets that were desired. I started this b/c I had some issues trying to figure out how and where to start contributing. We got about 1/4 of the way done before $DAYJOB ate my time and knocked me off IRC.
I'd be glad to pick these back up and get into the hierarchy discussion as well. You can see the current state if you hit the FIGs page and follow on to any of the FIG names that have links. I'd also like to get some input from FIG sponsors on the content.
https://fedoraproject.org/wiki/Infrastructure/FIGs https://fedoraproject.org/wiki/Infrastructure/FIGs/FIG_Build_job_description
I have a template for these that I can send round to anyone else who is interested.
Hi could you send this to Kevin Fenzi. I think he is hitting this partially with ticket groups.
On Mon, 6 Dec 2010 15:24:31 -0700 Stephen John Smoogen smooge@gmail.com wrote:
On Mon, Dec 6, 2010 at 07:26, Matt Micene matt.micene@dlt.com wrote:
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.
Speaking of AWOL, I was working with Mike on "job descriptions" for the FIGs (for lack of a better term) to help expand the publicly available information about the skills sets that were desired. I started this b/c I had some issues trying to figure out how and where to start contributing. We got about 1/4 of the way done before $DAYJOB ate my time and knocked me off IRC.
I'd be glad to pick these back up and get into the hierarchy discussion as well. You can see the current state if you hit the FIGs page and follow on to any of the FIG names that have links. I'd also like to get some input from FIG sponsors on the content.
https://fedoraproject.org/wiki/Infrastructure/FIGs https://fedoraproject.org/wiki/Infrastructure/FIGs/FIG_Build_job_description
I have a template for these that I can send round to anyone else who is interested.
Hi could you send this to Kevin Fenzi. I think he is hitting this partially with ticket groups.
If we could have a mapping of:
componenet in trac == FIG
that might be nice. Then we could have each FIG get CC'ed on tickets in their area. So, one way to join a FIG or see if it's something you want to work on would be to look at all the tickets in that group. It might be easier for people than looking at the big pile of all tickets.
Thoughts?
kevin
Hi could you send this to Kevin Fenzi. I think he is hitting this partially with ticket groups.
If we could have a mapping of:
componenet in trac == FIG
that might be nice. Then we could have each FIG get CC'ed on tickets
in
their area. So, one way to join a FIG or see if it's something you
want
to work on would be to look at all the tickets in that group. It might be easier for people than looking at the big pile of all tickets.
I think this is a good idea. There was some mapping of components to FIGs, but it was somewhat informal and I a few times I had to go back to Mike to clarify. Having a mapping that relates work (tickets) to FIGs would probably help people figure out how to contribute. There looks like some changes to components since last I looked too. Is this the work you've been doing Kevin?
-Matt
-------------------------------------------------------------------------- RHEL 6 has arrived. Are you ready? Get information on newly enhanced certifications and training options at http://www.dlt.com/redhat/training.
On Tue, 7 Dec 2010 09:24:25 -0500 "Matt Micene" matt.micene@dlt.com wrote:
I think this is a good idea. There was some mapping of components to FIGs, but it was somewhat informal and I a few times I had to go back to Mike to clarify. Having a mapping that relates work (tickets) to FIGs would probably help people figure out how to contribute. There looks like some changes to components since last I looked too. Is this the work you've been doing Kevin?
Yes, I added some components for things that had more than a few outstanding tickets. ;)
The only additional one I was thinking of was perhaps a 'Transifex' one, as there are a number of tickets for it. I don't know that we have a FIG/Group to assign them to however. ;(
If you could look at the FIGS and see if there is a mapping now? If not I can adjust or create new components?
kevin
The only additional one I was thinking of was perhaps a 'Transifex' one, as there are a number of tickets for it. I don't know that we
have
a FIG/Group to assign them to however. ;(
If you could look at the FIGS and see if there is a mapping now? If not I can adjust or create new components?
I'm probably not the best source since I started this *because* I was new and trying to feel my way around the FIGs and what work was done where but.... I believe that Transifex is handled within the sysadmin-web FIG. Maybe someone from sysadmin-web can confirm or deny?
This would probably be where a true component level separation falls down against the FIGs. I don't know enough about Trac to know if you can create ticket user groups against the FIGs and assign components that reflect use/technology to those groups.
-Matt
-------------------------------------------------------------------------- RHEL 6 has arrived. Are you ready? Get information on newly enhanced certifications and training options at http://www.dlt.com/redhat/training.
2010/12/8 Matt Micene matt.micene@dlt.com:
The only additional one I was thinking of was perhaps a 'Transifex' one, as there are a number of tickets for it. I don't know that we
have
a FIG/Group to assign them to however. ;(
If you could look at the FIGS and see if there is a mapping now? If not I can adjust or create new components?
I'm probably not the best source since I started this *because* I was new and trying to feel my way around the FIGs and what work was done where but.... I believe that Transifex is handled within the sysadmin-web FIG. Maybe someone from sysadmin-web can confirm or deny?
Yes, you're right, it's sysadmin-web. I'm new in fedora-admin and I'm working on ticket 2389, about Transifex update.
I have no problem to take care of Transifex once I get it updated.
I'm currently stuck with the transifex package requirement of intltool 0.37.1 or above. CentOS 5.5 base repo has intltool 0.35.0 so I guess it would be faster for Fedora to push an update to Fedora EPEL 5 updates-testing repo. I asked Matthias Lasen (mclasen), the intltool package maintainer, about the possibility to push an update to Fedora EPEL 5. I'm still waiting for an answer.
kind regards
Domingo Becker
On Wed, 8 Dec 2010 18:42:02 -0300 Domingo Becker domingobecker@gmail.com wrote:
Yes, you're right, it's sysadmin-web. I'm new in fedora-admin and I'm working on ticket 2389, about Transifex update.
I have no problem to take care of Transifex once I get it updated.
Cool. There are several other tickets related to it...
I'm currently stuck with the transifex package requirement of intltool 0.37.1 or above. CentOS 5.5 base repo has intltool 0.35.0 so I guess it would be faster for Fedora to push an update to Fedora EPEL 5 updates-testing repo.
Not possible I'm afraid.
EPEL never ships anything thats part of the base OS.
I asked Matthias Lasen (mclasen), the intltool package maintainer, about the possibility to push an update to Fedora EPEL 5. I'm still waiting for an answer.
He's likely not going to be able to help. You would need to get the RHEL maintainer (whoever that is) to push such an update. I suspect they would have very strong resistance to doing so in a stable release. ;(
Perhaps it would be better to target RHEL6?
kind regards
Domingo Becker
kevin
On Wed, 8 Dec 2010 14:02:47 -0500 "Matt Micene" matt.micene@dlt.com wrote:
I'm probably not the best source since I started this *because* I was new and trying to feel my way around the FIGs and what work was done where but.... I believe that Transifex is handled within the sysadmin-web FIG. Maybe someone from sysadmin-web can confirm or deny?
Yeah. Having it's own componet might make it easier to see it's tickets.
This would probably be where a true component level separation falls down against the FIGs. I don't know enough about Trac to know if you can create ticket user groups against the FIGs and assign components that reflect use/technology to those groups.
Yeah, basically you can make any number of components you want, and set some people or group to get CC'ed on new tickets filed on that component.
kevin
Yeah. Having it's own componet might make it easier to see it's tickets.
Yeah, basically you can make any number of components you want, and
set
some people or group to get CC'ed on new tickets filed on that component.
Then it makes sense (to me) to make the components reflect what people would report the issues against and use the groups to map the FIG members and handle the notifications and permissions.
Can Trac talk to FAS to get the group membership info?
-Matt
-------------------------------------------------------------------------- RHEL 6 has arrived. Are you ready? Get information on newly enhanced certifications and training options at http://www.dlt.com/redhat/training.
On Thu, 9 Dec 2010 09:54:53 -0500 "Matt Micene" matt.micene@dlt.com wrote:
Then it makes sense (to me) to make the components reflect what people would report the issues against and use the groups to map the FIG members and handle the notifications and permissions.
Yeah, seems reasonable to me.
Can Trac talk to FAS to get the group membership info?
You can set up 'Owners' for each component. Those Owners could be a fas group, a specific person or a list.
Here's the list we have currently:
Buildsys ausil Cumulus (Cloud) sysadmin-cloud-members Development toshio Elections elections-members FedoraInsight cmsadmin-members FedoraPeople sysadmin-tools-members,skvidal FedoraTalk sysadmin-tools-members General sysadmin-members Hosted Projects sysadmin-hosted-members@fedoraproject.org Mailing Lists sysadmin-hosted-members,sysadmin-tools-members Mirrors mdomsch,sysadmin-tools-members Monitoring sysadmin-noc-members SCM (Source Code Management) cvsadmin-members,sysadmin-cvs-members Security lmacken Systems mmcgrath Web Content webmaster
Happy to adjust/add/whatever these.
kevin
On Fri, Dec 10, 2010 at 12:03, Kevin Fenzi kevin@scrye.com wrote:
On Thu, 9 Dec 2010 09:54:53 -0500 "Matt Micene" matt.micene@dlt.com wrote:
Then it makes sense (to me) to make the components reflect what people would report the issues against and use the groups to map the FIG members and handle the notifications and permissions.
Yeah, seems reasonable to me.
Can Trac talk to FAS to get the group membership info?
You can set up 'Owners' for each component. Those Owners could be a fas group, a specific person or a list.
Here's the list we have currently:
Buildsys ausil
sysadmin-releng-members?
You can set up 'Owners' for each component. Those Owners could be a fas group, a specific person or a list.
Here's the list we have currently:
Buildsys ausilsysadmin-releng-members?
Looks like there are a few individuals or non-obvious alias (like ausil or webmaster) who get pinged on specific components, should we have a FIG list for every component to alleviate some burdens?
-Matt
-------------------------------------------------------------------------- “From patching to configuration and provisioning, learn how to optimize your system performance with Red Hat Network Satellite: http://www.dlt.com/lifecycle-webcast.%E2%80%9D
On Tue, 21 Dec 2010 11:27:32 -0500 "Matt Micene" matt.micene@dlt.com wrote:
You can set up 'Owners' for each component. Those Owners could be a fas group, a specific person or a list.
Here's the list we have currently:
Buildsys ausilsysadmin-releng-members?
Looks like there are a few individuals or non-obvious alias (like ausil or webmaster) who get pinged on specific components, should we have a FIG list for every component to alleviate some burdens?
Well, not sure it maps entirely one to one. I guess I would say we should ask those people to see if they would prefer it go to an FIG/group and if not, to think about how to grow things so it does. ;)
-Matt
kevin
infrastructure@lists.fedoraproject.org
-
David Nalley -
Domingo Becker -
Kevin Fenzi -
Kevin Fenzi -
Matt Micene -
Ricky Elrod -
Stephen John Smoogen