1 |
Alec Warner wrote: |
2 |
> The community currently has no good means to rank problems in the view |
3 |
> of users other than the forums; which currently have their own issues. |
4 |
|
5 |
Have you thought about the use of some other forum, a web page for |
6 |
example where you specifically as for user interaction, one with |
7 |
questions, answer boxes and tick boxes. The page and subject could be |
8 |
announced on all the current media (forums, lists, irc) and answers |
9 |
could be automatically converted into percentages for the thought of the |
10 |
community as a whole. |
11 |
> |
12 |
> User Coverage: Not everyone has a forums account. Not everyone uses |
13 |
> their forums account. We have no idea how many users we have |
14 |
> (ancidotal numbers suggest ~200000; see |
15 |
> http://dev.gentoo.org/~antarus/bouncer-stats.txt). It is difficult to |
16 |
> know what percentage of users responded and thus becomes difficult to |
17 |
> judge how important something is (we have only the respondants data to |
18 |
> use). |
19 |
> |
20 |
> Arguably you could say that anyone who didn't vote doesn't care; but |
21 |
> you have to factor in people who didn't learn of the vote during the |
22 |
> voting period. |
23 |
> |
24 |
> User Education: This is that whole Cathedral thing. Below I'll talk |
25 |
> about Daniel's goal of maximizing developer impact and this plays a |
26 |
> big part. Many developers don't talk to users because its draining |
27 |
> and they want to work on projects that they have a high impact on. I |
28 |
> could sit in #gentoo and field questions all day (I've done it before) |
29 |
> but I have things I could spend my time on that are more worthwhile to |
30 |
> the project (and we are lucky enough to have a crack team of awesome |
31 |
> contributors that staff that channel). |
32 |
|
33 |
Maybe communication and people skills should be part of the job |
34 |
description (language permitting of course)? If not then there should be |
35 |
developers whose job it is to relay the comments of those who do not or |
36 |
cannot want to communicate. |
37 |
> |
38 |
> Talking to users is exhausting when the user really has a |
39 |
> misconception about a given problem, program, or feature. It takes |
40 |
> time to educate people why something works the day it does and |
41 |
> documentation only helps so much. Give bad service and the user is |
42 |
> off to the forums to complain about how he was mistreated by that |
43 |
> Antarus guy on #gentoo-portage and how much Gentoo sucks. |
44 |
|
45 |
Here is where the forums could help out, if a question or rfc was put |
46 |
into a thread then any questions about the question could be answered by |
47 |
those users in the know. |
48 |
> |
49 |
> User Validation: Most systems that users can use to respond on a large |
50 |
> scale don't have a means to validate whether they use your software or |
51 |
> not. This is more of a trend game; needing to look at the aftermath |
52 |
> of any given aggregate data and look for areas where people may have |
53 |
> given feedback that we should throw out (like automated voting). I |
54 |
> don't think this problem is necessarily solvable or that big a deal |
55 |
> but it is something to consider/ |
56 |
|
57 |
Ask for a uname -a (not useful for me at the moment because I am stuck |
58 |
on windows) or something that might give you a more precise answer like |
59 |
requesting users set up an account (which could also give you more |
60 |
useful information like platform, stable/unstable and demographics. |
61 |
> |
62 |
>> Drobbins has addressed (a) and (b) and (c). My suggestion is |
63 |
>> that the-powers-that-be at Gentoo address them also, starting with |
64 |
>> (a) and produce, hopefully, a far better plan. |
65 |
> |
66 |
> Drobbins has addressed very little in my eyes. Sure we have |
67 |
> communication problems (pr was basically dead until this incident) and |
68 |
> we have leadership issues. His plan is not well specified: |
69 |
> |
70 |
> 1. Open the lines of communication. How? We have an influx of |
71 |
> people interested in helping out with GMN and PR which is good. We |
72 |
> have a new PR lead. I'm busy working on news items and learning XSL |
73 |
> to try and change the webpages a bit. The foundation obviously failed |
74 |
> at providing data in the past and I hope to change that. We have |
75 |
> tried to be as transparent as possible with posts to -nfp, posts to |
76 |
> -project, news items on the website, etc. |
77 |
> |
78 |
> Are there other places where communication is lacking? What kind of |
79 |
> information are the users looking for? |
80 |
|
81 |
Transparency is great and some of the comments from the short-lived |
82 |
userreps project was that most things seemed to be done in private, the |
83 |
first any of the users knew about anything was an announcement. |
84 |
|
85 |
Attitude is another. For instance, I made a comment on -dev (I think) |
86 |
that without users Gentoo would be nothing and the response I got was |
87 |
basically "p**s off, we develop because we want to". |
88 |
> |
89 |
> 2. Maximize developer impact per unit time. How? |
90 |
> I'm uncertain where Daniel thinks developers are wasting time stuck in |
91 |
> process. We could kill the 30 day stability guideline in an attempt |
92 |
> to get packages into stable quicker; but I'm unsure what that would do |
93 |
> to overall quality (which a subset of the userbase seems to think is |
94 |
> subpar at this time). I'm also unsure how much time it costs someone |
95 |
> to become a fully-fledged developer; however I think we have a decent |
96 |
> set of options for individuals who wish to contribute without being a |
97 |
> full-time developer (sunrise, proxy-maint, arch tester, overlays). |
98 |
|
99 |
Killing the 30 guideline would be a big mistake IMO. Quality is far more |
100 |
important. |
101 |
|
102 |
As for developers, Gentoo continually says it is under-staffed and one |
103 |
of the things I suggested when userrel started up was a developer |
104 |
fast-track, where current and former developers of other projects could |
105 |
demonstrate they had the skills and could be moved into their areas of |
106 |
expertise far quicker. |
107 |
> |
108 |
> Are there specific processes we have that you think hold developers back? |
109 |
|
110 |
Yes, the continual arguments over GLEPs. PMS is a good example - people |
111 |
trying to add their political piece of the puzzle in and everyone |
112 |
disagreeing. |
113 |
|
114 |
I honestly believe that when you have something as serious as a PMS then |
115 |
the constant bickering and the camps at gentoo have rendered it too |
116 |
incompetent to get it done itself, you need outside assistance who can |
117 |
listen to the arguments and make a decision. It would be great if an |
118 |
agreement could be struck up with another distro where assistance was |
119 |
given both ways. A request for discussion about the viability would only |
120 |
take an email to someone like Mark Shuttleworth and what do you have to |
121 |
lose? The worst that could happen is that someone says "we dont have the |
122 |
time, sorry" |
123 |
|
124 |
George |
125 |
|
126 |
-- |
127 |
gentoo-project@l.g.o mailing list |