Technical Collaboration Guidance/Prioritization list
 | This page is obsolete. It is being retained for archival purposes. It may document extensions or features that are obsolete and/or no longer supported. Do not rely on the information here being up-to-date. See Wikimedia Product Guidance for an evolution / follow-up of the Technical Collaboration Guidance. |
 | This page is currently a draft.
|
After a product or project has been conceptualized and discussed, it is important to ask some questions about the product to consider what makes something a priority from a community perspective. For example: What is the reason for doing this? Will I be affected? When is this happening? These questions are the sort that Community Liaisons ask to themselves and of a product team when preparing and distributing communication about a product, and they are the questions that Wikimedia community members ask as well. The reasons these questions are important is to make sure that a team is considering potential areas of concern or need in relation to the communities before beginning development.
Table form (draft)
[edit]| Question | Rationale | Example |
|---|---|---|
| Community Needs | ||
| 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. | A planned software change will only affect Wikisources. A contributor to the Polish Wikipedia occasionally edits the Polish Wikisource, so they would like to keep an eye on the progress. |
| Based on what evidence or research? | Wikimedians prefer to not only hear about research results, but to read it themselves. They may be able to point out additional prior research. | A planned software change doesn't 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. |
| Is this requested? | "Unrequested" software will generally require more convincing for adoption. | |
| Product name - Is it international? Is it unambiguous? Is it permanent? Is it the same in the code and in the docs? | Wikimedians prefer product names that are practical and translatable. Code-names often become unintentional permanent names. Long names will always be informally shortened. See Naming things. | Complicated names can be translated into many different forms, with particular meaning depending on the translation. This will confuse conversation and distract focus. |
| Is it a local or global extension? | Important to the scale of impact and maintenance. | |
| Are you affecting people who are not your target? If yes, can precautions be taken to not do so? | 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. | Users may not interact directly with a tool, but may end up indirectly in their workflows due to watchlists, recent changes, etc. If they know before hand that something is going to show up, their concern is often lessened. |
| 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. Documenting the location(s) makes it easier to both centralize new discussions, and to find old discussions. | If the software interacts with the community, holding a discussion about the software beforehand can help identify blockers, concerns, bugs, missing features, support, assistance in communications, etc. These discussions can be referenced in the future as needed. |
| Have all appropriate WMF teams been consulted? | Many points of software development intersect with multiple teams at the Wikimedia Foundation. Clear, consistent internal communication is as important as external to ensure no one is caught unaware. | |
| Timeline and Documentation | ||
| 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. | A chapter has an edit-a-thon scheduled, and there is a planned outage around that time for whatever reason. The chapter would like to know ahead of time. |
| Are you documenting this? If yes, is it published publicly? | See above. | |
| Have you defined a glossary introducing the new terms? | Glossaries help native-language speakers understand new terms, and helps translators to introduce new terms into their language communities as well. | |
| Background Research | ||
| Will this replace an existing tool? | Replacing an existing tool is a dramatic shift for people, and takes more work to get used to. | The appearance and curating of content for many "major" wikis is 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? | The extent to which workflows break is important in the amount of communication necessary for a change. | See above. |
| Will it add to editors' workload if it's a success? | The extent to which workloads are increased is important in the amount of communication necessary for a change. | Since the wikis operate under transparency and openness, new tools can easily add to the maintenance and governance of the sites. |
| Has this been tried before, internally (staff or community)? | Previous efforts, if they exist, presumably inform current plans. It's good to know what lessons have been learned. | Lessons learned, and presented, from previous development demonstrates both diligence and the necessity of new work to communities. |
| Does this already exist in the outside world? | See above. | |
| Are there industry standards around this? | People might have preconceived notions of expected software behavior from other sites. We also try to avoid xkcd 927. | People are likely to compare and contrast their experience from other parts of the internet, in an effort to inform and/or improve. |
| Analytics | ||
| What can be measured? | People want to know what is informing the decision-making process. | Contributors may be able to suggest additional or alternative metrics. |
| For how long will things be measured? | Fixed, or at least rough, timeframes for measurements help keep community and WMF teams on track. | |
| What will be done with this data? | See above. | |
| Technical Resources | ||
| What are the allocated maintenance resources? For how long? | Ownership of products post-release gives people a place to go with bug requests, features, and enhancements. They need to have an idea of what kind of support they can expect for this. | If a software may be unsupported after a known amount of time, with appropriate notice accommodations can be made to work around the lack of support. |
| What are the boundaries of tech support for edge-cases? | People want to know how far support can go for individual problems. | Many regular contributors have customized their experience through Javascript and CSS. Software changes can effect a number of individuals in very different ways. |
| 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 to millions of users. Expect the unexpected. | |
| Define the product's individual definition of alpha/beta/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 the state of its iteration is clear. |