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]
