Mailinglist Archive: opensuse-project (349 mails)

< Previous Next >
[opensuse-project] Re: Introducing the Freight Train
  • From: Jim Henderson <hendersj@xxxxxxxxx>
  • Date: Mon, 14 May 2012 22:43:30 +0000 (UTC)
  • Message-id: <jos1qi$etu$1@dough.gmane.org>
On Tue, 15 May 2012 00:23:27 +0200, Jos Poortvliet wrote:

Yes, we do want more communication, but we only want the _right_ kind
of communication.

It's important, though, that the "right kind" not just be defined as
"everyone who agrees with me" or even "everyone who agrees with the
majority".

Yup, disagreement is more than fun - it is useful ;-)

It can be. There are also points at which disagreement is not useful -
so it's important to distinguish between the two types of disagreement.

Disagreement that is of the "Is to!" "Is not!" back-and-forth variety is
obviously not particularly useful. It's important that the disagreement
include some substance as to why there's disagreement. Otherwise we
might as well be going for the "five minute" version rather than the full
half-hour (obligatory Monty Python reference).

As a community, we say that we value diversity.  For that to be true,
we have to not be seen to (or appear to - for the average viewer)
reject ideas based on who they come from or if they're unpopular - or
even if they're poorly expressed.

It's important to weigh ideas based on their merits.

And willingness of the person who brought them forward to implement
them. I'd pick a crappy solution to a problem with someone to implement
it over a perfect solution with nobody able to work on it anytime ;-)

Certainly there needs to be someone willing to implement them, but I
don't think it necessarily need be limited to the person who suggests the
idea. There are people who have great ideas but no background in
implementing technical solutions - but if they can get people on board to
work on the solution, that can be just as (if not more) effective.

I don't know that I could say as a blanket statement that I'd rather have
a crappy solution than no solution, though - in some cases, a
particularly crappy solution can prevent a better solution from being
implemented. There are also times that a /good/ solution should be put
aside in order to get a /great/ solution implemented. It's very much a
case-by-case thing, and driven by the need and importance of the solution
being implemented - there are lots of factors to consider.

Of course, all properly presented* opinions have value. But many of the
probably belong in bugzilla or openfate. They even have a +1 system :D

Yeah - but I think we maybe need (as a project) a more comprehensive way
of reviewing things. That /may/ be someplace we can improve. As I look
at how the enhancement system inside Attachmate (as a whole, but with my
history from the Novell side that's what I initially think of) is (or is
not) managed effectively, I think there are some excellent lessons there
in what not to do.

There's got to be someone to review the requests and determine (a) if
they're enhancements or bugs, (b) if they duplicate something else in the
system, (c) if they are already resolved, (d) if they're even relevant
any more.

Otherwise a system/systems like that become a black hole and nobody has
any confidence in them. I do occasionally hear from users who wonder if
it's even worth submitting a bug or an enhancement request because it /
feels/ like nobody's reviewing them (even if they are being reviewed).

This is an important enablement step that needs to be taken with the
community. :) There are few things that are as enabling (for a
community) as just listening and acting on feedback.

While input from users is valuable (and there is a number of VERY
knowledgeable non-developers lurking on this list giving VERY valuable
feedback from time to time), too much heavily distracts from the work to
be done. Some developers have unsubscribed from our core development
list(s) for this reason and frankly I care far more about getting them
back than getting a bit less input from users.

I think it's a question of taking the broader user base's input (whether
it be from MLs, forums, IRC, or other places - there are some SUSE-based
USENET groups that I recall seeing that I think we're probably missing a
lot of feedback from) and refining that feedback in a way that's useful
and not time-consuming to the developers working on making a better
product.

It can be tricky to balance, though - because listening doesn't always
lead to action (nor /can/ it, really - when two suggestions are in direct
opposition, one is not going to get implemented).

But this goes back to our earlier discussion - how do we balance our
core lists when it comes to amount of traffic, feedback we get,
checkups on the 'real-ness of issues', quality, moderation etcetera.
Something to discuss at oSC (October, Praha, more info coming soon).

Yeah, though it's a shame to miss feedback from people who can't be at a
physical event - it's extremely difficult to replicate a physical event
online, because you lose the "chatting around the water cooler"
conversations. VMware tried doing an entirely virtual event, and it was
interesting, but even with a venue set up to have informal discussions,
it still was missing that presence.

But it would be nice if we could figure something out so a good idea
isn't missed or lost because someone couldn't be at oSC.

respectfully-brought, relevant, reasonable, on-topic, non-repetitive
etc. And indeed, it doesn't matter who they're from and how well he/she
expresses himself. We all sucked at English at some time in the past,
even if that requires going back almost our entire lifetime (as is the
case for native speakers). 8-)

In instances where someone is expressing themselves poorly, there are
often reasons for it; I think of my interaction with Marco several months
ago, and clearly he had something he was putting energy into being upset
about, and I think when someone's got the energy to be upset about
something, there's a need to listen to the underlying issue, even if it
is poorly expressed. But it's important to separate the emotion from the
issue, both in representing the issue and in trying to understand it.

And of course we all do have off days. :)

Jim

--
Jim Henderson
Please keep on-topic replies on the list so everyone benefits

--
To unsubscribe, e-mail: opensuse-project+unsubscribe@xxxxxxxxxxxx
To contact the owner, email: opensuse-project+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups