[mb-devel] GSoC 15 : My proposed features for On-site Notifications project

Michael Wiencek

2015-03-16 18:11:45 UTC

Hi,

Post by Lokesh Walase
Kindly review my proposed features for the on-site notification
N.B : Notification is henceforth abbreviated as notif.
*0. Notif. related to the edits :*
(a)After a editor creates a new edit, whatever actions( yes/no/comments )
that happen on that edit, the user will be sent a notif.
If any other editor triggers some action on a edit, she will also be
notified all future actions on the edit automatically.( default behavior )
For actions related to a edit, there won't be email option i.e
compulsorily notif. only.
â
â
â
Alongside the notif there will be option to do so.
*1.Notif. related to artists/subscribers/labels etc :*
*Notification only
*Email only

They might want to receive both types of notifications, which the 'only'
makes it sound like they won't (maybe you had this in mind but didn't
choose the most ideal wording :)).

Post by Lokesh Walase
Now for every edit that happens to the subscribed option, she will be
notified/emailed as per the setting.
Same as it happens now - click on "un-subscribe"
*2.Edit closed :*
After an edit is closed, unsubscribe all the actors from the edit.
( I think this will happen automatically, since edit page itself will be
sort of frozen, so no action will be triggered)

People can still leave comments on an edit after it's closed, and emails
are sent to everyone who voted on it, so that'd be a change from the
current system (not that it couldn't be configurable if people want it to
be).

Post by Lokesh Walase
Basically, when a user checks her "subscriptions" page, that should be
updated.
*3.Notif Structure :*
(a) Edit on __ has __ yes votes
(b) Edit on __ has __ no votes
(c) User __ commented on edit __
i.e the notif. should be "grouped". The receiver should not get 1 notif.
per action on a given edit.

I'm not sure what you mean by "grouped" here. Grouping them by action could
be confusing if you have multiple notifications for a single edit, and have
to move between the groups to see how things happened chronologically. I
think just displaying them in order as they happened makes more sense.

Post by Lokesh Walase
*4.Unread Notif :*
If someone has unread notifications for more than $x days, send them an
email anyway.
---------------------------------------------------------------------
*Things I am exploring now : *
(a)Explore various settings options related to notif. on popular websites
( FB, Quora, Twitter) & find anything suitable to MusicBrainz
(b)Find out how notif. system can be build using python.
Kindly let me know if I'm moving in right direction.
---------------------------------------------------------------------
*Doubts : *
(a)All above changes are from end-user's view.
Am I expected to do deeper analysis for the proposal?
What more points shall I brain-storm on? ( Database changes, new tables
etc )

I'm interested in what changes to the database schema you'd propose, and if
you'd be writing this as a separate project in another language (e.g.
Python), how you'll be communicating with the perl code. More
implementation details should only improve your chances of being accepted,
anyway, since we can then be more sure you'll know what you're doing. :)

Your email also mostly focuses on edit notifications and doesn't mention
anything about messages between users, so it'd be good to add some
information about that too.

(b)Lot of UI changes will be required for this proposal.

Post by Lokesh Walase
Is this *also* part of GSoC project?

I'd assume so, otherwise no one would be able to use it. :)

Post by Lokesh Walase
(c)I'm not sure if I can implement all of the above features. I'm just
brain-storming.
I am right now analysing the efforts required.
(d)What is the preferred UTC time for IRC chat?
~ Lokesh Walase
_______________________________________________
MusicBrainz-devel mailing list
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel