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?

In T124288#1959108, @AdHuikeshoven wrote:

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.

In T124288#1959108, @AdHuikeshoven wrote:

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.

In T124288#1961823, @Qgil wrote:

In T124288#1959108, @AdHuikeshoven wrote:

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."

This task is blocking T124022: Goal: Clarify community engagement in WMF product development process and I'm scheduling it for March accordingly.

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.

2. 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.

In T124288#2209533, @Elitre wrote:

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.

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

In T124288#1983609, @Whatamidoing-WMF wrote:

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.

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.

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.

See also: T137088: Recommendations to publish Product updates

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?

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.