(In reply to comment #0)

As a substitute of a bot, MassMessage inherits a subscription model based on
entries listed in wiki pages. This is a very fragile process, open to abuse
and user mistakes.

Open to abuse how? Wiki pages provide full accountability and transparency, unlike user preferences.

That said, catching/preventing user mistakes (or more directly: simplifying the subscription process) is the actual underlying bug here, I think.

A first step wold be very basic: subscribe to all notifications / unsubscribe
from all notifications.

I can't imagine any use-case for this. As far as I'm concerned, this is a non-starter.

A possible next step would be to allow subscriptions per "channels" or
"newsletters".

We already have this, it's just implemented via wiki pages instead of via user preferences. Perhaps something like [[mw:Extension:LogEntry]] or [[mw:Extension:InputBox]] could be adapted to make subscribing easier. Maybe. Unsubscribing would be tricky, though. A small JavaScript gadget could easily be written to make adding and removing users from a list easier, but that wouldn't solve the possible use-case of wanting to see (as a subscriber) every newsletter to which you are subscribed.

I don't think this is a MassMessage bug. Perhaps an Echo bug. Perhaps an "Extensions requests" bug. But this seems likely out of scope for MassMessage.

(In reply to comment #1)

(In reply to comment #0)

As a substitute of a bot, MassMessage inherits a subscription model based on
entries listed in wiki pages. This is a very fragile process, open to abuse
and user mistakes.

Open to abuse how? Wiki pages provide full accountability and transparency,
unlike user preferences.

Unlike user preferences, anybody can edit the pages that MassMessage relies on. Sure, if someone deletes 60 entries this will be noticed, but the risk of having users doing small changes adding/removing someone else's entries is high.

That said, catching/preventing user mistakes (or more directly: simplifying
the
subscription process) is the actual underlying bug here, I think.

Agreed.

A first step wold be very basic: subscribe to all notifications / unsubscribe
from all notifications.

I can't imagine any use-case for this. As far as I'm concerned, this is a
non-starter.

3rd party MediaWiki with a bunch of users wants to send them notifications from time to time. Maye I didn't describe a correct first step, but the use-case responds to a real need.

I don't think this is a MassMessage bug. Perhaps an Echo bug. Perhaps an
"Extensions requests" bug. But this seems likely out of scope for
MassMessage.

It would be good to have a firm answer from the MassMessage maintainer(s). Currently MassMessage looks like the closest tool to deliver this needed feature. However, if you decide this functionality is out of scope then yes, we will need to find another way to do this.

Sorry about not responding to this sooner.

(In reply to comment #0)

As a substitute of a bot, MassMessage inherits a subscription model based on
entries listed in wiki pages. This is a very fragile process, open to abuse
and
user mistakes. It is also a process that puzzles most humans out there.

I agree that the {{#target}} syntax is not very friendly to users, and could definitely be made better, but I don't think that preferences are the way to go.

A first step wold be very basic: subscribe to all notifications / unsubscribe
from all notifications. A possible next step would be to allow subscriptions
per "channels" or "newsletters".

I don't believe this fits MassMessage's model very well. Input lists aren't tracked by the extension, and can be created by any user at any time. Messages might be sent out once, or they might be sent out regularly.

If you want to let users sign up for all notifications, just create a central list, and transclude that list on individual lists for each "newsletter".

I think this kind of functionality belongs in Echo (bug 56362 or bug 56361), though I remember being told Flow was going to handle subscriptions...

(In reply to comment #2)

Open to abuse how? Wiki pages provide full accountability and transparency,
unlike user preferences.

Unlike user preferences, anybody can edit the pages that MassMessage relies
on.
Sure, if someone deletes 60 entries this will be noticed, but the risk of
having users doing small changes adding/removing someone else's entries is
high.

This works both ways. Most wikis (anyone who isn't the WMF basically) don't keep logs of when a user's preferences change, so if a user sets it and then wonders why they're receiving the notification, there is no log available to verify it.

I know there were complaints of not being able to stop the Translation Notification Bot from posting on a user's talk page - only the user could change it in their settings.

It would be good to have a firm answer from the MassMessage maintainer(s).
Currently MassMessage looks like the closest tool to deliver this needed
feature. However, if you decide this functionality is out of scope then yes,
we
will need to find another way to do this.

I don't plan on adding a subscription ability to MassMessage via user preferences, nor do I think it makes sense for the extension. Echo is probably the closest to what I think you're looking for IMO.

(In reply to comment #3)

I don't plan on adding a subscription ability to MassMessage via user
preferences, nor do I think it makes sense for the extension. Echo is
probably the closest to what I think you're looking for IMO.

Ok, thank you for the clear answer. This is a WONTFIX for MasMessage, then.

Fabrice, Maryana, do you think this request has any future in the context of Echo or Flow? Otherwise this would be a request for a completely new extension.

In T59935#788056, @Aklapper wrote:

@Fabrice_Florin, @Maryana, do you think this request has any future in the context of Echo or Flow? Otherwise this would be a request for a completely new extension.

@DannyH ^ (as the inheritor of Echo, along with the corefeatures team ;)

Personally, I'm still hoping for

M12 Newsletter subscriptions panel

21

Yes, @Quiddity, that seems like the most reasonable approach to me as well. But let's please have the following user stories in mind from the start:

• As a user, I want to be able to subscribe to a global newsletter that interests me, without having to visit a separate website.

• As a user, I want to be able to see the most popular newsletters, or see newsletters of specific types (e.g. WikiProjects).

• As a user, I want to find the most recent issue or a sample issue of a newsletter quickly.

Each of these seem important for the first release of such functionality:

• Global newsletters facilitate discovery of content and updates from around the wiki-verse, and therefore we should not hide them away, but put them on equal footing with locally created newsletters.

• Long lists become unwieldy, and simple classifications/tags and table-sorts help keep it manageable.

• Sample issues are a good way to decide whether you want to subscribe to a newsletter. Each will tend to have its own landing page with its own navigation, which imposes cognitive load on the user to find information they will need to make an informed decision. We can eliminate that load by having a standard discovery mechanism for sample issues.

I understand Kunal's concern regarding the MassMessage extension as a possible foundation of this work. However, what Nick describes is definitely the direction I'd like us to go for newsletters. It seems likely to me that we'd want to share some code (for authoring/previewing messages, distributing via user talk, etc.), but perhaps not enough to justify bloating the MassMessage extension.

This isn't a WMF project yet, but let's think about the relative priority and complexity. It would IMO be a major win to improve Wikimedia-wide communications effectiveness across the board.

I really hope ths feature gets the attention it deserves. Our resources allocated in community communication, reader conversion, and editor retention keep growing, and I believe this would be a relative simple/cheap project in comparison, that would have a quick return of investment.

I have been pitching for it whenever someone was listening, not very successfully as you can see.

If nobody at the WMF will work on this anytime soon... Could we consider the possibility to have some contractor budget? I can also push it for a mentorship project or Individual Engagement Grant if I can get a technical mentor / code reviewer.

Now that we are developing T76199: Goal: Newsletter extension for MediaWiki with humble resources but high speed, I think it is better to decline this task and focus on Extension:Newsletter, which will offer a special page to browse and subscribe/unsubscribe to newsletters (T100492).

Should we close this task as Declined, or merge it with T100492: Implement 'Subscribing and unsubscribing' feature for Newsletter extension?

I think we should merge it as - we are declining this feature - only for 'now'. Once the extension matures, we might want something in the Special:Preferences too ( which might not be necessarily listing of newsletters - as it can get too lengthy to be in a single preference tab )

In T59935#1359774, @wctaiwan wrote:

I'm going to close it as declined because the task started out as a feature request for MassMessage, and has since become a feature request for the newsletter extension.

Safe to close in that case.