On Fri, 2010-05-07 at 00:08 -0400, Nick Bebout wrote: > These are the possible ideas I've heard so far: > > 1. Separate groups for each document as it is now, but give document > owners and other experienced members sponsor status (this can be > facilitated by making a docssponsors group which will auto-grant sponsor > status in all the individual groups. We could make a docscommitter group > too that auto-grants user status in all the individual groups. (This idea > would preserve the possibility to give commit access to just one group if > for some reason this was wanted.) > > 2. Use "docs" as the commit group for all of our documents. > > 3. Use "docs" as a tracking group for all docs project members, grant > "gitdocs" to give commit access to all documents when the member gets a > little experience. (Eliminate the separate groups for each document.) > > 4. Change nothing, have separate groups for all documents, have to track > down separate people to get approved for each document's commit group. > > Can we get some kind of informal poll going? Could everyone please email > the list with what they prefer? I think I included all of the ideas, > although if you have an idea that's not on the list, feel free to suggest > it too. > > My vote would be either 1 or 3. > > Nick > I vote for item 1, it seems like it would provide for more flexibility. > > On Thu, 06 May 2010 20:03:26 -0700, Ian MacGregor <ardchoille42@xxxxxxxxx> > wrote: > > On Thu, 2010-05-06 at 21:28 -0400, Ben Cotton wrote: > >> I'm a bit mixed on the issue. On the one hand, I'm don't want to lose > >> the member -> committer -> publisher progression that jjmcd mentioned. > >> I definitely don't think that we should hand new members commit > >> access everywhere right off. This is both for the sanity of the > >> documents and the sanity of the new members. I see no reason that new > >> members can't just upload patches to new or existing bugs until they > >> get more comfortable. After some vague and poorly-defined period or > >> level of confidence/competence, then we can move from member to > >> committer. > >> > >> Now having said that, I think it makes sense for committers to have > >> commit access to all the docs. By the time someone is ready to make > >> serious contributions to multiple documents, they've probably been > >> around for a bit and it becomes less of a hassle to just have a single > >> group. I don't think any of the doc owners are so territorial that > >> they would object to having extra help. > >> > >> I guess the TL;DR is that a single group is a good idea, provided it > >> is paired with some kind of seasoning process. > >> > >> This brings up a somewhat-related point that we can move into another > >> thread if it makes more sense, but one thing that would tie in with > >> this is more guidance for new members. I've been in the group for > >> nearly a year now, and everyone has been very helpful, but I think the > >> following two things would really help improve the new member > >> experience: > >> > >> 1. assigned mentoring for new members. If there was a pool of > >> experienced hands who were willing to serve as members, then as each > >> new member joined, they'd have someone who was their point of contact > >> for learning their way around FAS, git, Publican, etc. Like in > >> Euchre, it's often to learn from one person than several. > > > > I agree. > >> > >> 2. a regular start-to-finish guide class. I know I've seen the > >> write-ups for the guide process go by at least once, but I think it > >> would be helpful to have an IRC class once every release or two where > >> we take a dummy guide, branch it for the new release, update the > >> content, prepare for translation, etc. This would also be a good > >> refresher for the members who have forgotten some of the steps or > >> haven't done certain parts before. > > > > This, in my opinion, an excellent idea. I have had the experience, not > > in Fedora, of becoming a member of a team, asking how to perform a > > certain job, being told to "look it up" or RTFM and then completely > > losing interest and end up leaving the team. It's not only vital to > > recruit new members, but to train and nurture them as well, lest they > > "fall through the cracks" and become disinterested. > > > > It would also benefit everyone, in my opinion, to have "hello world" > > type of project for folks to work on and have their work inspected. > > > >> I realize this is easier said than done, we all have other > >> responsibilities to take care of and Fedora doesn't exactly pay us all > >> that well, but as time permits I think this would improve the Docs > >> experience for our members, and likely the quality of the > >> documentation we produce for the community. > > > > It might also help attract new members, as well as re-kindle old members > > who have left or become disinterested, and thereby boost our numbers. > > > >> I also realize that my > >> last sentence was pretty long and that's usually a sign that it's time > >> for me to shut up, so I will. :-) > >> > >> > >> BC > >> > >> -- > >> Ben Cotton > > > > > > -- > > Ian MacGregor > > http://sites.google.com/site/ardchoille42 -- docs mailing list docs@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/docs
