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