tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Laws" <simonsl...@googlemail.com>
Subject Re: Graduation next steps
Date Fri, 01 Feb 2008 10:47:07 GMT
On Jan 31, 2008 1:41 PM, ant elder <ant.elder@gmail.com> 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


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

Just some thoughts


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message