Technical Collaboration Guidance/Milestone communication

There is information to be shared between Wikimedia Foundation product teams and Wikimedia movement community members and end users. The purpose of this guide is to provide simple advice on when to communicate, what to communicate, and where to communicate, and what to expect in return. This guide assumes that there is a general product team description page, a general page for a particular product, and a page for documenting communication milestones.

When and how
Products that are being developed have milestones for information that can be shared with the Wikimedia communities. Information sharing builds knowledge and trust - the product teams share what they have, and the communities share information about the milestone back. Some examples of what can be considered milestones for information: Information about a product's development can be communicated at least towards the primary audience of the team's focus, for example the team's talk page, public mailing list, or appropriate community forum. After the information is communicated, community members than have the opportunity to respond with questions, comments, and concerns that will help the product iterate.
 * 1) Software is being considered and research and discussion is needed - check against principles, strategy, existing plans.
 * 2) How the software works is being considered and decided - user interaction, look and feel to the rest of the site
 * 3) A roadmap, plan, or timeline is determined, including tentative release dates - major community or WMF initiatives that may compete for time and energy from volunteers

What to expect
Generally speaking, the primary goal of a Wikimedian's contributions to the projects is not testing software, so the response to calls to feedback may be limited and volunteers cannot be forced into testing anything. Product teams can expect a few things from communities after issuing a request:
 * 1) There isn't really an expected or average feedback response time or rate - if volunteers are interested enough to comment, they may leave useful feedback. This cannot always be expected, and should not be taken for apathy.
 * 2) You'll hear from the users when software is deployed into production - calls for feedback prior to release of a product may attract some attention but there is little guarantee; however, if your product does not behave as expected when released the users will let you know.
 * 3) Users will likely respond with lack of familiarity with the technology - this applies to both what the user expects from the software and what its actual intended behavior is, as well as a lack of technical lingo.