Chronological Thread 

< Chronological >      < Thread >

---

Hi all,

I agree with Hugh's comments. This seems like a useful document to
include in the libCellML project, but it needs to be tided up and
formatted to make sense. Ideally, I would like to see the use-cases
laid out in terms of the milestones in the roadmap as this will help
determine the required sequence for implementation. There are
use-cases that clearly go beyond the requirements laid out in the
current roadmap, so we need to be clear what are just anticipated, but
still very useful, use-cases vs actual use-cases that libCellML needs
to support first. Obviously part of this process will determine if
changes in the roadmap are required.

It makes sense to me that each use-case is recast as an issue in the
tracker once work is going to start on that required feature or
use-case. But once this document is ordered according to the
milestones, then it would be trivial to do a bulk issue creation and
assign them to the appropriate milestone and priority, if that is the
preferred way to manage the use cases.

Some additional notes on the document:

The table in 4.v is missing mathematics. I also think it is important
that each column in that table has valid and an invalid entries (e.g.,
X with valid name; X with invalid name; X with no name; where X =
component, variable, units), as we need to ensure that libCellML
handles errors conditions gracefully. And these models that are being
created will form the basis of the CellML test suite, which is used to
test the validation capabilities of libCellML.

The distinction between built-in units and user-defined units seems
cumbersome. If a model either has units in it or it doesn't. The
support of the default set of units defined in the specification is an
internal detail - to me at least.

Given that validation is a key feature of libCellML, the validation
category (9) really needs to be filled out. Starting with the same
table as 4.v (with above modifications) seems like a good starting
point to me.


Cheers,
Andre.


On Wed, Jan 28, 2015 at 4:05 PM, Hugh Sorby
<h.sorby AT auckland.ac.nz>
wrote:
>
> Yes I think the document should be incorporated into the LibCellML project,
> after changes have been made.
>
> I think that this document is a fine place for managing a list of use cases.
> Each use case is turned into an issue on GitHub when it is needed and then
> worked on following the development process.
>
> I see this list as the basis for work that needs to be carried out to
> satisfy the aims of the libCellML project. So it fits in very well with
> agile methodologies where you have a big list of items that need to be
> completed to meet your aims and you adjust the list as your aims vary.
>
>
>
> On 01/28/15 15:30, Randall Britten wrote:
>
> Hi
>
> Before I jump in and work on formatting, and so on, I think the bigger
> question is: is this document considered valuable, and something we want to
> incorporate into the LibCellML project?
>
> If the consensus is that we should adopt this, then I agree that there is
> lots of room for improving the layout etc, but we should perhaps also
> consider something better than a document for managing lists of use cases
> (UCs) (we’ve already discussed that perhaps each UC becoming a GitHub issue,
> we could do that in bulk, or as we select what to work on next.)
>
> I don’t agree that a use case should be worked on (including documenting the
> use case itself) prior to the point that it is selected as the next work
> item. This is based on my understanding of agile methodologies such as
> Scrum and Extreme Programming (XP).
>
> Regards,
> Randall
>
> From: Hugh Sorby
> <h.sorby AT auckland.ac.nz>
> Reply-To:
> "cellml-tools-developers AT lists.cellml.org"
> <cellml-tools-developers AT lists.cellml.org>
> Date: Wednesday, 28 January 2015 3:02 pm
> To:
> "cellml-tools-developers AT lists.cellml.org"
> <cellml-tools-developers AT lists.cellml.org>
> Subject: Re: [[cellml-dev] ] libCellML use cases
>
>
> feedback:
>
> I would like to see the document re-ordered have the notes at the bottom,
> categories as headings and the use case(s) listed below the category
> headings
> have the use cases listed in order of priority or if the priority is not
> known the order that they are going to be worked on
> have the use cases listed as they would be tested using gtest
> have the first few use cases explicitly written out
> turn the linked google doc into an actual table in the document
>
> Cheers,
> Hugh.
>
> On 01/28/15 11:10, Randall Britten wrote:
>
> Hi all
>
> Some months ago, I started this document listing brief and informal
> descriptions of potential libCellML use cases:
> https://github.com/codecurve/libcellml/blob/listUsecases01/docs/source/usecases.rst
>
> These could help with project planning. During a discussions today and last
> week, we decided to mail this out for feedback. We foresee that many of
> these use cases will map to issues created in the libCellML tracker on
> GitHub, and hence become work items on the project and get implemented.
>
> I’ll respond to feedback the same day or the next working day where
> applicable.
>
> Regards,
> Randall Britten
>
>
>



--


David Nickerson
about.me/david.nickerson

---

• [[cellml-dev] ] libCellML use cases, Randall Britten, 01/28/2015
  • Re: [[cellml-dev] ] libCellML use cases, Hugh Sorby, 01/28/2015
    • Re: [[cellml-dev] ] libCellML use cases, Randall Britten, 01/28/2015
      • Re: [[cellml-dev] ] libCellML use cases, Hugh Sorby, 01/28/2015
        • Re: [[cellml-dev] ] libCellML use cases, David Nickerson, 01/29/2015

---

Archive powered by MHonArc 2.6.18.