Topic on Talk:Technical Collaboration Guidance/Milestone communication

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.