What could be done to improve the OM development process?
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
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..
More information about the community