[gentoo-project] Re: Plan, then communicate (no-list)

[Alec Warner]

On 1/20/08, John Lawles <jl.050877@×××××.com> wrote:
> Alec,
>
> > ...a thread about communication problems...

I've moved this to project.  Hopefully it will not be as flamey as you
expect; but if it is I apologize in advance.

>
> Not exactly.  Just for clarification, I was suggesting:
>
>   (a). Decide what the big-picture problems are, if any.
>   (b). If any, develop a plan
>   (c). Communicate it to users
>
>      From what I, as a mere user, can tell, the contentious issue
> is not so much (c) as it is (a).  The issue seems to be that some
> developers regard (a) as a personal insult rather than a request
> for better organization and coordination among the developers.

(a) is a bit vague.  Am I supposed to address issues that Gentoo
developers have?  Gentoo users have?  The Gentoo community?

The community currently has no good means to rank problems in the view
of users other than the forums; which currently have their own issues.

User Coverage: Not everyone has a forums account.  Not everyone uses
their forums account.  We have no idea how many users we have
(ancidotal numbers suggest ~200000; see
http://dev.gentoo.org/~antarus/bouncer-stats.txt).  It is difficult to
know what percentage of users responded and thus becomes difficult to
judge how important something is (we have only the respondants data to
use).

Arguably you could say that anyone who didn't vote doesn't care; but
you have to factor in people who didn't learn of the vote during the
voting period.

User Education: This is that whole Cathedral thing.  Below I'll talk
about Daniel's goal of maximizing developer impact and this plays a
big part.  Many developers don't talk to users because its draining
and they want to work on projects that they have a high impact on.  I
could sit in #gentoo and field questions all day (I've done it before)
but I have things I could spend my time on that are more worthwhile to
the project (and we are lucky enough to have a crack team of awesome
contributors that staff that channel).

Talking to users is exhausting when the user really has a
misconception about a given problem, program, or feature.  It takes
time to educate people why something works the day it does and
documentation only helps so much.  Give bad service and the user is
off to the forums to complain about how he was mistreated by that
Antarus guy on #gentoo-portage and how much Gentoo sucks.

That being said; talking to users who know what they are doing (doubly
so when they know more than me) is a delight and I'm generally happy
to take the time to respond.  If there was some way to aggregate user
complaints into concrete problem sets I'm all ears.

User Validation: Most systems that users can use to respond on a large
scale don't have a means to validate whether they use your software or
not.  This is more of a trend game; needing to look at the aftermath
of any given aggregate data and look for areas where people may have
given feedback that we should throw out (like automated voting).  I
don't think this problem is necessarily solvable or that big a deal
but it is something to consider/

>
>      Drobbins has addressed (a) and (b) and (c).  My suggestion is
> that the-powers-that-be at Gentoo address them also, starting with
> (a) and produce, hopefully, a far better plan.

Drobbins has addressed very little in my eyes.  Sure we have
communication problems (pr was basically dead until this incident) and
we have leadership issues.  His plan is not well specified:

1.  Open the lines of communication.  How?  We have an influx of
people interested in helping out with GMN and PR which is good.  We
have a new PR lead.  I'm busy working on news items and learning XSL
to try and change the webpages a bit.  The foundation obviously failed
at providing data in the past and I hope to change that.  We have
tried to be as transparent as possible with posts to -nfp, posts to
-project, news items on the website, etc.

Are there other places where communication is lacking?  What kind of
information are the users looking for?

2.  Maximize developer impact per unit time.  How?
I'm uncertain where Daniel thinks developers are wasting time stuck in
process.  We could kill the 30 day stability guideline in an attempt
to get packages into stable quicker; but I'm unsure what that would do
to overall quality (which a subset of the userbase seems to think is
subpar at this time).  I'm also unsure how much time it costs someone
to become a fully-fledged developer; however I think we have a decent
set of options for individuals who wish to contribute without being a
full-time developer (sunrise, proxy-maint, arch tester, overlays).

Are there specific processes we have that you think hold developers back?

3.  The project has hit several scalability issues; but Daniel does
not specify what these issues are or his ideas on solving them.  It's
difficult to specify management roles in a volunteer organization but
obviously some are needed.  Most projects lack a strong project lead
and finding qualified motivated people who want to spend some time
dealing with people instead of technical problems is a difficult
process that we could possibly improve.

What exactly are these scalability limits?  It is difficult to say
much about this item since it was vague.

>
>      This is sent off-list because, as you point out, it does not
> belong on gentoo-nfp.

Feel free to punch me if you dislike me forwarding it to project; I
think it is a worthwhile conversation to have and I wish to have it in
public.

>
> Regards,
>
> John
>

Thanks,

-Alec
antarus@g.o
-- 
gentoo-project@l.g.o mailing list