Mailing-List: contact tuscany-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: tuscany-dev@ws.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <47A78AD1.10408@apache.org>
Date: Mon, 04 Feb 2008 21:59:45 +0000
From: Simon Nash <nash@apache.org>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: tuscany-dev@ws.apache.org
Subject: Re: Graduation next steps
References: <71e1b5740801310541m7c74b1aamc00e38805cba81fd@mail.gmail.com>
 <c0c051b50802010247s554241e7y409bd8306e7712b2@mail.gmail.com>
In-Reply-To: <c0c051b50802010247s554241e7y409bd8306e7712b2@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Simon Laws wrote:
> 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 agree that the above are all excellent ideas not just for graduation
but also for making the project more successful in the long term.

> 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.
> 
+1 for starting by doing this as "baby steps" reports on diversity for
say the next 2 months (early Feb and early Mar).  We can then decide if
we think we are close to being ready to bring forward another graduation
proposal.

> 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.
> 
I agree we need to do something.  Asking people on the list to take
these on has made some inroads, but not enough.  Doing this by IRC
has worked in the past but has the problem of finding a time when
everyone can be available (e.g., my calendar is full at the times
that work for both India and California).

> 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.
> 
I think individual modules is too fine-grained a division.  What we
have now should be pretty close, but maybe a little more granularity
could be useful.

> 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.
> 
+1.  I try to do this for areas where I have some knowledege, but I
don't always manage to hit the 24-hour window.

> Use the JIRA system more effectively to prioritize our work. For example,
> there is a voting system.
> 
+1

> 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.
> 
+1

> 
> 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.
>
+1.  I think 1.2 is a good name for the next release.

> 
> 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.
> 
+1

> 
> 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)
>
+1.  This would really help.

> 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.
> 
+1.  Having descriptions at multiple levels of detail is important,
as one size does not fit all.

> Just some thoughts
> 
> Simon
> 
Very good ones :-)

   Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org