Technical Collaboration Guidance/Principles
 | 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. |
Principles
[edit]The Wikimedia Foundation designs and develops software for the end user in furtherance of its mission to empower and engage people around the world to collect and develop educational content under a free license or in the public domain, and to disseminate it effectively and globally.[1] When designing and developing software, the Wikimedia Foundation takes care to consider the following software development principles, that our content, software, practices and/or products should always:
- Free[2] and available - Be freely licensed and readily available for all people.
- Informed and insightful - Have a deep understanding of user needs and experiences. Decisions should be informed by data and research.
- Transparent and responsible - Development of a product should be in the open, with public feedback loops whenever possible. Decisions should be fully accounted for, and should be clearly explained and well-documented.
- Collaborative and iterative - Be developed together. Staff and volunteers should be receptive to feedback, feature requests, and bug reports throughout the lifecycle of a product.
- Accessible and secure - Provide a consistent, usable experience for all populations, regardless of technical limitations or physical disability. Software and its development should maintain user privacy and site security.
This list is not exhaustive.
Private Planning
[edit]Transparency is an important value and principle in the Wikimedia movement, including software development. Transparency fosters collaboration and discussion, distributing responsibility for success to all of those working on a particular project. With this in mind, the stages of the product development process must be as transparent as possible in order to facilitate the process itself.
Writing in public places
[edit]There is nothing wrong with private discussions about ideas. Privacy is often important when an idea is at its infancy, so that the thought can be developed and presented with minimal distraction. It can be beneficial at this stage that, if things are being written down, they begin to be shared in a public venue. In this sense, documentation can mean tentative plans, meeting agendas and notes, or early technical specifications.
Shifting or beginning work in a public space at this point allows for the opportunity for collaboration with volunteer developers and community members. These stakeholders likely have a definition of the problem and institutional memory of past attempts at resolution, and can make the product development process work much more smoothly from the start. To make things even easier, strive to document everything you do not understand yet, as well as what you do understand, and to put forward for discussion any potential negatives and drawbacks as early as possible.
In short
[edit]Loosely speaking, once a product is being more than just discussed casually, it's time to start writing things down on a wiki. Documentation will inform others, which will enable people to collaborate on the project.