What could be done to improve the OM development process?

[tim]

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