[CREATE] Inkscape questions

[Yuval Levy]

Hi a.l.e,

On June 21, 2011 03:09:47 AM a.l.e wrote:
> i can also give my point of view on the way the scribus bug tracker works.
> it's only my subjective view on it.

thank you for taking the time to share this perspective, very much 
appreciated.

 
> - in most cases a comment is made in the first 24 hours

wow!  you must have a very large team?  how many tickets do you receive in a 
typical week?

 
> - three kinds of bugs tend to be fixed very quickly:
>   - bugs which affect the PDF output or the own file reading,
>   - bugs affecting people with a deadline,
>   - bugs on features which have been implemented very recently;

impressive, so your team is committed to this kind of support level that is 
better than what many commercial products offer?  how can you keep that up?


>   all those bugs tend to be fixed in a few hours, maximum overnight.
>   mostly, without the need to directly address one of the main developers.

without the need to directly address one of the main developers?  if not 
developers, who fixes the bugs?

 
> - bugs and feature requests which tend to sit around for a long time:
>   - (subjective) usability issues
>   - ideas for new features inspired by other packages

do you expire / purge tickets that are unlikely to get attention?


>   - patches for non important tickets

this surprises me. one of the first thing I am trying to do in Hugin is to 
give patches the highest priority.  somebody has made the effort to contribute 
and they deserve feedback.  best case the patch is applied.

> 
> - the programmers do have a look at the bug tracker. some of them every
> day.
> 
> - a programmer aggressively tracks duplicated reports. 2-3 other
> programmers and some other developers also track dups.
> 
> - a few programmers and developers track bugs where the submitter could not
> provide the information needed to reproduce the bug (and close them)
> 
> - once or twice a year somebody goes through all the bugs and cleans up
> (this seems to somehow magically happen...)

are these processes documented somewhere?  do the programmers feel obliged?  
are they under contract?  or they are simply so dedicated?

 
> - we have our own bug tracker, we manage it through the web platform and we
> get mails for specific events. afaict mantis does not have any fancy
> features but no terrible drawbacks, either.

Mantis came up quite high in my ranking / evaluation.  The constraint that 
made me decide for Launchpad and not Mantis is that we don't have the 
resources for a self-hosted solution.  Sourceforge had a version of Mantis in 
their applications, but when I tried it it was outdated.  Plus, the SF 
infrastructure is not that reliable - I find it barely OK for Hugin's website.  
I did not find any other alternative for hosted Mantis.  I did look at Google 
Project, Github and a few others.  In the end I am happy with Launchpad and 
based on the feedback I have seen so far I think that the problem is not at 
the tool layer but rather at the processes and resources.  How do you keep 
your team motivated to work on the tracker tickets?

 
> - all in all the status is:
>   - 850 new reports (all of them have been looked at, but no action is
> planned) - 900 reports "accepted" (this means that somebody has defined in
> which version the issues will be worked upon, not that it will get fixed
> soon) - 8000 resolved issues
>   can we really manage 2000 open issues?

wow!


> at the end my sight on it is:
> 
> - important issues are correctly handled and timely fixed.
> 
> - problems and wishes from the community don't get lost (never), but there
> many requests sitting around for too long.
> 
> - the entries in the bug tracker are indeed used to inspire the actual
> programming work.
> 
> - we could find solutions to complex issues by using a mix of bug tracker,
> mailing list and wiki.
> 
> - we have big backlog of less important issues (and this is clearly not
> optimal).
> 
> - patches uploaded by "external" contributors to the bug tracker risk to be
> ignored.

this last point is the one that would worry me most.  but you don't seem to 
lack contributors, so maybe you don't need to worry.
 
 
> while i'm happy with the way our bug tracker works, i'd like to find a way
> to improve the flow of "external" contributions. it's painful to skim
> through such a long unordered list and it's not clear enough that
> everybody is welcome to look at it and provide patches!

exactly.  I would also look at the wishlist and intentionally lose some - 
maybe to an "idea system" where people can vote them up or down?

 
> it's also not always easy to convince the users to write a bug report

I can relate to that.  and sometimes it is our fault:  we answer on the 
mailing list, so why should they log on to another system that requires them 
to structure the information and to stand for it?

 
> voilà, personally, my conclusion is that the tool used is not so important
> and what most count is the way people work with it...

I think it is a combination and that the tools (with the exception of 
SourceForge's own tracker) are adequate for the use that the projects make of 
them.
 
 
> it was interesting to go through all this and try to "formalize" how i feel
> about the scribus bug tracker.

yes, we need more formalization.

 
> i wonder if there are interesting parts for anybody else, though...

I find it interesting.  I would like to see the practice you describe 
documented, and I would like to introduce something similar to Hugin, adapted 
to the available resources, unfortunately...

Yuv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/create/attachments/20110622/8ab3228c/attachment.pgp>