David Nickerson wrote: > Andrew Miller wrote: > >> Hi, >> >> At the Auckland CellML meeting today, we discussed the possibility of >> changing to a better tracker and moving some of the mailing list >> discussions onto that tracker. Everyone at the meeting agreed with this >> idea, so I am now looking for some input from the wider CellML community. >> >> By doing this, we are aiming to address several issues: >> 1) There is often lot of traffic on the mailing lists, but people are >> having difficulty following it. It was suggested that we could instead >> carry out these discussions on a good bug-tracker (which supports CC >> lists). We could broadcast newly created issues to the list, and >> everyone who was interested in following up on the issue could then add >> their address to the CC list and therefore see any comments being added >> to the tracker. This would ensure that everyone has the opportunity to >> follow topics they are interested in, but users don't get flooded with >> issues they don't care about. >> > > The problem I have with this approach is that issues initially submitted > to the list have a tendency to expand into much wider discussions, as we > have seen in some of the threads on the discussion list recently. > So > while I may not be interested in the initial topic and hence don't > subscribe to it, the ensuing discussion might be very interesting. I > would miss it all unless I continually check all the tracker items for > possibly interesting followups - which would be a lot of work. I think that this is one of the problem with mailing lists that we are trying to address. In a bug tracker, new issues would be created for aspects of the wider discussion (perhaps with dependency relationships with the main issue), and the creation of these new issues would trigger mails to the list.
At present, you can only find these wider issues if you read all the mail because they are often embedded deep. All of this is irrelevant if people unsubscribe (I understand that Catherine Lloyd is not on this list anymore because she felt she was getting flooded, Jonna is also considering unsubscribing, and even Poul finds it hard to keep up with all the threads as different issues get merged). > I much > prefer to have one place to look (my inbox) and use my tool of > preference to filter that as I see fit. > Unfortunately, I don't think that the average user who we want to get onto the list in order to build the CellML community will see it this way. > I guess such problems could be avoided if we could be assured that there > is some moderation of the tracker items such that if the moderator > decides the discussion has broadened sufficiently they could let the > wider community know in case more people want to join the discussion. > I think that we do need some people to keep an eye on the size of items and help ensure that overly complex items are split up into their component issues (which would result in everyone getting notified about the component issues). > While I can still see many flaws in such an approach, it might work out > ok in most cases. > I think that the real question is whether the problems solved outweigh the new problems created (I have a feeling that they will). > >> 2) Our present tracker makes it hard to browse issues by category (there >> are sort functions, but the user interface is not usable enough to use >> it regularly to see all the bugs for a given component and so on). The >> consequence of this is that we end up with lots of small trackers, e.g. >> one for PCEnv, one for the CellML API, one for the site, and moving >> issues between them is cumbersome (e.g. a bug filed by an end user about >> PCEnv might actually turn out to be a CellML API issue or even a CellML >> specification issue). >> > > I don't know if I see any problem here? As a novice PCEnv user I would > submit a bug in the PCEnv tracker - to me it doesn't matter if that bug > turns out to be a bug in the API, compilers, or anything else - to me > its simply a PCEnv bug. I would expect a PCEnv issue would need to be > reformulated by a PCEnv developer to make sense submitting it as a API > or specification issue anyway, so it would not generally be a straight > copy or move operation from one tracker to another. And the initial bug > submitter is probably just interested in when the bug is fixed in PCEnv, > not the API or specification. > I think that the interaction between the PCEnv and the CellML API issues are still important. The way that this sort of thing usually works in many other projects: => User submits a summary and description of their problem, classified based on the 'phenotype' of the bug. => Developer analyses the problem, updates the summary, and reclassifies it based on where the developer has determined the problem to lie. => Developer works on fixing the bug, keeping details in the tracker. => Developer resolves the bug. > While it might be nice to simply tag a submitted issue with extra > categories, I would see this as more of a convenience than any > absolutely required functionality. There would need to be a more > compelling reason for such a drastic move as dropping the current plone > based trackers. > The problem is that these issues are enough to make the current Plone-based trackers unusable now, let alone if we combine everything into one big tracker and use it for all our discussions. > >> If we had a good tracker, we could let all discussion take place on it. >> We could also have one big CellML tracker which collected bugs (in the >> general sense, which means everything from a concept through to a >> proposal through to an implementation) for everyone doing CellML related >> work (both at Auckland and for other groups which also wanted to use the >> tracker), which would hopefully increase the community focus of the >> CellML project, and make it easier for people to follow the issues they >> are interested in. >> > > As I pointed out to Randall in an earlier thread, we are currently > working on this using the existing plone tools. Have a look at > http://www.cellml.org/Members/andre/andre-s-test-cellml-centre/ and let > us know what you think. > > >> If we used a Plone based tracker, we would be able to have a single >> search which searched both the CellML site and the tracker. However, I >> think that this is just one consideration, and as Randall pointed out >> today, it already doesn't integrate with mailman. I think that both >> PloneCollectorNG and Poi lack the sort of usability that we require to >> make the tracker useful. While they may be able to support some of the >> features we need with a bit of coding, I don't think anyone has the time >> to do this, and so a more well established tracker with a larger set of >> features available out of the box would probably be better. >> > > Whats wrong with using google to do a web search? Mailman itself doesn't > provide any search functionality anyway, unless it just hasn't been > enabled for the cellml.org mailing lists, so searching the mail archives > requires the use of one of the other list archive sites, and I'd imagine > hooking a gmane search into the plone search would be easier to achieve > than replacing all the existing trackers. > I agree that using public index tools means that we don't really need to worry about search integration between the trackers and the site (which was really the only reason for sticking with the Plone-based ones). > >> I would recommend Bugzilla (Randall also mentioned JIRA, but it seems to >> be a commercial product, and price aside, if we can't review the tracker >> source code I'm not sure we should trust it with our data). >> > > you're kidding, right? Do you usually scour the source code of every > application you use before you trust it with your data? I don't always do this personally, but if it is a major Free / Open Source project I know someone will have. > While I agree > that an open source solution would be best, I think a better argument > might be required :-) > > So while I'm not against changing to new trackers I have yet to see > enough evidence to justify rerouting resources from model repository > developments to changing the trackers. Of course, if the resource is > available and different trackers can be accessed on a test server, then > I think it would be valuable to try out some of Andrew's ideas and see > how it all works in practice. > Just to put it in perspective, I set up a Bugzilla tracker for my PhD within two hours (from getting the source code, setting up the schemas, setting up the Bugzilla through to submitting a bug), and my PhD Bugzilla is more complicated than most, and that was without any previous expertise in Bugzilla administration. Contrast this with all the time that we all spend trying to piece together posts with mailing lists, and I think this will pay itself off quite fast. Best regards, Andrew _______________________________________________ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
