From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org)
	by finch.gentoo.org with esmtp (Exim 4.60)
	(envelope-from <gentoo-project+bounces-243-garchives=archives.gentoo.org@lists.gentoo.org>)
	id 1JGnPO-0004ZD-UC
	for garchives@archives.gentoo.org; Mon, 21 Jan 2008 03:33:15 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
	by pigeon.gentoo.org (Postfix) with SMTP id EEC3FE0603;
	Mon, 21 Jan 2008 03:33:03 +0000 (UTC)
Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183])
	by pigeon.gentoo.org (Postfix) with ESMTP id 9F3A5E0603
	for <gentoo-project@lists.gentoo.org>; Mon, 21 Jan 2008 03:33:03 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
	by smtp.gentoo.org (Postfix) with ESMTP id 2CCE065AC3
	for <gentoo-project@lists.gentoo.org>; Mon, 21 Jan 2008 03:33:03 +0000 (UTC)
X-Virus-Scanned: amavisd-new at gentoo.org
X-Spam-Score: -0.279
X-Spam-Level: 
X-Spam-Status: No, score=-0.279 required=5.5 tests=[AWL=-0.280,
	BAYES_50=0.001]
Received: from smtp.gentoo.org ([127.0.0.1])
	by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 0HWVrq15ZvWe for <gentoo-project@lists.gentoo.org>;
	Mon, 21 Jan 2008 03:32:57 +0000 (UTC)
Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184])
	by smtp.gentoo.org (Postfix) with ESMTP id 2376565A8E
	for <gentoo-project@gentoo.org>; Mon, 21 Jan 2008 03:32:56 +0000 (UTC)
Received: by nf-out-0910.google.com with SMTP id b2so270815nfb.44
        for <gentoo-project@gentoo.org>; Sun, 20 Jan 2008 19:32:55 -0800 (PST)
Received: by 10.78.138.14 with SMTP id l14mr8397014hud.23.1200886375419;
        Sun, 20 Jan 2008 19:32:55 -0800 (PST)
Received: by 10.78.46.19 with HTTP; Sun, 20 Jan 2008 19:32:55 -0800 (PST)
Message-ID: <b41005390801201932y37cd2978y1e5be8becd1a1c91@mail.gmail.com>
Date: Sun, 20 Jan 2008 19:32:55 -0800
From: "Alec Warner" <antarus@gentoo.org>
Sender: antarus@scriptkitty.com
To: "John Lawles" <jl.050877@gmail.com>
Subject: [gentoo-project] Re: Plan, then communicate (no-list)
Cc: gentoo-project@lists.gentoo.org
In-Reply-To: <20080121015439.GA18636@redwoodscientific.com>
Precedence: bulk
List-Post: <mailto:gentoo-project@lists.gentoo.org>
List-Help: <mailto:gentoo-project+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-project+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-project+subscribe@lists.gentoo.org>
List-Id: Gentoo Project discussion list <gentoo-project.gentoo.org>
X-BeenThere: gentoo-project@lists.gentoo.org
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20080120215706.GA16357@redwoodscientific.com>
	 <b41005390801201455w241b8832wcc77da934c4edfb7@mail.gmail.com>
	 <20080120233809.GA18052@redwoodscientific.com>
	 <200801201908.07265.vapier@gentoo.org>
	 <20080121015439.GA18636@redwoodscientific.com>
X-Google-Sender-Auth: 7b5952c63287c8be
X-Archives-Salt: 80bb4bff-170d-40a4-b56c-e74b015124b5
X-Archives-Hash: 260f0a179f02544abb9440e191fa6663

On 1/20/08, John Lawles <jl.050877@gmail.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@gentoo.org
-- 
gentoo-project@lists.gentoo.org mailing list