Talk:Requests for comment/Notification framework

Previous page history was archived for backup purposes at Talk:Requests for comment/Notification framework/LQT Archive 1 on 2015-07-10.

Here are a few draft use cases. This list shouldn't be taken too literally. The cases here are meant to provide an idea of the types of emails that the notification should support.

These also assume the lack of a threaded discussion system.

(not in any specific order)

• When someone leaves a message on my talk page, I receive an email which includes the following information:
  • Username of the person who wrote on my talk page
  • Content of the message left on my talk page (including section heading)
  • Instructions on how to reply

• When I register for an account on Wikipedia, I get an email welcoming me.

• When I complete my first successful edit on Wikipedia, I get an email congratulating me. Email contains more ways for me to get involved.

• When I reach autoconfirmed status, I get an email letting me know I can edit BLPs’s (I’m not suggesting we actually do this -- I’m just trying to give a sense for the type of functionality).

• When I complete 100/500/1000/etc edits, I receive an email congratulating me.

• After completing 10 edits and xx amount of time, I receive an email with “tutorial” type information. (Idea here is that we send out more tutuorial information on syntax, policy, etc. for editors who show that they are well-intentioned).

• When someone reverts my edit, I receive an email letting me know what happened and why.

• When I submit a page for creation, I receive an email letting me know that my page has been submitted for creation.

• When the page I submitted changes state, I receive an email letting me know what happened.

• I receive an email when someone expands an article I created, letting me know what the additions were and who made them.

• When I rate my first article, I receive an email thanking me. (Rating could mean adding a comment)

• When my rating comment gets promoted to the talk page, I get a message letting me know, with a link to the talk page discussion.

• When I rate my 5th article, I receive an email thanking me for my contributions, and encouraging me to try to edit.

• I can opt to receive periodic emails about Wikip/media developments (e.g., new features)

• I can sign up for emails about specific Wikiprojects.

• If I stop editing for x weeks, I receive an email encouraging me to resume editing.
• When a page I recently edited gets a template, I receive an email letting me know what happened in plain language.
• When my talk page gets a template, I receive an email letting me know what happened in plain language.
• When a bot does something, I receive an email letting me know what the bot did, without referring to the bot/requiring me to know what a bot is.

• Email controls:
  • I can opt to receive no emails.
  • I can opt to receive all my emails in a dailly or weekly digest.
  • I can consolidate emails by type (e.g., all emails about users editing my talk page)
  • I can opt out of emails by type (e.g., automatic congrats emails, talk page notifications, etc.)

• We should have ways to ask for emails from users that haven't provided (e.g., user submits a MoodBar comment but hasn't provided an email address.

This post was posted by Howief (WMF), but signed as Howief.

All sounds good! Lots of the individual items there are things that should be configurable or apply to a specific extension setup, but common infrastructure should serve them all well.

Just wanted to note that the Wikia notification system seems to do some of this already, like "achievements".

Leaving the backends up to an abstract system that lets extensions plug-in new types of notification backends would be a good idea.

I'm starting to get interested in the idea of some extension sending out some message over a socket to something that sends out some XMPP or maybe even growl notification.

The current design (as discussed, but not written up) is that individual extensions will be able to define types of notifications and how they are to be handled. And then the user can choose which notifications they wish to receive and so forth.

Each extension will "publish" to the broadcaster, who then Does The Right Thing. Modifying the Broadcaster could possibly do things like spit out XMPP notifications and the like; that's a clever idea that I hadn't thought about.

Given your note on having multiple types of notifications we may actually want to formally include the possibility of any number of notification broadcast types.

Given one type of notification type input it's easy for an extension to simply come up with it's own preferences checkboxes. But given a number of possible notification types and a number of possible ways of being notified we may actually want to build this using some sort of specialized grid of preferences. One where say the horizontal axis is the types of output email, iOS/Android app push, XMPP, and other plugins and the vertical access is the types of notifications you may receive.

Something like that will probably be a huge mess to create unless we formally include the notion of any number of notification source types and any number of possible notification outputs.

Have we looked into what Wikia is doing? I bet they have something we can use.

http://help.wikia.com/wiki/Help:Notifications

These are bubbles which pop up for the user, but I see some things in their code which suggest you can get them by email. This seems to be all connected in their Oasis / Notifications module, but I could be wrong.

https://svn.wikia-code.com/wikia/trunk/skins/oasis/modules/

Inez wrote a bunch of this so maybe we can ask him.

We've actually talked a lot with Wikia about their notifications system. The week before Christmas, Howie, Brion and I met with them and got a full dump of how their system works and its dependencies. It's pretty fresh, which is why I'm planning on stealing a lot of the design from them.

However, their underlying technology stack makes it pretty difficult for us to re-use their code. It's really dependent upon their local frameworks, and chopping that out may be more effort than just writing from scratch.

etherpad:NotificationNotes

At no.wp I made a notification system, and there was one very interesting lesson learned. Those who used the system got comments about their presence in every discussion. Over time it seemed to polarize the community and escalating trends in the community. I'm not sure exactly why this happened, but it could seem like those users using the system outrun other users and the later got frustrated. People were used to hang around a long time before posting replies and didn't realize that other users got instant warnings about upcoming discussions.

The expected behavior is not the polarization of discussions, rather the system (ie the on-going dialogue ) as a whole should be become more stable when the delay between interactions goes down. That was the idea. The frustration could come from some people (myself was one of them) outrun other people, that is people experiencing different delay and because they were used to be the first one to comment on a thread the feeling of power was shifted.

The system is pretty simple. The watchlist is polled from m time to time to see if anything interesting shows up, and if so warns the user. If the user visits a page it will also be put on a temporary watchlist. If something goes in the RC-feed then a notification is shown in the lower right corner of the window, and after a short delay is removed again. This happens independent of loading of other pages, but unloading a page can interrupt an on-going notification that will not be repeated after the next load. If redesigned it should probably use session storage instead of cookies, and it should probably try to resume interrupted notifications. It is also possible to load the watchlist only once and store it in the session storage to avoid polling the watch list feed continuously.

The gadget is still available, but I don't know if anyone use it anymore.

See also User:Jeblad/Notifications

We've got a watchlist feature where it'll stop sending you e-mails until you view the page, and an open bug on how this makes it easy to view or ignore it in a way that makes it so that you stop getting notifications you DO want.

That does bring up an idea here. We can have e-mail notifications on each notification and a "Don't email me individual notification emails" option (maybe a clearer name) that will send out one e-mail and won't send out another until the user has visited the Special: page with notifications. Unlike articles a notification Special: page requires you to be logged in to see, and as a result doesn't suffer from the same issue.

If it's a low traffic wiki, seeing a series of diffs for articles as separate notifications in a notification area might be nice too.