Michael, thank you for your answer.

I started another thread which is even less visionary, going for a
4.1.1 maintenance release ASAP. See
http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-April/149629.html

However for the vision part you brought up the idea of

   "Squeak as the best documented Smalltalk system"

I like this idea.
A friend of mine is a 70 year old mathematician who used to work for
IBM 40 years ago. She says that she was taught at that documentation
is 50% of the product. I think this still applies. Of course people
always say one should browse the code in the image and it is true, it
reveals a lot. But if I want a drink out of a soda-wending machine I'd
like to know where to put in the coin and which buttons to press. Most
of the time I do not want to know how the machine is constructed.

API documentation is fine but process oriented documentation is needed
in addition.

Maybe we could have a goal of motivating 30 people contributing to
documentation. Everyone writing a little tutorial and with a small
sample application.

A calculator, a game, puzzles, a scrapbook, a world clock, ToolBuilder
examples, a small parser, some simulations, a little spreadsheet for
doing a simple budget, a flash card came, a sound library browser, an
outliner, the HelpSystem (with tags), a browser for flickr, a curl
plugin example, example accessing this NON-relational databases (JSON
based), a website done with Http view, links to Seaside more
examples,.... you name it.

Video sessions where people demonstrate how they actually work in
Squeak would be beneficial as well.

--Hannes


On 4/26/10, Michael Haupt <mhaupt at gmail.com> wrote:
> Hi,
>
> thanks, Hannes, for pointing to the board meeting post.
>
> On Mon, Apr 26, 2010 at 8:02 AM, Hannes Hirzel <hannes.hirzel at gmail.com>
> wrote:
>> I have thought about it again:
>>
>> Themes:
>> - Documentation
>> - Package management
>> - More Tests
>>
>> Plus
>> Open issues which did not make it into 4.1, more GUI enhancements
>> (this includes a one-stop place for importing and exporting resources)
>> and bug fixes.
>
> That quite nails it, and is much more sensible than my extensive wish list.
> :-)
>
> I'll keep those things in mind, though ...
>
>> However realistically speaking  - the process should be driven by the
>> people who want to contribute code in the areas.
>>
>> The other approach is just to set a time frame - and then include what
>> is available at that time.
>
> Hm, er, no. Not exactly a vision, right? Is there one? What is Squeak
> supposed to be in 1 or 2 years? Is there anyone formulating and
> conveying a roadmap? Anyone?
>
> Best,
>
> Michael
>
>