I'm happy to see this discussion going and I think most of the points listed make a lot of sense.
A small detail to add to the list that I think could have some importance: your -dev list is flooded by Jira issues. Newcomers interested in Tuscany's development are very likely to get overwhelmed by all the noise. I'd redirect that to -commits. Cheers, Matthieu On Feb 1, 2008 2:47 AM, Simon Laws <[EMAIL PROTECTED]> wrote: > 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 >
