Email notifications for users

Bug #929084 reported by Chris Johnston
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Summit
Confirmed
Medium
Unassigned

Bug Description

It would be nice for summit to send out email notifications for many different scenarios

Work items can be found in the blueprint.

description: updated
Changed in summit:
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
Michael Hall (mhall119) wrote :

Should users be able to unsubscribe to emails on a per-meeting basis, or just globally?

Revision history for this message
Chris Johnston (cjohnston) wrote :

That's probably a good point.

Revision history for this message
Stephen Doel (stephen-doel) wrote : RE: [Bug 929084] Re: Email notifications for users

Ideally, they can unsubscribe from meetings individually

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Chris Johnston
Sent: 10 February 2012 16:53
To: <email address hidden>
Subject: [Bug 929084] Re: Email notifications for users

That's probably a good point.

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/929084

Title:
  Email notifications for users

Status in Summit - The UDS Scheduler:
  Confirmed

Bug description:
  It would be nice for summit to send out email notifications for many
  different scenarios

  Work items can be found in the blueprint.

To manage notifications about this bug go to:
https://bugs.launchpad.net/summit/+bug/929084/+subscriptions

Revision history for this message
James Tunnicliffe (dooferlad) wrote :

What is the use case for unsubscribing from a single meeting? I can imagine wanting to get updates of different types to duplicate the update notifications that we get from blueprints (for a meeting without blueprints), but per-meeting seems very fine grained.

I was thinking that in terms of subscriptions we could have levels of interest indicated by the user and the user could assign different levels of email notifications to those, for example:

Participation essential
Participation preferred
Would like to attend
Not attending

I would suggest emails be triggered on events and that users get to tick which events trigger emails to which levels of interest they have specified.

In theory, you could mark yourself as not attending a meeting, but be interested in it enough to be kept informed. I have no idea if anyone would do this, but having a level of interest -> quantity of email you want mapping would probably be nicer to manage for users as well as being easier to code up.

Revision history for this message
Chris Johnston (cjohnston) wrote :

I would look at it as, I want to attend the meeting if I can, but it's not important enough for me to get spammed about changes.

Revision history for this message
Stephen Doel (stephen-doel) wrote :

At the moment, the Summit view allows you to "Attend This Meeting" or "Skip This Meeting". We should discriminate on the Attend, to essential and preferred as James suggests. I think the third level (would like to) is not necessary.

Then, perhaps you have a global settings you have access to around e-mail notifications. Default is you get notified for all Essential meetings and their changes only. You can then choose what else you have access to.

As James says, in theory we could also add that people want to monitor a meeting they are not attending. But I suggest waiting for user feedback to assess demand for that first.

Thx

Stephen

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of James Tunnicliffe
Sent: 14 February 2012 17:58
To: <email address hidden>
Subject: [Bug 929084] Re: Email notifications for users

What is the use case for unsubscribing from a single meeting? I can
imagine wanting to get updates of different types to duplicate the
update notifications that we get from blueprints (for a meeting without
blueprints), but per-meeting seems very fine grained.

I was thinking that in terms of subscriptions we could have levels of
interest indicated by the user and the user could assign different
levels of email notifications to those, for example:

Participation essential
Participation preferred
Would like to attend
Not attending

I would suggest emails be triggered on events and that users get to tick
which events trigger emails to which levels of interest they have
specified.

In theory, you could mark yourself as not attending a meeting, but be
interested in it enough to be kept informed. I have no idea if anyone
would do this, but having a level of interest -> quantity of email you
want mapping would probably be nicer to manage for users as well as
being easier to code up.

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/929084

Title:
  Email notifications for users

Status in Summit - The UDS Scheduler:
  Confirmed

Bug description:
  It would be nice for summit to send out email notifications for many
  different scenarios

  Work items can be found in the blueprint.

To manage notifications about this bug go to:
https://bugs.launchpad.net/summit/+bug/929084/+subscriptions

Revision history for this message
Chris Johnston (cjohnston) wrote :

With the number of attendees at UDS, I would be very hesitant to make required the default and then make it more work to attent and not be required. The number of required participants will usually be less than the amount who are just attending. Because of that, I would think leave not required default. At UDS there are a number of people who don't know how Summit works and them making themselves required when they shouldn't be could cause havoc to the rescheduler.

All this being said, we could possibly make an ajax-y popup that allows checking required and describes what it is for.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.