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@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org