== Draft proposal ==
This guideline defines where [[ https://www.mediawiki.org/wiki/Technical_Collaboration_Guideline/Vision#Calls_for_feedback | 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 [[ https://www.mediawiki.org/wiki/Technical_Collaboration_Guideline/Vision#Checkpoints | 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-Liaison), then they should be identified in the project page.
* If there are additional channels or languages covered with the help of volunteer [[ https://meta.wikimedia.org/wiki/Tech/Ambassadors | 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.