Page MenuHomePhabricator

Communication channels between communities and teams involved in the product development process
Closed, ResolvedPublic

Description

Draft proposal

This guideline defines where calls for feedback should be handled. The focus here is on concepts, we can polish the format and wording on-wiki.

Requirements

  • A call for feedback is announced by a team in relation of a project and a checkpoint. Team, Project, and Checkpoint pages must be up to date when a call for feedback is announced.

Locations

  • The canonical page of a call for feedback is a translatable subpage of the related Project page in mediawiki.org, i.e. mediawiki.org/wiki/Nice_Project/Design_ checkpoint
  • A project in Phabricator must be identified as destination of the processed feedback.

Announcement

  • The announcement of a call for feedback must be posted in these locations:
    • Project page
    • Checkpoint page
    • Project and Checkpoint newsletters (requires Extension:Newsletter being available in mediawiki.org)
  • Optionally, the team can announce to additional channels, expressing clearly whether feedback must be posted in the canonical discussion page (default) or whether they will be watching that channel and engage in discussions there (exceptional situation backed by team members or volunteers committing to the task).
    • For the first and last checkpoint (Plan and Beta), the main Village Pump is a good destination.
    • For the intermediate checkpoints, it is better to target the Technical Village Pump in order to avoid fatigue in the main one, or skip the announcement whee no TVP is available.

Feedback and discussion

  • The canonical page for discussing a call for feedback is the related discussion page.
  • While English is the default language, feedback in other languages can be posted in the canonical discussion page, understanding that the team will do their best to understand the message, and they will reply in English.
    • If translated versions of the call for feedback exist, their discussion pages can also be used to post feedback.
  • Since all relevant feedback must be ultimately reflected at the Project space in Phabricator, feedback posted directly in Phabricator is welcome as well.

Resolution

  • The resolution of a call for feedback will be posted in the cal for feedback page, and it will be summarized in the Project page.
  • All the actions resulting from the call for feedback must be documented in the call for feedback page.
  • Actions will be linked to their related tasks in Phabricator, except in justified cases that will be explained in the call for feedback page.

Previous description

We have a product development process with several stages, several development teams, several communities, and several individuals, all of them using multiple communications channels, multiple tools, multiple languages...

We need to make sense out of this, so communities can participate, individual contributors can get involved, and development teams can get things done.

Some ideas:

  • Communication is useful only when the relevant information reaches the development team and influences their work.
  • We should define the minimum communication requirements for any project following the process, i.e. a translatable project page in mediawiki.org and a project in Phabricator, both watched by the team, who commits to respond in English in these channels.
  • If the team wants to be active in more channels or languages (on their own or with the help of Community-Relations-Support), then they should be identified in the project page.
  • If there are additional channels or languages covered with the help of volunteer Tech Ambassadors, they should also be documented in the project. The idea being that the participants of any channel or community could easily check whether they are currently "supported" or not.
  • Phabricator would be the place where ultimately action happens. Important feedback needs to be reflected in the form of bug reports, tasks, blockers... It should also be the place with more demanding communication standards (English only, technical/product discussion, on-topic, avoidance of duplication and redundancy...)
  • However, nobody apart from the project contributors should be forced to use Phabricator. At the very least, non-technical users should be able to provide feedback in English at the project discussion page, knowing that someone will take care of taking any relevant bits to the Phabricator project. The same is to be expected in the other channels and languages that the team has identified as supported through their project page.

This flow of communication can only work when people know when to provide feedback about what and where. Watching wiki pages, phabricator projects, mailing lists and village pumps will not work efficiently for a majority of potential contributors. Each of these channels produces too much noise (or "signal for others, noise for me").

Subscriptions and notifications should play a key role informing the right targets about the right topics at the right times:

  • Imagine that people could subscribe to key updates about a specific project, i.e. Mary subscribes to Project WikiFoo.
  • Imagine that people could subscribe to key updates about a specific development stage, i.e. John subscribes to Release Stage.
  • Imagine that Project WikiFoo just declared their intention of entering the Release stage by publishing a release plan proposals. Both Mary and John would receive a notification "WikiFoo's release plan is available for review".
  • This functionality could be provided by the upcoming MediaWiki-extensions-Newsletter (T110170).

Discussions and Q&A are not the only ways to discuss and, in fact, they are the more complex and demanding forms of communication. Ratings, surveys, and data gathering can scale better across types of users and languages. Ideally a project would receive quantitative and qualitative information that could be cross-checked in order to understand the impact of a feature better.

See also

Related Objects

StatusAssignedTask
DuplicateNone
DuplicateNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
StalledNone
OpenNone
ResolvedQgil
ResolvedKeegan
OpenNone
OpenNone
OpenNone
DuplicateNone
OpenNone
InvalidKeegan
DuplicateQgil
ResolvedQgil
ResolvedQgil
DeclinedKeegan
DuplicateTrizek-WMF
ResolvedMoushira
ResolvedQgil
ResolvedKeegan
ResolvedKeegan
ResolvedKeegan
ResolvedKeegan
DeclinedNone
ResolvedKeegan

Event Timeline

Qgil created this task.Jan 21 2016, 2:34 PM
Qgil raised the priority of this task from to Needs Triage.
Qgil updated the task description. (Show Details)
Qgil added subscribers: AdHuikeshoven, Qgil, Aklapper, Keegan.
Restricted Application added a subscriber: StudiesWorld. · View Herald TranscriptJan 21 2016, 2:34 PM
jayvdb added a subscriber: jayvdb.Jan 21 2016, 3:41 PM
Elitre added a subscriber: Elitre.Jan 21 2016, 6:12 PM

I like the part "nobody apart from the project contributors should be forced to use Phabricator. " (A lot of people find in hard to navigate Phabricator, including me).

This part puzzles me: "At the very least, non-technical users should be able to provide feedback in English at the project discussion page".

Wikimedia users in my experience prefer to comment in their own language on the website they are contributing to, for example contributors to de.wp will comment on de.wp and not on another website.

This leads to two questions:

  • "project discussion page" will that be at the home wiki of the user?
  • what if the user doesn't want to provide feedback in English?
Trizek-WMF added a subscriber: Trizek-WMF.EditedJan 25 2016, 2:32 PM

This part puzzles me: "At the very least, non-technical users should be able to provide feedback in English at the project discussion page".
Wikimedia users in my experience prefer to comment in their own language on the website they are contributing to, for example contributors to de.wp will comment on de.wp and not on another website.
This leads to two questions:

  • "project discussion page" will that be at the home wiki of the user?
  • what if the user doesn't want to provide feedback in English?

For logistical reasons, it is complicated to have a feedback page on each wiki for each project. When there is a lot of feedback or discussions, we keep a page on the "local" wiki. If not, we try to regroup feedback pages for all users on MediaWiki.org. In a close future, cross-wiki notifications will help a lot to be aware of what happen elsewhere.

In any case, people can provide feedback in their language if they want, there is no problem about that. Community Liaisons use online translation tools to understand the meaning of the request, and, when it is unclear, we ask for clarifications or request help from an other user who speak both the request language and English. The answer will be in English, unless if there is someone in the development team who can answer in the user native language.

Qgil added a comment.Jan 25 2016, 3:27 PM

This leads to two questions:

  • "project discussion page" will that be at the home wiki of the user?

In addition to what @Trizek-WMF said, the description above proposes that "If the team wants to be active in more channels or languages..." Some teams might have the capacity of covering certain wikis and certain languages, either because they have the resources or because their team members happen to be active in certain wikis or speak certain languages, and then volunteer as actual tech ambassadors themselves.

But we clearly cannot promise anything beyond Phabricator and mediawiki.org by default.

Ad, I think your second question should read "What if the user cannot provide feedback in English?" We have many users who simply cannot write in English (at all, or not enough to explain a situation). I don't think that it is realistic to expect people to provide feedback in English. As Trizek says, we can usually cope with non-English feedback. I would not want to discourage anyone from providing feedback merely because they don't communicate easily in English.

I don't think that documenting Tech Ambassadors is necessarily a good idea. Volunteers may sign up and then be absent or not paying attention at the relevant moment. On local pages, people can figure out whether someone is actively supporting the page by looking at previous comments on the page. On central pages, you should post in whatever language you think will work best. If the reply is in English (and doesn't later get translated), then that means no translator was watching the discussion.

I like the subscription/notification idea, but I don't think it will work. To use the Newsletter extension, someone has to actually write the newsletter (for every project, and there are a lot of them!). And figure out which lists to send it to (Let's see, this is about the visual editor, so that's the big list, but we're deploying to this group of wikis, so it's also the Release list – most of whom won't care about this particular release, but oh, well – and we also mentioned our plans for an upcoming feature, so I need the "Planning" list, and there's a request for feedback on a design prototype, so that's the "Design" list, and...).

I think that a subscription system might be more feasible with Phab tags. That might be less work (although you'd have to tag all the tasks), and it would be more useful (e.g., you could subscribe to only what you want, i.e., things tagged with both Release and VisualEditor).

However, I'm not entirely certain that it would represent an improvement over Tech/News for most people.

Cross-wiki notifications will be released this quarter. This feature will help people a lot, when a message is left on a different wiki than the one they are used to frequent.

And having a subscription by email is always a more important involvement than just watch (quite anonymously) a page on a wiki.

This leads to two questions:

  • "project discussion page" will that be at the home wiki of the user?

In addition to what @Trizek-WMF said, the description above proposes that "If the team wants to be active in more channels or languages..." Some teams might have the capacity of covering certain wikis and certain languages, either because they have the resources or because their team members happen to be active in certain wikis or speak certain languages, and then volunteer as actual tech ambassadors themselves.
But we clearly cannot promise anything beyond Phabricator and mediawiki.org by default.

I'm actually tempted to say that a task like T90908 looks like a blocker before we declare "default" venues. For Meta, see here.

Agree, added it as a blocker. We can't have "this is the place where, generally, everyone goes for everything. By the way, there are no rules about conduct or civility."

Qgil claimed this task.Mar 8 2016, 10:10 AM
Qgil triaged this task as Low priority.

Nobody took this task for March. I will take it tentatively.

Izno added a subscriber: Izno.Mar 8 2016, 10:10 PM
Qgil raised the priority of this task from Low to Normal.Apr 15 2016, 5:31 AM
Qgil edited subscribers, added: Alsee; removed: CKoerner_WMF, Izno.
Qgil edited subscribers, added: CKoerner_WMF, Izno; removed: Alsee.

(Sorry, weird cache problem caused some changes in subscribers)

Elitre added a comment.EditedApr 15 2016, 11:56 AM

I want to explain briefly how "feedback centralization" currently works for the visual editor. We recently steered away from a model which implied the creation of a feedback page at each of the almost 900 WMF wikis, exactly because this will help us in being more effective while processing feedback from a larger pool of wikis, not just the biggest ones. We believe every voice counts, and people deserve answers.

Since we're talking about a real case, and I sense that not everyone is convinced "centralization" should be a thing, I'm curious in finding out what problems people perceive with our current approach. Please elaborate about why this model shouldn't work with other products.

  1. There is a "central" feedback page, which lives at mediawiki.org. It is meant to be the feedback page for all projects, as in, everyone should feel that their comments about the product, no matter where they're actually using it, belong there - and they obviously can use their language. Most local feedback pages (exceptions explained below) were redirected there. Feedback left with the built-in tool inside VE also lands there, for the majority of wikis. I committed to watching that space (along with others: James and other people from the VE team spontaneously weigh in there as well). If a question is posted there, I'll reply if I know the answer, or I'll bring it to whoever does. If I can't figure something out, I can clarify with the user or request help to their community fellows. Centralization also means chances are high, that editors will find that someone else has already written about the issues or requests they wanted to post.
  1. Now for the exceptions.
  • There are some Wikipedias where the flow of feedback is constant and huge (mainly en.wiki). These wikis are also used to get similar conversations on a local page, distinct from, say, the tech village pump. Therefore, it makes sense to keep feedback local there. There aren't too many of them, so we can "commit" to a more or less stable liaison presence there.
  • There are other Wikipedias where the product hasn't been fully deployed, so we know we're gonna get increased feedback there when that happens, therefore "centralization" there is postponed.
  • There are Wikipedias where community members volunteered to keep an eye on local feedback pages which already existed, and act as "volunteer liaisons". Basically, they'll watch the page, address concerns when needed, file tasks on Phab if necessary, and escalate to me or to mediawiki.org if necessary. The Swedish Wikipedia is an example, but I'd argue the Italian one is also basically in a similar situation.

The TL;DR is that centralization doesn't really mean "one single place".
It means more a single, well-publicized place which everyone can use and which is properly "staffed", combined with local pages if people at those communities commit to maintain them (and it really takes just one person per community with a basic knowledge of English to be effective). It doesn't mean we won't get feedback in any other way or will refuse to look at feedback if provided at a different venue. It is also not the only way to provide feedback, when the team is a constant presence on IRC and offers an open weekly meeting, among other things.
(Also, the built-in feedback tool needs to be improved, as it currently delivers off-topic messages as well - not a new problem though, we know this happens on local pages as well.)

My points are:
when it comes to bugs, we need to be more effective in explaining how good feedback is given and how related conversations can be found, but we also need to encourage autonomy in Phab use;
when it comes to feature requests, it doesn't really matter if people use a local page, another page or Phab to leave related feedback. I don't think any of these are effective when each user posts their huge list of desired changes. They're basically unactionable, impossible to combine. In these cases, we may want to figure out how a given team wishes to get comments about a certain feature (e.g., the VE team used a separate page to collect all the thoughts about "table editing", but a specific thread on a board could work as well).

IMO the main problem with centralization as "one single place" is that people post information on their home wikis. If you're doing technical stuff, then you can reasonably expect that there will be some feedback at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical) because that's where many Wikipedia editors – and even non-Wikipedia editors – are going to take their questions and problems.

A relatively common process on smaller wikis is for someone to post a problem to the central discussion area, and if it can't be solved locally, then one of their fellow community members passes the information along to a bigger board – maybe the village pump for the Wikipedia in the same language, or maybe WP:VPT if they have a tech-savvy English speaker in the community, but there is an existing process of escalating problem reports in most communities that we are essentially asking them to abandon (for "products", but not for all of the template/CSS/user script/etc. things that they need help with).

And even when the users are willing to go to "Not My Wiki" to use a new process, they may not know what the name of the product is, and therefore be unable to find the central place. It's not always obvious whether a problem is actually "product" rather than "user script", for example.

I want to explain briefly how "feedback centralization" currently works for the visual editor. We recently steered away from a model which implied the creation of a feedback page at each of the almost 900 WMF wikis, exactly because this will help us in being more effective while processing feedback from a larger pool of wikis, not just the biggest ones. We believe every voice counts, and people deserve answers.
Since we're talking about a real case, and I sense that not everyone is convinced "centralization" should be a thing, I'm curious in finding out what problems people perceive with our current approach. Please elaborate about why this model shouldn't work with other products.

  1. There is a "central" feedback page, which lives at mediawiki.org. It is meant to be the feedback page for all projects, as in, everyone should feel that their comments about the product, no matter where they're actually using it, belong there - and they obviously can use their language. Most local feedback pages (exceptions explained below) were redirected there. Feedback left with the built-in tool inside VE also lands there, for the majority of wikis. I committed to watching that space (along with others: James and other people from the VE team spontaneously weigh in there as well). If a question is posted there, I'll reply if I know the answer, or I'll bring it to whoever does. If I can't figure something out, I can clarify with the user or request help to their community fellows. Centralization also means chances are high, that editors will find that someone else has already written about the issues or requests they wanted to post.

If every piece of software had a mechanism built in to centralize feedback, that'd be wonderful. Unfortunately we've only built it into a few products, and the feature of Beta Features that does this is pretty much ignored by community members because people rarely actually go to Beta Features preferences.

All in all, the model VE uses is great IMO and I wish we did it with all products.

The TL;DR is that centralization doesn't really mean "one single place".

I 100% agree, I think our team members agree as well, and so do a number of people that work directly with us. The problem that I run into is that outside of this group of people, a lot of folks within the WMF do actually think that centralization means all in one place and want to eliminate all but one feedback loop, and come hell or high water it is up to the CLs to make it happen and make the communities go along with it. The roadblock is internal in changing this mindset.

Qgil raised the priority of this task from Normal to High.Apr 18 2016, 6:32 AM
Qgil updated the task description. (Show Details)Apr 22 2016, 11:30 AM
Qgil added a comment.Apr 22 2016, 11:34 AM

Check the draft in the description, a first attempt to address all the feedback received here. (thank you!)

I like the subscription/notification idea, but I don't think it will work. To use the Newsletter extension, someone has to actually write the newsletter (for every project, and there are a lot of them!).

To make an announcement using the Newsletter extension, the team only needs to provide a title (i.e. Call for feedback: "Design checkpoint for Nice Project") and a URL (the call for feedback wiki page). That's all, pressing the send button will send a notification to all the subscribers of the newsletter.

Qgil added a comment.Apr 28 2016, 9:00 AM

Silence = agreement?

I expect the Technical Collaboration Guideline to be a living document, especially at the beginning, when theory and practice will meet in different situations. If this is good enough for a first draft, then I will post this text on-wiki wherever @Keegan prefers and resolve this task.

Qgil lowered the priority of this task from High to Low.May 5 2016, 8:29 AM

Lowering priority while waiting from @Keegan's instructions.

Elitre added a comment.May 9 2016, 9:39 AM

The TL;DR is that centralization doesn't really mean "one single place".

I 100% agree, I think our team members agree as well, and so do a number of people that work directly with us. The problem that I run into is that outside of this group of people, a lot of folks within the WMF do actually think that centralization means all in one place and want to eliminate all but one feedback loop, and come hell or high water it is up to the CLs to make it happen and make the communities go along with it. The roadblock is internal in changing this mindset.

When we started to work for VE what we did was establishing local pages. The practice of the local feedback page that someone from WMF watches is one /we/ introduced (possibly with en.wp being an exception). That proved to be a unsustainable workflow, so that's certainly something CLs just can't commit to anymore. I believe that centralization is good for anyone's sanity, and that it's a concept well established in communities as well (moving people's requests to the place where they belong or telling them "you need to ask this question on page X" rather than actually answering the question is very common among volunteers :) ). OTOH we know that when we provide multiple channels we get diverse feedback, so "ignoring everything which is not posted on page X" is not sensible either, so that's something that PMs and their teams may also want to keep in mind.

Keegan claimed this task.May 9 2016, 6:40 PM

In the light of comments at T137510, let me reiterate one point: this team has actively supported dozens feedback pages, for years. Doing this for every product, at every wiki, just doesn't work. We either agree that centralization needs to happen, with almost all the local feedback pages having to be actively maintained by volunteers only (and CLs involved only in particular cases by pings/mentions, that is, the current VE model explained above), or we would be just lying about the level of service we can provide as a team, at least when it comes to wikis.

I think at this point we can keep all the information that Quim has researched and laid out here, and link to it for further detail down the road in https://www.mediawiki.org/wiki/Technical_Collaboration_Guideline/Milestone_communication or even transfer the text to the wiki itself, then close this task because all-in-all, things are far too complicated to make this blanket granular for all teams. Thoughts on that?

Qgil added a comment.EditedJun 14 2016, 1:59 PM

I might be biased :) but I would transfer the text to the wiki itself. It is a guideline that teams can always adapt to their needs.

Filed T141868 as yet another element toward proper feedback centralization and board management.