Re: Bug 35306: Global (to a wiki farm or family) message delivery (thoughts)

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Bug 35306: Global (to a wiki farm or family) message delivery (thoughts)

Terry Chay
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 <[hidden email]> 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: [hidden email]
i: http://terrychay.com/
w: http://meta.wikimedia.org/wiki/User:Tychay
aim: terrychay

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Bug 35306: Global (to a wiki farm or family) message delivery (thoughts)

Howie Fung
Dan and I can't commit Platform resources to maintaining this extension
without a conversation with Robla first, or someone else from the Platform
team that can speak for resourcing on their behalf.

My preference would be to integrate this into Echo, and to do so with a
proper evaluation of the Edwardsbot requirements (as Terry suggests).

Let's check with Robla about the Platform resourcing as a next step -- he
should be back in the office next week.

Howie




On Thu, Oct 3, 2013 at 12:22 PM, Terry Chay <[hidden email]> 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 <[hidden email]> 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: [hidden email]
> i: http://terrychay.com/
> w: http://meta.wikimedia.org/wiki/User:Tychay
> aim: terrychay
>
>


--
_______________________
Howie Fung
Director of Product Development
Wikimedia Foundation

[hidden email]
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [EE] Bug 35306: Global (to a wiki farm or family) message delivery (thoughts)

Steven Walling-3
On Thu, Oct 3, 2013 at 2:33 PM, Howie Fung <[hidden email]> wrote:

> My preference would be to integrate this into Echo, and to do so with a
> proper evaluation of the Edwardsbot requirements (as Terry suggests).


BTW, on that front, there has been interest from Quim and others in
https://www.mediawiki.org/wiki/Extension:Newsletter


--
Steven Walling,
Product Manager
https://wikimediafoundation.org/
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Bug 35306: Global (to a wiki farm or family) message delivery (thoughts)

Terry Chay
In reply to this post by Terry Chay
(reposting: held in moderation because of recipient list)

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 <[hidden email]> 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: [hidden email]
i: http://terrychay.com/
w: http://meta.wikimedia.org/wiki/User:Tychay
aim: terrychay
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Bug 35306: Global (to a wiki farm or family) message delivery (thoughts)

Terry Chay
On Oct 3, 2013, at 3:15 PM, Terry Chay <[hidden email]> wrote:

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

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.

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: [hidden email]
i: http://terrychay.com/
w: http://meta.wikimedia.org/wiki/User:Tychay
aim: terrychay

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Bug 35306: Global (to a wiki farm or family) message delivery (thoughts)

Isarra Yos
In reply to this post by Terry Chay
Out of curiosity, when did it become a requirement that Foundation
management be involved throughout the process of all feature
development, and that the WMF take over maintaining anything deployed to
Wikimedia projects? Because that's just not feasible, and never has been.

 1. If the volunteers need or want something, they make it. That's how
    MediaWiki happened, how Wikipedia happened, how the very Foundation
    for which you work happened, and while now there is infrastructure
    in which paid professionals (ie you) handle some of it, you cannot
    handle everything, and to think you can just shuts out the
    volunteers who make the projects strong, and who began the entire
    thing in the first place.
 2. Of course nobody expects the paid folks to maintain MassMessage, no
    more than anyone expects them to maintain most of the other
    extensions the projects use, because /they never have/. (If Echo
    will duplicate the functionality, then this extension can be phased
    out in favour of that when it does, but as you yourself indicated on
    one of the bugs, this is unlikely to happen any time soon.)

Meantime this extension has been discussed - with both those who would
deploy it and those who would use it. Please reconsider your approach here.

-I

On 03/10/13 20:22, Terry Chay 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 <[hidden email]> 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: [hidden email]
> i: http://terrychay.com/
> w: http://meta.wikimedia.org/wiki/User:Tychay
> aim: terrychay
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Bug 35306: Global (to a wiki farm or family) message delivery (thoughts)

MZMcBride-2
In reply to this post by Terry Chay
Terry Chay wrote:
>[a very long e-mail about the MassMessage extension]

Hi Terry.

Have you ever used or tested the MassMessage MediaWiki extension? If so,
when and where specifically?

MZMcBride



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Bug 35306: Global (to a wiki farm or family) message delivery (thoughts)

Casey Brown-5
In reply to this post by Isarra Yos
On Thu, Oct 3, 2013 at 9:52 PM, Isarra Yos <[hidden email]> wrote:
> If the volunteers need or want something, they make it. That's how
> MediaWiki happened, how Wikipedia happened, how the very Foundation
> for which you work happened, and while now there is infrastructure
> in which paid professionals (ie you) handle some of it, you cannot
> handle everything, and to think you can just shuts out the
> volunteers who make the projects strong, and who began the entire
> thing in the first place.

Indeed. Let's not let perfect be the enemy of the good.

There's a current need for a more lasting replacement for the
EdwardsBot hack, and a good extension that accomplishes this need and
has been tested and vetted. There's no reason not to enable it now and
then disable it if it becomes obsolete with the new extension you're
developing.

--
Casey Brown (Cbrown1023)
caseybrown.org

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Bug 35306: Global (to a wiki farm or family) message delivery (thoughts)

Chad
In reply to this post by Terry Chay
On Thu, Oct 3, 2013 at 6:50 PM, Terry Chay <[hidden email]> wrote:

> 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.
>
>
I don't think this assertion is true, nor is the future it describes. We've
been
deploying extensions for a long time since before Features Engineering
existed. Heck, I can think of a half dozen that we've deployed in the last
year or so that Features didn't have anything to do with at all :)

As long as someone's willing to maintain it, someone's willing to deploy it,
it satisfies a technical need and/or has community consensus and most
importantly has passed technical review then I'm always in favor of
deploying
extensions that people want to get live. It's incredibly encouraging
especially
to our volunteer devs to see the fruits of their labors actually being used
:)

-Chad
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Bug 35306: Global (to a wiki farm or family) message delivery (thoughts)

Yuvi Panda
On Fri, Oct 4, 2013 at 9:07 AM, Chad <[hidden email]> wrote:
> [snip] It's incredibly encouraging
> especially
> to our volunteer devs to see the fruits of their labors actually being used
> :)

Indeed - and Extension:ShortUrl which I wrote as a volunteer getting
deployed made me immensely happy. Also made the folks at the (often
neglected?) Indian language communities where it was deployed happy.
Let's not bottleneck 'what we can deploy' with 'how many people we are
paying'.
--
Yuvi Panda T
http://yuvi.in/blog

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Bug 35306: Global (to a wiki farm or family) message delivery (thoughts)

Thomas PT
I support strongly Chad comment.

The motivation of most of volunteers like me is to see their code deployed. There are a lot of extensions like ProofreadPage that have been written and are maintained without nearly any help from the WMF Feature department. If you assert something like "everything should be controlled by WMF Feature department", requesting volunteer work has, I think, no more any sense and it's a sentence of death for project like Wikisource that relies strongly on community written and maintained extensions.

Sorry for these hard words but it's, I think, the success in the long term of some projects like Wikisource that is at stake.

Thomas (User:Tpt)

Le 4 oct. 2013 à 07:45, Yuvi Panda <[hidden email]> a écrit :

> On Fri, Oct 4, 2013 at 9:07 AM, Chad <[hidden email]> wrote:
>> [snip] It's incredibly encouraging
>> especially
>> to our volunteer devs to see the fruits of their labors actually being used
>> :)
>
> Indeed - and Extension:ShortUrl which I wrote as a volunteer getting
> deployed made me immensely happy. Also made the folks at the (often
> neglected?) Indian language communities where it was deployed happy.
> Let's not bottleneck 'what we can deploy' with 'how many people we are
> paying'.
> --

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Bug 35306: Global (to a wiki farm or family) message delivery (thoughts)

Brion Vibber-4
In reply to this post by Terry Chay
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" <[hidden email]> 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 <[hidden email]> 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: [hidden email]
> i: http://terrychay.com/
> w: http://meta.wikimedia.org/wiki/User:Tychay
> aim: terrychay
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Bug 35306: Global (to a wiki farm or family) message delivery (thoughts)

Mark A. Hershberger-4
On 10/04/2013 12:34 PM, Brion Vibber wrote:
> 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

If that is the case, I would certainly like that spelled out.

Mark.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Bug 35306: Global (to a wiki farm or family) message delivery (thoughts)

Bartosz Dziewoński
In reply to this post by Brion Vibber-4
On Fri, 04 Oct 2013 18:34:10 +0200, Brion Vibber <[hidden email]> wrote:

> 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?

The way I understand it, yes.

The deployment was not widely consulted (this is a pretty small extension, all in all) – there was the bug and a mail to the design list when Greg asked for design review – and as far as I know basically handled by a person or two from Operations. Terry believes that somebody else has to vet the deployment, saying that all extensions are basically Features' responsibility.

Please note that I was not really in the loop (I helped review the extension a little) and I've read this entire thread on a bus (so I might be misrepresenting something).

--
Matma Rex

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [EE] Bug 35306: Global (to a wiki farm or family) message delivery (thoughts)

Erik Moeller-4
In reply to this post by Brion Vibber-4
On Fri, Oct 4, 2013 at 9:34 AM, Brion Vibber <[hidden email]> wrote:
> 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?

Of course not. I think Terry's mostly concerned that there's clear
ownership and maintainership for a new extension going forward, and
that it's properly reviewed before it goes out the door. He's
overstating, but he's coming from a reasonable place of caution.

I like the checklist process in
https://www.mediawiki.org/wiki/Review_queue (irrespective of the exact
steps) because it is agnostic as to who does the work required to get
something out the door. That said, it's a given that WMF does get the
blame when things go wrong, especially on a large scale, and as
operator of the sites we do have a role in making sure we're not
causing harm, incurring unreasonable technical debt, or going against
WMF's goals.

As for MassMessage, I looked at and played with it and there were
definitely issues with just pushing it out the door. As originally
planned, it would enable any admin anywhere to post bulk messages to
any wiki from any other wiki using a bot account created by the
extension. This raises policy and auditing questions beyond what
EdwardsBot is doing. There's consensus for a simpler deployment to
start with, with Meta acting as a place for coordinating cross-wiki
messages. That seems reasonable to me, and I definitely look forward
to seeing how well this works in practice.

--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Bug 35306: Global (to a wiki farm or family) message delivery (thoughts)

Brion Vibber-4
In reply to this post by Terry Chay
So I asked Erik offline for some clarification on this thread, since a
number of people seem worried. To summarize:

* there is no existing or planned rule that WMF Features dept must sign off
on all extensions prior to deployment
* there is no existing or planned rule that WMF Features dept must maintain
all extensions prior to deployment
* there is no existing or planned rule that WMF Features dept can choose to
waive these requirements, because they don't exist in the first place

Existing and continued-to-be-planned policy is that someone, somewhere has
to maintain stuff to be deployed, but there's no specific rule on who.

-- brion



On Thu, Oct 3, 2013 at 6:50 PM, Terry Chay <[hidden email]> wrote:

> On Oct 3, 2013, at 3:15 PM, Terry Chay <[hidden email]> wrote:
>
> > 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.
>
> 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.
>
> 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: [hidden email]
> i: http://terrychay.com/
> w: http://meta.wikimedia.org/wiki/User:Tychay
> aim: terrychay
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Bug 35306: Global (to a wiki farm or family) message delivery (thoughts)

Erik Moeller-4
In reply to this post by Terry Chay
On Thu, Oct 3, 2013 at 6:50 PM, Terry Chay <[hidden email]> wrote:

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

I'd actually say that this paragraph more accurately describes both
historical and current practice than your preceding enumeration,
except that certain competencies (product/design) have historically
been under-represented in the dev process and should be more
consistently looped in now that we have more folks who wear those hats
(both within WMF and beyond).

Erik

--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Bug 35306: Global (to a wiki farm or family) message delivery (thoughts)

MZMcBride-2
In reply to this post by Brion Vibber-4
Brion Vibber wrote:
>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?

MassMessage is a utility, not a feature. :-)

I think Terry, quite reasonably, was concerned about Terry or members of
Terry's team being tasked with indefinitely maintaining an extension that
Terry and Terry's team had no part in developing. My confusion comes from
where Terry got the idea that anyone was asking Terry or Terry's team to
get involved here in any capacity.

My understanding is that the MassMessage deployment came up in an internal
Wikimedia Foundation meeting and Terry injected himself into this issue.
After learning that Terry had an interest, I copied him (and Howie and
Fabrice) on the relevant bug and then e-mailed the three of them directly
the following week when I didn't hear back from them. This, along with
posting to a public wiki, a public bug tracker, and committing code to
a public code repository, is what Terry has described as "back-dooring."

In the past day or so, Terry has made a number of claims about Wikimedia
development (both past and present) that appear to be undocumented,
unsupported, and/or untrue, depending on the claim.

MZMcBride



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Bug 35306: Global (to a wiki farm or family) message delivery (thoughts)

Dan Garry
In reply to this post by Terry Chay
This has mostly died down now so I'm reluctant to perform thread
necromancy, but there are a few things for me to say here. I'm going to
stick to the product side of things (i.e. MassMessage stuff), as that's my
primary domain. I could also offer some thoughts on the other topics of
management and community code deployment, but I think the (in my view) more
important discussion of the product.

I think, as one of the people with an overall responsibility for platform,
I would be negligent in my duties to simply accept Terry's "no" without
doing a more detailed assessment of the situation myself. If someone asks
me why I didn't do something, and my only response is "a director told me
no", then I'm a bad product manager. I need to have my own reasons. I also
think this no from Terry has not taken into account that this is not
intended to be a long term solution, which I will elaborate on below. The
mistake I *have* made so far in this is that I made "sure, let's do this"
comments on these bugs without properly assessing the long term plan and
vision of the product, which is also bad product management. I will do this
assessment in this email. I'll look at the problem, the solutions, and
questions that arise from this.

*The problem: the presently available mass message delivery system is
inadequate.*
Whether you're looking at it from the point of view of site performance, or
purely in terms of delivering messages effectively, I think we all agree on
this. EdwardsBot has been around for a long time and when it was made it
solved a problem to which there was no other readily available solution,
namely getting messages out to people. However, it is fundamentally a hack,
and might not integrate with the vision of the future (e.g. Flow).

Given that we're agreed on what the problem is, trying to derive a product
that solves the problem is easier than if we disagreed! So, let's look at
the high-level details. It doesn't make sense to get bogged down in details
(e.g. exact workflows for the product's operation, such as the question of
whether it makes sense for any admin to post messages to any wiki from any
other wiki) before we even consider the high-level solutions. The way I see
this discussion so far, there are two high-level solutions to the problem
that've been proposed.

*Proposed solution 1: refine and enable MassMessage (with the view that it
will be superseded at some point by a better solution) then work on the
better solution.*
*Proposed solution 2: abandon MassMessage, and continue to use EdwardsBot,
and focus our efforts on the better solution.*
*
*
The first thing I observe about these solutions is that both of them
recognise that MassMessage is, relatively speaking, a short term solution.
We all know it's going to be replaced by something better in the future. So
the above solutions really boil down to a single question.

*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.
*
*
In terms of my own training and enrichment as a product manager, I think it
makes sense to try to explore these questions anyway, as it will contribute
to my skill set. In fact, even writing this email has helped me with that.
*
*
A quick comment on the long term solutions. I disagree with the idea that
echo should be used actually deliver newsletters (e.g. The Wikipedia
Signpost, Wikiproject newsletters). It should notify one of the delivery,
not actually deliver. I think, in terms of the future (i.e. Flow), it
doesn't make sense to have a bot (whether it's EdwardsBot or a MassMessage
bot) starting a discussion on a Flow page to deliver a message to you.
That's also doing it backwards. However, Brandon has talked a lot about how
his ideas for Flow will include being able to subscribe to discussions. One
could extend that to also subscribe to newsletters, and you can then choose
whether echo notifies you of them or not. The newsletter is held in a
centralised location and displayed to you on some relevant feed that's
designed for newsletters. That's my vision of the future, in particular
because it's not specific to the WMF domain and can easily be used by other
large wikis to get notices out to people. Whether there needs to be a
specific use case for subscribing to newsletters, or whether it's included
in a separate use case, is a discussion to have about Flow.

I'll put the assessment of these things onto my priority list.

Dan


On 3 October 2013 20:22, Terry Chay <[hidden email]> 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 <[hidden email]> 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: [hidden email]
> 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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Bug 35306: Global (to a wiki farm or family) message delivery (thoughts)

Jonathan Morgan
Necromancy? I'll jump on that bandwagon.

On Thu, Oct 10, 2013 at 9:01 AM, Dan Garry <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
> > 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
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



--
Jonathan T. Morgan
Learning Strategist
Wikimedia Foundation
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
12