Bear in mind reading this that I'm aware I know nothing of your internal workings, and wouldn't presume to know better. I just hope to contribute something from my experiences, and will take no offence if ignored.
Holger Freyther wrote: > --- > 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. > I disagree, you /can/ assign them to a single engineer (even if they don't like it!), and they can then in turn break it down to constituent parts (bugs) that have clear engineer ownership. As an engineer I don't like having bugs on my list that I see no clear path to fixing, so will dig down into the details till I have a good description of the problem and a plan for resolving it, however convoluted. Being responsible for a bug doesn't necessarily mean being the person who actually makes the code changes, just the person who keeps revisiting it till it's done (depending on importance). > 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? > I see no bad faith here :-) Personally I think bug trackers (I use bugzilla for my dev work) have no trouble supporting both user oriented and developer oriented reports. Where there is an apparent disconnect between the points of view, eg user: "i can't phone fred" dev: "d-bus message foo is malformed by obscure component x", both reports can co-exist, and a dependency can show the relationship between them, ie the user can't phone fred (bug #1) until the d-bus problem (bug #2) is corrected (blocks bug #1). In my experience, if a user files a vague (but eventually reproducable) bug report, then the bug report lands in my virtual in-tray, and once I've figured out the cause (with my developer hat on) I will perhaps file a more detailed separate report and link the two if appropriate. I make it my mission to never have any bugs in my in-tray that I haven't analysed down to the root cause. So I guess what I'm saying is the bug reports need to be assigned to someone with sufficient knowledge to either get to the root cause or re-assign it to someone who they think can. If you personally don't know how to fill in details for a bug report then, simply reassign it to a suitable engineer, and then (depending on organisational structure) kick them till it's understood/done, or ask them nicely to look at it. :-) Tim Abell _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community