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 <tchay(a)wikimedia.org> wrote:
> On Oct 3, 2013, at 3:15 PM, Terry Chay <tchay(a)wikimedia.org> 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: tchay(a)wikimedia.org
> i: http://terrychay.com/
> w: http://meta.wikimedia.org/wiki/User:Tychay
> aim: terrychay
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
Hi folks,
We just published a blog post with an update on the Notifications project:
https://blog.wikimedia.org/2013/10/01/notifications-launch-on-more-wikipedi…
Please share it with your community -- and let us know if you have any feedback or questions.
Thanks again to everyone who made this successful project possible!
Fabrice
P.S.: Sorry if you received this message twice, due to a technical snafu with our mail server. :(
_______________________________
Fabrice Florin
Product Manager
Wikimedia Foundation
http://en.wikipedia.org/wiki/User:Fabrice_Florin_(WMF)
@fabriceflorin