[kforge-dev] Re: release and iteration plans

Rufus Pollock rufus.pollock at okfn.org
Sun Jan 15 12:24:30 UTC 2006

John Bywater wrote:
> Hi Rufus,
> Regarding the release plan [1], is the list of use cases in order? Shall 
> I take the top 4.5 weeks worth forward for the first iteration plan? I 
> think I will break the stories into tasks, and try to plan/estimate 
> things a bit more.

I have now updated this page to break it up and it now is as follows 
(note there is no iteration 3 because of reduction in CLI use case -- 
see comments further below -- and the removal of the wordpress plugin 
use case):


= Release Plan =

== Release 1.0 ==

End date: 2006-03 (end)

   * 3 iterations and an assumed velocity of 4.5 per iteration
   * For use case summary see KforgeDev/UseCases
   * bracketed items are not use cases but work items deriving from 
refactoring or improvement of existing system

=== Iteration 1 ===
   * refactor/improve permissions system (see KforgeBacklog)
   * url layout (see KforgeBacklog)
   * KforgeDev/UseCases/UseCase38 -- Project is purged
   * KforgeDev/UseCases/UseCase39 -- Project is undeleted
   * KforgeDev/UseCases/UseCase40 -- User is purged
   * KforgeDev/UseCases/UseCase41 -- User is undeleted
   * KforgeDev/UseCases/UseCase43 -- The service is administered from a 
command line interface

=== Iteration 2 ===

   * KforgeDev/UseCases/UseCase15 -- Registered person registers 
themselves as member of a project
   * KforgeDev/UseCases/UseCase44 -- Request new password (or a 
reminder) if old has been lost
   * KforgeDev/UseCases/UseCase45 -- Improve deployment so that python 
package dependencies are enforced (use setuptools?)

> Also, for "The service is administered from a command line interface", 
> are we talking about the kforge system-service, or a project-plugin 
> service? In other words, are we talking about finishing kforge-admin, or 
> adding support for Service domain object instances. During the release 
> planning meeting, I assumed the former.

I think this should be fairly minimal and consist only of reflecting in 
the CLI what exists in the command layer (or even some subset of the 
commands). I think it should include things not available from the kui 
such as:
   1. purging and undeleting things
   2. creating plugins
   3. (re)setting passwords for users

For more complex actions I think it might be better to simply use the 
python interface rather than reinventing this in our own interactive 
environment. For example setting a role for person X on project Y is:

import kforge.dom
r = kforge.dom.DomainRegistry()
y = r.projects['Y']
x = r.persons['X']
member = y.members[x]
member.role = r.roles['roleName']

While this could be made simpler by the provision of a specific command 
in the CLI I don't think it is worth making that effort until we know 
there is a clear need.



More information about the kforge-dev mailing list