Re: GSoC 15 : My proposed features for On-site Notifications project

On Thu, Mar 12, 2015 at 2:03 PM, Lokesh Walase <[email protected]> wrote:

> Hi all!
>
>
Hi,


> Kindly review my proposed features for the on-site notification
> gsoc-proposal <http://tickets.musicbrainz.org/browse/MBS-1801> :
>
> 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.
>
> (b) To stop notif :
>
>
>
> ​
> ​
>
> ​
>
> Alongside the notif there will be option to do so.
>
>
> *1.Notif. related to artists/subscribers/labels etc :*
> (a) On clicking on the "subscribe" option, editor will get 2 options  :
>        *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 :)).


> Now for every edit that happens to the subscribed option, she will be
> notified/emailed as per the setting.
>
> (b) To stop notif :
> 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).


> 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.


> *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.
> Is this *also* part of GSoC project?
>
>
I'd assume so, otherwise no one would be able to use it. :)


> (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
> [email protected]
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel
>

_______________________________________________
MusicBrainz-devel mailing list
[email protected]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel