I think releasing every 4-6 weeks is probably a bit too often.
Most users won't want to upgrade so frequently, especially at
this stage of an incubator project when new releases may be a bit
unstable. Another factor is the overhead involved in cutting a
release. On balance I'd suggest releasing every 2 months would be
reasonable timing, with a release closedown cycle starting perhaps
2-3 weeks before the release goes out.
I think there's value in forward planning for release content.
Our scenarios should provide a basis for deciding what new function
is most needed in the next release, and maybe even thinking a bit
further ahead ("pencilled in" rather than a firm commitment or plan).
For major pieces of functionality, it is likely that forward planning
will be needed to get a realistic idea of what can be fitted into
each release. Other items that are smaller or less critical to our
users (don't forget that these are the audience for our releases) can
be accomodated with a lot less in the way of pre-planning.
Simon
Jim Marino wrote:
On Jul 3, 2006, at 11:31 PM, ant elder wrote:
On 7/3/06, Jim Marino <[EMAIL PROTECTED]> wrote:
...and involve a lot less "upfront planning"?
In other words, people work on what interests them and the community
cuts a release when it decides a useful level of new functionality
has been reached.
Can you provide pointers to any other Apache projects that work like
this?
I've never seen any other project of significant size, open source or
otherwise, work like that.
There's three main problems I see with the 'do whatever you like'
approach.
Please read my words carefully:
- I wrote, "a lot less 'upfront planning'" as opposed to "no upfront
planning". I'm not an anarchist :-)
- The rest of the passage was also important in this respect:
"Practically, people should just detail the scenarios and features that
they think are interesting on the wiki, through email, etc. and work on
implementing them". By *documenting* what interests people in some way
(we should be flexible here), letting people work on those features,
and then deciding at quick intervals (4-6 weeks) when to cut a release
sounds pretty reasonable to me. The "lightweight" planning part comes
in with the documenting of interests and then the decision process to
have a release.
Of course, there is the waterfall approach commonly associated with
commercial software development. I don't think this works well in many
open source environments for a variety of reasons that I won't go into
as they are off topic.
In terms of open source projects, I think you will find this type of
"lightweight" planning happening in a lot of projects. For example,
AspectWerkz operated very successfully this way as does Spring
(although they are taking a little longer for releases, probably due to
the maturity of the project). I think you will find some Apache
projects as well...
With no clear goals, direction, or coordination we wont end up with
anything
very useful that fits together and works in an elegant and seamless way.
I probably could have gone into more detail on my thinking around
release cycles, but it should be patently clear that I was not
advocating an agenda of no goals and no coordination. I assume you did
notice that I have been spending a lot of time creating scenarios on
the wiki? It is also the subject of the current thread. Hyperbole in my
opinion doesn't really move the community forward.
I believe scenarios are an excellent way to form a basis for
coordination and bring the community together. My point was that by
having people detail what interests them, others join in and a
consensus emerges when certain scenarios gain momentum. I find this to
be a nice balance between the interests of large group as well as
smaller pockets of one or two individuals. Under this system, one or
two people can make a difference since they are free to implement
features they feel strongly about (assuming they are aligned with the
project charter).
No
one will do the boring work - documentation, testing, uninteresting
bugs in
JIRAs, etc.
That's why we have coding standards. I have been one of the staunchest
advocates of unit testing, documentation, etc. as you are aware.
And it will be hard to grow the community.
Modularity, scenarios and having a positive environment which
encourages people to work on what interests them are all great ways to
grow a community.
Over the past months I've been trying to get new people to come
participate
in Tuscany and they all complain about no roadmap of what we trying to
achieve, no wish list of wanted function, and no plan of whats coming
up in
the next few milestones.
In the past we had "roadmaps" here:
http://wiki.apache.org/ws/Tuscany/TuscanyJava/Tasks
http://wiki.apache.org/ws/Tuscany/TuscanyJava/Roadmap
There is, however, a general issue related to the SCA specs and Tuscany
of what the value adds are. I have been working with others in the spec
group to help fix this from the braoder SCA perspective.
In terms of Tuscany, I would suggest we as a community do likewise. To
me, that starts with actions of individuals. Could you please begin by
posting your "wish list" of wanted function somewhere? I think it would
be great to do this as scenarios but emails to the list will do.
Yes we need to encourage new people to come
contribute whatever function they think is useful regardless of if or
where
we had that function in our plans, but surely the main development
team need
to have a bit more focus and coordination if we're to create
something very
useful.
...ant
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Simon C Nash IBM Distinguished Engineer
Hursley Park, Winchester, UK [EMAIL PROTECTED]
Tel. +44-1962-815156 Fax +44-1962-818999
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
