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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create