My favorites | Sign in
Logo
                
Search
for
Updated Jul 09, 2008 by norman.x.gray
Iteration1  
Iteration 1 notes

Iteration 1, 25 June – 9 July

Stories for this iteration

Java API: Implement addClaim method to call RESTful addClaim method Effort: 2 days

Spacebook: Call addClaim RESTful API call. Effort: 3 days

RESTful API: Application adds a number of triples to the SAC, either PUTting to a named claim, or PUTting to its parent and getting a named claim in the response. Effort: 2 days

None of these were completed during the iteration, because everyone was going round in circles reorganising their repository (Tony and Norman), or fighting with Tomcat (Kona and Norman), or otherwise just getting infrastructure in place (everyone). So bump them to Iteration2 or Iteration3.

Notes

Iteration planning meeting: 2008 June 24, 12.00, by Skypecon.

  1. Does the process document at http://code.google.com/p/skua/wiki/Process look reasonable? Looks reasonable.
  2. Is anything obviously missing from the set of user stories at http://code.google.com/p/skua/wiki/UserStories ? Nothing obviously missing -- we'll add more stuff as we go.
  3. Are there any other documents that we need (see http://code.google.com/p/skua/w/list?q=label:process for a list of process documents). No other documents obviously required.
  4. Brief discussion about Quaestor's role: good enough for the moment -- we can change horses before long
  5. What iteration dates will we have? The book suggests midweek to midweek
  6. Estimate and prioritise a few of the likely stories
  7. Pick some stories to implement in this iteration!

In future iteration planning meetings, points 1-6 should be replaced by a single iteration review.

How committed are we to Quaestor? Not massively. Quaestor is about 4300 lines of code, and moving to Platform or Virtuoso or..., would be feasible. Possibly move this from the AstroGrid CVS to a googlecode project. What would be involved in moving to Platform?

Where do you 'make' claims? Do you make them locally and then ship/share them? Or do you make them where you want them to live, namely in a shared SAC? Possibly easier to implement just the latter, and implement the former if it turns out to be easier from a UI point of view. Leave bags out of it for the moment.

We'll have two-week iterations, starting roughly now.

We'll have a go at daily stand-up skypecons, and see how we get on...


Sign in to add a comment
Hosted by Google Code