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