Skip to Content.
Sympa Menu

devel - RE: [sympa-dev] Information about development status?

Subject: Developers of Sympa

List archive

Chronological Thread  
  • From: "Adam Bernstein" <address@concealed>
  • To: "Olivier Salaun - CRU" <address@concealed>
  • Cc: <address@concealed>
  • Subject: RE: [sympa-dev] Information about development status?
  • Date: Fri, 18 Jul 2003 17:58:13 -0700

> I know we did not communicate much on develpments essentially because we
> did not
> have much time to do it and because we could not precisely evalute what
> new developments
> could be done.

I understand perfectly -- but it really would be helpful just to see the
requested feature list, so we know whether or not to put in a new request.
We can see some by choosing "severity: feature" in the bugtracker, but
there were many more on the list that aren't in the bugtracker. How about
a separate Web page collecting them all? Or maybe a separate bugtracker
queue?

> I don't think we'll have time to develop much more features...but
> contributions are welcome :)

Okay, sounds like text digest would be the next big one. Several people
have had rough versions of that lately -- anyone ready to share?

> We'll definitely have an automatic bounce management system at the end
> of this summer. This work in not finished yet so please tell us abou
> your design : we could grab some good ideas.

Here's the algorithm we plan:

To the bounce-handling code will be added the following behavior, with the
variables representing parameters controlled by the list
administrators:
· Each soft (temporary) bounce increments the bounce counter by one.
· Each hard (permanent) bounce increments the bounce counter by *N*
soft bounces.
· Set a subscriber to "inactive" mode (same meaning as the current
"no_mail" mode) if their bounces total more than *X* over a
minimum of *Y* days.
· Automatically unsubscribe every address that remains "inactive" for
*Z* days.
There will be a new Web page for manually reactivating bouncing subscribers
or resubscribing those automatically unsubscribed.

We need the ability to re-subscribe people that have been automatically
unsubscribed, which will involve adding to and changing the information
that's stored in the database. We expect to add an "unsubscriber_table"
containing all previous subscribers, including a field showing how/why
they were unsubscribed, but it could be done more simply than this. You
could also just omit the final step in the above process (unsubscription),
and it would still be an acceptable scheme.

adam




Archive powered by MHonArc 2.6.19+.

Top of Page