Hi Michael, Christoph, designers and developers On Tue, 08 Mar 2011 12:05:22 +0000 Michael Meeks <michael.meeks@novell.com> wrote:
We finally get a competant, enthusiastic, motivated developer - actually fixing our horrible user interface problems: and he does some great improvement - and our design guys apparently emit a long stream of complaining left and right ! That, if true, is hard to excuse.
However, it is a such a common issue, that it even has a name "Parkinson's Law of Triviality" or "colour of the bikeshed": http://en.wikipedia.org/wiki/Parkinson%27s_Law_of_Triviality So we should not be ashamed that it happens, only be prepared to handle it well. For developers this means that you cant make everybody happy and you should not dispair if not everybody loves your implementation on first sight. For nondevelopers it means you should have to build a consensus in a larger group (best including some trusted grognard of the project). If each nondeveloper directly approaches a developer alone with their contradicting ideas(*), that poor confused developer will have a hard decision to make, which might even be outside his expertise. He might even innocently build a compromise which pleases nobody ("I will implement the wings from the plane proposal, but to make the ship proponents happy too I will also add a sail to our vehicle"). So if you see a change in an area you are interested in: The one thing a volunteer developers will love to hear would be: "Awesome! Way better than before. I will sit down with some other guys to discuss how to even make it better and we will get back to you with a proposal when we found a consensus!" It you think it is actually worse than before, the first thing to find out is if you are alone with that opinion. If you are not, team up and create a proposal. On Tue, 08 Mar 2011 18:42:05 +0100 Christoph Noack <christoph@dogmatux.com> wrote:
So here a short takeaway:
* Please ping us in any case if you need something
* Have also in mind that some of our members are new and also
need some time to get settled --> expect personal likings, relax and
wait for a mature outcome
* If you require a decision more quickly, or if you're unsure
about the current state, then please feel free to bother
us ...
* Over the time we'll get to know each other ... and you'll know
whom to trust ;-)
Agreed, as with the rest of you post, with one slight modification: I see little reason why a developer should not start working on an issue like this(**) even before there is a final decision. Personally, I think the bug #31251 should stay at least RESOLVED - WORKSFORME until there is a clear specification of how exactly it should be done different. At _that_ point the bug should be reopened, but before that there is no open bug, because the discussion might very well end with no consensus, or the consensus is "current solution is best". Oh, and as a sidenote: It would be a good idea to link to the discussion in the bug otherwise it will be repeated half a year later. Best Regards, Bjoern (*) Keep in mind that even simple statements like "this is very important" can be contradicting. Somebody else might find something else way more important. (**) If the issue is a major feature requiring lots of interdependent changes, that is a different issue. -- https://launchpad.net/~bjoern-michaelsen
Attachment:
signature.asc
Description: PGP signature