Hi all


The following citations have prompted me to answer.
I perceive them as summarizing the key points to this important 
discussion.
I like to propose a moderate, easy to implement solution which solves
a real problem which has prompted several people in the past to quit
this list.


Dan Shafer wrote: (emphasis added by me)
>Following threads was very difficult at best and
>_filtering out topics_ in which I was not interested proved all but
>_impossible_.


Rosemary Michelle Simpson wrote: (additional emphasis added by me)
>The issue, I think, is having a variety of tools for different mindsets
>that captures the same material.  This is the issue faced by information
>structure designers and indexers - providing different gateways into and
>_different_ structures over the same material.  Thus, we need the mailing
>list _plus_ other tools that could feed the mailing list content into 

>(1) spatial hypertext interfaces for exploring related material such as
>the ConceptLab project I'm currently working on, 

>(2) database archives such as the Yahoo archive only with much much 
> more flexible and powerful toolsets,

>(3) Swiki pages, and other vehicles as people think of them.  

The point is that _the mailing list is not the problem_; the lack of other
tools over the same material is.



In the rest of the email I will follow the outline:

1. Mailing list as the main discussion channel in the Squeak community
2. Swiki use
3. Advantages of a mailing list 
4. Proposal: Additional Squeak Mailing List Conventions to aid filtering
5. Summary
6. Further steps

1. Mailing list as the main discussion channel in the Squeak community
----------------------------------------------------------------------

When thinking of changeing away from the mailing list one has to 
bear in mind that this list is the main discussion channel in the Squeak 
community which feeds various derived services.

See Squeak Email List
*http://minnow.cc.gatech.edu/squeak/608*


This list is the source of various extracts:

See: Mailing List Archives
*http://minnow.cc.gatech.edu/squeak/775*

The German Smalltalk users group runs a Swiki with just the extracts
of the topics marked with [Bug] and [Fix]

- Bug Reports Archive at *http://swiki.gsug.org/sqbugs/*
- Bug Fixes Archive at *http://swiki.gsug.org/sqfixes/*

See Reporting Bugs and Fixes
*http://minnow.cc.gatech.edu/squeak/398*
for more information on this


The mail archive in Vienna (for example
*http://macos.tuwien.ac.at:9009/MailArchive.recentTopics*) 
powered by the original Squeak powered web server
by Georg Gollmann has now about 40000 entries.
(*http://macos.tuwien.ac.at/English.html*). It seems that
this useful service has been happily running without too much interaction
by Georg.



Note on mail reader: 
A mail reader with processing rules is helpful in 
dealing with the 1000 or so messages a month this list generates.
(e.g. I'm using MS Outlook at the moment).
This already eases the task considerably. (see also proposal
for additional tags below)


2. Swiki use
------------

We have a Swiki which is not yet used to it's full potential.


I think there should be more interaction between this list and the swiki
such as
- cross-reference to a swiki page
- take out a specialised discussion to the swiki
- edit a summary of a discussion on this list an put it onto a swiki.
- discuss something here and put it in the swiki faq or recipe collection.


Note: Actually this is already the case. But there could be more
of this. 

I suppose that many people are not yet used to the idea of
editing a  website together with other participants ("tele-cooperation", 
I hope that the word 'cooperation' has no negative connotation in English,
in German it is just neutral.)

In the past minnow was unreliable. It's now considerably better.

Hint: Don't forget to consult the 'changed' list often as there
you see somehow going on the line of discussion on the swiki.

The purpose of the Swiki is to contain the more 'stable' information.


3. Advantages of a mailing list 
-------------------------------

I'd like to mention some advantages I perceive:

a) Somewhat more "personal". (In a sense an illusion, because of the
archives which actually let the messages appear like in a newsgroup)


b) Allows digression in topics because of it's relatively unstructured
approach. Important in discussing research topics, gathering new ideas.
(associative/lateral thinking)


c) Implements "forgetting things": Many things uttered here often
are draft issues, ideas, suggestions, criticisms 
(justfied /unjustified). 

If it prompts somebody to come with a more useful thought or a solution
then it has served it's purpose. The things here can then be forgotten. 
The ones which are important are picked by somebody and brought in a
more definite form. Through the big volume of the list this 'forgetting 
function' is implemented which I consider important for real advance.
You have to give room for unfinished thoughts and change of opinion.

d) Good offline medium:
I download the mails on my laptop and then have a database of 
interesting things available when I'm not connected to the net.
It allows people with limited access to the net to participate 
actively (for whatever reason e.g. cost issue, not in all countries
of the world internet access is cheap. If you can download the things
in bulk that's fine).

e) Not necessary to follow everything. It doesn't matter if you
don't read everything. (BTW For this really to become true we should
have more editors who do summaries on the Swiki, excerpts and comments)

4. Additional Squeak Mailing List Conventions to aid filtering
--------------------------------------------------------------

This list uses some conventions at the moment
(See also 'Reporting Bugs and Fixes'
http://minnow.cc.gatech.edu/squeak/398 )


In the title string tags are used in a operative sense:
[Bug]        Bug report
[Fix]        Fix for a bug
[ENH]        Enhancement
[GOODIE]     Little addition which can be little application or some
             change of Squeak like changing the appearance
[ANN]        Announcement of a major addition
[Q]          Question
[Newbie]     Question by a newbie or somebody how thinks he is one.



I propose that there would be a considerable benefit in this system if
some more generally accepted tags would be used. 
There should't be too many of them as they have to be known by heart for 
ease of use.


The following is a proposal for additional content oriented tags:
(alphabetical order)


[Deployment] Deployment related topics like "majorShrink" issues,
             release number questions, configuration questions and 
             the like.
[Dynabook]   Conceptual issues regarding the dynabook vision and
             it's implementation.
[EToys]      EToys related things
[HW]         Topics related to a specific Hardware (for example iPaq
             implementation)
[IDE]        Integrated Development Environment; topics regarding
             browser variants, inspectors explorers and the debugger.
[Idea]       Tag for discussing new ideas what to do with Squeak
[IO]         Input / Output related things like driving a lego RCX, serial
             connection
[Morphic]    General Morphic related topics (Design patterns, usage,
             missing things)
[Multimedia] Multimedia issues like how to use squeak for presentations
             and font, sound,  graphic and movie related issues.
[Reln.n]     Issues specifically in connection with a specific official
             release n.n like 3.0 (the last one)
[SqApp]      Squeak applications like Celeste, Scamper, PDAMorph, Nebraska
[ST]         General Smalltalk related issues
[Teach]      Discussion on how to teach Squeak or how to use Squeak in
             teaching.
[Tutorial]   Squeak tutorials (for example Dan Shafer and John
             Hinsley asking questions when they are developing 
             tutorials just to mention two recent authors, or users
             of tutorials who want them to have updated.)
[VM]         Virtual Machine related topics (VM Maker, code generator,
             porting efforts)
[XP]         Recently people have been beginning to use this list as
             a very moderate kind of Extreme Programming (XP) style
             through email by posting unfinished things (e.g.
             change sets) and asking other to participate. This hasn't
             been the case in the past and I think this is very
             valuable.
             However not everybody want's to join in and even shouldn't
             therefore by having a mailfilter directing the messages
             marked with [XP] to a subfolder everything would be fine.



Why use this tags?

The tags should serve the sole purpose of dividing up the chunk of a 1000 
or so mails per month into more managable chunks. 

They should be understandable without having to consult this list.
This list has the purpose of coming up with a proposal for a
commonly agreed set.

The other purpose of these tags is that derived services are still easy to
implement. 

Several of the tags can be used in the same message title if necessary.





Tag application examples

For example there are VM implementors which do a excellent job for the
community. However that's not in everybodys focus. So a tag discussing
VM issues would allow easy filtering and archiving. A swiki like the
German User's Groups bug tracking swiki could collect VM-related things.


Another example: Some people are interested in EToy others are not. This
tag helps to separate mail.

The [Teach] tag could be used to set up a swiki with copies of the mails
where people could further add things for tutorials and instructions.




Implementation of these additional tags

Additional tags can be introduced gradually as we need them. And they can
as well be used without to much consultation as long as we don't have too
many of them (say less then 20).



5. Summary
----------

I consider it important to organize the discussion around concepts.
For this purpose the mailing list is a valuable tool.

However to facilitate automatic processing / filtering it helps to 
have a common more or less agreed set of general tags.  
Somewhat overlapping tags are OK as as long as there are not too many.

So I propose to use semantic tags like the ones listed under Point 4
consistenly in the title string of the mails. 
Implementation: 'As we go along, just use them'. 
*Nobody* will complain having some more tags in the title string.

The costs of implementing other solutions are considerable for the
community.
This solution costs very little (time and cognitive effort) but brings a
big additional value with existing tools and setups.





6. Further steps
----------------

I put this mail unchanged (besides some formatting) as well on the Swiki:

http://minnow.cc.gatech.edu/squeak/1962


Just edit it and change it or add things. You may reedit it completely.
I don't mind or if I do, I will change things again. ;-)


I would like to see a more or less commonly agreed tagset ("controlled
thesaurus"). 

This does not contradict the the fact that we can already *start now*
using
these additional tags. We'll see what works and what doesn't. 
It will be no big issue if for some time there is some inconsistency.
In fact it will be better not worse. It was actually the same thing with 
the already existing tags. 

A typical very simple application scenario will then be to set up a mail 
filter which puts mails within one group of tags (a personal selection) in 
one folder and the rest in another folder. 




Hannes Hirzel