What could be done to improve the OM development process?

[Norbert Hartl]

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