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:
--
Fedora-websites-list mailing list
Fedora-websites-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-websites-list
