CellML Discussion List

Text archives Help


[cellml-discussion] CellML tracker


Chronological Thread 
  • From: david.nickerson at nus.edu.sg (David Nickerson)
  • Subject: [cellml-discussion] CellML tracker
  • Date: Wed, 27 Jun 2007 10:03:19 +0800

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 much
prefer to have one place to look (my inbox) and use my tool of
preference to filter that as I see fit.

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.
While I can still see many flaws in such an approach, it might work out
ok in most cases.

> 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.

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.

> 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 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? 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.


Andre.




Archive powered by MHonArc 2.6.18.

Top of page