j.fp.o design process strawman (criticism please!)

[Mel Chua]

As I pore through Websites stuff tonight and think about how to tackle 
join.fp.o, I'm realizing that I have a very dim notion (actually, "dim" 
is generous) of what a good design process to go through for this kind 
of thing would be. 
http://en.wikipedia.org/wiki/Engineering_design_process seems to... not 
exactly fit, but I will stab in the dark and try to use it, and hope 
better alternatives present themselves.

*Please* criticize this gameplan. It's put up here so that it can be 
ripped apart - I'm stuck on finding a better way to think about this, so 
I figured I'd try something (anything) and then let y'all tell me what 
my mistakes are.

---

1. Identify a need: "j.fp.o doesn't really get people to join fedora."

2. Define the problem: I can think of several angles to tackle this from 
- not sure which (if any) are useful ways of looking at this.

* Improve click-through percentages from j.fp.o to the "How To Join 
$Group" page of any group. (If someone reads j.fp.o clicks through to 
read step-by-step join instructions for at least one team, it counts as 
a yes; if they read j.fp.o but don't read a team's join instructions 
afterwards, it counts as a no.)
* Minimize the time it takes a newcomer to go from "I have started 
reading j.fp.o because it looked interesting, and know nobody to help 
me" to "I have made my first tracked project contribution." A good 
target might be 90 minutes.
* Minimize the time it takes a newcomer to go from "I have started 
reading j.fp.o because it looked interesting, and know nobody to help 
me" to having a mentor contact and welcome them, and help them decide on 
a first project to do. A good target might be 20 minutes. (yes, these 
targets are ambitious.)
* For each successive release, raise the number of contributions made by 
community members whose first contribution was towards that release. 
(For instance, F12 contributions made by volunteers who first got 
involved with Fedora during the F12 cycle.)

3. Conduct research: (This is where I am now, I am trying to figure out 
the answers to these questions.)

* How can the above metrics be instrumented? (Is it possible to measure 
them at all?)

* Who are the current users...
** looking at j.fp.o?
** finding j.fp.o helpful? (how?)
** not finding j.fp.o helpful (and disappearing rather than telling us 
it didn't help them out? what would have made it useful to them?)

* Who do we want...
** looking at j.fp.o?
** joining our community? (Do we *want* to consciously set up a 
minimum-effort barrier to encourage only the motivated? Are we trying to 
get more non-code contributors?)

* Who is it that wants these people looking at and using j.fp.o (beyond 
the Websites team)? Are there specific people on specific teams that 
have particular recruiting needs, and who can offer to mentor newcomers 
(or otherwise set up a newbie-contribution infrastructure for their 
particular projects/teams)?

* What does the 'join' experience look like for other projects - what do 
they consider? How do they compare, and what can we learn from them?

(The rest of the steps I'm not even going to think about just yet - this 
is plenty to tackle for now.)

4. Narrow the research:
5. Analyzing set criteria:
6. Finding alternative solutions:
7. Analyzing possible solutions:
8. Making a decision:
9. Presenting the product:
10. Communicating and selling the product:

[Mike McGrath]

On Sat, 11 Jul 2009, Mel Chua wrote:

>  As I pore through Websites stuff tonight and think about how to
> tackle
>  join.fp.o, I'm realizing that I have a very dim notion (actually, "dim" is
>  generous) of what a good design process to go through for this kind of thing
>  would be. http://en.wikipedia.org/wiki/Engineering_design_process seems to...
>  not exactly fit, but I will stab in the dark and try to use it, and hope
>  better alternatives present themselves.
>
>  *Please* criticize this gameplan. It's put up here so that it can be ripped
>  apart - I'm stuck on finding a better way to think about this, so I figured
>  I'd try something (anything) and then let y'all tell me what my mistakes are.
>
>  ---
>
>  1. Identify a need: "j.fp.o doesn't really get people to join fedora."
>  
I've always found one of the biggest problems with joining is setting
expectations, fedora is a HUGe place.  I think people get lost and don't
know what we expect from them.  This is especially true of more passive
volunteers that just want to be told what to do.  I've found they don't
know what to do, don't enjoy being told what to do and generally don't
have a good experience after joining.

	-Mike

[Todd Zullinger]

Mike McGrath wrote:
>  I've always found one of the biggest problems with joining is
>  setting expectations, fedora is a HUGe place.  I think people get
>  lost and don't know what we expect from them.  This is especially
>  true of more passive volunteers that just want to be told what to
>  do.  I've found they don't know what to do, don't enjoy being told
>  what to do and generally don't have a good experience after joining. 
Judging from my past experiences in other volunteer organizations,
this is a common problem.  I think this could be a niche filled by
mentors, if there are folks that know their way around the various
systems in Fedora and enjoy showing others the ropes.  Of course,
finding good mentors can be a challenge in itself.

FWIW, I think you do a pretty good job at this in the infrastructure
area Mike.  You have my respect for organizing the relatively large
and diverse group of folks who work on the many tasks that make the
Fedora Infrastructure successful.

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Truth is like a well-known whore.  Everybody knows her but it's
embarrassing to meet her in the street.
    -- Wolfgang Borchert

[Sijis Aviles]

As someone that is new to the joining process, I think Mike is right
that some of the problem is expectation. I think some of it is also
direction. After someone joins and sends a 'intro' message to the
list, there is a welcome response but not exactly a follow-up on what
the next steps are. I know that folks are busy and you cannot guide
everything through the process, but we should provide some next steps
and direction.

A thought is having a list of what is currently being worked on for
each group, something like
http://fedoraproject.org/wiki/Websites#Projects (see
join.fedoraproject.org area). The only thing i would add a 'task to be
completed' item or help needed area.

Another thought would be somehow list what an individual could do
right after they join and have "levels" of tasks. Infrastructure might
be different since folks might require some level of system access to
complete tasks, so we'd have to provide types of 'tasks' they can do,
in order to gain trust in the group before access is granted.
(these are just rough ideas)
Level 1 - review open tickets, fix wiki entries
Level 2 - assist in group tasks, code review, improvement ideas
Level 3 - lead project/implementation, etc..

I've enjoyed and been frustrated with the joining process but overall
is been a positive one. Like many things, it can be improved
(mentoring is a good idea). In its current state, individuals need to
be self-motivated and figure out what to do next on their own.

Sijis

On Sun, Jul 12, 2009 at 10:12 PM, Todd Zullinger<tmz(a)pobox.com> wrote:
>  Mike McGrath wrote:
> > I've always found one of the biggest problems with joining is
> > setting expectations, fedora is a HUGe place.  I think people get
> > lost and don't know what we expect from them.  This is especially
> > true of more passive volunteers that just want to be told what to
> > do.  I've found they don't know what to do, don't enjoy being told
> > what to do and generally don't have a good experience after joining.
>
>  Judging from my past experiences in other volunteer organizations,
>  this is a common problem.  I think this could be a niche filled by
>  mentors, if there are folks that know their way around the various
>  systems in Fedora and enjoy showing others the ropes.  Of course,
>  finding good mentors can be a challenge in itself.
>
>  FWIW, I think you do a pretty good job at this in the infrastructure
>  area Mike.  You have my respect for organizing the relatively large
>  and diverse group of folks who work on the many tasks that make the
>  Fedora Infrastructure successful.
>
>  --
>  Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>  Truth is like a well-known whore.  Everybody knows her but it's
>  embarrassing to meet her in the street.
>     -- Wolfgang Borchert
>
>
>  --
>  Fedora-websites-list mailing list
>  Fedora-websites-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-websites-list
>
>