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@wikimedia.org wrote:
On Oct 3, 2013, at 3:15 PM, Terry Chay tchay@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:
- 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@wikimedia.org i: http://terrychay.com/ w: http://meta.wikimedia.org/wiki/User:Tychay aim: terrychay
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l