[Mailman-Developers] GSOC Project Discussion

[varun sharma]

Hi Steve,
I think it will be a good idea to provide an option of digests, as the case
you have mentioned may occur in a real situation.

Hi Richard,
Lets take an example of a moderator of some mailing list:

==Before going on vacaton==
1. If someone sends a "new user" request, the moderator will receive an
email in real time about request.
2. The task will be added to his and other moderators' ToDo list.

==During Vacation==
1. If someone sends a "new user" request, the moderator "on vacation" will
NOT receive any email about pending "add user" request.
2. The task will be added to his and other moderators' ToDo list.

==After Vacation==
1. He will receive all the emails as he was receiving before going on
vacation.
2. The pending tasks will show up in his ToDo queue
3. He will receive an email about the tasks done in his absence
4. He will receive email about pending tasks that were added to his ToDo
list and are still pending.


So, I think the overlapping vacation may be handled in two ways:
1. Follow up the procedure as written above , i.e: If there are multiple
moderators going on vacation for same span of time, then the tasks will
remain pending in their ToDo list .During vacations, they can login to the
postorius and see their pending tasks, but there won't be any email
notifications about the pending tasks during the vacation period. But there
will be no mailing list delivery.

2. Second option as it came to my mind after you mentioned this case is
that, the last moderator(assuming all other moderators have already set
thier "on vacation" mode without digests) going on vacation will not be
allowed to completely opt-out of emails. As steve suggested, we can provide
a digest mode for notifications also. So the last moderator going on
vacation will have to choose "digest" mode for notifications as well as
mailing list mail delivery if he want to go on vacation  :)


On Mon, May 20, 2013 at 1:36 AM, Richard Wackerbarth <rkw at dataplex.net>wrote:

> Varun,
>
> Perhaps I did miss-attribute the material. Thank you for pointing it out.
> I offer my apologies for doing so. Sometimes the "quote levels" get
> confused and it is not easy to tell which author provided some particular
> text.
>
> Since you appear to be the one responsible for the suggested behavior,
> would you please address the concerns that I raised about it.
>
> In particular, consider what mechanisms would be needed to handle your
> item 2 below (Knowing changes ...)
> What if there are multiple moderators who go on overlapping vacations?
>
> Richard
>
> On May 19, 2013, at 11:38 AM, varun sharma <varunsharmalive at gmail.com>
> wrote:
>
> > Hi Richard,
> > I think you have misunderstood my paragraph to be barry's. I was
> > suggesting the adding up of pending tasks of moderators and list
> > owners to their "ToDo" list during their vacation period with
> > suspension of email.
> > The phrase which you have mentioned, might be confusing. But actually
> > i was talking about two different operations.
> > 1. The mail delivery will be stopped for moderators as well as list
> > owners. So the moderators should also not receive any "add request
> > pending" email during the vacation period.The todo queue will remain
> > updated.
> > 2. The second thing is some moderators might be interested in knowing
> > the administrative changes done in their absence. So they should
> > receive a summary of the tasks done(eg. users added) in their absence
> > once they come back from vacation.This was what i was talking about in
> > that paragraph.
> >
> > On 5/19/13, Richard Wackerbarth <rkw at dataplex.net> wrote:
> >> On Sat, May 18, 2013 at 1:46 AM, Barry Warsaw <barry at list.org> wrote:
> >>>
> >>>> On May 13, 2013, at 10:52 PM, varun sharma wrote:
> >>>>
> >>>> Question: Should you be able to add a vacation stop to moderator or
> >>>> owner
> >>>> emails?
> >>>
> >>> I think the owner or moderators also should be allowed to use the in
> >>> vacation suspension of mails from the mailing lists they moderate or
> own,
> >>> given all the administrative tasks that need their attention must be
> >>> added
> >>> to their ToDo queue.
> >>> eg:
> >>> Lets say there is a mailing list that requires moderator's approval for
> >>> any
> >>> new user to join. If one of the moderator has set  "on vacation" for
> his
> >>> account, then he should only get "pending approval request"  in his
> ToDo
> >>> task list. If some other moderator responds to that request, then it
> will
> >>> be automatically removed from the ToDo list of all the moderators,
> >>> including the one "on the vacation" and the moderator "on vacation"
> will
> >>> never know if there was any request.
> >>>
> >>> Also there can be email alerts as soon as some task is added to the
> ToDo
> >>> list but if the user is "on vacation" then he will not receive any of
> >>> these
> >>> emails until he disables his "on vacation" flag. All the pending ToDo
> >>> tasks/(tasks done in his absence) may be emailed him at once when he
> >>> comes
> >>> back from the vacation.
> >>
> >> Barry,
> >> You have used some phrases that cause me to infer that the -core would
> have
> >> to keep extensive information about moderation requests.
> >>
> >> For example: "(tasks done in his absence) may be emailed him at once
> when he
> >> comes back from the vacation."
> >> I hope that you meant "tasks NOT done". Otherwise, someone would have to
> >> maintain a history of the tasks. (Although such an archive would appear
> to
> >> be a task more appropriate for the KittyStore and HyperKitty retrieval
> >> mechanisms.
> >>
> >> Now, since "-core" maintains the queue of pending tasks and is also the
> >> agent that sends out emails, do you propose the add an "on demand" type
> of
> >> "digest" for the moderation queue?
> >> We might think of this as a rendering of the current task queue in an
> >> RFC-822-styled format analogous to the REST request that is delivered
> in a
> >> JSON based format. Presumedly, since this is a "push" notification, the
> >> "return from vacation" process could trigger this request.
> >>
> >> Richard
> >>
> >>
>
>