Re: [cellml-discussion] Concerning the CellML Model Repository

2007-06-26 Thread Tommy Yu
David Nickerson wrote:
 Hi Tommy,
 
 That looks good - its all starting to make sense to me now.
 
 I'm just wondering how your system would handle a case where two authors 
 independently encode the same published model. The first author to 
 upload their encoding would get ownership of the publication alias (if 
 I have the terminology right). Is there any way for the second author to 
 get a similar alias to their encoding of the model? This is starting to 
 sound like a version/variant theme, but its probably a situation that 
 will crop up quite frequently...

I guess it depends on how those two model creators work.  If John and Mary work 
independently and two different models describing the same item were created, 
each will need have separate project directories.  If John did get the 
publication alias set up first it would obviously point to his model, but now 
Mary comes along and wants to have a separate model up also.  What could happen 
is this:

1) Publication alias is no longer an alias, but a directory holding aliases to 
users' models.
2) New model directory is created.  John and Mary's model directory is copied 
into there.

While outcome is similar, 1) separates publications from models a lot more, may 
reflect this situation when a paper with multiple models with each created by 
different people:

John, Mary and Ming creates on models a, b, c based on Doe's paper.  All three 
gets approved, and repos://publication/doe_2007_1/ is created containing 

repos://publication/doe_2007_1/pathway_a - repos://!rev/45/home/john/a
repos://publication/doe_2007_1/pathway_b - repos://!rev/60/home/mary/b
repos://publication/doe_2007_1/pathway_c - repos://!rev/54/home/ming/c

created by their respective creators.  Each published model is treated 
differently, note their revision numbers.

2) has the benefit of encouraging model creators to work together, groups the 
same models in one place, and may reflect this situation:

A publication that describes multiple models with different people coding up 
each one could have a shared UUID named workspace, owned by the people working 
on it, with each separate models in its own directory.  The publication alias 
could be owned by the whole group that worked on the model.

I just flushed this out of my head, both of these suggestions may have very 
interesting consequences that is not noted here.

This was a very good question.

 
 This is a slightly different example from your example workflow and 
 could be viewed as John and Mary both having valid and correct but 
 different encodings of the doe_2007_1 paper. Actually, I just saw the 
 '_1' on the publication link - is that some kind of version/variant that 
 would be _2 for Mary in my example? I had been assuming the 2007_1 meant 
 January 2007.
 

It could conceivably mean the first paper John Doe published in 2007, or 
January, as that haven't been decided yet.

Thanks,
Tommy.

 
 Thanks,
 Andre.
 
 Tommy Yu wrote:
 Hi,

 I thought Andrew's ideas here is worth expanding, and I wrote a page based 
 on that.

 http://www.cellml.org/Members/tommy/BaseRepository

 Cheers,
 Tommy.
 
 ___
 cellml-discussion mailing list
 cellml-discussion@cellml.org
 http://www.cellml.org/mailman/listinfo/cellml-discussion

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


Re: [cellml-discussion] Concerning the CellML Model Repository

2007-06-26 Thread Matt
I don't understand the purpose of this.

It looks like you are inventing a versioning system to implement from scratch.

I don't see how this system would work with someone working on a
filesystem and not wanting to use a browser - you'd have to invent
client software for this.

Start by reviewing things like:

subversion
svk
darcs
monotone
arch
etc

Review them in the context of the use-cases that need to be satisfied.

Include use-cases such as someone working on a complex model that uses
imports of models in a local space. Include use-cases of someone
wanting to follow volatile vs non-volatile versions/branches, etc.

Include the environments from which you expect this versioning system
to work (e.g. commands on a filesystem, webdav, etc).

What are the kinds of relationships between permissions and roles. I
know you have some ideas here, but it's not very replete and perhaps
needs to be put in a table.

I think aliases in for web URIs are the least of the problems at the moment.

On 6/26/07, Tommy Yu [EMAIL PROTECTED] wrote:
 Hi,

 I thought Andrew's ideas here is worth expanding, and I wrote a page based on 
 that.

 http://www.cellml.org/Members/tommy/BaseRepository

 Cheers,
 Tommy.



 Andrew Miller wrote:
  Matt wrote:
  - Version/Variant
  It already clogged up the system.  There is no proper revision control 
  mechanism, what we have now is an ad-hoc emulated system.
 
  I don't think it has clogged the system I just think it has been
  improperly used both by authors and by the user interface. This is no
  fault of the authors, there is simply a specification for versioning
  that is missing. The hope is that subversion applies well to this.
 
  I think that the versioning system itself is the root of the problem,
  because it is simultaneously too complicated and too limited.
 
  In particular:
  Branching is inherently a hierarchical process with arbitrary depth, in
  the sense that branches can be made from branches to an arbitrary depth.
  However, the variant / version system does not really provide the proper
  tools to deal with this, because it is limited to two levels (variant
  and version) before its utility in tracking what is a derivative of what
  is exhausted.
 
  It is also inadequate because a new model might combine parts of other
  models, especially if it is a 1.1 model, and these parts need to be
  tracked individually.
 
  I think that the solution is to simplify down to a single global version
  number that is common across the repository or the model (like in
  Subversion), and then let either the CellML metadata, or perhaps the
  Subversion copy history, describe the way a model has been derived.
 
  I see the following workflow as being both simpler and more general...
 
  John Doe creates a new model directory which has its primary URL at:
  http://www.cellml.org/models/id/0ff280ef-dce6-4a42-a275-c9a7d9699096/
 
  John now owns this model and is the only one who can change it. John
  also gets to decide the visibility of different revisions of the model.
 
  John makes several revisions to the model (each of which bumps the
  global revision number). There is a URL by which each historic version
  can be referred to.
 
  John then publishes the model in a journal, referring to it by the
  primary URL (or perhaps a short-form if we want to offer authors the
  option of assigning one). After the paper is accepted by a peer-reviewed
  journal, John updates the metadata on the model. When he commits these
  changes, the repository sees this and creates a new alias, e.g. at:
  http://www.cellml.org/models/citation/doe_2007_1/
 
  John makes some further changes to his model post-publication and
  commits them. However, by some mechanism (perhaps by the change
  metadata?) the repository knows that this is a change which occurred
  post-publication by John.
 
  Mary notices that there was a discrepancy between the model and John's
  published paper (assuming that he didn't reference the CellML model in
  the paper). She creates a new primary URL containing a copy of John's
  published model, at:
  http://www.cellml.org/models/id/281ab697-4607-4fcf-a433-f3ec382fb445/
  She gets John to check this. When John agrees, she updates the metadata
  on her model to indicate that her version is a more correct version of
  John's paper. The repository then updates so that
  http://www.cellml.org/models/citation/doe_2007_1/ is a reference to
  John's fixed version.
 
  John merges in Mary's changes to
  http://www.cellml.org/models/id/0ff280ef-dce6-4a42-a275-c9a7d9699096/
  and continues working on more changes. He starts collaborating with
  Mary, so he grants her write access to
  http://www.cellml.org/models/id/0ff280ef-dce6-4a42-a275-c9a7d9699096/.
 
  Ming wants to create a derivative of John's paper, so he creates a copy
  of the revision referenced from
  http://www.cellml.org/models/citation/doe_2007_1/ at
  

Re: [cellml-discussion] Concerning the CellML Model Repository

2007-06-26 Thread Tommy Yu
Matt wrote:
 I don't understand the purpose of this.
 
 It looks like you are inventing a versioning system to implement from scratch.
 

That's what it looks like, but if you recall the software choices I have 
written down I have been considering them, and have been going through the 
features they offer that would be of use to us.  I am being agnostic to 
software right here, as someone would like me to stay away from underlying 
pieces at the moment.  I am conveying a generic concept of a repository in the 
context of CellML model development, outlining possible hints to what may be 
best practices.

 I don't see how this system would work with someone working on a
 filesystem and not wanting to use a browser - you'd have to invent
 client software for this.
 
 Start by reviewing things like:
 
 subversion
 svk
 darcs
 monotone
 arch
 etc
 

I did, I already suggested to use Subversion as a possible backend (I also 
reviewed how GIT might be a reasonable choice if we proxy remote repositories), 
possibly a RDBMS to help with the relationship aspect of models, and Plone/Zope 
for the workflow states and presentation front-end via WWW.

 Review them in the context of the use-cases that need to be satisfied.
 
 Include use-cases such as someone working on a complex model that uses
 imports of models in a local space. Include use-cases of someone
 wanting to follow volatile vs non-volatile versions/branches, etc.
 

If a model builder develops their models in their local space they could import 
items from within their projects via relative paths (no different than working 
locally on their storage device).  If they rely on other models they could 
import a specific frozen version of a model, or the development version, from 
the repository.  Volatile versions are provided for anyone who need it.

 Include the environments from which you expect this versioning system
 to work (e.g. commands on a filesystem, webdav, etc).
 

If it's subversion someone could do a svn ci or use their GUI clients to update 
models.  They could also update via WWW.

 What are the kinds of relationships between permissions and roles. I
 know you have some ideas here, but it's not very replete and perhaps
 needs to be put in a table.
 

They will be put on the table.

 I think aliases in for web URIs are the least of the problems at the moment.
 
 On 6/26/07, Tommy Yu [EMAIL PROTECTED] wrote:
 Hi,

 I thought Andrew's ideas here is worth expanding, and I wrote a page based 
 on that.

 http://www.cellml.org/Members/tommy/BaseRepository

 Cheers,
 Tommy.



 Andrew Miller wrote:
 Matt wrote:
 - Version/Variant
 It already clogged up the system.  There is no proper revision control 
 mechanism, what we have now is an ad-hoc emulated system.

 I don't think it has clogged the system I just think it has been
 improperly used both by authors and by the user interface. This is no
 fault of the authors, there is simply a specification for versioning
 that is missing. The hope is that subversion applies well to this.

 I think that the versioning system itself is the root of the problem,
 because it is simultaneously too complicated and too limited.

 In particular:
 Branching is inherently a hierarchical process with arbitrary depth, in
 the sense that branches can be made from branches to an arbitrary depth.
 However, the variant / version system does not really provide the proper
 tools to deal with this, because it is limited to two levels (variant
 and version) before its utility in tracking what is a derivative of what
 is exhausted.

 It is also inadequate because a new model might combine parts of other
 models, especially if it is a 1.1 model, and these parts need to be
 tracked individually.

 I think that the solution is to simplify down to a single global version
 number that is common across the repository or the model (like in
 Subversion), and then let either the CellML metadata, or perhaps the
 Subversion copy history, describe the way a model has been derived.

 I see the following workflow as being both simpler and more general...

 John Doe creates a new model directory which has its primary URL at:
 http://www.cellml.org/models/id/0ff280ef-dce6-4a42-a275-c9a7d9699096/

 John now owns this model and is the only one who can change it. John
 also gets to decide the visibility of different revisions of the model.

 John makes several revisions to the model (each of which bumps the
 global revision number). There is a URL by which each historic version
 can be referred to.

 John then publishes the model in a journal, referring to it by the
 primary URL (or perhaps a short-form if we want to offer authors the
 option of assigning one). After the paper is accepted by a peer-reviewed
 journal, John updates the metadata on the model. When he commits these
 changes, the repository sees this and creates a new alias, e.g. at:
 http://www.cellml.org/models/citation/doe_2007_1/

 John makes some further changes to his model 

Re: [cellml-discussion] Concerning the CellML Model Repository

2007-06-26 Thread Matt
On 6/26/07, Tommy Yu [EMAIL PROTECTED] wrote:
 Matt wrote:
  I don't understand the purpose of this.
 
  It looks like you are inventing a versioning system to implement from 
  scratch.
 

 That's what it looks like, but if you recall the software choices I have 
 written down I have been considering them, and have been going through the 
 features they offer that would be of use to us.  I am being agnostic to 
 software right here, as someone would like me to stay away from underlying 
 pieces at the moment.  I am conveying a generic concept of a repository in 
 the context of CellML model development, outlining possible hints to what may 
 be best practices.


I was meaning to look at these other projects to look at the use-cases
they solve. It seems like you are reinventing them from the beginning
starting at the lowest level of a database identifier. Look at the
problems these systesm are trying to solve, and compare it to CellML
models.



  I don't see how this system would work with someone working on a
  filesystem and not wanting to use a browser - you'd have to invent
  client software for this.
 
  Start by reviewing things like:
 
  subversion
  svk
  darcs
  monotone
  arch
  etc
 

 I did, I already suggested to use Subversion as a possible backend (I also 
 reviewed how GIT might be a reasonable choice if we proxy remote 
 repositories), possibly a RDBMS to help with the relationship aspect of 
 models, and Plone/Zope for the workflow states and presentation front-end via 
 WWW.

And the next line below here says review them in the context of the use-cases.


  Review them in the context of the use-cases that need to be satisfied.
 
  Include use-cases such as someone working on a complex model that uses
  imports of models in a local space. Include use-cases of someone
  wanting to follow volatile vs non-volatile versions/branches, etc.
 

 If a model builder develops their models in their local space they could 
 import items from within their projects via relative paths (no different than 
 working locally on their storage device).  If they rely on other models they 
 could import a specific frozen version of a model, or the development 
 version, from the repository.  Volatile versions are provided for anyone who 
 need it.

So write them out as examples, i.e. what their local filesystem looks
like for that particular project, what the import URIs look like, and
the commands they use to manipulate versions/branches/etc of this.

What does it mean to want to follow a volatile version ? - what are
the implications of this ? - do changesets make sense in such
contexts?


  Include the environments from which you expect this versioning system
  to work (e.g. commands on a filesystem, webdav, etc).
 

 If it's subversion someone could do a svn ci or use their GUI clients to 
 update models.  They could also update via WWW.

Not the actual commands ... just the environments/contexts that are
important. For example, is it important for someone to be able to
start a project on a local filesystem and add it to the repository -
what conditions are necessary for various roles to add something to
the repository.


  What are the kinds of relationships between permissions and roles. I
  know you have some ideas here, but it's not very replete and perhaps
  needs to be put in a table.
 

 They will be put on the table.

In a table. Something readable.


  I think aliases in for web URIs are the least of the problems at the moment.
 
  On 6/26/07, Tommy Yu [EMAIL PROTECTED] wrote:
  Hi,
 
  I thought Andrew's ideas here is worth expanding, and I wrote a page based 
  on that.
 
  http://www.cellml.org/Members/tommy/BaseRepository
 
  Cheers,
  Tommy.
 
 
 
  Andrew Miller wrote:
  Matt wrote:
  - Version/Variant
  It already clogged up the system.  There is no proper revision control 
  mechanism, what we have now is an ad-hoc emulated system.
 
  I don't think it has clogged the system I just think it has been
  improperly used both by authors and by the user interface. This is no
  fault of the authors, there is simply a specification for versioning
  that is missing. The hope is that subversion applies well to this.
 
  I think that the versioning system itself is the root of the problem,
  because it is simultaneously too complicated and too limited.
 
  In particular:
  Branching is inherently a hierarchical process with arbitrary depth, in
  the sense that branches can be made from branches to an arbitrary depth.
  However, the variant / version system does not really provide the proper
  tools to deal with this, because it is limited to two levels (variant
  and version) before its utility in tracking what is a derivative of what
  is exhausted.
 
  It is also inadequate because a new model might combine parts of other
  models, especially if it is a 1.1 model, and these parts need to be
  tracked individually.
 
  I think that the solution is to simplify down to a single global version
  

Re: [cellml-discussion] Concerning the CellML Model Repository

2007-06-26 Thread Matt
This is my view of where things should be heading:

The main impetus for this thread is moving the cellml.org site
forward. In this sense I would like to see a description of what it
currently does and what features have been informally slated.

Then I'd like to see a document that re-writes these out as use-cases
that don't depend on technology (but can certainly borrow ideas from
various technologies).

A large part of this are the cellml.org use-cases around the use of
metadata in the models.

While the underlying implementation of the repository is something to
discuss, I think that it is a red herring at the moment. The issues
seems more to do with various use-cases being difficult to represent
in the current style of model naming and the difficulty of reflecting
someone's local filesystem workflow/layout. I think there is too much
of a rush to solve the repository issue quickly based on these
idiosyncrasies of the cellml.org model naming problem.

Some(!!)  considerations:

- how is a modelers local workspace organized? e.g. we have talked
about the possible need for a manifest file; the possibility of
metadata sitting separate from the model itself; etc. Is the idea of a
workspace appropriate? Would people have multiple workspaces, say one
for each model, or one workspace for all their models, or both?

- do people want to use a single central repository? Or should they be
able to work independently in their own instance of a repository and
perhaps at some point transfer their project to another one?

- there has been an assumption that the base unit stored in a
repository should be a cellml/xml model - why is this? check the
reasons why this is believed to be the way it should be.

- don't try to figure out the URI scheme right now - even in use
cases. The only attention to URI will be the bahviour it might exhibit
in the modeling process: for example, you want someone to be able to
move from tracking a volatile branch of a model in their imports to a
stable one (that's all you have to say, not what the URIs might look
like).

- don't attach specific technologies to the repository system until
the use-case space has been filled out

The evolution of the repository is a non-small task (it's actually
someone's PhD topic). So once there is a pretty certain idea of what
the repository may be, then how does the current system in the plone
site sit with respect to this? Are there technologies that take us a
step closer that could be weaved into the current product? etc..

What are the priorities for cellml.org?
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


[cellml-discussion] Tracker for Roadmap

2007-06-26 Thread Randall Britten
Hi

At last week's meeting, we listed some items for the updated roadmap for 
PcEnv.  The existing roadmap/milestones list is quite out of date.

I am considering using the PcEnv tracker to manage this list, in the 
hope that as features are implemented, they will be marked as resolved 
in the tracker, facilitating keeping the list up to date.

This approach could also be used for the other roadmaps, e.g. 
repository, specifications, general cellml site etc.

In my experience on previous projects, using some form of tracker for 
roadmaps works well.

Although PloneCollectorNG seems inferior (in my opinion) to other 
trackers (e.g. Jira), it has the advantage that it is integrated into 
the rest of the site.  So, in the interest of taking small steps, I 
think we should stick with it for now.

Your feedback would be appreciated. Thanks.

Regards,
Randall

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


Re: [cellml-discussion] Tracker for Roadmap

2007-06-26 Thread David Nickerson
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.

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.


Andre.


Randall Britten wrote:
 Hi
 
 At last week's meeting, we listed some items for the updated roadmap for 
 PcEnv.  The existing roadmap/milestones list is quite out of date.
 
 I am considering using the PcEnv tracker to manage this list, in the 
 hope that as features are implemented, they will be marked as resolved 
 in the tracker, facilitating keeping the list up to date.
 
 This approach could also be used for the other roadmaps, e.g. 
 repository, specifications, general cellml site etc.
 
 In my experience on previous projects, using some form of tracker for 
 roadmaps works well.
 
 Although PloneCollectorNG seems inferior (in my opinion) to other 
 trackers (e.g. Jira), it has the advantage that it is integrated into 
 the rest of the site.  So, in the interest of taking small steps, I 
 think we should stick with it for now.
 
 Your feedback would be appreciated. Thanks.
 
 Regards,
 Randall
 
 ___
 cellml-discussion mailing list
 cellml-discussion@cellml.org
 http://www.cellml.org/mailman/listinfo/cellml-discussion

-- 
David Nickerson, PhD
Research Fellow
Division of Bioengineering
Faculty of Engineering
National University of Singapore
Email: [EMAIL PROTECTED]
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


[cellml-discussion] Proposal: Local CellML team e-mail addresses

2007-06-26 Thread Andrew Miller
Hi,

There has been some discussion recently about how best to handle local 
CellML addresses (which can be used by local groups with an interest in 
CellML to arrange meetings and hold other discussions which are purely 
local in scope and not of interest to the broader CellML community).

At the University of Auckland, we have a list for the Auckland CellML 
team. However, I feel that some of the discussion on that list would 
probably better occur on the cellml-discussion mailing list (or another 
more public forum). After discussing this at our Auckland CellML group 
meeting, it was suggested that perhaps similar issues are arising at 
other localised groups working on CellML. To this end, we came up with a 
rough proposal (which I expand on below) which I hope will help both the 
Auckland group and other groups using CellML to collaborate.

Please note that this is just a proposal, and I would welcome feedback 
on how we can improve it. I would be especially interested to hear 
opinions from other groups outside Auckland using CellML.

Proposal:

1) Groups can request location@cellml.org mailing lists.
  a) Any group which is working on a CellML related project may [follow 
some procedure which needs to be decided] to request a mailing list for 
discussion of location specific matters related to their CellML project.
  b) The e-mail address requested shall follow the format 
location@cellml.org, where location is replaced with a short word, 
phrase, or abbrevation which describes the geographical location of the 
group concerned.
  c) The location name should be sufficient to uniquely distinguish the 
group from other separate groups that may wish to work on CellML. List 
names are subject to review to ensure that they are unlikely to conflict 
with another group or cause confusion.

2) Location-specific mailing lists to have open membership and be 
publicly archived.
  a) Any person may join any location-specific mailing list without 
moderator approval, regardless of their actual geographic location.
  b) All location-specific mailing lists shall have a publicly readable 
archive, hosted at cellml.org.

3) Scope and posting rules for location-specific mailing lists.
  a) All messages posted to location-specific mailing lists must be 
related in some way to CellML, or to tools which process CellML, or to 
the operation of groups with an interest in CellML. Some degree of 
leeway should be afforded by cellml.org administrators here, as long as 
the list is not being used as a free hosting service for work not even 
vaguely related CellML.
  b) Message posters are strongly encouraged to send messages which may 
be of broader interest to the cellml-discussion list rather than to the 
location-specific address.
  c) The location-specific mailing lists must not be used for 
information which is of a private or confidential nature (after all, it 
is an open membership list with a public archive).
  d) All posters to location-specific mailing lists agree that their 
messages may be further distributed (with attribution to them), 
including by forwarding to the cellml-discussion list or by inclusion in 
public bug-trackers (and also agree to the translation of their messages 
into another language).
  e) The location-specific groups may establish their own additional 
posting rules by their normal decision-making process, as long as these 
posting rules do not conflict with the general rules described here. 
These posting rules may include (without limitation) the scope of the 
list, who is allowed to post to the list (but not who can subscribe) and 
how often, and the permitted language(s) of any posts to the list.

4) Administration and moderation of location-specific mailing lists.
  a) Each location-specific group shall determine their own process for 
the control of their own mailing lists, and their nominated 
administrator will be provided with a password allowing them access to 
the administrative interface.
  b) Group designated administrators are free to change the settings of 
the groups location-specific CellML mailing list (after changes are 
approved through the appropriate local decision-making processes). 
However, they must not make changes which cause the mailing list 
archives to be no longer public, or which cause the list to require 
moderator approval before allowing subscriptions.
  c) Group designated administrators may also (in accordance with 
locally determined policies) subscribe and remove people from their 
mailing lists are a service to the person being added or removed. 
Administrators may infer that a person wishes to be added or removed 
from the mailing list if they are visiting / commencing employment or 
leaving the group respectively. However, administrators may not add or 
remove any person from the mailing list who does not wish to be added or 
removed, as this would prevent the list from being open membership.
  d) Group designated administrators may (in accordance 

Re: [cellml-discussion] Tracker for Roadmap

2007-06-26 Thread Andrew Miller
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
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


Re: [cellml-discussion] CellML tracker

2007-06-26 Thread David Nickerson
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 

Re: [cellml-discussion] Proposal: Local CellML team e-mail addresses

2007-06-26 Thread Andrew Miller
David Nickerson wrote:
 Hi Andrew,

 I think this is an excessive response to a very minor problem. I very 
 easily see this evolving into many separate and distinct local 
 communities with little interaction.
The intention is that these lists only be used for messages like 'There 
is a meeting on Level 6 at 10:00 am on Tuesday this week', or 'The 
recently announced release can be run by on Linux by local users from 
/people/blah/binaries/myprog', rather than significant CellML related 
issues, and that is the goal of my guideline.

I think that there are already very separate and distinct local 
communities (we hardly ever hear from many of the communities who are 
working on CellML), and the idea is that by acknowledging this and 
providing an archived, open resource for local discussions with an 
encouragement to send non-local messages to the more general list, we 
can actively build stronger community interactions.

  For the same reasons we removed the 
 cellml-tools mailing list, I would very much like to see 
 cellml-discussion remain as the only public forum for discussing CellML 
 related issues, until such time as we decide that the list is being 
 flooded with too many emails on one topic and we separate that topic off 
 onto its own mailing list. I have yet to see any need for this.
   
Although a lot of messages currently get sent directly to interested 
recipients to avoid flooding the list, and moving these onto a local 
list would cause them to be archived.
 The idea of the team-cellml mailing list was for discussion amongst the 
 original Auckland team on issues relating to the underlying functioning 
 of the CellML project and a place to debate decisions when consensus 
 could not be achieved amongst the wider CellML community.
  The 
 [EMAIL PROTECTED] mailing list would not serve this purpose.
   
I don't think that we need a separate mailing list for this, because 
there is no need to tie decision making processes to the mailing list.

The process for developing a given resource is ultimately determined by 
whoever funds that resource, and the people who make the final decision 
can do so on the basis of discussions (which may include them) on the 
list. I don't see any need for a second mailing list for this.

 Andre.



 Andrew Miller wrote:
   
 Hi,

 There has been some discussion recently about how best to handle local 
 CellML addresses (which can be used by local groups with an interest in 
 CellML to arrange meetings and hold other discussions which are purely 
 local in scope and not of interest to the broader CellML community).

 At the University of Auckland, we have a list for the Auckland CellML 
 team. However, I feel that some of the discussion on that list would 
 probably better occur on the cellml-discussion mailing list (or another 
 more public forum). After discussing this at our Auckland CellML group 
 meeting, it was suggested that perhaps similar issues are arising at 
 other localised groups working on CellML. To this end, we came up with a 
 rough proposal (which I expand on below) which I hope will help both the 
 Auckland group and other groups using CellML to collaborate.

 Please note that this is just a proposal, and I would welcome feedback 
 on how we can improve it. I would be especially interested to hear 
 opinions from other groups outside Auckland using CellML.

 Proposal:
 
 1) Groups can request location@cellml.org mailing lists.
   a) Any group which is working on a CellML related project may [follow 
 some procedure which needs to be decided] to request a mailing list for 
 discussion of location specific matters related to their CellML project.
   b) The e-mail address requested shall follow the format 
 location@cellml.org, where location is replaced with a short word, 
 phrase, or abbrevation which describes the geographical location of the 
 group concerned.
   c) The location name should be sufficient to uniquely distinguish the 
 group from other separate groups that may wish to work on CellML. List 
 names are subject to review to ensure that they are unlikely to conflict 
 with another group or cause confusion.

 2) Location-specific mailing lists to have open membership and be 
 publicly archived.
   a) Any person may join any location-specific mailing list without 
 moderator approval, regardless of their actual geographic location.
   b) All location-specific mailing lists shall have a publicly readable 
 archive, hosted at cellml.org.

 3) Scope and posting rules for location-specific mailing lists.
   a) All messages posted to location-specific mailing lists must be 
 related in some way to CellML, or to tools which process CellML, or to 
 the operation of groups with an interest in CellML. Some degree of 
 leeway should be afforded by cellml.org administrators here, as long as 
 the list is not being used as a free hosting service for work not even 
 vaguely related CellML.
   b) Message posters are strongly encouraged to send 

Re: [cellml-discussion] CellML tracker

2007-06-26 Thread Andrew Miller
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 

Re: [cellml-discussion] Proposal: Local CellML team e-mail addresses

2007-06-26 Thread David Nickerson
Andrew Miller wrote:
 David Nickerson wrote:
 Hi Andrew,

 I think this is an excessive response to a very minor problem. I very 
 easily see this evolving into many separate and distinct local 
 communities with little interaction.
 The intention is that these lists only be used for messages like 'There 
 is a meeting on Level 6 at 10:00 am on Tuesday this week', or 'The 
 recently announced release can be run by on Linux by local users from 
 /people/blah/binaries/myprog', rather than significant CellML related 
 issues, and that is the goal of my guideline.

what is the benefit of a public archive of such messages?

 I think that there are already very separate and distinct local 
 communities (we hardly ever hear from many of the communities who are 
 working on CellML), and the idea is that by acknowledging this and 
 providing an archived, open resource for local discussions with an 
 encouragement to send non-local messages to the more general list, we 
 can actively build stronger community interactions.

Perhaps some examples of these local communities you envision might 
help? The ones that I know about that you might be referring to are (and 
the groups involved):

- The integration of CellML with JSim (Washington, Singapore, Auckland)
- The use of the CellML API in non-Auckland based tools (Kyoto, Osaka, 
Oxford, Singapore, Auckland)
- Model curation (the definition of level 4 curation) (Washington, 
Wisconsin, Oxford, Singapore, Auckland)

and probably others that I can't recall. Not sure how your idea of local 
communities would address these, and given the effort I have put into 
getting these discussion on the cellml-discussion mailing list, with 
little success, I don't see anything changing in the future.

  For the same reasons we removed the 
 cellml-tools mailing list, I would very much like to see 
 cellml-discussion remain as the only public forum for discussing CellML 
 related issues, until such time as we decide that the list is being 
 flooded with too many emails on one topic and we separate that topic off 
 onto its own mailing list. I have yet to see any need for this.
   
 Although a lot of messages currently get sent directly to interested 
 recipients to avoid flooding the list, and moving these onto a local 
 list would cause them to be archived.

as above, I'm not sure who your target is other than the Auckland group? 
and how you would get these personal discussions to take place on a 
publicly archived mailing list? and if you can achieve this it would be 
much more beneficial to the community to have them moved onto the 
cellml-discussion list rather than a local one.

 The idea of the team-cellml mailing list was for discussion amongst the 
 original Auckland team on issues relating to the underlying functioning 
 of the CellML project and a place to debate decisions when consensus 
 could not be achieved amongst the wider CellML community.
  The 
 [EMAIL PROTECTED] mailing list would not serve this purpose.
   
 I don't think that we need a separate mailing list for this, because 
 there is no need to tie decision making processes to the mailing list.
 
 The process for developing a given resource is ultimately determined by 
 whoever funds that resource, and the people who make the final decision 
 can do so on the basis of discussions (which may include them) on the 
 list. I don't see any need for a second mailing list for this.

This is true and suitable for particular locally-based and driven 
resources (such as PCEnv). But for the larger community to succeed, 
there needs to be at some level a governing body of some kind that 
ensures (as best as possible within the constraints of time and money) 
that the project continues to progress with some consistency. The three 
community resources that I would see governed by such a body are the 
specifications (CellML and metadata), the model repository, and the API. 
But I think this is a different topic and not relevant to this discussion.


Andre.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


Re: [cellml-discussion] CellML tracker

2007-06-26 Thread Randall Britten


Andrew Miller wrote:
 Hi,
...
 
 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).

Jira provide their source code (surprising as that may be).
Jira is provided to open source projects free-of-charge.

Note: I'm just clarifying those two points.  I'm not in favour of any 
particular tracker, just the one that we all agree is the best one for 
the job.  I mention those two as starting points in our search.

I have set up the trial version of Jira on http://bioeng123:8080, for 
those here in the institute.  You could download and setup the trial 
yourself if you can't access that.  Alternatively, look at some well 
known open source projects that use Jira, e.g. JBoss 
(http://jira.jboss.com/jira/) and some others on 
http://jira.codehaus.org/.  There are more, linked from the Jira site.

Michael Dunstan just suggested Trac and Poi as being worth looking 
at too.


___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


Re: [cellml-discussion] Proposal: Local CellML team e-mail addresses

2007-06-26 Thread Andrew Miller
David Nickerson wrote:
 Andrew Miller wrote:
   
 David Nickerson wrote:
 
 Hi Andrew,

 I think this is an excessive response to a very minor problem. I very 
 easily see this evolving into many separate and distinct local 
 communities with little interaction.
   
 The intention is that these lists only be used for messages like 'There 
 is a meeting on Level 6 at 10:00 am on Tuesday this week', or 'The 
 recently announced release can be run by on Linux by local users from 
 /people/blah/binaries/myprog', rather than significant CellML related 
 issues, and that is the goal of my guideline.
 

 what is the benefit of a public archive of such messages?
   
1) It makes it much easier for people to refer back to what has happened 
in the past, and makes it possible to search these messages using a 
search engine.
2) It helps to stop people from using the list as a 'private' list 
rather than a 'local' list, and so opens up the CellML community to new 
participants a lot more. Obviously, we can't stop people having private 
discussions if they want to do so, but providing a non-private forum for 
local discussions will hopefully help everyone to get a better idea at 
what other groups are doing.
3) It provides outsiders to a given local group the ability to search 
other groups without being flooded.

   
 I think that there are already very separate and distinct local 
 communities (we hardly ever hear from many of the communities who are 
 working on CellML), and the idea is that by acknowledging this and 
 providing an archived, open resource for local discussions with an 
 encouragement to send non-local messages to the more general list, we 
 can actively build stronger community interactions.
 

 Perhaps some examples of these local communities you envision might 
 help? The ones that I know about that you might be referring to are (and 
 the groups involved):

 - The integration of CellML with JSim (Washington, Singapore, Auckland)
 - The use of the CellML API in non-Auckland based tools (Kyoto, Osaka, 
 Oxford, Singapore, Auckland)
 - Model curation (the definition of level 4 curation) (Washington, 
 Wisconsin, Oxford, Singapore, Auckland)

 and probably others that I can't recall. Not sure how your idea of local 
 communities would address these, and given the effort I have put into 
 getting these discussion on the cellml-discussion mailing list, with 
 little success, I don't see anything changing in the future.
   
Don't forget the current local group (auckland@). I think that it is 
important that if we are to increase the community participation of the 
CellML project from outside of Auckland, we must move away from treating 
the Auckland group as special, so if we set up an auckland@ list, we 
really need to offer other groups the ability to do the same on equal 
terms (even if they don't accept this offer).
   
  For the same reasons we removed the 
 cellml-tools mailing list, I would very much like to see 
 cellml-discussion remain as the only public forum for discussing CellML 
 related issues, until such time as we decide that the list is being 
 flooded with too many emails on one topic and we separate that topic off 
 onto its own mailing list. I have yet to see any need for this.
   
   
 Although a lot of messages currently get sent directly to interested 
 recipients to avoid flooding the list, and moving these onto a local 
 list would cause them to be archived.
 

 as above, I'm not sure who your target is other than the Auckland group? 
 and how you would get these personal discussions to take place on a 
 publicly archived mailing list?
I presume most personal discussions take place because it would be 
inappropriate to flood the main lists with them, rather than because 
there is anything private about them. Hopefully, we can get these 
discussions out into the public just by providing the facilities for 
them to be archived.
  and if you can achieve this it would be 
 much more beneficial to the community to have them moved onto the 
 cellml-discussion list rather than a local one.
   
Unfortunately, the cellml-discussion list already gets so much traffic 
that people are unsubscribing or are reluctant to subscribe.

Perhaps we won't need this proposal if we instead go for the tracker 
based proposal.
   
 The idea of the team-cellml mailing list was for discussion amongst the 
 original Auckland team on issues relating to the underlying functioning 
 of the CellML project and a place to debate decisions when consensus 
 could not be achieved amongst the wider CellML community.
  The 
 [EMAIL PROTECTED] mailing list would not serve this purpose.
   
   
 I don't think that we need a separate mailing list for this, because 
 there is no need to tie decision making processes to the mailing list.

 The process for developing a given resource is ultimately determined by 
 whoever funds that resource, and the people who make the final decision 
 can do 

Re: [cellml-discussion] Proposal: Local CellML team e-mail addresses

2007-06-26 Thread James Lawson
Andrew Miller wrote:
 Hi,
 
 There has been some discussion recently about how best to handle local 
 CellML addresses (which can be used by local groups with an interest in 
 CellML to arrange meetings and hold other discussions which are purely 
 local in scope and not of interest to the broader CellML community).
 

Something I didn't think of before... surely most other groups already
have a mailing list that serves their group's interest anyway... What
would make it worthwhile for them to actually swap over to an official
cellml list?

 At the University of Auckland, we have a list for the Auckland CellML 
 team. However, I feel that some of the discussion on that list would 
 probably better occur on the cellml-discussion mailing list (or another 
 more public forum). After discussing this at our Auckland CellML group 
 meeting, it was suggested that perhaps similar issues are arising at 
 other localised groups working on CellML. To this end, we came up with a 
 rough proposal (which I expand on below) which I hope will help both the 
 Auckland group and other groups using CellML to collaborate.
 
 Please note that this is just a proposal, and I would welcome feedback 
 on how we can improve it. I would be especially interested to hear 
 opinions from other groups outside Auckland using CellML.
 
 Proposal:
 
 1) Groups can request location@cellml.org mailing lists.
   a) Any group which is working on a CellML related project may [follow 
 some procedure which needs to be decided] to request a mailing list for 
 discussion of location specific matters related to their CellML project.
   b) The e-mail address requested shall follow the format 
 location@cellml.org, where location is replaced with a short word, 
 phrase, or abbrevation which describes the geographical location of the 
 group concerned.
   c) The location name should be sufficient to uniquely distinguish the 
 group from other separate groups that may wish to work on CellML. List 
 names are subject to review to ensure that they are unlikely to conflict 
 with another group or cause confusion.
 
 2) Location-specific mailing lists to have open membership and be 
 publicly archived.
   a) Any person may join any location-specific mailing list without 
 moderator approval, regardless of their actual geographic location.
   b) All location-specific mailing lists shall have a publicly readable 
 archive, hosted at cellml.org.
 
 3) Scope and posting rules for location-specific mailing lists.
   a) All messages posted to location-specific mailing lists must be 
 related in some way to CellML, or to tools which process CellML, or to 
 the operation of groups with an interest in CellML. Some degree of 
 leeway should be afforded by cellml.org administrators here, as long as 
 the list is not being used as a free hosting service for work not even 
 vaguely related CellML.
   b) Message posters are strongly encouraged to send messages which may 
 be of broader interest to the cellml-discussion list rather than to the 
 location-specific address.
   c) The location-specific mailing lists must not be used for 
 information which is of a private or confidential nature (after all, it 
 is an open membership list with a public archive).
   d) All posters to location-specific mailing lists agree that their 
 messages may be further distributed (with attribution to them), 
 including by forwarding to the cellml-discussion list or by inclusion in 
 public bug-trackers (and also agree to the translation of their messages 
 into another language).
   e) The location-specific groups may establish their own additional 
 posting rules by their normal decision-making process, as long as these 
 posting rules do not conflict with the general rules described here. 
 These posting rules may include (without limitation) the scope of the 
 list, who is allowed to post to the list (but not who can subscribe) and 
 how often, and the permitted language(s) of any posts to the list.
 
 4) Administration and moderation of location-specific mailing lists.
   a) Each location-specific group shall determine their own process for 
 the control of their own mailing lists, and their nominated 
 administrator will be provided with a password allowing them access to 
 the administrative interface.
   b) Group designated administrators are free to change the settings of 
 the groups location-specific CellML mailing list (after changes are 
 approved through the appropriate local decision-making processes). 
 However, they must not make changes which cause the mailing list 
 archives to be no longer public, or which cause the list to require 
 moderator approval before allowing subscriptions.
   c) Group designated administrators may also (in accordance with 
 locally determined policies) subscribe and remove people from their 
 mailing lists are a service to the person being added or removed. 
 Administrators may infer that a person wishes to be added or removed 
 from the 

Re: [cellml-discussion] CellML tracker

2007-06-26 Thread Andrew Miller
David Nickerson wrote:
 Michael Dunstan just suggested Trac and Poi as being worth looking 
 at too.
   
   
 I don't think Poi has the same level of features as Bugzilla (e.g. CC 
 lists, etc...).
 

 are these CC lists any different to the subscription feature of the 
 current plone tracker that we're using?
   
I don't know of any per-issue subscription feature in PCNG, and a web 
search didn't seem to find anything about this.

Perhaps you have details about this?

Best regards,
Andrew
 ___
 cellml-discussion mailing list
 cellml-discussion@cellml.org
 http://www.cellml.org/mailman/listinfo/cellml-discussion
   

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


Re: [cellml-discussion] Proposal: Local CellML team e-mail addresses

2007-06-26 Thread James Lawson
Andrew Miller wrote:
 David Nickerson wrote:
 Hi Andrew,

 I think this is an excessive response to a very minor problem. I very 
 easily see this evolving into many separate and distinct local 
 communities with little interaction.
 The intention is that these lists only be used for messages like 'There 
 is a meeting on Level 6 at 10:00 am on Tuesday this week', or 'The 
 recently announced release can be run by on Linux by local users from 
 /people/blah/binaries/myprog', rather than significant CellML related 
 issues, and that is the goal of my guideline.
 
 I think that there are already very separate and distinct local 
 communities (we hardly ever hear from many of the communities who are 
 working on CellML), and the idea is that by acknowledging this and 
 providing an archived, open resource for local discussions with an 
 encouragement to send non-local messages to the more general list, we 
 can actively build stronger community interactions.
 

But how interested in these group-specific announcements are other
groups going to be?

  For the same reasons we removed the 
 cellml-tools mailing list, I would very much like to see 
 cellml-discussion remain as the only public forum for discussing CellML 
 related issues, until such time as we decide that the list is being 
 flooded with too many emails on one topic and we separate that topic off 
 onto its own mailing list. I have yet to see any need for this.
   
 Although a lot of messages currently get sent directly to interested 
 recipients to avoid flooding the list, and moving these onto a local 
 list would cause them to be archived.
 The idea of the team-cellml mailing list was for discussion amongst the 
 original Auckland team on issues relating to the underlying functioning 
 of the CellML project and a place to debate decisions when consensus 
 could not be achieved amongst the wider CellML community.
  The 
 [EMAIL PROTECTED] mailing list would not serve this purpose.
   
 I don't think that we need a separate mailing list for this, because 
 there is no need to tie decision making processes to the mailing list.
 
 The process for developing a given resource is ultimately determined by 
 whoever funds that resource, and the people who make the final decision 
 can do so on the basis of discussions (which may include them) on the 
 list. I don't see any need for a second mailing list for this.
 Andre.



 Andrew Miller wrote:
   
 Hi,

 There has been some discussion recently about how best to handle local 
 CellML addresses (which can be used by local groups with an interest in 
 CellML to arrange meetings and hold other discussions which are purely 
 local in scope and not of interest to the broader CellML community).

 At the University of Auckland, we have a list for the Auckland CellML 
 team. However, I feel that some of the discussion on that list would 
 probably better occur on the cellml-discussion mailing list (or another 
 more public forum). After discussing this at our Auckland CellML group 
 meeting, it was suggested that perhaps similar issues are arising at 
 other localised groups working on CellML. To this end, we came up with a 
 rough proposal (which I expand on below) which I hope will help both the 
 Auckland group and other groups using CellML to collaborate.

 Please note that this is just a proposal, and I would welcome feedback 
 on how we can improve it. I would be especially interested to hear 
 opinions from other groups outside Auckland using CellML.

 Proposal:
 
 1) Groups can request location@cellml.org mailing lists.
   a) Any group which is working on a CellML related project may [follow 
 some procedure which needs to be decided] to request a mailing list for 
 discussion of location specific matters related to their CellML project.
   b) The e-mail address requested shall follow the format 
 location@cellml.org, where location is replaced with a short word, 
 phrase, or abbrevation which describes the geographical location of the 
 group concerned.
   c) The location name should be sufficient to uniquely distinguish the 
 group from other separate groups that may wish to work on CellML. List 
 names are subject to review to ensure that they are unlikely to conflict 
 with another group or cause confusion.

 2) Location-specific mailing lists to have open membership and be 
 publicly archived.
   a) Any person may join any location-specific mailing list without 
 moderator approval, regardless of their actual geographic location.
   b) All location-specific mailing lists shall have a publicly readable 
 archive, hosted at cellml.org.

 3) Scope and posting rules for location-specific mailing lists.
   a) All messages posted to location-specific mailing lists must be 
 related in some way to CellML, or to tools which process CellML, or to 
 the operation of groups with an interest in CellML. Some degree of 
 leeway should be afforded by cellml.org administrators here, as long as 
 the list is not