On Jan 31, 2008 1:41 PM, ant elder <[EMAIL PROTECTED]> wrote:
I'd like to get some discussion going on what we want to do for
graduating
to an Apache TLP.
The attempt back in November raised issues about diversity and since
then
it
feels like we've just been waiting around hoping diversity would
improve.
We
were unlikely then and we are almost there, would it help to have a
target
to aim for so we can be a bit more proactive? How about trying again at
the
April or May board meeting which would give us a two or three full
months
from now? Having a few months would give us some time to work on turning
some of the contributors we already have into committers and to get
other
committers added to the PPMC, but a few months is also near enough to
keep
us focused. If we're seen to be working on this it may also encourage
some
of the contributors we have to be more active and so easier to make
committers.
There's a lot i think the project could do to encourage others to
participate, here's a few things I can think of -
We have a lot of downloads and real users, we need to try to get more of
these people engaged and contributing, things that may help are:
- better documentation, whats there is a bit sparse and our website has
started to fall behind and there's quite a few extensions with no or out
dated documentation
- more publicity about what each new Tuscany release can do, we have
lots
of
new stuff in 1.1 but the only place we say that is in the release notes.
The
Tuscany blog is a little neglected these days
- post to user list as each bit of new function is completed to try to
engage users and to show them their comments can make a real difference
to
what gets in the next release
- more timely action on JIRAs, we're getting quite a back log, if we're
quick to look at JIRAs it might encourage users to help debug and
provide
patches
Once a user does start contributing I think there are things we could do
better on the the dev list to make it easier and to encourage
participation:
- just generally improve the ML traffic which is at an all time low, if
we
the active developers don't discuss much then new contributors likely
wont
either
- one reason ML traffic could be down is that discussion is going on
off-list instead, is there? Is it really necessary? Lets make a real
effort
to keep all discussion on the dev list.
- more timely replies in discussions. if someone replies to a thread
often
it ends up with people waiting for a follow-up reply, if that follow-up
takes ages to come the discussion can stall and people loose interest
and
move on to something else.
- we may need to provide more active help to contributors when they make
suggestions, not just ask if they'd implement it but at least provide
lots
of detail about how they could do it or even step up and help code even
if
we may not think its the most useful thing
What do others think, would any of those things help? Any other
suggestions
that could help improve our diversity? Does aiming for the April board
meet
sound ok or too soon or too far?
...ant
I think all of the things you suggest are excellent ideas and that we
should
do better in all of these areas regardless of our aspirations to graduate
from the incubator. I wouldn't like to think we put effort in now and then
sit back as soon as we do graduate.
I'm in two minds about whether having a target for graduation is
appropriate. I would like to suggest that we give ourselves a target for
improving our diversity by addressing all of the good points you make and
undertake to report/discuss our progress with the IPMC at some interval
(monthly) to see if a new graduation proposal is appropriate. However I'll
have to take you advice as to whether posting to general@, reporting what
progress we have made and soliciting feedback will provide a response or
whether we actually have to start a [VOTE] to get peoples attention.
Motivated by your points some specific thoughts that come to mind...
JIRA Handling
The JIRA backlog is a real problem and I, for one, have been very poor at
addressing this. We want to be in a position where incoming JIRA are
classified, assigned and turned round as quickly as possible. So two
problems to solve.
1. The backlog -
Can we set up an IRC chat session(s) to walk through the 170 or so
outstanding JIRA to decide what to do about them ASAP.
2. The process going forward
Sort out the classification system so that we can better monitor which
areas
have problems in the project. We either represent all the components in
the
system or come up with some very generic classification. I think it's
easier
and more valuable if we can associate JIRA with the modules we have in SVN
so I'll volunteer to correct the classification list if people like this.
Set ourselves, as a community, the target of classifying and having people
volunteer to work with the creators of new JIRA within 24 (?) hours of
them
coming in. I agree with your comments that we should be trying to work
with
users and helping them to provide patches rather than just fixing
problems.
To do this we need to have someone willing to step up and reply to the
reporter quickly while we have their attention.
Use the JIRA system more effectively to prioritize our work. For example,
there is a voting system.
The closing of JIRA also gives us a good key for advertising the new
features or fixes that are appearing in the code base. I.e easy to search
and summarize the JIRA that are resolved/closed each week. Maybe we could
have a Tuscany newsletter on the user list/web site/blog each week giving
this kind of info for those not watching the project very closely.
Release Planning
We could also be more organized in planning releases and use JIRA more pro
actively, as we do in the final stages of release preparation, to defined
and prioritize the features of the next release. This would seem to be a
crucial area for wider community participation and if we can leverage the
JIRA people have already raised then they might be more interested in
commenting on release content rather than the arbitrary lists of features
that we personally are interested in that we have relied on to date. I
suggest we do this for 1.2 (is this what it will be called) and plan the
release by creating the release label and assigning JIRA to it now.
Mail list traffic
+1 Making sure that the people who drop in on Tuscany out of choice are
made
to feel welcome in our community, get swift attention and are encouraged
to
participate is probably one of the easiest and most effective things we
can
do.
Documentation
One thing I would like to do is promote the modular approach to the
documentation we have with SCA Java extensions at the moment, I.e. rather
than having a long rambling user guide have short one page white papers on
each feature of interest. It's easier create, easier to index and easier
to
maintain. With this in mind how about we separate the SCA Java user guide
page into two sepate pages.
- Overview (the overview material we already have)
- Features (a list of pages addressing all of the individual features of
the
software using the same approach we already have for extensions)
Looking back, some of our mail list interactions seem from the outside to
be
esoteric and incomprehensible to say the least as they deal with the
details
of a relatively complex software development. I don't know if it's
achievable but, as the software is starting to settle down architecturally
speaking, it would be good to start netting out some of the important
architecture details into words and pictures to provide an easier way in
for
the eager newcomer rather than just relying on reading the source.
Personally I find this a very daunting challenge if we have a monolithic
architecture document but more achievable if it were simply summarizing
the
salient point about some architectural aspect that has been discussed.
This
leads me to suggest that, like the user guide, we modularize the
architecture guide and rely on a list of white paper type material that we
can generate incrementally and group together as and when related topics
are
documented.
Just some thoughts
Simon
