Raw list of all the points mentioned in the "Graduation Next Steps" thread - http://apache.markmail.org/message/jwt6vnb3tc4xgfe5
1) Have a timeframe for trying again (graduation)?
2) 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
3) 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
4) 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
5) 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
6) 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
7) 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.
8) 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.
9) 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
10) follow up much more diligently on applying patches that are submitted.
11) working with people that open JIRAs to see if we can help them to create a patch.
12) follow up with folks to post to the list to see what their interests are and try to draw them into a closer involvement.
13) report/discuss our progress with the IPMC at some interval (monthly) to see if a new graduation proposal is appropriate.
14) incoming JIRA are classified, assigned and turned round as quickly as possible
15) 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.
16) Sort out the classification system so that we can better monitor which areas have problems in the project.
17) either represent all the components in the (JIRA) system or come up with some very generic classification.
18) 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.
19) Use the JIRA system more effectively to prioritize our work. For example, there is a voting system.
20) 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.
21) 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.
22) 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.
23) separate the SCA Java user guide page into two sepate pages.
24) 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.
25) 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.
26) cleanup and organize JIRAs to help people find where to contribute
27) apply patches from contributors more quickly
28) have a roadmap with features, their status and who's working on them
29) route the JIRA traffic out of the dev list
30) improve mailing list communication with shorter and clearer emails
31) post everything that's useful to users to the user list
32) provide better architecture and design docs
33) publish more tutorials and how-to docs to help users get on board
34) using Docbook for documenting things?
35) graph of dependency between modules will help new developers to inspect better the code.
36) Typically these discussions have multiple aspects to it and we end up bringing perspectives to each aspect. If there is such a topic then I'd think the WIKI is a good place. There could be one description of the problem and comments by the community at various points.
37) Spawn threads for different topics, keep each thread specific
38) Post short summary emails
39) Document details on our Wiki in a developer section
40) Use VOTE more often to make decisions?
41) Let people implement alternatives, providing concrete ground for discussion later?