On Wednesday 13 August 2008 12:34:06 Norbert Hartl wrote: > 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.
It is. In the SIM PIN Dialog bug the log was really helpful to identify the issue as I see it. Feedback is _very_ valuable. > > 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. For bugs found by QA it is actually working that way. For the rest we should aim to get there as well. > > 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: hehe, we never talked about domain specific languages (user <-> developer is a bit different though), but I'm not surprised you have looked into that. > > - 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. Yes that is the difficult part. I don't get into details right now... :) > 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. yeah, this is work in progress. Stuff like two bug trackers, controlling some more fields.. and various other things float through my head and I have to organize this first. Other entities fix that by shielding developers and putting 1st line support there acting as a multiplexers... but I think reaching developers directly can be valuable.. cya tonight z. _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community