On Wednesday 13 August 2008 12:34:06 Norbert Hartl wrote: > On Wed, 2008-08-13 at 11:02 +0200, Holger Freyther wrote: > > On Wednesday 13 August 2008 00:05:14 Jeffery Davis wrote: > > > 2. Better communication between the development community and the end > > > user community. I have yet to see anyone say they're pleased > > > as punch with the keyboard. When almost everyone is unhappy, closing > > > bugs as 'working as intended' is pigheaded. > > > > Hey, > > > > as this action is misunderstood a couple of small words. What is the > > bugtracker for? The way we have used docs.openmoko.org so far is to make > > it an engineering tool. The assigned/owned tickets tells/informs > > engineers what to work on, when to get it done (milestone) and how > > important that is. > > Don't forget the problem reports which are a valuable source of feedback > for those developers. So the bugtracker is also for reporting bugs and > enhancement wishes. > > > The benefit of having as precise tasks as possible is that they are > > small, can be assigned to a single person, one can set the severity and > > the milestone. After this small task was done, the engineer can set it to > > in_testing and QA can test that single fix. > > In an ideal world it would something like this. > > > Now we have bugreports like the SIM PIN Dialog or the Keyboard. No doubt > > that there is a real issue but they are the exact the opposite of the > > above workflow. We can not assign a single engineer to take care of them. > > This means they will never be addressed as no one is responsible and not > > many people are capable of touching everything that would be needed to > > resolve the bug. > > > > So how to get out of that? Look at the issues presented and file tickets > > for each single issue. These can be assigned to developers, these can > > have a milestone set, these can have a severity, these fixes can actually > > be tested and verified. With my limited resources, internet connectivity > > (GPRS through the neo), my available time and my main tasks in mind, I > > have simply no time to create the tickets for each and every issue. So I > > name the issues I see in the report (and yes the list can be incomplete) > > and rely on people/interest holders to file a new precise bug report. > > This is to make it possible for engineers actually being able to do a > > bugfix which is in the interest of the community... > > > > Is that bad faith? How do others see that? > > No, it is just a gap. Users expect that developer understand their > concerns (you should know what it in "it is broken" means) and developer > expect that users understand their concerns (they should report e.g. > that component X makes wrong assumption and produces a race condition). > In between there is a huge gap. While the sentence "improve the > communication" is complete non-sense it indicates at least the helpless- > ness how to bridge the gap. > In my opinion bridging the gap means translation of the language from > the consumer to the engineer. I know only two things that can bridge > this gap: > > - if problem reports are written as reproducable misbehaviour one can > report it and developer can reproduce the same thing to find his own > words/ the real issue behind it. Then the engineer should translate > the ticket (subject) to the real thing > - community workers can leverage this manually by trying to understand > the customer and having enough knowledge to know how the engineer > needs the information in order to be able to work. As this is a boring > job you have to be paid for it (hello moko). That is nothing you can > expect from people to do in their spare time. > > It is difficult and I could write pages with all those aspects of > community vs. paid workers, product vs. development platform, > widget set A vs. widget set B and so on. But it would be even more > boring than this mail. So I let it go :) > > My experience is that working with a ticket system takes a lot of time. > Don't take tickets statically. Change them as you would change code when > you recognize that it doesn't work. That way a unspecific user complaint > could be turned into something valuable. And workarounds are workarounds > and they are useful until real issues have been fixed. Regarding the > "No SIM pin dialog" where I was involved the ticket isn't that bad. > There is an issue recognized "no sim pin dialog while qpe is eating > your device". And there is a workaround. So why not open a ticket "qpe > does not detect media files on the SD card" which is blocked by the > "no sim pin" ticket? In the sim pin ticket you can announce the work- > around and in the second ticket you can complain about the shitty > workaround. But then it is clear. The workaround isn't good and has > to be removed as soon as the first issue is solved. In the meantime > it does something good. > > My proposal for the ticket system would be to define rules. As soon as > you have a page which describes when a ticket is useful and when it > is not you can reject tickets from users pointing to that page. That > sounds harsh at first but becomes useful really quick because this is > a restriction where the community benefits. The rationale behind this is > that everybody gains if _you_ are fixing code instead of managing > tickets. > > that must have been at least 3 cents. > > Norbert
Very well put, clear and constructive! +10 SH _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community