Thoughts on Eric Raymond's Insights

[Jef Spaleta]

Jonathan Gardner wrote:
> Everyone is a volunteer

Everyone is a potential volunteer. You included.

> We recruit the users (the "Eloi") and ask them to choose a project 
> they are interested in, and we hook them up with those specialists

Have you looked at the fedora.redhat.com project pages...that looks
like a recruitment effort to me..based on each project. Or are you
talking about hiring a brass band and marching around or something
similar? Recruitment efforts on a lot of fronts are in need of creative
ideas. By the way, for anyone reading fedora.us QA review needs
volunteers. So does the Fedora Core community triage effort, find me on
#fedora-bugs on the irc network if you are interested in helping out
with either of those efforts....

> We recruit some more-technically minded people (the "Morlocks") and 
> have them develop some usuability plans. These people should not be 
> testers or developers, but people who understand the software or have
> the ability to communicate productively with the authors of the 
> software

Have fun trying to identify the people who can do that well.

> A third set of people will actually engage with the end-users in one-
> on-one sessions, following the plans that were developed

Are you keeping a running count in your head about the number of people
you are talking about...and how much time you really expect these
volunteers to contribute consistently? One on One sessions are expensive
in terms of manhours...and you don't have anyone signed up yet..so your
total number of manhours to spend are zero. Don't start building a
process that is manpower expensive..until you have manpower to burn...
you are going to kill the process under its own weight before you even
get someone to volunteer.

> The usuability sessions will be made public, so that other unrelated 
> projects can derive some benefit from them

A more cynical view is that, making it public will provide other
'potential' volunteers the opportunity to rip apart your methodology and
reinterpret the result to prove the result you derived from the sessions
are invalid....be careful what you wish for.

> We'll allow others who know  more about this kind of thing to comment
> on the results, summarize it for the developers, identify the problems
> and suggest solutions

Unless you have a commitment from the developers to buy into the
methodology that forms the basis of the summaries...this is just going
to lead to a lot of argument. I tell you right now, that you aren't
likely to win over development mindshare just by handing them a
usability summary without their involvement with outlining at least the
methodology you layout. If you are going to experiment with this, you
should first find a project with developers who are open to working with
you on this to see if it really will be helpful. Pushing the summaries
on developers for a project if they aren't interested..is not going to
help.  

> With enough data, we should be able to identify the biggest problems
> and work to solve them before FC3. Then, when FC3 comes out, we can do
> this all over again.

This is a very hopeful hypothesis. And I would argue, that the biggest
problems will be defined differently by different segments of the
userbase. It will be interesting how you build a process that matches
biggest problems...to specific usage patterns...in an unbiased manner.
It will be interesting to see how you guard against having your
summaries being biased by a small vocal minority.

> The only problems I see are getting people involved and working with 
> each other. I worry that while we will be able to get participants, 
> those will always be the *wrong* people we are trying to target

There are LOADS of problems...loads and loads...
i like this handbook on volunteerism

http://www.sport.vic.gov.au/Web/SRV/srvimages.nsf/Images/VMPWorkbookpdf/
$File/VMPWorkbook.pdf

The summary on the first 18 pages are so, is generally useful as a
guideline for any volunteer process...

> However, never  underestimate the amount of data that one session can
> produce! So maybe we don't need that much to actually happen.

the amount of data isn't the question, I fear for the quality of the
data, and whether what you will be producing is something the developers
want. 

Maybe if you rethink this idea assuming you only have 3 or 4 people who
are energized about working on the problem you see, and think about a
process that can produce a result with just 3 or 4 people's worth of
volunteer time. Think usability strike team, instead of usability
batalion,

-jef"is still looking for someone to head up an accessibility strike
team"spaleta
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040301/ba460bfc/attachment.sig>