Deployment Council

There has not been consensus regarding this recommendation but we would like to discuss it with the rest of the WGs

Q 1 What is your Recommendation?

Make governance of the software used in Wikimedia projects more inclusive, participatory and predictable by setting up a “Deployment Council” for setting the requirements for deploying new functionality to the wikis, in the form of a co-decision-making process between the organization building the feature and the editor community.

Q 2-1 What assumptions are you making about the future context that led you to make this Recommendation?

This recommendation aims at unifying the view of what are required and acceptable features between the product and engineering people in various movement bodies with some of the stakeholders such as content contributors. We hope that establishing a trusted council with a mandate would help the cause of a unified view.

Q 2-2 What is your thinking and logic behind this recommendation?

Becoming the essential infrastructure of free knowledge will no doubt mean significant changes to the software the wiki communities interact with, and currently deploying major changes is often controversial and stressful, as there is no formal system for editors to set requirements, so they are left to oppose changes they disagree with by informal means; and with no dedicated process, they default to processes used on wikis (like requests for comment) which tend to be poorly suited for the task. While the situation is not completely unmanageable, it does limit the pace of deployment.

To fix this situation, and a new group with a community-given mandate is needed to provide the continuity (product owner organizations need to be secure that basic planning choices won’t be rehashed after millions of donor dollars have already been invested) and high quality of decisions.

Q 3-1 What will change because of the Recommendation?

The late stage of the product development process will become smoother (being based on the consensus of more stakeholders).

Q 3-2 Who specifically will be influenced by this recommendation?

Movement entities doing major product development work (such as the WMF and WMDE; if the recommendation on Decentralization is followed, significantly more in the future), wiki editor communities who are most affected by new products.

Q 4-1 Could this Recommendation have a negative impact/change?

Yes, If implemented wrongly, will lead to more frustration from the communities than today, or low-quality decisions.

If a good process isn’t determined the deployment council could potentially slow down deployment by slower decision making. An overly risk-averse council might hold back new features due to small problems within them even though the existing problems they solve might be far bigger.

Q 4-2 What could be done to mitigate this risk?

Involve the communities in the change process; ensure participants are well-informed.

Determining a good process for the council will be crucial for mitigating this risk. A focus on creating and acting on policies with a clear mandate will be important for mitigation.

Q 5 How does this Recommendation relate to the current structural reality?

It adds a new structure around product decision making.

Q 6-1 Does this Recommendation connect or depend on another of your Recommendations? If yes, how?

It is complemented by the Open Product Proposal Process recommendation which deals with the other half of the development process.

Good decision making requires constructive and respectful but frank discussions with well-informed participants, thus this recommendation relies on Support Community Decisionmaking and Disseminate Product Knowledge.

Q 6-2 Does this Recommendation connect or relate to your Scoping Questions? If yes, how?

It answers the scoping question “Which are the structures and processes to assure the required level of inclusion in decision making and planning of the community at large in their full diversity?”

Q 7 How is this Recommendation connected to other WGs?

It suggests changing movement-wide decision-making processes, which is also in the territory of Roles and Responsibilities.

v t e Movement Strategy Working Group recommendations (September 2019) Now merged into the final 10 recommendations
Advocacy	1. Transparency 2. Diversity 3. Global conversation 4. Knowledge management 5. Advocacy Hub 6. Common positioning 7. Partnerships 8. Empowerment of advocates 9. Self-Determination 10. Protection of Advocates
Capacity Building	1. Building Capacity for Capacity Building 2. Matching human assets and online knowledge resources with capacity building needs 3. Capacity Building Should Occur in Context 4. Provide Capacity Building for Organizational Development 5. Resources for Capacity Building 6. Evaluating Capacity Building 7. Online Training 8. Mentoring and leadership development 9. Recognizing Individuals 10. Independently governed Capacity Building ‘Unit’
Community Health	1. A joint set of rules we all agree to live by (a.k.a. Code of Conduct) 2. Redefining power structures to better serve the communities 3. Building the leadership of the future 4. Structure for handling conflicts- before, during and after 5. Investing in building an inclusive global community 6. Newcomers are a key indicator to the success of the movement 7. “Democratizing” participation (making Wikipedia/Wikimedia everyone’s responsibility) and reducing barriers for participation 8. Privacy and security for everyone 9. Opening the circle: All terrain readiness 10. Network to continually support community health 11. Aligning resource allocation with community health goals 12. Investing in equity-centered technologies
Diversity	1. Introducing people-centered principles within the Wikimedia movement 2. Reaching a self-aware and dynamic structure aimed at community diversity and health 3. Redesigning the platforms for more diversity of people and content experiences 4. Planned community diversification 5. Reflective policies for participation and governance 6. Establishing partnerships in order to represent and protect worlds’ cultural diversity 7. Decentralized administrative structure for resource allocation 8. Bridging different local contexts and Wikimedia projects' notability and verifiability policies
Partnerships	1. Provide the knowledge needed for understanding and solving global issues 2. Wikimedia as steward of the Free Knowledge Ecosystem 3. Shared ecosystem of services and tools for content partnerships 4. Data partnerships approach to fulfill the vision of knowledge as a service for our partners 5. Focus on knowledge equity when determining priorities for Partnerships 6. Partnerships as part of a Distributed Vision 7. Partnerships as a shared and equitable resource and activity 8. Prioritise documentation 9. Invest in sharing knowledge about partnerships across the movement 10. Support the skills development of people working on partnerships 11. Invest in the leadership potential of community members 12. Establish recognition principles for new partners for attribution and content donation 13. Additional research for areas where we have identified issues but haven’t made recommendations
Product & Technology	1. Evaluate and Decentralize Technology Components 2. Support Community Decision-making 3. Open Product Proposal Process 4. Deployment Council 5. Disseminate Product Knowledge 6A. Improve Technical Contributor Engagement 6B. Modernize Technical Contributor Tooling 7. Realize the Potential of the Third-Party Ecosystem 8. Movement Technology Ethics Review Process 9. Monitoring Product Trust and Availability 10. Developing an Evolving Technology Vision and Strategy
Resource Allocation	A. Set Common Framework of Principles for Resource Allocation B. Design participatory decision making for Resource Allocation C. Recognize privileges / Design for equity D. Distribute existing structures E. Build Thematic hubs – to provide services to the free knowledge movement long term F. Ensure flexible approach to resource allocation in a complex, fast moving and changeable space G. Allocate resources for capacity and sustainability H. Allocate resources to new types of partners/organisations (essential infrastructure of the free knowledge ecosystem) I. Include knowledge consumers
Revenue Streams	1. Turn the Wikimedia API into a revenue source 2. Provide Paid Wiki-related Services 3. Monetize merchandise 4. Expand global fundraising 5. Develop non-fundraising revenue streams for affiliates 6. Set a goal of financial sustainability for all movement actors 7. Diversification of revenue channels
Roles & Responsibilities	0. Scenario 1. All of this exists to support our primary purpose: free knowledge and its distribution (Original) 2&3. Decentralisation and self-management 4&5. Establish a Movement Charter 6. Wikimedia movement organisations will be governed by inclusive, diverse, and accountable boards 7. Capacity building