Can someone summarize this thread? As far as I can tell someone has invented a requirement that all features be blessed by the WMF Features team, and I'm pretty sure that can't be right. Can it?
-- brion On Oct 3, 2013 12:27 PM, "Terry Chay" <[email protected]> wrote: > I am posting this to wikitech-l, ee-l, and will cross-post this to > https://bugzilla.wikimedia.org/show_bug.cgi?id=35306 because it's > important to keep frank discussions in the open. > > 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. > > Here is why I am inijating this thread: > > 1) > https://wikitech.wikimedia.org/w/index.php?title=Deployments&diff=83188&oldid=83134 > > 2) On Sep 30, 2013, at 4:25 PM, MZMcBride <[email protected]> wrote: > > > Hi Fabrice, Terry, and Howie, > > > > https://bugzilla.wikimedia.org/show_bug.cgi?id=35306#c19 is awaiting > feedback (if you have any). > > > > MZ > > > 3) > https://wikitech.wikimedia.org/w/index.php?title=Deployments&diff=84903&oldid=84888 > > … > > 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. > > Take care, > > terry > > > terry chay 최태리 > Director of Features Engineering > Wikimedia Foundation > “Imagine a world in which every single human being can freely share in the > sum of all knowledge. That's our commitment.” > > p: +1 (415) 839-6885 x6832 > m: +1 (408) 480-8902 > e: [email protected] > i: http://terrychay.com/ > w: http://meta.wikimedia.org/wiki/User:Tychay > aim: terrychay > > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
