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