Hello,
Before writing this stuff I though I would run it by the list for
review. These are my thoughts on the development cycle, roadmap and
release process for the Workflow project in general.
As stated on the homepage of the project we are running under the
following directives:
- Extensibility
- Stability
I am lacking a third directive, but I hope it will present itself at
some point.
The reason to have the 3 directives is a technique I learned during
education, when getting to a cross road of sort, a dicussion which
require conclusion or an obstacle, the directives can help make the
right decision. The reason why I have chosen these two directives are:
1. Extensibility, Workflow is a framework, it should be extensible
for the developer/user utilizing it so it can be used to solve the
user/developers particular problem without having to patch the core
modules.
2. Stability, Workflow is in production in several places and when
Chris handed it over to me as maintainer I looked at it as already
finished, but it still has a lot of potential for improvement etc.
and "code is never really done" to quote a book I am reading. - but
Workflow is actually put to use and is not a toy system, so we need
stability in order for the project to keep afloat.
I am for the release early, release often paradigm, but this is an
open source project and it is not the primary work for most of us, so
we make releases when there is something to release, so in order to
keep releases frequent (and the project alive) we keep releases small.
As for development and releases, I divide this into two parts:
1. Bug/Documentation fixes, resulting in maintenance releases
2. New features or feature enhancements resulting in regular releases
The regular releases will be planned, not scheduled, but planned - in
that sense they come from the ROADMAP and can be identified as tasks
in the sf.net project system.
The ROADMAP is an outline of where we want to go, only the firstmost
topic is being worked for the forthcoming release, but we can
reprioritize, parallelize etc. as long as we have the resources and
the will to do so.
A developer (or several) will be assigned to the ROADMAP scheduled
activities (tasks) and it is released when it is done, until the
release several maintenance releases might be made (based on branches
from the last release point).
I am very much interested in development is also focused on unit-
tests, since the release process is dependent on the test suite
passing prior to release, but it is expected that developers does not
break the test-suite with out notificed the rest of the project
members. I regard the test-suite as a safeguard to keep stability,
however tests contain bugs aswell or as in our case is not covering
the code completely.
This brings me to the other part of the development efforts aimed at
Quality Assurance.
I attempted to get the coverage for the project improved, this is an
ongoing process, but the goal is stability, so we can develop more
freely, using the test-suite as a tool to ensure we have no unforseen
problems. We want to break tests in that sense we want the code to
evolve, but we want to KNOW when we break it so we can address this.
The current ROADMAP looks like the following:
Development:
- Implement dynamically loading of workflows
- Implement versioning of workflows
...There are several feature requests in the system and there is not
need for me to list them here...
QA:
- Improve test coverage
So that was sort of what I have in mind and things are up for
discussion, I will get back with a preliminary draft of my ideas on
how the bug handling process.
Looking forward to hearing your thoughts on the topic,
jonasbn
|
