Necromancy? I'll jump on that bandwagon.
On Thu, Oct 10, 2013 at 9:01 AM, Dan Garry <dgarry(a)wikimedia.org> wrote:
*The question: do we need an interim solution for message delivery, until a
future-proofed solution is developed?*
*
*
How I answer this question depends on questions that I don't have the
answer to yet.
1) "How much of a performance problem is EdwardsBot?".
a) If it's a big problem for site performance, then I think working on
something to alleviate that problem in the mean time (i.e. MassMessage)
could be worthwhile. Platform now has a performance engineer, Ori, who I
can explore that question with. If the answer is "Not a performance problem
at all", then that helps us rule out the need for an interim solution.
2) "How long will the future-proofed solution take to make?".
a) If it's going to be a "long" time (for some definition of
"long"), then
polishing off MassMessage into a form we're all happy with, so it can be
used, may make sense. This also means we don't have a long term commitment
to maintaining it, as we will be kicking it out when we're done with it.
If the solution is that there is zero need for an interim solution, then we
needn't discuss any of the details.
*
*
I submit one more question for consideration here:
3) "How much easier is MassMessage to use than
GlobalMessageDelivery/EdwardsBot?"
a) I tested it, and I think it's a substantially improved workflow. Others
may disagree. Even if we are able to fast-track a permanent solution, those
of us who spam with any frequency stand to save time and frustration in the
interim with MassMessage.
On 3 October 2013 20:22, Terry Chay <tchay(a)wikimedia.org> 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…
2) On Sep 30, 2013, at 4:25 PM, MZMcBride <z(a)mzmcbride.com> 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…
…
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: tchay(a)wikimedia.org
i:
http://terrychay.com/
w:
http://meta.wikimedia.org/wiki/User:Tychay
aim: terrychay
--
Dan Garry
Associate Product Manager for Platform
Wikimedia Foundation
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
Jonathan T. Morgan
Learning Strategist
Wikimedia Foundation