What could be done to improve the OM development process?

[Norbert Hartl]

On Wed, 2008-08-13 at 14:09 +0200, Olivier Berger wrote:
> Holger Freyther <zecke at openmoko.org> writes:
> 
> > 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.
> >
> 
> Whereas us users have been assuming that it was an open bugtracker for
> en-users...
> 
> Maybe there would be a need for some other Bug-tracking tool, which
> would clearly support the separation between support-oriented
> bugtracker (external) and engineering-oriented one (internal maybe) ?
> 
Having two different tools raises complexity and lowers collaborative
work. And what do you get from it?

> I don't think trac's is powerful enough to play both roles without
> much frustration from either side (but I may be wrong).
> 
In my opinion it is never the tool that prevents organized work. Not
having the "right tool" is just the simplest excuse for being
organized ;)

> In any case, a policy should be drafted and announced widely. And
> mailing-lists for users vs bugtracker for engineering is not
> satisfactory for any open project, of course.
> 
> Also, maybe you would need to rely on an organisational tool like a
> todo manager to assign work to people, whereas bugtrackers may only be
> there as a repository of knowledge and a communication tool ?
> 
Wow, I think it is exactly the opposite. What a bugtracker does best
is keeping things that have to be done. What it doesn't do so good is
serve as a knowledge base or communication tool. We are communicating
over a mailing list. For the rest (ticketing, wiki, source repository)
trac tries to be a good integration of those systems.

Norbert