Developers of Sympa

[Olivier Salaun - CRU <address@concealed>]

[summary topic]

> [...]
> I think it's probably best to keep escape_html, escape_subject and 
> escape_mailto_subject separate for now as it will mean that parser and 
> rendering weirdness can be dealt with in the appropriate section 
> without affecting other items. escape_html and the code that relies on 
> it is pretty mature by now, but my code isn't...

Ok

[categorisation topic]

> [...]I was thinking something like "X-Sympa-Msg-Cat", unless you've 
> already planned a better name.

That's fine for me.

> [...]
> I've also give a little thought to the email moderation options, as 
> they'll be important to some users (and are how I approve about half 
> the messages for lists I moderate, so they're important to me too).

What user interface do you imagine to allow moderators to choose a 
category ?

> > It could be usefull to separate category IDs from category title ; 
> > this could make subject tagging easier and would allow 
> > internationalization (if required).
>
> I'll bear this in mind. I wasn't thinking of tagging the subject line 
> with the message category, as I intended the category to purely be for 
> constructing the categorised summary, but a tag like 
> [listname.category] could be useful for some. [...]

Maybe I was not that clear :
I thought that your plans were to ask message authors to tag their 
messages in the message subject, which I think is a good idea...
Then they would only mention the category short name (or ID) whereas the 
summary would refer to the category in a more verbose way.
For example : 'bounce' in Sympa ML context would be a category ID and 
'Bounces (non-delivery reports) management in Sympa' would be the title.

> > How do you imagine message authors would indicate a category in the 
> > message subject ?
>
> I was thinking of filtering by particular keywords in the message 
> subject line - eg a subject line containing "seminar", "lecture"
> etc would be tentatively assigned a category of "Lectures and 
> Seminars" that could be accepted by the moderator or over-ridden as 
> part of the approval process.
>
> This has the advantage of requiring no more thought on the part of the 
> authors than "What is this email about?" - in conjunction with some
> simple guidelines for acceptable and useful subject lines, this ought 
> to be enough for our purposes.

Then you would define a list of expressions for each category.
This approach is to guess what the message is about, based on the 
subject ; another approach would be to make the author explicitely tell 
what category the message in related to ; maybe it is too constraining 
for authors.

> It might also be possible to automatically place messages in the same 
> category as the message they're in reply to. I hadn't planned on doing 
> this, as the messages on the system this is for are usually one-off 
> announcements rather than threaded discussions. I imagine the 
> threading code for the archives would be a good place to look for ideas.

The archive code is actually out of Sympa, in MhOnArc. 

> > For subscribers that don't have filterring facilities in their mail 
> > user agent, Sympa could propose categories of interrest to limit the 
> > messages sent to a subscriber.
>
> Server-side filtering... this is a great idea. It hadn't occurred to 
> me, and it is outside the scope of the additions I've been asked to 
> make, but I'll certainly bear it in mind as a possibility and do 
> everything I can to make my code a good foundation to build it on.

Fine.

> > If you have question about the code design...
>
> I'm sure I'll have lots. I already have lots of things I need to ask 
> about -  the hard part is framing the questions correctly, as it 
> always is. I'll probably ask a couple of things about wwsympa 
> tomorrow,[...]

You're welcome.

> On an unrelated subject, I had a question from a user about printing a 
> message without all the extra stuff that shows in the web interface. I 
> told her that the answer for now was to mail it to herself and print 
> it from her mail client, but are there any plans for a "Print view" 
> mode like many web-mail systems have? One of our reasons for adopting 
> sympa was to keep a lot of mail out of people's inboxes, and a "Print 
> View" mode would help us achieve that.

That's a good feature idea that could also be usefull on the REVIEW page,
please add an entry in Mantis for it : http://listes.cru.fr/mantis/

--
Olivier Salaun
Comite Reseau des Universites