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
