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
