Guide/notes/document sponsorship

Fri May 7 05:07:36 UTC 2010

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 at gmail.com>
> 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