Last modified: 2014-05-19 17:02:53 UTC
When a user has a beta feature enabled, and that feature receives a major update (functional change, new browser support, major blocker bug fixes, etc) user should receives an echo notification about the changes and link to the project or talk page with a change log or summary of major updates.
Picking one of these related new Echo notification requests to comment about the whole pack. Jared explained that one idea was suggested at the hackathon in Zürich: new contributors could be pointed to requests for new Echo notifications. They could create them relatively easily, based on the current notifications and with the help of the design team for the graphics. Dear community fellows, please confirm whether (under these circumstances) this is a EASY task. Help also prioritizing the notifications you would like to push first. Thank you.
(In reply to Quim Gil from comment #1) > Dear community fellows, please confirm whether (under these circumstances) > this is a EASY task. Help also prioritizing the notifications you would like > to push first. Thank you. I wouldn't say it's easy to create new types of Echo notifications, unless you're already familiar with how the formatters work.
It's not easy, but it's also not totally crazy. You would need a table, keeping track of the beta features, the version of the feature etc. Then check the registrations for the beta features once in a while, see if a new notification needs to be created and scheduled. put the job on the queue and write to the table that you have sent a 'new', 'updated' or another type of notification etc. Ideally we expand echo with some 'action' options, so that users can 'opt-in' to a new feature right from the notification for instance, but that is secondary. Versioning of beta features is important for this one btw. You could have x.y.z x: for generation (the 6 month test period) of an experiment feature (this would send 'new' beta feature motifs) y: significant updates to the experiment (a monthly update, sending feature updated motifs) z: minor changes or revision number or something (small css fix) that don't warrant a notification.
So maybe a single task is not EASY, and neither good for Google Code-in, but a family of Beta notifications requests could become a good internship project? If so, the proposal could be added to https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects
(In reply to Quim Gil from comment #4) > So maybe a single task is not EASY, and neither good for Google Code-in, but > a family of Beta notifications requests could become a good internship > project? If so, the proposal could be added to > > https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects Possibly. However, I think it's wildly premature to add these as advertised projects when there's still considerable debate as to whether these are WONTFIX tasks.
Fair enough. Where is that debate happening?
(In reply to Quim Gil from comment #6) > Fair enough. Where is that debate happening? It's not actively happening.
(In reply to Derk-Jan Hartman from comment #3) > It's not easy, but it's also not totally crazy. > > You would need a table, keeping track of the beta features, the version of > the feature etc. > > Then check the registrations for the beta features once in a while, see if a > new notification needs to be created and scheduled. put the job on the queue > and write to the table that you have sent a 'new', 'updated' or another type > of notification etc. I was thinking of just using a maintenance script whenever a new feature is updated/deployed, that way we don't need a table to keep track of anything, but just do it manually.
