This sounds like a good list to start with.  There was also an even 
earlier "3.7 starter list" of items that I threw out on the SqF a couple 
of months ago, which has some overlap with your list, but there were a 
few extra things on my list that you could add to yours:

- Accufonts, to help clean up the Squeak-L licensing issue.  Also, we 
could consider adding the Bitstream fonts as Diego mentioned.
- Diego's look enhancements
- consider/discuss adding the ANSI compatibility changeset

Other than that...

 > 10. Come up with *anything* regarding bug tracking. Both for the 
image and
 > for packages. SM2 can help a bit.

We could have some more specific goals here... The highest priority goal 
should be moving the bulk of the more mundane traffic (e.g. [closed] and 
[update] messages) off of the squeak-dev list.  But we need a balance of 
still having the important traffic on the list (or on another list) so 
that things can still be discussed.  I would be happy if Brent or Markus 
wanted to take the lead on handling this, I have plenty of other stuff 
to work on... :-)  Other later goals would include attaching bug 
reports/fixes to specific packages, etc.

Also, at some point we discussed adding some slightly more formal sort 
of Proposal Process in order to help keep track of larger issues and 
assign responsibility, etc.  (Of course, there's plenty of other stuff 
on our 3.7 list already, but we can prioritize...)

- Doug


goran.krampe at bluefish.se wrote:

>Hi all!
>
>Just felt like writing a bit "The Day After". 3.6 is out! Yay! And
>personally I think we all did quite good with this one.
>
>3.6 is the third release of Squeak that is "community driven". 3.4 was
>the first one, but IIRC it included mostly the 3.3 work (without
>3.3-Modules) so even though it was the first release done by the
>community through Doug Way (with help from Scott) it still consisted
>mostly of work done "during SqC".
>
>3.5 was a very small release (with a few "critical" bug fixes) which we
>did mostly to get "our feet wet". The move to have a small release was
>criticized at the time but whatever - water under the bridge. :-)
>
>3.5->3.6 turned out to be 244 updates. 3.2->3.4 was 214 updates so 3.6
>is much more a "real release". We set up a plan at the beginning and we
>almost followed it all through. Sure, we can always improve the process.
>
>The Party
>===========
>
>Yesterday we had a "party" on the squeak IRC channel. Sure, we could have prepared it better with some fun stuff going on - but hey. :-) Anyway, it started slowly and built up gradually throughout. Someone counted 40 nicks total - quite a lot of people showed up and there where interesting discussions and toasts to people deserving it etc. Generally nice!
>
>I think we should try to have more of these "fun virtual events". Daniel and I have discussed a few ideas and I know that the idea of a "Bugathon" has been voiced. As always someone need to "take charge" so if you have a good idea, speak up!
>
>For example - a "BFAV crash course" on IRC with the authors and harvesters standing by for support would probably be a great boost.
>
>
>Now what?
>============
>
>3.7 alpha is starting and as always we have tons of things going on. And that is a really good thing! This means that Squeak is alive and kicking.
>
>The harvesting process has picked up a notch, BFAV works pretty good. There is a discussion currently how we should deal with bug tracking and that discussion also bring other issues to the table like for example the "Steward idea" and how we carve up the image into different areas of responsibility. Most discussions about bug tracking eventually end up in the "Who is responsible for that code?"-area. Note that this is not necessarily the same thing as cutting these areas out into packages.
>
>Personally I think that during the 3.7 iteration we should at least consider doing these things:
>
>1. We (guides) have started trying to formulate a vision that we stand by. This is still very much in its infancy, but I think one goal for 3.7 is to get that out.
>
>2. I think we should at least try to rotate one Guide. Rotation was a key idea from the beginning and I think it is healthy for the community.
>
>3. Make a targeted effort at "harvesting" many of the enhancement packages currently living on SM. Many of those actually belong in the base image packages.
>
>4. Get the new Compiler in. The word is out that SmaCC is now available under MIT so the license question is out of the way. Let's get this stuff in! It would be a real shame if all that work Anthony did got wasted...
>
>5. Get Babel in and squeeze out a few translations. Already much on the way.
>
>6. Split out at least ... 3 (?) more packages from Basic.
>
>7. Get the TimeStamp/DateAndTime-whatever-package in. I am getting bored at including that in SM...
>
>8. Whatever stuff that comes out of KCP and MCP of course. :)
>
>9. General harvesting, and perhaps have a "BFAV crash course" during the iteration to pick up more users and thus speed through more eyeballs.
>
>10. Come up with *anything* regarding bug tracking. Both for the image and for packages. SM2 can help a bit.
>
>11. Start thinking about Stewarding areas of the image using PackageInfo definitions (without necessarily splitting it out). This way we get someone "in charge" and bug tracking, decision making etc gets much more defined.
>
>12. And of course... get SM2 up and running. :-)
>
>
>Now, this is by far a full list of candidate tasks. There are tons more that I both didn't think of rightnow or even purposefully left out so that other people get a chance to pipe up.
>
>over and out for now, Göran
>
>PS. If people simply throw out candidate tasks I will gather them up to a grand list which we then can prioritize.
>  
>