David Nickerson wrote: > Hi Randall, > > Two quick points. PCEnv is an Auckland tool and as discussed previously > it should be kept quite distinct from the community sections of > cellml.org - i.e., there shouldn't be a common tracker for PCEnv and the > specifications and cellml.org etc. > I think as the repository, the CellML specification, and PCEnv as three CellML-related projects which are available to the community.
They each have their own decision making processes associated with them, and the decision-making process for PCEnv favours the allocation of resources towards features that benefit users at the Bioengineering Institute. There are also other projects not run from Auckland that are related to CellML, which again have their own decision-making process. I think that it is appropriate to have one bug-tracker which holds issues (features, proposals, bug reports) for any CellML-related project. We could create the categories for tools at the author's request. As long as tracker categories are used to separate everything, I don't see there being a major problem in putting things in one tracker - after all, an issue that someone raises with PCEnv might actually be a specification or CellML API issue. > Secondly, Matt and I have been looking into the use of the Plone > Software Centre for dealing with the core CellML projects > (specifications, model repository(s), and API). While not perfect this > seems a good way to start collecting proposals and turning them into > actual action items in associated trackers. While this effort has kind > of stalled as things like the test server and python/plone upgrades are > happening, you can see an initial start at > http://www.cellml.org/Members/andre/andre-s-test-cellml-centre/. If > you're looking into this sort if thing (or anyone else out there) it > would be great if you can have a play around in there and let us know > what your thoughts are. > A few comments on the technology: 1) I don't like the idea of separating proposals and issues from each other, because it is a blurry line. I would prefer that there be a single unit (lets call it an issue), with dependencies between an issue. A complex issue could then depend on other issues which make up the smaller 'actual action items' needed to resolve the issue, while simple issues might not need this. Using a bugtracker that supports this, such as Bugzilla, would also make it possible to follow links between the issues. 2) A CC list allowing you to follow an issue would be useful (see for example, the CC list in Bugzilla). 3) The interface where you can type formatted changes to the proposal into the document is good, but I don't think the change history is very useful because it doesn't show all changes (c.f. the Bugzilla process, where you create attachments for the proposal, which could either be a document or a specific patch, and you comment about that, and keep a record of which attachments are obsolete). It would also be good to be able to have several competing proposals up and lump them together by the same motivation, and then merge them, with ability to track what is going on. 4) I'm not sure how configurable, but I don't think that the Plone 'proposed by, seconded by' process will fit for all our projects. Also, whatever flagging method we do use, I think it should be primarily associated with proposals and not with issues / motivations, if there are several proposals for the same motivation. 5) There seem to be some technical issues with it, as it is giving me URLs like http://localhost:11080/cellml/Members/andre/andre-s-test-cellml-centre/cellml/roadmap/5/#motivation All in all, I would vote that we go with something a bit more mature with the usability issues sorted out, like Bugzilla, rather than Plone Software Centre, Poi, or PCNG. Best regards, Andrew _______________________________________________ cellml-discussion mailing list [email protected] http://www.cellml.org/mailman/listinfo/cellml-discussion
