Just to be clear, this page is not intended to be open for editing by anyone, correct? I'm noticing that all of the content here has been written only by WMF employees. I can see why this might be a WMF-only page, given that it deals with WMF practices, but if that's not the intention, it would be pretty silly if participation was wanted but nobody participated due to an incorrect assumption...
Talk:Technical Collaboration Guidance/Flow
Hi there. TCG is still in a review phase by teams at WMF. Community feedback on talk pages is always welcome. We invited reviews last year, and I think what's in that email still applies.
That doesn't really answer my question, unless review means something other than I thought it did... Thanks for the information, though.
I've been copyediting TCG pages as I re-read them, and I've found several unnecessarily long sentences. I think it might be a good idea to check these pages for translatability, once the drafts are a little more developed.
I agree, thank you.
(I may be wrong FWIW)
- the doc doesn't seem to mention progressive/staged rollouts, a popular and common way of launching a feature in gradual steps to better figure out community reception and catch bugs;
- it looks like we make a big deal of translations, but then this doesn't seem to be reflected, or at least not enough, in the principles;
- it doesn't seem to mention retrospectives or other useful practices thru which the teams can be more equipped for future work.
The TCG is finished, as part of last fiscal year's annual plan as noted in the introduction. I would add that by "finished" I mean it's as finished as a wiki page can be; it's free to be modified and/or expanded as needed in the future to reflect practices. The draft tag remains, however, as management teams within the WMF still need to get together and come to an agreement over what this draft means in theory and in practice (i.e. to make sure that everyone is on the same page). The TCG remains a help document so the the agreement that the page is waiting for does not have to do with any notions of implementation in the sense of policy or process.
In practice, the TCG is being used in the day-to-day, project, and strategic planning work of the Technical Collaboration team. These best practices have been used for quite some time this past year, and will continue to reflect the methodology of the team's work. I am also working with the ORES team as they develop an auditing tool, helping the team align their work with the TCG as best as possible as the tool cycles through development.
And, uh...that's about it for now, I think. Thanks to all who have contributed on this and other talk pages for this project, it's much appreciated.
Might be an interesting case study: Phab:T163069
There's the subject-space page and then six subpages to read? Can this be consolidated and put on a single page? Each of these seven pages also have separate talk pages. Am I really expected to read 14 pages?
Oh, I found another subpage, Technical Collaboration Guideline/Vision, which of course also has a long talk page. Bleh.
I'll copy here what is relevant of a comment I made about how the TCG "handles" community concerns here.
Year after year the WMF has forced out disruptive and controversial software projects. In 2013, it took a community revolt on English Wikipedia for the rollout of VE, which (as I understand it) was ultimately revealed to have been rushed out in part due to financial grant terms, despite it causing significant damage. In 2014 controversy over Flow erupted. It took over a year of kicking and screaming for the WMF to concede that it wouldn't necessarily roll it out globally in the future, and yet more months before it was removed from enwiki, and even then only under threat of a serious flaming at RfC. In 2015 Gather was introduced to enwiki. In this case indeed, actionable blockers were proposed: collections could not be deleted, collections automatically used non-free content in violation of the EDP, the moderation system was very hard to use, and enwiki admins were being expected to patrol it with no benefit to serious contributors of content. Only one of these things was addressed. Complaints continued to be raised about the rest of the problems, but Moushira Elamrawy, the liasion for Gather, instead of understanding and passing on the gravity of these complaints, tried to pacify the community without taking any action about the problems. Eventually an RfC demanded Gather be removed. Then Toby Negrin needed a lot of convincing that yes, we actually meant it, and we wouldn't allow him to kick it into the long grass. Yes, the proposal looked reasonable on the face of it, but all trust had broken down.
For years the WMF has needed to be coerced into listening to community concerns on major software projects. Time after time, staffers have tried to avoid dealing with the issues. Now the TCG says that, to slow down a deployment, the community must declare actionable blockers. It doesn't [explicitly] allow for philosophical differences of opinion. It doesn't mention a community outright rejecting a feature. It's a codification of the existing uphill battle communties face when trying to get their fundamental, deep concerns heard about a project in progress.
Hi BethNaught,
I understand where you are coming from, and perhaps I can explain the difference here in implementation with the TCG and the previous experiences. Please keep in mind I might speak in some broad generalities in a few cases, and know that I understand specifics are much more complicated.
When the previous instances have occurred, a good deal of the pain and division was created by miscommunications, a lack of clarity in expectations, and a lack of clarity in roles and responsibilities in developing and deploying software. These failures create the philosophical differences that end up often times dividing and inflaming releases. Identification and engagement with communities and community members should be taking place from the inception of an idea, with discussions along the way as needed to review and mold the product to make sure that it fits community needs, both in philosophy and hands-on work.
What we often had in the past occurrences was a lack of engagement from the start of the idea; the result was that the WMF had the idea, built out the prototype or whatnot, released it, then asked for feedback. At that point we're in the bad feedback loop cycle, from the very start. At this point is when, as you say, the "philosophical differences of opinion" come to head and there's really no fruitful outcome to be had for anyone, because we weren't all on the same page from the start.
The idea behind the TCG is that communities and community members should be on the same page from the start. Ideas can be discussed through to make sure these philosophical differences are worked out before it is too late, identifying what a product can and can't do to fulfil the needs of the communities. In light of this approach, I do not consider it a codification of the uphill battle. If the idea was to continue on in the "old way," so-to-speak, just dropping things on communities and not taking "I don't like it" for an answer, I'd be much more inclined to agree with you.
Now, with that said, "I don't like it" still isn't a valid answer for blocking software, just as it's not a reason for changing content or policies on the wikis. What should occur is collaboration and consensus building, and we at the WMF can work on doing that from the start, just as volunteers do to build the projects.
Thank you for your considered and thoughtful answer which clarifies a few points. I would say that "I like it" isn't a reason for mandating a software deployment either. When there is agreement about a fundamental idea, the TCG seems to me to be a collation of good practice which ought to be observed. It might have helped the PageTriage extension and the abortive page creation workflow on enwiki, for example. Also, if as you say, collaboration on ideas from the start means that certain disliked ideas will be more readily killed off, that is good.
One specific provision I question in light of your comment is "It may happen that one or just a few communities will keep pushing back a new product/feature while all the rest are happy with it. The likely scenarios are that either the new product/feature keeps spreading until reaching full coverage, or the community concerns grow and ultimately force a change of product plans" (from /Community decisions). This needs to be better defined. Last time I heard, the Related Pages extension is not being deployed on dewiki because of their Themenring policy, although some other wikis actively welcome it. This is a counterexample. While I realise having many wikis with different combinations of extensions can be a pain, the TCG needs to lay out under what circumstances individual wiki opt-outs are possible/likely. "Change of product plans" is unhelpfully vague IMO.
I agree about your points that need better defined - and I'd extend that to most points raised in the TCG as a whole. This is something I think about constantly, and is something that will be pursued in the future. The idea right now is to establish some baselines and best practices in communication, which in turn will lead to general good habits around discussing ideas, transparency both in planning and decision making, and all those other dreams of working better, together. There's a whole lot of steps in between to accomplish this, and it will take a lot of time, but that's the general vision here.
tl;dr, in response to your further points, is they are good ones. We have to discuss and detail opt-in/opt-out criteria. That is a large topic on its own right, and will have to be worked out as a separate project from the TCG. It will happen, though I have not discussed any timeframes for those conversations at this point. Getting down these baselines of communications is a first step.
I would like to suggest adding performance to the same level of requirement as privacy and security. When any of those considerations are explored after the fact, it can be expensive, or completely impractical in the most extreme cases, to apply. It can be a legitimate blocker for a launch when something is slow, just as it is when it's insecure or has privacy issues.
A slow service is also a service inaccessible in many parts of the world, as people tend to give up before a slow feature loads. In that sense it's a sub-part of the accessibility criteria already listed here.
Good point, thank you. I'll look into it for the next draft.
After being reminded of phabricator:T130470, I think we should make sure any document of this nature includes guidance about documenting lessons learned from failed projects and deployments. To not summarize and document past failings (and successes!) is to waste both donor time and money in an unacceptable way, in my opinion.
As noted in a separate thread, I haven't read everything written here, so this may already be covered in this guideline.
Postmortems are not currently in the TCG, but it's a good idea to look at working something in about them. Thanks for that.
I've received a good deal of feedback about the TCG being called a "guideline," since the word guideline has a specific connotation - it's a form of instruction. This was giving a false impression of the TCG, where we wanted the emphasis to be on the guidance provided. As such, I changed the name.