What could be done to improve the OM development process?

Holger Freyther zecke at openmoko.org
Wed Aug 13 17:07:19 CEST 2008


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.




More information about the community mailing list