Talk:Technical Collaboration Guidance/Milestone communication

See Talk:Strategy/Wikimedia_movement/2017/Cycle_2/The_Augmented_Age#What_else_is_important_to_add_to_this_theme_to_make_it_stronger.3F . Looks relevant for this page theme, especially with the upcoming changes that the Newsletter extension may be bringing?

The sentence above is confusing. I believe the subpages are supposed to be for milestones?

You're right, I've clarified the text to "a dedicated wiki subpage of the product and/or project's page on mediawiki.org."

I think it would be useful to offer a project page template (a skeleton, not a MediaWiki template). Project owners could adapt it, deviate from it or ignore it completely, but having a common reference would be useful.

For instance, in the context of the Onboarding New Developers program, we want to define criteria for Featured Projects. One of the criteria is a decent project page. However, what makes a project page decent?

CC @AKlapper (WMF)

This is what I'm wanting to do at phab:T155663.

Yeah, if there is a template designed then I'm more than happy to include it here.

This should be a more official recommendation somewhere. It also lives on Office wiki, but it should belong to TCG. Just like there are no rollouts on Fridays, there should be no (major) announcements on that same day as well, in particular if the announcement is deemed to be potentially troubling and may cause immediate and worried reactions, it is important that the entire team (not just the CLs) is around to address questions promptly and to help achieving a well informed and balanced conversation.

When a certain change, no matter how minor, requires further actions from the communities (for instance changes in Common.js/Common.css), that change should be communicated on wiki, along with clear expectations of the changes to be made and, if possible, an example.

It would also help if such changes could be evaluated after a while: how many communities did make the change? For the communities that did not make it, what was the blocker? Did they start a discussion following the announcement? Did they work around the new feature to disable it? Are they dependent on a single person who was not available/willing to make the change? On the long run, this should lead to upgrades to this guideline.

https://meta.wikimedia.org/wiki/Tech/News is on-wiki and might be sufficient? Or do you have recent examples of changes that require further actions from the communities that were not included in Tech News?

For communities that subscribe to it with the Village Pump, it most likely is. For the rest, I'm not sure, the workflow probably differs from wiki to wiki. Sending a one-time invite for communities to subscribe their village pump would help mitigate this and make the news more relevant.

Due to the massive size of Wikipedia and sister projects, even apparently insignificant changes applied to a large number of pages can affect a significant number of viewers. I believe that such changes should be announced at the very least to the Technical Ambassadors so they can respond to questions. While it is difficult to say what "large number of pages" should mean, I would include here changes that affect common page elements (TOC, tables, images, infoboxes)

All changes might effect large number of pages. I think the point of concern is the level of impact (iow: how much is changing). We're a big website with tons of pages and tons of viewers. So any absolute (or even relative) metric for "large" wouldn't be useful in gauging importance for further review/announcement.

Currently the TCG only mentions Tech Ambassadors in the context of translations. While there is a connection between Tech Ambassadors and volunteer translators indeed, they are not exactly the same concepts. Tech Ambassadors have a (mostly untapped) potential for mediaing in the participation of communities in product development. For what I know, this was in fact part of the original plan. We have a mostly non-publicized mailing list and it is already being useful, but with some (little?) extra effort we could have a lot more.

Affirming that "what do we do with tech ambassadors?" is still an open question, up to and including "who is 'we'". I do think this has a part in systemic community engagement, but I think creating, executing, and then maintaining a plan here is a pretty big undertaking since, at the end of the day, it's volunteer management. It'll take a dedicated project to revamp the program, IMO.

Volunteer management is one of the specializations of the Technical Collaboration team. Instead of revamping, we could do progressive improvements, planning one per quarter or so. What is important is to agree on an objective first. We (you, I) could ask in the tech-ambassadors list, pointing them to this thread.

With the Cross-wiki search conversation drawing to a close [1] I wanted to reflect upon the task and how what we did reflects in the sections outlined here. This is a bit of a ‘postmortem’ on how the TCG guided us and what we learned along the way. I hope it’s valuable to other liaisons and product teams. I also hope that it doesn’t sound too much like I’m patting myself on the back. :) Keep me honest if it does. I encourage others to do the same reflection with their work.

When and how

I think by having the conversation early we didn’t get caught in too much ‘last minute’ work. Working with the Product Manager and engineers we defined deadlines by working backward from the biggest date. For us it was “We want to give the community members interested in search enough time to respond”. Our aim was for a month (set roughly on July 19 (https://etherpad.wikimedia.org/p/inter-wiki) of discussion time. Since the last day of the quarter was at the end of September we aimed for getting the communication ready (in messaging and preparedness for translation) by the end of August.

I don’t have a good gauge to know if a month was appropriate, but no one was upset at it being too short :) I do think that a handful of weeks would be too short for a task of this importance/size. I also think we could have done a bit better job communicating reminders about participating.

A note on coverage - maybe not TCG specific, but product plans should account for sick time, vacation, professional events, and just plain emergencies. I was out for a week in the midst of starting the conversation and made sure to reach out to both the product team and my peers to make sure the work moved forward.

Translations

We had translations in our plans all along, including a week of time after finalizing the communication to ask for translations. As reflected in the TCG, planning for translations helps greatly in being honest in our goals to include all communities.

We had the post to the various Village Pumps translated into 10 languages other than English.

The main page was only translated in to Ukraine. I should have pushed for more translations in both the message and conversation. A hard thing to balance for me. I don’t want to be too burdensome to our volunteers (or to fellow staff in my absence).

Where

There was a small discussion on which wiki to post the request for feedback. Meta seemed most appropriate as the changes to search will affect all projects. However, considering the Discovery department has an overwhelming amount of documentation on MediaWiki the decision was made to host it there.

I think more important than “where will this live” is “where will you share it”. We used the Village Pumps and mailing lists as our main drivers back to the conversation. With past Discovery discussions we’ve stuck to the more technical-focused mailing lists (discovery-l, wikitech-l). Since this task reaches well into the non-technical side of things we also included wikimedia-l.

Because the conversation was grouped around “Should we make this change?” and “How should this change be designed?” we created a sub-page specifically for the design aspect with a few ‘teaser’ images on the main discussion page. I think this helped keep the introduction and ‘ask’ a little easier to digest.

What to say

Humorously our request for comment was three sentences on what will be a significant change to the appearance and functionality of search across all projects. When Deb wrote the message I couldn’t think of much to add; or remove. To add to what the TCG says regarding ‘What to say” I would add, “Be as succinct as possible”. Short sentences that are to the point go much further than long sentences that bury the focus.

Speaking of focus, we tried to focus the questions around a few topics. We approached the communities with five big questions. However, the first question had 10 sub notes. Probably could have been a more succinct there. :)

At the same time wanted to prompt discussion with ideas. I’m of the thinking it’s easier to get feedback when you have some sort of prompts vs a blank talk page. My advice for future projects is to keep the focus around the conversation with 2-3 big questions for folks to ponder. Don’t say, “What do you think?” instead say “What do you think about A, B, and C?”. Populate the talk page with those topics and encourage other topics to be included.

What to expect

In past lives I’ve worked at large organizations spread out across multiple geographies. Getting everyone - who is paid to work there - to respond to consultations always proved problematic. When applying expectations to an even larger and more diverse group of folks volunteering their time I am pleasantly surprised when any number of folks show up. :)

However, again I would have liked more voices. We had less than a dozen voices in the talk pages about of a few hundred page views and mailing list/Village Pumps with even higher viewership. I think a change of expectations around how frequently we reach out during a consultation should be discussed. Posting once and waiting for folks to show up is not good enough. Perhaps ‘check in’ reminders or further channels could be utilized during a push to get more folks to participate.

To be clear, I do appreciate those that did show up and thank them for their time and thoughts.

----

These are just a few thoughts I had after working on this task during the last quarter. I'm happy to answer any questions and appreciate feedback.

1. ↑ the conversation has died down, it is the end of quarter at the WMF, and starting this conversation was one of our team goals.

Thanks a lot for this. My 2c, when you write Don’t say, “What do you think?” instead say “What do you think about A, B, and C?”. Populate the talk page with those topics and encourage other topics to be included., I'd actually rather see that expanded to "What do you think about A, B, and C" and "Add a proposal here". You want to go with the first option only if alternatives are really not so many or viable and you need help figuring out which one would work the best for most people; but when you are "brainstorming" ideas, you want to make space for other ideas you didn't come up with and to give them equal chance to be selected.

I agree!

I think that prompts are very useful, especially if they come in the form of concrete examples and screenshots. I think it's hard for people to "see" what we're talking about. This can be hard enough in our everyday volunteer work when talking about (for example) how to re-structure a Wikipedia article, but it's even harder for editors and other content contributors to "see" what the devs mean when they're talking about software behavior.

The examples of prompts I had in mind are more like this one from Legal, this one from Reading, this one from the Maps team.

Minor point on planning translations:

When it works out, I try to request translations at the start of the week. Tech News does its translation work over the weekend, and it's good to stay out of their way. Also, when you request translations on a Monday or Tuesday, then you're more likely to be around the first few days (when most of the translation work is done), in case any of the translators have any questions.

On the problem of (enough) people not responding:

• We're sending out too many notices for too many discussions already.
• If we send out multiple announcements per discussion, we may get even less response ("Eh, I don't need to look at that today. They'll send me a reminder next week..."). And we'll certainly make the signal:noise ratio worse for 99% of contributors.

One option that I've been considering is combining everything into a single (monthly?) announcement, sort of Tech News style, with links to all of the major discussion requests and announcements. I'm not sure this is The One True Solution™ (in addition to the obvious faults about time, hassle, translation, etc., sometimes it would be a near-duplicate of the main page at Meta:, so perhaps not adding a lot of value), but if we come up with enough ideas, we might find something that's more or less workable.

There is an idea that we haven't developed or even agreed yet about having checkpoint pages, project information pages, and the possibility for users to subscribe for updates in a specific checkpoint and/or project. I think this is better than one big list with everything every month which, again, will be followed by more or less the same usual suspects.

In this example, the checkpoint would be i.e. "New feature proposals" and the project would be "Cross-wiki Search". Since it is the first checkpoint of a new project, it would have been notified in the parent project "Search" (and/or "Discovery") too.

The Newsletter extension (which si functional since Wikimania and is waiting in Beta to complete code review and security review) will make the creation and maintenance of these "information points" very easy.

But people still have to magically know that they need to sign up for a particular newsletter, if they want to learn more about the project that they still haven't ever heard about, because the information wasn't pushed out to them.

Sure, new project proposals and in general "new" anything need an extra push in communication. I still think the idea of specialized checkpoints works better for all the rest of situations.

Anyway, maybe we can offer the full list you are proposing by virtue of section transclusion, aggregating the recent updates of each checkpoint into a "monthly log" of sorts.

I have a similar idea. Has anyone discussed doing something like the Centralized_discussion template on English Wikipedia?

But where would that template live? On each wiki? With content in English?

Well, it sort of already lives at M:Community Engagement/Calendar. In English, of course.

Should "mass-message delivery to appropriate community forums" be linked to Help:Extension:MassMessage?

"Principles" said "with public feedback loops whenever possible" and "Milestone communication" says "volunteers [...] may leave useful feedback". The "Where" section lists "A dedicated wiki product or project page" (which has a Discussion page) or "mailing list". Should it be explicitly mentioned that you should expect and react to important and relevant feedback, or am I overcautious?

Good question. The issue here is the subjectivity of what is important and relevant feedback, which should be put forward in the expectations in the ask. I'll think on it.

The current text says: community members then have the opportunity to respond with questions, comments, and concerns that will help the product iterate.

I basically drew two inferences from that. (1) It could be interpreted as the WMF saying it intends to reject/ignore any community feedback unless it is feedback saying the project should move forward, and (2) that was not the intended meaning, as it seems to contradict the the process that Qgil-WMF has been writing up. Those other pages say the WMF does invite community feedback that a project should back up or be blocked.

Keegan (WMF) informed me that was "not the case", and apparently disagreed with one of my two inferences. However I'm at a total loss trying to figure which of the two inferences Keegan was referring to. The two interpretations are completely opposite.

Either:

1. The text here should be clarified to say the WMF welcomes community feedback that there's a problem and a project should roll back or be blocked; or
2. This page does intend to prohibit/ignore that sort of community feedback, the various pages are contradictory, and WMF needs to sort out a coherent position on what Collaboration means.

For what it's worth, I hope/vote for option 1.

"This product does not suit our project and should not be deployed, or rolled back" certainly falls under the category of a concern. The text I have written does not contain inferences, assumptions, or hidden agendas, and I'm not going to alter it because you are looking for them, nor am I going to pick your false either/or dichotomy.

I'm glad we agree that it shouldn't be interpreted as restricted only to "concerns that will help the product iterate". Given the history of miscommunications and tensions, and the fact that there *are* a lot of people who will interpret it as meaning what you wrote and only what you wrote, do you agree it would be beneficial to come up with some way to rephrase it which doesn't invite that sort of miscommunication?

I do not agree, and please indulge me to explain.

I understand the context for your point. As staff I was there for the visual editor release, I was there for Media Viewer; as a volunteer I was there for a million other decisions before related to how our wikis look, feel, and function. I truly get the misunderstandings of communication.

The TCG is meant for product teams, it provides a very high level documentation of best practices. The audience for the text is not everyone, it is very focused and does not exist in a vacuum. The TCG's principles and practices will go hand-in-hand with product work - if we do this right, we will continue to make great inroads technical collaboration with the Wikimedia communities. Including disclaimers about whether something has approval or not is moot, because the goal of one of the goals of our team's work is to not even be producing things that are not beneficial in the first place.

If you're interested in talking to me real-time about my project, please email me and we'll set up a time to talk by whatever medium you might be most comfortable with.

Thank you. Explaining it as intended as an internally-directed communication helped me understand where you're coming from. I still offer my suggestion that it be worded better. Regardless of the intended audience, it's still a public page and there is community interest in how the WMF plans to handle the subject. The current wording too easily pairs up with the Media Viewer Consultation, where the WMF literally declared "out of scope" any discussion other than upgrades. I think it feeds distrust if it leads any cynical readers to read it in that sort of manner.

one of the goals of our team's work is to not even be producing things that are not beneficial in the first place

Yes, certainly. Most of the time everything is fine, and I'm seeing lots of good steps being taken to reduce the chance of problems in the future. But eventually there is going to be a good-faith disagreement on what is "beneficial". That is the hard-to-address case, but that's exactly the case that most needs to be addressed when everything is calm. It would be bad for everyone if a future conflict were to escalate worse than in the past.