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: