https://bugzilla.wikimedia.org/show_bug.cgi?id=52723
--- Comment #35 from Terry Chay <[email protected]> --- 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. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
