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