Does it have the same problem as the global message delivery system on wikis which use LiquidThreads?
(see [[meta:User talk:EdwardsBot/Archive 1#LQT compatibility]])

(In reply to comment #1)

Does it have the same problem as the global message delivery system on wikis
which use LiquidThreads?
(see [[meta:User talk:EdwardsBot/Archive 1#LQT compatibility]])

The real bug is that those wikis are still using LiquidThreads. :-)

But if you want to add a dependency bug about MassMessage supporting LiquidThreads, it shouldn't be too painful to code.

For reference: https://gerrit.wikimedia.org/r/#/q/project:mediawiki/extensions/MassMessage+status:open,n,z.

(In reply to comment #1)

(see [[meta:User talk:EdwardsBot/Archive 1#LQT compatibility]])

The correct link is [[User talk:EdwardsBot/Archive 1#LQT compatibility]].

Hi Legoktm, I see that http://www.mediawiki.org/wiki/Extension:MassMessage exists but where is its bugtracker? See https://www.mediawiki.org/wiki/Bug_management/Project_Maintainers#To_add_a_project_or_component

(In reply to comment #5)

Hi Legoktm, I see that http://www.mediawiki.org/wiki/Extension:MassMessage
exists but where is its bugtracker? See
https://www.mediawiki.org/wiki/Bug_management/Project_Maintainers#To_add_a_project_or_component

Filed as bug 52730.

Hello, this is a quasi-automated-but-not-really message:

I am reviewing all tracking bugs for extensions to review and deploy to WMF servers. See the list here:
https://bugzilla.wikimedia.org/showdependencytree.cgi?id=31235&hide_resolved=1

The [[mw:Review queue]] page lists the steps necessary to complete the review. I have copied them below and done some initial filling out based on what I can easily gleen from this bug and any linked to sources that are obvious. If I miss something/state something false, please do correct me.

Also, if you haven't yet done so, please review the information on and linked to from:
https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment

TODO/Check list

Extension page on mediawiki.org: yes
Bugzilla component: yes
Extension in Gerrit: yes
Design Review: no
Archeticecture/Performance Review: no
Security Review: no
Screencast (if applicable): no
Community support: no?

Thanks for writing out a checklist.

(In reply to comment #7)

TODO/Check list

Extension page on mediawiki.org: yes
Bugzilla component: yes
Extension in Gerrit: yes

Right.

Design Review: no

Not sure this is relevant as this extension isn't really user-facing, but if you want to find someone to review the design, go for it.

Architecture/Performance Review: no
Security Review: no

These are the two areas needed here.

Greg: how do we get this extension reviewed for architecture/performance and security?

Screencast (if applicable): no

Not sure what this is about. It seems irrelevant.

Community support: no?

Yes, plenty of it.

(In reply to comment #8)

Thanks for writing out a checklist.

:)

(In reply to comment #7)

TODO/Check list

Extension page on mediawiki.org: yes
Bugzilla component: yes
Extension in Gerrit: yes

Right.

Design Review: no

Not sure this is relevant as this extension isn't really user-facing, but if
you want to find someone to review the design, go for it.

Well, for some definition of user, right? It has sysop user facing UI. For a design review, the Design mailing list is a good place to start (and then ping until success).

Architecture/Performance Review: no
Security Review: no

These are the two areas needed here.

Greg: how do we get this extension reviewed for architecture/performance and
security?

First pass would be to send a note to wikitech-l asking for help. Unfortunately, this week is a combined Tech Days and All Hands so WMF tech staff will be slower to respond than normal, but I know you know who to ping as needed (Aaron/Tim for arch, Chris for security).

Screencast (if applicable): no

Not sure what this is about. It seems irrelevant.

Well, if there are any userfacing bits (even for non-mortals), then it'd be good to have a walk-through of how the extension is supposed to work/what the process is. Think of it as a required bit of user documentation :)

Community support: no?

Yes, plenty of it.

Awesome. I believe you, but would appreciate links to where discussion has happened.

(In reply to comment #9)

Community support: no?

Yes, plenty of it.

Awesome. I believe you, but would appreciate links to where discussion has
happened.

Long wanted feature to not have to have bots making tens/thousands of edits onwiki. Not sure a discussion par se would have happened.. (if one has, great)

To users, it really doesn't matter where it comes from.

(In reply to comment #9)

Not sure this is relevant as this extension isn't really user-facing, but if
you want to find someone to review the design, go for it.

Well, for some definition of user, right? It has sysop user facing UI. For a
design review, the Design mailing list is a good place to start (and then
ping until success).

Lego: please go ahead and e-mail the design mailing list (include a working demo of the tool, of course). If they have constructive feedback, wonderful. Otherwise, I don't consider this a blocker to deployment.

Greg: how do we get this extension reviewed for architecture/performance and
security?

First pass would be to send a note to wikitech-l asking for help.
Unfortunately, this week is a combined Tech Days and All Hands so WMF tech
staff will be slower to respond than normal, but I know you know who to ping
as needed (Aaron/Tim for arch, Chris for security).

Lego: please go ahead and e-mail wikitech-l asking for a review once you're ready and you've done your best to ensure that the extension is in a reviewable state. Test rigorously!

If you could cross-reference these two mailing list posts on this bug, that would be wonderful.

Well, if there are any userfacing bits (even for non-mortals), then it'd be
good to have a walk-through of how the extension is supposed to work/what the
process is. Think of it as a required bit of user documentation :)

If you write docs about how to create one of these mythical screencasts, I'll consider it. In the meantime, over a decade of development has progressed without these being a requirement. We're not going to start with this extension. :-)

Community support: no?

Yes, plenty of it.

Awesome. I believe you, but would appreciate links to where discussion has
happened.

This request is a blocker to bug 35306. It falls outside the requirement for community consensus as it's an obvious and uncontroversial enhancement request; it is replacing a non-production, largely unsupported tool (i.e., the Python script that currently powers [[m:Global message delivery]]); and it has limited exposure (only admins will have access by default, and even most admins won't use this tool... for now).

Bug 35306 gives most of the background here, but it's probably reasonable for me to point out that many (if not most) global message deliveries are connected to Wikimedia Foundation staff. The targets lists at [[m:Global message delivery/Targets]] comprise hundreds (maybe thousands) of users who have signed up for various newsletters and other mailings, in addition to a number of distribution lists used by Wikimedia volunteers and staff (including technical announcements and other breaking changes announced to [[m:Distribution list/Global message delivery]]). You could consider this a third or fourth exemption to the community consensus guideline, if you'd like. ;-)

The goal is to get this extension deployed (to phase 0 wikis) by the end of September. I'm not sure if this will be possible, but I've tentatively added it to the deployments calendar for September 30: https://wikitech.wikimedia.org/w/index.php?diff=83188&oldid=83134#Near_term.

Lego: feel free to move the date into October if necessary.

CC'ing Dan Garry (new Platform PM). No action needed Dan (yet ;) ). Just using this as a way to remind us to talk about this work and how you'll interface with it.

(In reply to comment #11)

(In reply to comment #9)

Not sure this is relevant as this extension isn't really user-facing, but if
you want to find someone to review the design, go for it.

Well, for some definition of user, right? It has sysop user facing UI. For a
design review, the Design mailing list is a good place to start (and then
ping until success).

Lego: please go ahead and e-mail the design mailing list (include a working
demo of the tool, of course). If they have constructive feedback, wonderful.
Otherwise, I don't consider this a blocker to deployment.

Email sent to design list: http://lists.wikimedia.org/pipermail/design/2013-September/000923.html

I just spent a few minutes talking with Chris who said he would be able to do a security review of the extension this week.

Currently waiting for a few patches to be reviewed and then I'll send an email to wikitech-l.

Just an update, I'm still working on the review. There were a few bits that looked odd as I was testing, so I'd like to dig into those before giving the all clear. Should be able to get that finished on Monday.

There was a request to see if this extension would make sense as an improvement to Notifications/Echo. This discussion would probably be good to have with the WMF product team (maybe including Fabrice, Terry, and Howie).

I'll default to defer for now, until that conversation happens.

(In reply to comment #17)

There was a request to see if this extension would make sense as an
improvement to Notifications/Echo. This discussion would probably be good to
have with the WMF product team (maybe including Fabrice, Terry, and Howie).

This already took place at bug 35306.

I'll default to defer for now, until that conversation happens.

I don't know what this means. Can you clarify?

(In reply to comment #18)

(In reply to comment #17)

There was a request to see if this extension would make sense as an
improvement to Notifications/Echo. This discussion would probably be good to
have with the WMF product team (maybe including Fabrice, Terry, and Howie).

This already took place at bug 35306.

Right, so, I'm deferring judgement on that (and related) conversations to Terry C and Howie F right now. More on why below...

I'll default to defer for now, until that conversation happens.

I don't know what this means. Can you clarify?

Mostly, I brought this (deploying MassMessage) up in a Deployment updates meeting, and there was some push back from a product view. In short: "shouldn't this functionality be built into something like Echo?" So, I won't go around them and deploy MassMessage everywhere until that conversation is settled (for some value of "settled").

Now, what we should do is deploy MassMessage somewhere so you/others can test its functionality on a WMF production-like site. Let's get this out to test2.wikipedia this Thursday. Filed bug 54518 for that.

Err, I mean, after Chris S gives the all clear, security-review-wise: https://bugzilla.wikimedia.org/show_bug.cgi?id=52723#c16

After a couple of updates, it all looks ok from the security side.

Some updates:

MassMessage was successfully deployed to test and test2 today (thanks Reedy!). I did a few simple tests making sure everything worked fine (https://test.wikipedia.org/w/index.php?title=Special%3ALog&type=massmessage&user=Legoktm&page=&year=&month=-1&tagfilter=&hide_patrol_log=1&hide_review_log=1&hide_thanks_log=1)

MZMcBride has sent out a message to people who currently use EdwardsBot on enwiki and meta asking them to test it on testwiki and provide feedback (https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Spam&oldid=5895864).

We're still waiting on comments from Fabrice/Howie/Terry (bug 35306 comment 20).

[[mw:Help:Extension:MassMessage]] has documentation on how an administrator would use the special page to send out a message. [[m:MassMessage]] has also been created.

(In reply to comment #22)

Hah! I just came here to write pretty much the same comment. Brilliant. Thank you, Lego.

Testing is underway (cf. [[testwiki:Special:Log/massmessage]]) and feedback has started to come in (cf. [[m:Talk:MassMessage]]).

(In reply to comment #19)

Mostly, I brought this (deploying MassMessage) up in a Deployment updates
meeting, and there was some push back from a product view. In short:
"shouldn't this functionality be built into something like Echo?" So, I won't
go around them and deploy MassMessage everywhere until that conversation is
settled (for some value of "settled").

I'm still awaiting feedback from Terry, Howie, or Fabrice on bug 35306 (I also e-mailed them yesterday with a pointer to the bug), however Lego pointed out to me that Echo doesn't currently support cross-wiki notifications, so Echo integration is probably completely off the table for now.

I think a month of testing is sufficient for this extension, so I've tentatively scheduled a deployment to all Wikimedia wikis for the end of October (cf. https://wikitech.wikimedia.org/w/index.php?diff=84903&oldid=84888#Near_term). You know the calendar much better than me, though, so let me know if that's a particularly bad time for whatever reason.

There is some overlap with Echo with this. On the other hand, there are some things that this might be suited for, such as the delivery of the Wikipedia Signpost. It's my view that an in-built solution to replace EdwardsBot would be useful, and if we enable this extension we could always disable it should Echo supersede it.

I'm CCing Fabrice Florin, the product manager for notifications, to see if he has any input.

(In reply to comment #25)

There is some overlap with Echo with this.

In general, yes. Both extensions provide a 'notification' functionality, however there are some pretty big differences as well.

1. Echo notifications for the most part are private; only you can see your Echo notifications. MM is designed so that everything (target list, message content) is fully public.

2. Echo is centered around users, given that you can only send notifications to users. MM can send to basically any page, which is necessary for global message delivery (most messages are sent to village pumps, not users directly).

3. Echo notifications are quick short messages that usually are just a link to something else. In many cases, EdwardsBot delivers the whole message to your talk page (example: https://en.wikipedia.org/?diff=prev&oldid=565236352). In this regard MM has been designed so that the end user receiving the message would not see any difference.

(In reply to comment #25)

if we enable this extension we could always disable it should
Echo supersede it.

I don't think merging MM into Echo is a good idea. Rather, MM should use Echo notifications instead of talk page ones if $wgMMUseEcho is enabled. Or something like that...

As someone that has discussed the topic of mass notifications / announcements / newsletters with many people I agree with the approach being proposed here:

• MassMessage solves a problem here and now by deprecating EdwardsBotwith a better solution.

• There is a possibility to integrate an Echo plugin to MM in the future, but this is no blocker for a deployment to Wikimedia wikis now.

• There are other future possibilities around announcements / newsletters in the future, in the lines proposed at https://www.mediawiki.org/wiki/Extension:Newsletter#Wishlist and MassMessages might or might not be a good project to handle this, but again this is no obstacle for a deployment now.

tchay wrote:

We have two separate but related bugs here:

https://bugzilla.wikimedia.org/show_bug.cgi?id=35306
https://bugzilla.wikimedia.org/show_bug.cgi?id=52723

bug 35306 is an tracking bug MZMcBride posted for a solution to deal with EdwardsBot. I believe it dates to around the time I was first employed almost two years ago.

bug 52723 is a recent bug to deploy Legoktm's MassMessage extension as a solution to bug 35306, it is less than a month old there has been little public discussion, and until it appeared on the deploy calendar last week, I wasn't even aware of its existence.

The problem with moving on bug 52723 as a solution to bug 35306 is it commits Features Engineering to maintaining an extension that is a stop gap solution with no or very little discussion in a manner that doesn't serve a broad strategic goal about how messages, notifications, etc. should be handled on the wikis. To the first, maybe there is something wrong with my e-mail client, but I have yet to find this discussion on wikitech-l or anywhere outside the bug.

Because of the above, my view is that this solution is being back-doored in and just moves the "technical debt" from one sheet (the community and tool labs) to another that has even less capability. I am biased against that because the latter sheet (WMF Features Engineering) is my responsibility. This is just my view, I'm open for us coming to consensus on a solution for this bug, but what I have seen is not consensus.

It is along these lines that, I asked to remove MassMessage from the deploy calendar when it was added to the deploy calendar without discussion from Features, Design, or Product last week. After discussion during that Friday meeting among the EPMs, I compromised to let it to go out on two test wikis, but not on mediawiki. Nobody made the case that it should go out on mediawiki. I demurred because no person at the WMF, including me as Director of Features Engineering, should fiat a decision when unaware of the status of discussions involved.

But let frank: if this had been a WMF employee writing this extension, it wouldn't have made it to even the test wikis by a country mile. In fact, a lot of extensions have been written by employees and either have extensive discussion, review, and buy-in (e.g. GuidedTours), or have not been deployed (e.g. Etherpad, the org chart, BetaFeatures) even though much more work has been done on them.

I also don't like that WMF resources in Platform and Design are being spent to review something that has had no adequate discussion over in the annual plan, in anyone's 20% time, in any cross-team discussion, or public discussion on wikitech-l (There was a last minute thread in the Design list, I am not on the design list, nor should I be, and the Creative Director is new and the team is just trying to get their sea legs and some consideration to that needs to be done here). Furthermore, after further discussion, nearly all of Product felt I should not have compromised earlier because the following situation might occur: Having gotten it onto "the cluster" people would then move to back-door it into deployment on the basis that it's already on the cluster. Their prediction is occurring right now. This is a bogus argument because nobody agreed this should be on the cluster, it's just that nobody has reviewed it in a thorough enough manner to shout "NO!"

If necessary, I'm going to shout "NO!" at this moment.

Having said that, there is the larger issue of bug 35306 which has been sitting there unsolved for a while as well as the smaller issue of the month's work Legoktm and MZMcBride have already put into Bug 52723 and [[mw:Extension:MassMessage]] possibly going to waste if I keep blocking it. Besides, MZ is sitting there trying to hold everything up on his own shoulders with EdwardsBot, and we all know it.

…

Let me address the functionality overlap with Echo:

LanguageEngineering built their own parallel message/notification system before Echo that lives on Meta today. They commit to supporting their own parallel message/notification system, and I'm okay with it living outside Echo (where it currently does), but there is an understanding that they've basically committed to that work with no support from Features for the duration that it does live outside Echo.

In those lines, I'm glad that Platform has helped out here, but unless Platform is committing to support MassMessage indefinitely into the future and not just provide one-time security and deploy assistance, I'm not okay with them adding to Features work even though they've been super helpful to MZMcBride and Legoktm. If Dan Garry is willing to commit Platform to support MassMessage, I'll think the same precedent we've done with LE applies here.

Furthermore, before *in-echo, outside-echo, use-echo) for a solution to be bug 35306, it needs to actually exhibit product discipline. The WMF gets panned for having a "agile processes" but not actually doing so, but we do have some process and we need to at least apply the same product discipline that we apply everywhere else to this bug.

For example, features in MassMessage and EdwardsBot need to be addressed in a Must-Have, Should-Have, Could-Have, Won't-Have (MoSCoW) framework. Features like "mass delivery from a list" are probably a Must-Have; features like "cross-wiki notification" are probably a should-have, other features like "public over private notifications", "page-centric over user-centric" or "longer stream notifications" are either not a must-have or could have or are should-haves to be done outside Echo by a different service (bot) using the Echo API or some extension thereof. All that is a product issue, and I nor anyone in my team is in product. Those decisions should be done in discussion with the Product team and they should not be disintermediated from it, which they have been.

I understand that many people would like to see a solution to Bug 35306 would be great to have. I'd like to see a better Signpost notification system and a more generalized solution for newsletter delivery also! I'd also like a pony. But we have already committed resources and continue to commit resources without discussion from the people (Product Design, not Features Engineering) who have been tasked with this responsibility and are very good at these sort of thing. I hope everyone participating on this bug can see that dropping this bomb on a newly hired associate product manager is simply not cool on so many levels.

…

Here is my suggestion:

(This is thinking, not a directive so don't think of this as definitive or final, I'm seeking consensus here.)

First, bug 35306 is a long-standing request. I think it's important we get headway on this, but I hope others will be understanding if it doesn't happen immediately, so long as there is a commitment for this to happen.

(For perspective, Flow was first proposed years ago, and was added to the annual plan almost two years ago before their first actual development sprint was completed (end of this week!). Echo was first deployed almost 8 months ago and is still not out on all the wikis. BetaFeatures has been in discussion for months and is still not deployed, nor is the commitment to maintain inside Features and that has caused a lot of issues. Fixing things right right takes time because consensus takes time and open discussion.)

There is an RfP for student developer time for legoktm for things like this (Finding a solution for Bug 35306 but not [[mw:Extension:MassMessage]] because MassMessage would not be deployed if it was my own engineer). Benny Situ has been spending all his time supporting [[mw:Extension:Echo]] when he should balancing [[mw:Flow]] development time into Echo bug fixes and needs to spend at least one sprint (two weeks) solely getting up to speed on Flow before doing enhancements for [[wm:Echo]]. Furthermore, Echo is not deployed everywhere yet and is still rolling out (though I've been pushing up the timetable on this as I feel we're too slow here), so it can't reach the places that EdwardsBot cat.

After the above happen, I'd like Benny and Kunal to work together to add some of the functionality of EdwardsBot into Echo for mass message delivery. Because of this, I'm moving bug 35306 into Echo as an enhancement and raising it's priority.

In the meantime I'll be OK with leaving MassMessage on test and test2 wikis because the alternative would be to remove it from the cluster entirely. The experiences and code Kunal derives by that can inform the enhancement to Echo, as well as things it already does that find themselves outside Echo (Echo does not and should not post to talk pages). So I figure two stages:

1. wait for some things to happen: legoktm to get an RfP, Echo to be on all wikis, and Benny to do an entire Flow only sprint and balancing his time more effectively wrt Echo.
2. MoSCoW other features of MassMessage/EdwardsBot for integration into Echo
3. Enhance and deploy a first pass to Echo to allow some sort of mass notification from a wiki list
4. Some sort of cross wiki notification enhancement (requires a design pass)
5. Discuss how to implement must-have or should-have features of EdwardsBot that can't live in Echo (permanent log of events)?
6. Add those to plan and be done.

The above can occur independently or in parallel to the above. If Product thinks it cool to commit Platform's constrained engineering resources to deploying and supporting MassMessage Extension forever and use it to take advantage of Echo when the features roll out in some undefined future, consider this thinking moot or at least orthogonal to MassMessage. IMO, it is bad enough that something important like BetaFeatures is without a home, but my answer from Features is "No" for MassMessage. If this was my own engineer, I'd raise hell with them for this and yell at their Product Manager for not being a good steward of Platform's time.

tchay wrote:

I am not modifying this bug, to leave open the avenue that Platform Engineering commits to supporting [[mw:Extension:MassMessage]], only bug 35306.

(In reply to comment #28)

bug 52723 is a recent bug to deploy Legoktm's MassMessage extension as a
solution to bug 35306, it is less than a month old there has been little
public
discussion [...]

For your following points, it seems you're implying that the desiderata and requirements for this extension are not clear. This couldn't be less clear: the requirements are to take over EdwardsBot (a successful product) in the least impactful way possible.

The problem with moving on bug 52723 as a solution to bug 35306 is it commits
Features Engineering to maintaining an extension that is a stop gap solution
with no or very little discussion in a manner that doesn't serve a broad
strategic goal about how messages, notifications, etc. should be handled on
the
wikis. [...]

This appears to be a false problem. If Echo or something else in a future provides equivalent or better features, the extension will fall into disuse and/or it can be undeployed.

[...] After discussion during that Friday
meeting among the EPMs, I compromised to let it to go out on two test wikis,
but not on mediawiki. Nobody made the case that it should go out on
mediawiki.

AFAIK, this is a MediaWiki extension. Do you mean "not on mediawiki.org"?

[...]

For example, features in MassMessage and EdwardsBot need to be addressed in a
Must-Have, Should-Have, Could-Have, Won't-Have (MoSCoW) framework.

Isn't this what dependencies are for? I see one dependency and it's fixed.

[...]

1. wait for some things to happen: legoktm to get an RfP, Echo to be on all

wikis, and Benny to do an entire Flow only sprint and balancing his time more
effectively wrt Echo.

I don't understand how keeping to use a bot for the very same things this extension would do helps Echo.

2. MoSCoW other features of MassMessage/EdwardsBot for integration into Echo
3. Enhance and deploy a first pass to Echo to allow some sort of mass

notification from a wiki list

4. Some sort of cross wiki notification enhancement (requires a design pass)
5. Discuss how to implement must-have or should-have features of EdwardsBot

that can't live in Echo (permanent log of events)?

6. Add those to plan and be done.

I don't get these points. If you're responsible for Echo, it's your responsibility to decide what Echo is going to incorporate, it's not the others' responsibility to guess it and be blocked for years while you figure it out. Are you saying you're going to figure it out so that people can understand how to work with/for Echo without being just blocked by it?

The above can occur independently or in parallel to the above. If Product
thinks it cool to commit Platform's constrained engineering resources to
deploying and supporting MassMessage Extension forever

This is one thing,

and use it to take
advantage of Echo when the features roll out in some undefined future,

this looks like an unreasonable requirement (are you going to shutdown message bots too if they don't use Echo?).

*couldn't be less true

tchay wrote:

(In reply to comment #30)

(In reply to comment #28)

bug 52723 is a recent bug to deploy Legoktm's MassMessage extension as a
solution to bug 35306, it is less than a month old there has been little
public
discussion [...]

For your following points, it seems you're implying that the desiderata and
requirements for this extension are not clear. This couldn't be less true[edit]:
the
requirements are to take over EdwardsBot (a successful product) in the least
impactful way possible.

bug 52723 on its own is clear, but as a solution to bug 35306, it is not. If we actually want to solve bug 35306 in an ideal world, nobody would use 52723, nor would Platform resources have been spent on 52723.

For instance, what is the timescale necessary before EdwardsBot is unworkable? Has it failed immediately or is failure immanent? If not, why then the rush on bug 52723? If so, then we need to discuss what to do of which bug 52723 is the only option right now. No other extension in recent memory has been deployed on the cluster with so little public discussion, without any product approvals, without any commitment from Features for maintenance.

The problem with moving on bug 52723 as a solution to bug 35306 is it commits
Features Engineering to maintaining an extension that is a stop gap solution
with no or very little discussion in a manner that doesn't serve a broad
strategic goal about how messages, notifications, etc. should be handled on
the
wikis. [...]

This appears to be a false problem. If Echo or something else in a future
provides equivalent or better features, the extension will fall into disuse
and/or it can be undeployed.

That argument may have held water back when extensions like ReaderFeedback or LiquidThreads were written and deployed. We still have those extensions cluttering the cluster with no serious commitment to support, no easy avenue for sunsetting. Unlike that time, we now real product and development processes in place. Those processes should be given a chance to work before being bypassed.

It would be unfair to every engineer here and all extensions written if the old standard of, "If something better comes along, this will die naturally" is applied in this case barring some emergency. That standard hasn't been applied during my tenure here and I'm not going to make an exception just because Platform's checklist for covers core deployments has been gamed to cover a new extension deployment that would not reached this stage and would have received an reprimand from me (wasting Platform's resources) had my own engineers done this.

While MassMessage is replacing or superseding current site functionality, this is this isn't improving or superseding a current (neglected) extension. For instance, the community-initiated work being done on the Math Extension (which I might had has had infinitely more discussion on wikitech-l) because this site functionality If anything, the inability of Features Engineering to review and maintain the current deployed extensions should make the case against MassMessage adding to that balance sheet already deeply in the red.

The simple reality is that Features Engineering will not support the MassMessage Extension as is. But if a different department like Platform Engineering is actually committed to supporting it indefinitely, I'll cede the ground entirely. I did the same to Language Engineering with Translation Notifications. This time, I'd recommend discussion with others how that experience has worked out (I don't know myself, because Feature ceded responsibility here).

[...] After discussion during that Friday
meeting among the EPMs, I compromised to let it to go out on two test wikis,
but not on mediawiki. Nobody made the case that it should go out on
mediawiki.

AFAIK, this is a MediaWiki extension. Do you mean "not on mediawiki.org"?

Yes, sorry. I meant the mediawiki.org. You can see the context of my use of mediawiki by itself from the change history I linked to above.

I don't get these points. If you're responsible for Echo, it's your
responsibility to decide what Echo is going to incorporate, it's not the
others' responsibility to guess it and be blocked for years while you figure
it
out.

I'm responsible for ENGINEERING RESOURCING on Echo. Right now a full-time engineer has been devoting his full time in supporting a product that is "done" simply because the rollout hasn't yet happened on all the wikis. If I want to commit more time developing enhancements to it, I have to take that resource from somewhere else like VisualEditor or Flow. Because it affects those teams, I'd negotiate with the product managers on that time. In addition, I'm okay with being ordered to change that current level or resourcing by Erik, Sue, or the Board, but until then I make the resourcing decision based on my responsibility toward achieving the Annual Plan, the Strategy, and other commitments we've made.

You have a misguided view of what I do or what works in general in our movement or at the WMF. What or what-not Echo incorporates, like all decisions of this nature, are not mine alone but the responsibility of Product Design in discussion with me, my teams, and others. When it comes to Echo specifically, because I have the least domain knowledge on the team, I have the least contribution and thus the least authority to do beyond a suggestion. This is a Good Thing. We should be good stewards of each others time and energy and not commit others without discussion with them.

I have a lot of stuff I'd like to do and I'd like to promie, but I agree to abide by this framework and expect my teams to do the same. I make and enforce the rules with respect to Features Engineering, but I do not make all the decisions for the features, or even the most relevant ones in this matter.

Are you saying you're going to figure it out so that people can
understand
how to work with/for Echo without being just blocked by it?

I am saying, "Here is an approach we can take. I realize that it's a 3-6 month to 1 year thing, but so is everything else we've done. If you've held off for almost 2 years, can you hold off a bit longer? This approach can be done orthogonal to other approaches (like this bug), but the important thing to be is consistent so we avoid things (like ad-hoc extension deployments) that we know haven't worked in the past."

I'm saying if you can't be blocked by this bug and need Features to support it, then either go without Features or state reasons other than "it's been in bugzilla for almost 2 years" because that has never been a standard to get stuff fixed and deployed.

I'm asking that while I agree (and I think most would) that it'd be nice to have movement on the parent bug, people stop trying to exploit known holes in our development processes to try to get a particular implementation that is not derived from consensus and has bypassed every standard erected to safeguard sustainable development at the WMF: either work within the system or don't but don't try to get something deployed and say it's Features' problem because it's an extension. This sort of behavior breaks down trust in our people and processes many of whom and which are new, fragile,and need to be nurtured, not exploited.

For instance, BetaFeatures was shopped around long before MassMessage, bypassing Features Engineering. They got a bite in Multimedia and Mobile and now Multimedia wants to deploy this and move on to work on… Multimedia and is in a spot with respect to support for this extension. Part of me wants to say, "Well you knew this was going to happen, why didn't you involve the rest of Product and Features before you got to this point?" And that's for an extension that had far more buy-in, development, design, and direction (from the VP level even), and isn't even deployed yet!

It is for exactly sort of situations that the consensus and discussions with product, design, and features is a standard for all new features in the first place. When this rule is bent as in the case of BetaFeatures, it causes problems which the people who took it on understood would come as a consequence. When this rule isn't even followed, as in the case of MassMessage, Features opts-out, but another department is welcome to take this on.

The above can occur independently or in parallel to the above. If Product
thinks it cool to commit Platform's constrained engineering resources to
deploying and supporting MassMessage Extension forever

This is one thing,

and use it to take
advantage of Echo when the features roll out in some undefined future,

this looks like an unreasonable requirement

The requirement for extensions to be deployed has ALWAYS been that Features Engineering sign off on a commitment to maintain the extension. I've relaxed it to be: "If another engineering department in collaboration with product is willing to commit to it, Features will not block." I'd like to someday relax this further to: "If any engineering department or community development in collaboration with the other core competencies (features, product, design, and community) are willing to commit to it, no one should block." We are not there yet, and trying to rail against that is winning a battle at the cost of the war breaking down these silos and having shared ownership and responsibility in our organization, in our community, and in our movement.

(are you going to shutdown
message
bots too if they don't use Echo?).

No. Message bots are not Extensions. I think the criteria to move EdwardsBot into ToolLabs is different. If MZMcBride would like assistance on this, I think the engineering community team and operations will offer it.

Personally, I (and I assume you) would like a solution beyond and more sustainable than saddling MZ and EdwardsBot with more work. The original bug points out that much of the Wikimedia Foundation is dependent on MZ's bot. If MassMessage Extension is the only option or is an emergency option, so be it — people have shortcutted processes before and have had to live with the consequences.

Otherwise, we need to have that discussion in front of all of WMF Tech, on Wikitech-l in front of the mediawiki community, and in front of the C-levels and the board as part of the annual plan, not just on this bug.

I don't want to monopolise the discussion so I'll briefly reply to some "personal points".

(In reply to comment #32)

This appears to be a false problem. If Echo or something else in a future
provides equivalent or better features, the extension will fall into disuse
and/or it can be undeployed.

That argument may have held water back when extensions like ReaderFeedback or
LiquidThreads were written and deployed.

This comparison carries no value: 1) LQT can't be undeployed because we'd lose critical data (discussions) from the wiki, 2) AFT is being expanded right now with no exit strategy I'm aware of (probably under the understanding that nobody cares if all that data disappears from the wikis after undeployment).

[...]

I don't get these points. If you're responsible for Echo, it's your
responsibility to decide what Echo is going to incorporate, it's not the
others' responsibility to guess it and be blocked for years while you figure
it
out.

I'm responsible for ENGINEERING RESOURCING on Echo. [...]

You have a misguided view of what I do or what works in general in our
movement
or at the WMF.

I highly doubt I do. My sentence started with an "If" for a reason: I've no idea who's responsible for Echo.

Let me note that I asked how you planned to coordinate with other pieces of code/devs working in this area already 9 months ago: [[m:IRC office hours/2013-01-08]].

[...] I'm asking that while I agree (and I think most would) that it'd be nice to
have movement on the parent bug, people stop trying to exploit known holes in
our development processes to try to get a particular implementation that is
not
derived from consensus and has bypassed every standard erected to safeguard
sustainable development at the WMF: either work within the system or don't
but
don't try to get something deployed and say it's Features' problem because
it's
an extension. This sort of behavior breaks down trust in our people and
processes many of whom and which are new, fragile,and need to be nurtured,
not
exploited.

I gather that you feel insulted and circumvented or something like that and I'm sorry for this personal pain you're suffering, but all this talk about exploiting doesn't look helpful.

[...]

The above can occur independently or in parallel to the above. If Product
thinks it cool to commit Platform's constrained engineering resources to
[...] use it to take
advantage of Echo when the features roll out in some undefined future,

this looks like an unreasonable requirement

The requirement for extensions to be deployed has ALWAYS been that Features
Engineering sign off on a commitment to maintain the extension. [...]

This is not a reply to my line you quoted.

tchay wrote:

(In reply to comment #33)

This comparison carries no value: 1) LQT can't be undeployed because we'd
lose
critical data (discussions) from the wiki, 2) AFT is being expanded right now
with no exit strategy I'm aware of (probably under the understanding that
nobody cares if all that data disappears from the wikis after undeployment).

It carries more value that bug 31235 does to implement bug 52723. MassMessage is an extension, as an extension it is under the same rules as all other extensions for deployment.

1. LQT can't be underplayed and we're stuck with it for an uncertainf eatures
2. ReaderFeedback, AFT, and AFTv5 are all different extensions.

I highly doubt I do. My sentence started with an "If" for a reason: I've no
idea who's responsible for Echo.

Then I apologize, it's easy to read your statement and not have the hidden assumption that someone is responsible for Echo. Nobody is, it, like everything else, is a shared responsibility.

Let me note that I asked how you planned to coordinate with other pieces of
code/devs working in this area already 9 months ago: [[m:IRC office
hours/2013-01-08]].

Hmm, I didn't read what you said as being related to this, most of what was in that discussion was posted on the grandparent bug and little movement has been done since then.

As to your logs: currently there is only one Dev working on Echo: bsitu. RoanKattouw and matthiasmullie never got the chance to work on this project, lwelling is no longer with us, Krenair is a community dev who I assume is wrapped up in other issues with core, kaldari is now in Mobile, fabriceflorin is in Multimedia and Werdna is on Flow. I don't know the state of [[mw:Extension:TranslationNotifications]] but I believe it's under active development/maintenance by Language Engineering. Their contributions are in this log, on mediawiki, in the code base, and in fabriceflorin's notes. When work on Echo is restarted, bsitu will be involved in it.

I gather that you feel insulted and circumvented or something like that and
I'm
sorry for this personal pain you're suffering, but all this talk about
exploiting doesn't look helpful.

I'm not insulted. I pushed back one time in a close-door meeting (I prevented deployment on mediawiki.org with the understanding from all the participants of the meeting that MassMessage would not be deployed on the cluster). Since people aren't aware of it, I am trying to explain the decision and the reasoning behind it.

I apologize for this language of "exploiting." Here was the topline of my original discussion which is relevant (but deleted from the bug comment):

When I use to loaded words like "back-dooring" etc, I believe that no malice was intended and the discussions so far have been in good faith from all parties. I think people have a valid concern and want it addressed and are wondering honestly how decisions have been made. In particular, my decision to not allow the MassMessage Extension to roll out onto MediaWiki last week, since that occurred during a meeting that didn't even involve or derive have consultation (except ex-post-facto) with any product manager or engineer here.

It is very likely that adding the previous deploy and this one to the deploy calendar on Thursday would have someone like me either missing it or taking it at face value (that someone outside my own team added it and has adopted responsibility).

Last week, I didn't have time to figure out the parameters of where the decision to deploy MassMessage came from, so I only pushed back on mediawiki.org. The understanding from me and all the participants of the Friday meeting was that MassMessage would not be deployed beyond that.

The fact is at that moment this spent all of one day on the deploy calendar added by someone outside the WMF, one and a half weeks in public development on obscure parts of the wiki and bugzilla, had no discussion with product, no plan for support, etc.

No new feature would have been deployed to even test or test2 without discussions from Features, Design and Product. I didn't realize that any of this had occurred.

This is not a standard anymore for deployment of an extension, nor has it been for quite a while.

This is not a reply to my line you quoted.

Hmm, I feel it is but I guess this depends on the definition of what is is? :-)

If it is unreasonable to require sign off for Features Engineering for Extension deploy than it is an unreasonable thing that has been in place long before me. I'm trying to relax that requirement, one area of relaxing is to find another home for deployment and support.

Last year, there was a broken core change about timestamping slipped through Platform review and got deployed. Because of that, a better thought-out and previously-developed pending core change for the exact same feature from Werdna got bumped. To get this fixed,the Echo team had to make a new core patch that superseded the earlier, broken patch, satisfied Language Engineering's wishlist, and handled what Echo needed which took weeks of effort and time that wasn't necessary had the timestamp patch not been put into core in the first place.

It was unreasonable, but it was life.

We can operate on the old rules of "Features Engineering needs to sign on support for Extension wide cluster deploy" or we cannot.

Under the former, Features's answer is not no. Our answer is We need to hear something more urgent and important or my answer is not yet from Features. Everything WMF Features Engineering does is in collaboration with other areas: product, design, design, and community, and I refuse to allow me or my teams to operate differently.

Under the latter, support for this needs to find another home just like TranslationNotifications or BetaFeatures did.

Someday, I hope we can do better. Things like BetaFeatures and Workflows part of Flow may make that possible.

tchay wrote:

Ori has stepped up and is willing to commit his time to help Legoktm in supporting MassMessage on an ongoing basis. According to the current standard of the above, there is no longer any block on bug 52723.

Time still has to be made to handle the rollout, but I'm assuming what is already in-process in Platform, and Ori can assist beyond that.

The requirement for extensions to be deployed has ALWAYS been that Features
Engineering sign off on a commitment to maintain the extension. I've relaxed it
to be: "If another engineering department in collaboration with product is
willing to commit to it, Features will not block." I'd like to someday relax
this further to: "If any engineering department or community development in
collaboration with the other core competencies (features, product, design, and
community) are willing to commit to it, no one should block." We are not there
yet, and trying to rail against that is winning a battle at the cost of the war
breaking down these silos and having shared ownership and responsibility in our
organization, in our community, and in our movement.

Please realize the current state of affairs is that new Extension deploy can be done under the following frameworks:

1. The traditional "Features signs off on all extensions" that has always been in place. For Features to sign off on this, like with our own engineering staff, we require collaboration and buy-in in affected areas like the product managers and designers who will lose productivity or might be retasked on this. We must be good stewards of each-others times, and I would not have permitted (and will not permit) my engineers to task Platform and Design engineers for MassMessage in the manner that has happened to date (water under the bridge at this point).
2. The above can and has been be bypassed on a directive from the VPE as was the case for BetaFeatures.
3. Like LanguageEngineering's use of TranslationNotifications instead of Echo, if another team consisting of engineering, product, and design is willing to commit to supporting on an ongoing basis, then extension deploy proceeds without the traditional rule of discussing Features. Note, in this example we have an assumption that the feature set of MassMessage is as-is so it currently doesn't involve Product or Design, nor does it require more engineering resources inside the WMF beyond Ori who is currently untasked.

We still eventually want to reach the point where the criteria is not the amalgam of rules above but a simpler one based on intent, expertise-sharing and consensus-building: "If any engineering department or community developer in collaboration with the other core competencies (engineering, product, design, and community) are willing to commit to ongoing maintenance of a feature, then no one group should block it."

We haven't reached there yet, and please realize that when me make exceptions as in this case, it compromises the larger picture of our need to break down these silos and create shared ownership and responsibility in the WMF, in our communities, and in the movement as a whole.

(In reply to comment #35)

The requirement for extensions to be deployed has ALWAYS been that Features
Engineering sign off on a commitment to maintain the extension.

You've been at the Wikimedia Foundation for, what, two years? You really feel it's appropriate to lecture me and others about how things have "always" been? You seem to have absolutely no sense of how software deployments have operated for the majority of Wikimedia's existence.

You're attempting to dictate to volunteers as though they're your subordinates. This is wildly inappropriate.

Do you have a link to this doctrine regarding software deployments and sign-offs? As far as I can tell, you've just made it up here on this bug. But perhaps there's a guideline you've written on mediawiki.org, wikitech.wikimedia.org, or Meta-Wiki. Please share.

Is the current thinking to give users on any wiki the right to use Special:MassMessage to spam users on any other wiki?

It seems to me you'd want something like:

• Users on Meta can trigger cross-wiki notifications;
• Users on any other wiki can only trigger local notifications.

Otherwise you end up with an audit trail mess. Having a single log in one place and a single place to set policy around these things seems highly desirable. If we're on the same page on that, I'm significantly less concerned about the long term impact of the extension.

(In reply to comment #35)

Ori has stepped up and is willing to commit his time to help Legoktm in
supporting MassMessage on an ongoing basis. According to the current standard
of the above, there is no longer any block on bug 52723.

Thank you Ori!

The requirement for extensions to be deployed has ALWAYS been that Features
Engineering sign off on a commitment to maintain the extension.

This isn't consistent with the documentation at [[mw:Writing an extension for deployment]], [[mw:Review queue]] and Greg's checklist in comment 7.

(In reply to comment #37)

Is the current thinking to give users on any wiki the right to use
Special:MassMessage to spam users on any other wiki?

Yes. The design idea here was that this is already possibly by any user. Anyone can open up a bunch of browser tabs and post to dozens of wikis quickly without even logging in. Or, for example, I've been posting to hundreds of wikis for years without a privileged account using only a very simple Python script. The difference here in functionality isn't very big. The primary difference is that we're adding a proper user interface for delivery submissions and reducing the need for an external dependency (a bot).

It seems to me you'd want something like:

• Users on Meta can trigger cross-wiki notifications;
• Users on any other wiki can only trigger local notifications.

This was considered and it's probably easy enough to implement these restrictions, but as I said above, I'm not sure they're necessary. My view was to take a "wait and see" approach. If local administrators begin to abuse or misuse the tool, we can always add in restrictions later.

Otherwise you end up with an audit trail mess. Having a single log in one
place and a single place to set policy around these things seems highly
desirable.

Again, anyone can go around posting messages to any wiki right now without even logging in. Giving local administrators the ability to send cross-wiki messages with a simpler tool doesn't seem to warrant much concern from my perspective, but if you consider this a requirement for wider deployment, Lego can add in the restrictions.

The bot currently provides an audit trail by (optionally?) appending an HTML comment containing the originating wiki, message sender's name, etc., I believe. Lego can confirm this.

tchay wrote:

You're going to resort to ad hominem instead of attacking the argument when you're already getting what you want?

I am not trying to "dictate" anything to volunteers. Volunteers didn't deploy the code onto test and test2, it was Reedy. Volunteers are free to develop. They're not free to have their developed code deployed on the cluster. Nobody is.

As for the proof of this "doctrine," just like MediaWiki core has always been the responsibility of Platform, the Extensions space has traditionally been the responsibility of Features Engineering. Historically, new extension deploy and a commitment to deploy was done by Brion and later by Roan. This used to be enforced in terms of SVN access, and the artifact still exists in the form of who has +2 on Gerrit. In the case of deploying a new extension, it requires +2 on gerrit, shell access, and an implied commitment to maintain.

I've been trying to relax this as I feel this is unscalable solution, but with that right comes the responsibility. If you or other community developers are unwilling to hold yourselves to the same responsibility that every engineer of the Foundation is held to, you are free to do so. But nobody has the right to have +2, nobody has the right to shell access, etc. Just as Platform and Ops reserve the right as policy to rescind my +2 access and my non-existent shell access, they could rescind anyone else's, even yours if it existed.

(In reply to comment #38)

The requirement for extensions to be deployed has ALWAYS been that Features
Engineering sign off on a commitment to maintain the extension.

This isn't consistent with the documentation at [[mw:Writing an extension for
deployment]], [[mw:Review queue]] and Greg's checklist in comment 7.

Interesting links.

To the first document which has its origins in the SVN days, the first stop with Howie Fung and his product management team. To my knowledge the only person asked was a Dan Garry, and not as a first stop on anything. I mentioned in my original post why that people should know better. The second stop was wikitech-l. To my knowledge mine was the first post on the subject.

The second document is newly written by Platform not vetted by anyone in Features. I assume that if Platform wants to operate that way then they're committed to maintaining an extension approved that that process, that's cool with me and entirely consistent to my statements. In it's original incarnation it was Sumana's way of managing code review of existing extensions.

The third link refers to someone who has been at the WMF even less time than me. If we're to use MZMcBrides seniority rules, the fact that some newly-minted, improperly vetted document was used by a relatively new engineer doesn't carry weight.

I hope that documentation is updated.

(In reply to comment #7)

TODO/Check list

Extension page on mediawiki.org: yes
Bugzilla component: yes
Extension in Gerrit: yes
Design Review: no
Archeticecture/Performance Review: no
Security Review: no
Screencast (if applicable): no
Community support: no?

As a designer, I did a design review over IRC. I said something along the lines of 'looks shiny'.

I hope that helps, as I'm not sure what more you could want with this kind of extension. Other issues beyond the interface itself have generally already been established by precedent (EdwardsBot).

(In reply to comment #40)

Do you have a link to this doctrine regarding software deployments and
sign-offs? [...] perhaps there's a guideline you've written on mediawiki.org,
wikitech.wikimedia.org, or Meta-Wiki. Please share.

Go on. I'll wait.

(In reply to comment #39)

(In reply to comment #37)

Is the current thinking to give users on any wiki the right to use
Special:MassMessage to spam users on any other wiki?

Yes. The design idea here was that this is already possibly by any user.
Anyone
can open up a bunch of browser tabs and post to dozens of wikis quickly
without
even logging in. Or, for example, I've been posting to hundreds of wikis for
years without a privileged account using only a very simple Python script.

It might be worth noting that the MassMessage bot account used automatically adds itself to the 'bot' group, but isn't able to override full protections or anything like that.

It seems to me you'd want something like:

• Users on Meta can trigger cross-wiki notifications;
• Users on any other wiki can only trigger local notifications.

This was considered and it's probably easy enough to implement these
restrictions, but as I said above, I'm not sure they're necessary.

An initial version of the extension had this differentiation, but it was removed in https://gerrit.wikimedia.org/r/#/c/78047/. I don't mind revisiting the concept either (file a bug for it?), as it wouldn't be hard to implement technically.

My view was
to take a "wait and see" approach. If local administrators begin to abuse or
misuse the tool, we can always add in restrictions later.

Otherwise you end up with an audit trail mess. Having a single log in one
place and a single place to set policy around these things seems highly
desirable.

I actually wrote [[mw:Extension:CentralLogging]] for this problem a while back, but it wouldn't work in the WMF environment.

The bot currently provides an audit trail by (optionally?) appending an HTML
comment containing the originating wiki, message sender's name, etc., I
believe. Lego can confirm this.

The audit trail is not optional (though a wiki could choose to blank the message and make it useless). An example is https://test2.wikipedia.org/w/index.php?title=User_talk:Legoktm&action=edit&section=2, which includes the origin wiki, sender, and spamlist used.

(In reply to comment #41)

As a designer, I did a design review over IRC. I said something along the
lines
of 'looks shiny'.

For reference, Isarra created [[commons:File:Massmessage preview (uncyc).png]], and pointed out a few flaws in the initial design, like using tables for the form (now switched to proper <div>s), and the submit/preview buttons stacked on top of each other (now side-by-side).

(In reply to comment #40)

(In reply to comment #38)

The requirement for extensions to be deployed has ALWAYS been that Features
Engineering sign off on a commitment to maintain the extension.

This isn't consistent with the documentation at [[mw:Writing an extension for
deployment]], [[mw:Review queue]] and Greg's checklist in comment 7.

Interesting links.

To the first document which has its origins in the SVN days, the first stop
with Howie Fung and his product management team. To my knowledge the only
person asked was a Dan Garry, and not as a first stop on anything.

Dan was cc'd by Greg in comment 13. I wasn't aware that Platform and/or Features were supposed to be in the loop so I never bothered to do it.

I mentioned
in my original post why that people should know better. The second stop was
wikitech-l. To my knowledge mine was the first post on the subject.

Correct. I had spoken with Greg a few days earlier about emailing wikitech-l / Aaron / Tim for the architecture review, and he recommended that I wait for your comments ;-)

The second document is newly written by Platform not vetted by anyone in
Features.

For someone outside of the WMF who is trying to get an extension deployed, the distinction between Platform and Features isn't very clear, nor really important. Was VipsScaler (also written by a volunteer) handled by Features? All we really want is our code deployed :P

The third link refers to someone who has been at the WMF even less time than
me. If we're to use MZMcBrides seniority rules, the fact that some
newly-minted, improperly vetted document was used by a relatively new
engineer
doesn't carry weight.

The checklist is fine, it just seems like its missing one step according to you (notify Features and/or Platform teams).

I hope that documentation is updated.

Be bold!

tchay wrote:

(In reply to comment #41)

(In reply to comment #7)

TODO/Check list

Extension page on mediawiki.org: yes
Bugzilla component: yes
Extension in Gerrit: yes
Design Review: no
Archeticecture/Performance Review: no
Security Review: no
Screencast (if applicable): no
Community support: no?

As a designer, I did a design review over IRC. I said something along the
lines
of 'looks shiny'.

I hope that helps, as I'm not sure what more you could want with this kind of
extension. Other issues beyond the interface itself have generally already
been
established by precedent (EdwardsBot).

We'd have to ask Greg what he really meant by this when he added that to [[mw:Review queue]] instead of leaving the process pointing back to [[mw:Writing_an_extension_for_deployment]], but if I were to hazard a guess:

I think Greg tried to clear the review queue because it was suffering from neglect. He tried summarize the original linked document: [[mw:Writing_an_extension_for_deployment#Design_review]] by saying it has a proper "design review." It clearly implies design review as being a product design review with a design UI design component [[mw:WMF_Project_Design_Review_Process]] probably dating back to when they were in the same department.

If you look at an earlier revision [https://www.mediawiki.org/w/index.php?title=Review_queue&oldid=697844], you can see the tracking list that was its original purpose since Brion created it. Around that time, it was getting unmanageable four months ago with little movement. My guess is that there simply had been no recent Extensions (other than in-flight extensions like Math and SignupAPI) that had actually gone through this process and in an effort to systematize the process into a workable checklist, it got morphed over time from "send it to product design for review" to "send an e-mail to a designer and to the design mailing list." *shrug*

tchay wrote:

To the first document which has its origins in the SVN days, the first stop
with Howie Fung and his product management team. To my knowledge the only
person asked was a Dan Garry, and not as a first stop on anything.

Dan was cc'd by Greg in comment 13. I wasn't aware that Platform and/or
Features were supposed to be in the loop so I never bothered to do it.

It's unfortunate. Dan is new and is not really in a position to speak for product, and I don't think that was the intent of comment 13 to make him make a call.

The implication of Platform or Features is in the later stage of code review for deployment. There was a time that Sumana would manage that using 20% time volunteered by Features, but that was over a year ago. :-( Since then commitment to maintain deployed extensions has fallen through the crack between Platform and Features.

Correct. I had spoken with Greg a few days earlier about emailing wikitech-l
/
Aaron / Tim for the architecture review, and he recommended that I wait for
your comments ;-)

Oh, well then why was it added to the deploy calendar? Can we remove it backand wait for comments to make sure it's okay to deploy before adding it to the lsit of things to be deployed? As it stands now, my position is I'm okay with it because Ori is okay with helping you support and monitor it for issues that might crop up like comment 37 above.

The second document is newly written by Platform not vetted by anyone in
Features.

For someone outside of the WMF who is trying to get an extension deployed,
the
distinction between Platform and Features isn't very clear, nor really
important. Was VipsScaler (also written by a volunteer) handled by Features?

No, and in earlier incarnations of the queue, I think [[mw:VipsScaler]] was linked. Development on it was started in 2011, I think multimedia team (originally a Features team, now in Platform) deployed it. That team is obviously committed to maintain. :-)

All we really want is our code deployed :P

Totally understandable. :-)

The checklist is fine, it just seems like its missing one step according to
you
(notify Features and/or Platform teams).

I'm okay with clarifying that a design review means a product design review and PM signoff and adding that a plan for engineering, product, and design maintenance needs to be in place going forward (beyond simply bugzilla).

(In reply to comment #39)

This was considered and it's probably easy enough to implement these
restrictions, but as I said above, I'm not sure they're necessary. My view
was
to take a "wait and see" approach. If local administrators begin to abuse or
misuse the tool, we can always add in restrictions later.

I would actually look at it differently. Right now, as I understand it, cross-wiki message delivery is only configured to be run from Meta, where it's easy to see who's configuring what "spams" and for what audiences. It's easy for folks to have a shared conversation about what's appropriate and what isn't, and even for people to revert additions that they see as unreasonable.

So you've actually created a very clever tool that plays well into the norms of the wiki community, and uses an existing shared space (Meta) in the intended manner.

In contrast, enabling admins everywhere to _easily_ post bulk messages across wikis from anywhere, with the audit trail being HTML comments in the messages that are left, is IMO quite likely to play against the norms of the wiki, because messages _will_ be sent in a manner that's inconsistent with the norms of a given target wiki, and it'll be harder for the community to have a shared conversation about it or even to easily see what's happening (because there is no central message log at that point).

Because actions such as compiling target lists are dispersed, the normal processes of community peer review won't kick in as effectively to moderate and monitor behavior.

Yes, anyone can of course post anywhere today, but not everyone has access to a shared bot account that they can use on any wiki to do so, nor do they have an automated delivery tool. ReviewerBot would suddenly take bot actions on wikis and users would be tasked with figuring out what's going on. That's manageable if the only possible source is Meta, but more problematic if the source is any of our wikis.

Cross-wiki bulk messages to anywhere from anywhere are a significant change from the status quo that requires more consideration. And on that point, WMF will certainly get the blame if the tool is misused.

So I'm not comfortable with a deploy that amounts to giving admins in every wiki 'massmessage' permission to every other wiki. I'd be fine with 1) limiting the availability of the massmessage permission to Meta, or 2) adding back the global/local message delivery distinction and enabling local delivery on all wikis, and global delivery on Meta.

Better broadcasting tools should still continually be developed, and the imperfections of this approach will hopefully feed into whatever comes next, whether it's an iteration on MassMessage or an entirely new approach.

s/ReviewerBot/MessengerBot/

(In reply to comment #34)

[...] Last year, there was a broken core change about timestamping slipped through
Platform review and got deployed. Because of that, a better thought-out and
previously-developed pending core change for the exact same feature from
Werdna
got bumped. [...]

The only thing I found is https://gerrit.wikimedia.org/r/#/c/15746 which was merged after ignoring code-review for months, causing a developer and translator revolt.

(In reply to comment #48)

So I'm not comfortable with a deploy that amounts to giving admins in every
wiki 'massmessage' permission to every other wiki. I'd be fine with 1)
limiting
the availability of the massmessage permission to Meta, or 2) adding back the
global/local message delivery distinction and enabling local delivery on all
wikis, and global delivery on Meta.

Better broadcasting tools should still continually be developed, and the
imperfections of this approach will hopefully feed into whatever comes next,
whether it's an iteration on MassMessage or an entirely new approach.

+1
I think this is totally reasonable and was indeed my only true worry about the extension.
I'd add the permission to a special group, possibly reusing centralnoticeadmin group, since the first deploy, to avoid needless requests for adminship.
More than that, we could even try to replicate the logging of the messages content to a wiki page, for enhanced accountability.

(In reply to comment #48)
If there is any way to do global logs (alongside local ones) this would be a very good place to use that, as that would make all wikis much more easily accountable for any usage of this tool.

That said you're probably right in that just enabling the sending part on meta would be better, since, on top of logs and such all being in one place, usage guidelines and crap would also be better synced. And implicitly trusting all admins isn't necessarily a good idea when different projects can have completely different methods and standards when approaching problems, and on top of that pretty much anyone can become an admin at least somewhere (which isn't even necessarily a bad thing, since if they happen to be in the right place even the most unexpected of folks can prove quite useful, but also doesn't mean it should carry weight elsewhere).

So just have a request page for anyone new to use, and a right that can be added to anyone who ain't an admin if they've general use for the spammer and clearly understand what not to do, or whatever. I'm sure the meta folks can argue out some actual details there.

(In reply to comment #48)

(In reply to comment #39)

<snip>

I've filed bug 54954 as a blocker to this one. I've asked a few preliminary questions on how this should be implemented, so if people who have options could comment there please :)

I have a quick question about the extension itself. Maybe I'm reading this code wrong, but the extension appears to iterate through the recipients on the special page, and then make a new job for each recipient. If this is true, that means that this extension would be launching thousands of jobs from a single web request. It kind of defeats the purpose of the job queue in the first place.

Also, do people have some sort of irrational fear of the FormSpecialPage class?

One more thing - we'll need to add standard licensing/ToS language to the submit screen to ensure content is licensed consistent with Wikimedia requirements. The wikimedia-copyrightwarning message in the WikimediaMessages extension should do the trick.

(In reply to comment #53)

I have a quick question about the extension itself. Maybe I'm reading this
code
wrong, but the extension appears to iterate through the recipients on the
special page, and then make a new job for each recipient. If this is true,
that
means that this extension would be launching thousands of jobs from a single
web request. It kind of defeats the purpose of the job queue in the first
place.

Yes, that's correct. I'm not sure how it defeats the purpose of the job queue though. We could do it like refreshlinks works and submit a job that submits more jobs, but I don't see how that would be any better. I did a simple test on testwiki a week ago and submitted 2k jobs at once and it seemed to work fine.

Also, do people have some sort of irrational fear of the FormSpecialPage
class?

I actually didn't know that existed until now. I basically forked the code of TranslationNotifications and used that...

(In reply to comment #54)

One more thing - we'll need to add standard licensing/ToS language to the
submit screen to ensure content is licensed consistent with Wikimedia
requirements. The wikimedia-copyrightwarning message in the WikimediaMessages
extension should do the trick.

(The relevant function is EditPage::getCopyrightWarning(), the messages shouldn't be used directly.)

All of the blocking bugs have been resolved. What happens now? (Greg?)

I've been working with Aaron via email on the architecture review and I believe everything has been resolved (cc'd Aaron to get confirmation on that).

(In reply to comment #57)

All of the blocking bugs have been resolved. What happens now? (Greg?)

Thanks for merging :). I just added bug 55822 which is a config change for how the jobs will get processed, it would be good to get that deployed and make sure there are no issues before the full deployment.

Lego: can you please submit a changeset to enable MassMessage on all (public) Wikimedia wikis?

(In reply to comment #59)

Lego: can you please submit a changeset to enable MassMessage on all (public)
Wikimedia wikis?

I submitted https://gerrit.wikimedia.org/r/#/c/91344/ a few days ago.

Change 91344 had a related patch set uploaded by MZMcBride:
Enable MassMessage on all wikis

https://gerrit.wikimedia.org/r/91344