Join Page Refresh

[Luke Macken]

On Wed, Jul 23, 2008 at 09:13:34AM -0400, Paul W. Frields wrote:
> On Wed, 2008-07-23 at 08:36 +0100, Jonathan Roberts wrote:
> > 2008/7/23 Paul W. Frields <stickster at gmail.com>:
> > > On Tue, 2008-07-22 at 22:41 +0100, Jonathan Roberts wrote:
> > >> Hey all,
> > >>
> > >> I said in last night's meeting that I'd start work on a draft of
> > >> content to go on the join page, to clarify the process and make it
> > >> more useful. This is what I have so far, but is it too wordy? (Lol, of
> > >> course this is entirely text, but is it too long!)
> > > [...snip...]
> > >
> > > What is the purpose of this page?  What should the user be doing on this
> > > page?
> > 
> > To me, the purpose of this page is to explain the process of how one
> > becomes an active Fedora contributor.
> > 
> > As it is now, it provides very little information beyond signing up
> > for an account and a link to a wiki page with very little information
> > about each role and the associated teams. To become an active
> > contributor I think one needs to know at least a little bit more than
> > what's currently there.
> 
> I agree this page is wrong as is.
> 
> I think the right way to do this is to simply direct people to the
> account system first from this page, without any fanfare.  At the
> completion of the process, the user should then have a choice of:
> 
> 1. self-service information, by choosing a role that holds interest and
> landing on a page with actual useful data about what to do next
> 2. full-service information, where the user is presented with some
> selections that present a task list.
> 
> This page fails on #1 because the paths to the self-service data lead
> the user away from the account system, and not just one click either.
> The place the user lands has nothing truly useful, so the user is forced
> to click repeatedly to find other information, making it more unlikely
> to return to where the path started.  The self-service information
> should be stripped from this initial join.fp.o page, and be presented as
> a link following account creation.  No reason the join.fp.o page
> couldn't have a small but obvious link like "Why sign up?" leading to a
> general page like:
> https://fedoraproject.org/wiki/FAQ#For_Fedora_Contributors 
> ...or a better page including text similar to what you laid out earlier.
> 
> You should talk to Luke Macken about #2, because he has some amazing
> ideas about what to do there.

If we want Fedora development to efficiently scale to a large number of new
contributors, we cannot expect someone to always be there to hold peoples hands
and effectively task them with work to do.  Saying "Welcome!  Here is Bugzilla
and a dozen mailing lists" is possibly the best ways to scare someone away, and
yet I see it being done far too often.  The only way that Fedora development
can scale to an infinite number of contributors is if Fedora can properly
delegate its own tasks to its contributors.  Fedora is enduring some
growing-pains at the moment, and I feel that now is the time to take a step
back and take a serious look at what we are doing, how we are doing it, and
how we can improve.

Problems
========
- Our current new contributor process leaves people in the dark.  "Ok, I have a
  Fedora account...what do I do now!?  Meh, I guess I'll just troll mailing
  lists in the mean time..."
- Our current process expects people to keep up with a ridiculous 
  number of high-volume data stream: IRC, Email, commits , wiki changes, etc 
- A serious lack of formal task delegation.
- We lack a cohesive list of high level goals.  The Feature          
  process is the closest thing we have, but there are no clear     
  actionable items associated with any given feature.                
- No clear tasks that new people can easily pickup.  Issues in bugzilla have
  default assignees, which don't encourage people to grab bugs and help out.
- Our 1-to-1/1-to-many package maintainership model does not scale.
- There is no easy way to find someone to help you if you have a     
  problem or a question.  This leads to the current state of         
  fedora-devel-list, with an extremely poor signal:noise ratio.
- "Special Interest Groups" do not properly accommodate or even encourage
  new members, nor do they have clear goals, tasks, accountability,
  documentation, or communication channels.  Most are inactive and stale.
- Not only is bugzilla an awful workflow tool, but with the amazing
  growth of fedorahosted, our tasks are spread out even more.
- Our communication channels are lacking
    IRC.  No easy way to reference or search conversations.
    Mailing lists.  Overhead of joining and setting up filters.  Not easy to
    reference or search conversations.  Threads get stale and die very quickly.
    An abundance of trolls and ad hominem.  Rational discourse is sparse.
    It's obvious that people do not have anything better to do -- so lets
    change that :)
- Lack of meritocracy.  If we don't effectively track what is getting done and
  who is doing it, it is extremely difficult to give credit where credit is due.
                                                                     
Solutions                                                            
=========                                                            
- Fedora needs to know the skills of its contributors.
  We could add these details to FAS, and make it a part of the new contributor
  process.   I would also love to see this checkbox:
    [X] I am willing to help people with these subjects (Instant mentorship)
- Packages/projects/tasks should know what technology it is comprised of.
  This way, we can easily funnel people with various skills to the places
  that need them
- A list of high level goals that we wish to accomplish, with a cohesive list
  of actionable items associated with each goal, organized by the skills
  required to complete it.
- Each action item needs to have associated with it:                           
  * The skills required to complete it                           
  * Difficulty level / estimated time to complete
  * A higher level goal associated with this task
  * A team that is accountable for this task
  * A team/person that can help with questions regarding this task
  * A person/group that is working on it                 
      - if no one has chosen to work on it, we need to make it   
        dead simple for anyone to say "Hey, I'll give this a shot" 
      - This system needs to automatically touch base with       
        people after a given amount of time.  "Hi, I noticed that  
        you've signed up to work on $TASK, but you have not made a 
        status update in $TIME.                                    
            Click here if you have completed this task.
            Click here to make a status update.                    
            Click here to get help from a mentor                   
            Click here to give the task back to the community"
- Allow for teams to easily be created and destroyed.  Make it simple to create
  sub-communities.
- Allow people to easily join or leave a team.                    
- Funnel bugs/tasks/communication to the appropriate team
- Make it trivial to grab tasks
- Make it trivial to communicate
- Each team should have a Standard Operating Procedure.  "Welcome to the $TEAM,
  here is a handbook containing everything you need to know to start becoming
  a useful contributor"
- Revamp our current maintainership model.  We went from a 1-to-1 package to
  maintainer model to a 1-to-many model.  The only possible way to scale is 
  to have a many-to-many model where we have teams of people that are
  responsible for groups of packages.
- Allow for rating of goals/features/etc -- let the community prioritize 
  the goals of the project.
- Making our bug and ticket lists much more open, available, and easier to
  navigate.
- Create a simple "I want to work on Fedora" wizard that holds users 
  hands through the new account process, and points them to the right
  projects/sub-communities/teams/groups/SIGs to get involved with.

This is not a comprehensive list by any means; it's merely a braindump that
will hopefully be food for thought.  I'd be interested to hear what you all
think of my various assertions and "solutions".  I would love to hear about
more problems that people see with the current Fedora community architecture,
along with other potential solutions.

Cheers,

luke