What could be done to improve the OM development process?

[Sander Hepp]

On Wednesday 13 August 2008 12:34:06 Norbert Hartl wrote:
> On Wed, 2008-08-13 at 11:02 +0200, Holger Freyther wrote:
> > On Wednesday 13 August 2008 00:05:14 Jeffery Davis wrote:
> > > 2. Better communication between the development community and the end
> > > user community.  I have yet to see anyone say they're pleased
> > > as punch with the keyboard.  When almost everyone is unhappy, closing
> > > bugs as 'working as intended' is pigheaded.
> >
> > Hey,
> >
> > as this action is misunderstood a couple of small words. What is the
> > bugtracker for? The way we have used docs.openmoko.org so far is to make
> > it an engineering tool. The assigned/owned tickets tells/informs
> > engineers what to work on, when to get it done (milestone) and how
> > important that is.
>
> 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.
>
> > 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.
>
> > 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.
> >
> > 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?
>
> 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:
>
> - 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.
>
> It is difficult and I could write pages with all those aspects of
> community vs. paid workers, product vs. development platform,
> widget set A vs. widget set B and so on. But it would be even more
> boring than this mail. So I let it go :)
>
> My experience is that working with a ticket system takes a lot of time.
> Don't take tickets statically. Change them as you would change code when
> you recognize that it doesn't work. That way a unspecific user complaint
> could be turned into something valuable. And workarounds are workarounds
> and they are useful until real issues have been fixed. Regarding the
> "No SIM pin dialog" where I was involved the ticket isn't that bad.
> There is an issue recognized "no sim pin dialog while qpe is eating
> your device". And there is a workaround. So why not open a ticket "qpe
> does not detect media files on the SD card" which is blocked by the
> "no sim pin" ticket? In the sim pin ticket you can announce the work-
> around and in the second ticket you can complain about the shitty
> workaround. But then it is clear. The workaround isn't good and has
> to be removed as soon as the first issue is solved. In the meantime
> it does something good.
>
> 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.
>
> that must have been at least 3 cents.
>
> Norbert

Very well put, clear and constructive!
+10

SH