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.

Sounds like this is easier requested than enacted, but I think for the purposes of engagement it would be extremely helpful to have. Is there anything I can do to support?

@Rdicerb I think @Legoktm's solution should work fairly well, and shouldn't be *that* hard to set up (a week at worst?). After that, it's a matter of running it manually every time people who maintain the beta feature think it is 'updated' enough - that can be part of the deployment process for beta features.