tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Raymond Feng" <enjoyj...@gmail.com>
Subject Re: Graduation next steps
Date Mon, 04 Feb 2008 22:18:16 GMT
The e-mail is getting long :-). I just want to add my +1 to these great 
ideas. I definitely willing to help in various areas.


----- Original Message ----- 
From: "Simon Nash" <nash@apache.org>
To: <tuscany-dev@ws.apache.org>
Sent: Monday, February 04, 2008 1:59 PM
Subject: Re: Graduation next steps

> 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

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

View raw message