This page lists questions that community members routinely ask when they learn about a new, upcoming project. It is not meant to be comprehensiveâMovement Communications have read these questions often enough that they have decided to try and summarise the most frequent ones. You can use them to draft your own FAQ page.
Question
Rationale: why does this matter?
Background
What problem(s) is this intended to solve, and for whom?
This helps people identify if they will be affected, which may influence how much attention they pay, and the nature of their reaction.
Based on what evidence, research, or request?
Wikimedians prefer to not only hear about research results, but to read it themselves. Some of them may even be able to point out additional prior research. A planned software change may not make sense to a user or set of users, based on their experience. Providing research may help the users to see the problem from a different angle, or provide additional input.
Has this been tried before, internally (by staff or community members), or externally (is it an industry standard)?
Previous efforts, if they exist, presumably inform current plans. It's good to know what lessons have been learned. Additionally, people might have preconceived notions of expected software behavior from other sites. We also try to avoid proliferation of standards.
What is changing
Will this replace an existing tool?
Replacing an existing tool is a dramatic shift for people, and takes more work to get used to. Many of the workflows for curating the content on many "major" wikis are highly customized, and prone to break easily. Editors need time and space to adjust to changes to their workflow(s).
Will this break anyone's workflow? To a significant extent? If you are affecting people who are not your target, can precautions be taken to not do so?
The extent to which workflows will (or might) break is important in determining the amount of communication necessary for a change. If people who are not directly benefiting from software are affected by a change, they tend to be adverse towards the change. Minimizing this risk is important to acceptance.
Will it add to existing contributors' workload, if it's a success?
The extent to which workloads are increased is important when communicating about a change. The communities will be more open to adjusting if they sense that drawbacks aren't being hidden, but that they have been foreseen and that measures have been taken to mitigate issues.
Will it scale? (both to small wikis, and to large wikis)
People want to know if they can or should expect to see this on other wikis, or affecting millions of users.
Have you defined a glossary introducing any new terms?
Glossaries help native-language speakers understand new terms, and helps translators to introduce new terms into their language communities as well.
Timeline
Do you have a timeline, no matter how rough?
People would like to know when to expect things for various reasons such as event planning, and a rough idea of when things may happen will help relieve some anxiety about potential changes. If yes, make sure it is published. If no, at least publish an idea of when one might be available.
Can you define, even roughly, the product's individual definition of alpha/beta/MVP/release?
People want to know the definition of a product's stage, so there are parameters and boundaries around the development limitations. People can tolerate more bugs and missing features if the status of the software and the state of its iteration is clear.
Feedback
Where are you discussing this with the communities?
Discussion is the basis for many decisions on-wiki. Communities often prefer to discuss software changes before they occur, identify blockers, concerns, bugs, missing features, support, assistance in communications, etc. Documenting the location(s) makes it easier to both centralize new discussions, and to find old discussions.
