Critical issues presentations/Analyzing conflict and possible solutions around WMF software development
- Submission no. 101
- Title of the submission
Analyzing conflict and possible solutions around WMF software development
- Author of the submission
- Quim Gil
- Country of origin
Germany; United States of America
- software development
- Wikimedia Foundation
Developing software products and features is one of the main activities of the Wikimedia Foundation. Making users happy is hard, but it should not be as hard as it seems in Wikimedia. What could be a productive an exciting partnership between the WMF and the communities turns too often into tension, misunderstanding, and frustration. Why is that, and how can we build an environment of productivity and trust?
In this session we will look at the WMF product development process. We will identify known points of tension and their underlying causes, trying to understand and explain why they keep becoming a problem. Finally, we will look at possible implementable solutions, identifying the social and technical challenges that need to be overcome.
Several teams at the Wikimedia Foundation are collaborating defining a product development process that Wikimedia communities and technical contributors can co-design, watch, and join. This is a good opportunity to share a common view of how software products and features should be conceptualized, planned, designed, build, deployed, and maintained. A common view that users, editors, and other non-technical contributors should be able to understand, and should be able to follow and get involved according to their interests and skills.
The definition of a product development process is also a good opportunity to analyze recurrent problems in their context, and to find solutions that are not only consistent with the Wikimedia values, but also implementable, efficient, and even just as interesting and fun like other Wikimedia activities.
- How could new concepts be communicated sooner and better, in a productive environment welcoming experimentation and fresh ideas?
- How could developer teams ask for feedback during earlier stages of development, receiving feedback from a wide range of users and skills?
- How could our communities watch the progress of new projects since their inception, knowing when to provide feedback and how?
- How could our communities define their interest or their reticence toward specific new features in a simple and constructive way, deciding when and how such features would be deployed in their projects?
While there is no way to find solutions to all problems in one conference session, we believe that 18 minutes should be enough to provide a clear picture of the problems and suggest potential solutions that can spark further discussions during the event and beyond.