Guide/notes/document sponsorship

[Nick Bebout]

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


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