Statement:32: Difference between revisions
No edit summary |
m (Text replacement - "â" to "") |
||
Line 36: | Line 36: | ||
* raise priority for implementing a code review process for JS/CSS pages on Wikimedia sites | * raise priority for implementing a code review process for JS/CSS pages on Wikimedia sites | ||
* start thinking about a technical sysop user right | * start thinking about a technical sysop user right | ||
* make it clear which user scripts/gadgets/tools are maintained, which are stable and which are proofs of concept or prototypes (for example: provide a (central) 'store' of maintained gadgets/tools with different levels: "stable version", "experimental version" | * make it clear which user scripts/gadgets/tools are maintained, which are stable and which are proofs of concept or prototypes (for example: provide a (central) 'store' of maintained gadgets/tools with different levels: "stable version", "experimental version" ¦) | ||
Let's start refactoring. | Let's start refactoring. | ||
}} | }} |
Revision as of 18:44, 13 November 2017
Tags | |
---|---|
Primary Session | |
Secondary Sessions |
Refactoring the Open: First steps to get ready for the next level
Wikimedia's technical environment has grown into a very complex system throughout the past 15 years. Measured in internet years, parts of the software are ancient. When implementing a new feature, refactoring of a piece of the (extended) MediaWiki software is often required first. Following this principle of a.) refactoring and b.) implementation of something new, I suggest to start the discussion of the future technology direction by reflecting (and possibly: refactoring) the current Open Source practices and processes within the Wikimedia context.
A mono perspective won't let us survive (and is less fun, too)
When we talk about "Open Source" within Wikimedia we're not only talking about free licenses and open code repositories. We're talking about global collaboration and the technical contributions of many: Through this, we ensure that the Wikimedia projects stay alive and evolve, that we constantly develop new ideas, that multiple and diverse perspectives shape the development of our infrastructure and tools.
We are great in having ideas, and we are good in trying things out. But we still partly fail at prioritising the problems we know we have and address them accordingly.
I believe that we should
better maintain the Technical Community and find ways to grow by
- allocating stable code review resources from paid staff for volunteer and 3rd party developers
- improving the documentation of the code base
- providing a single entry point that is easy accessible for interested developers
- building up partnerships with Open Source communities we might share interests in the future with (for example, communities around audio, video or translation technologies)
constantly take diverse perspectives into account by
- finding better ways to gather and address feedback from smaller language communities and non-Wikipedia sites
- being less Wikipedia-centric when it comes to research: Not yet existing or emerging communities might not be interested in creating articles, but in contributing data or multimedia content or in building tools to reuse data and multimedia content
build more bridges across local wikis and increase knowledge of local requirements by
- fostering cross-wiki exchange (example activity: template Hackathon)
- increasing the knowledge of the requirements that come along with different languages (example activity: multilingual support conference)
Open Source doesn't mean anything is possible - does it?
We have established processes and regulations for contributions to MediaWiki itself. But we lack processes and practices for local developments to ensure both, the freedom and space to experiment for the Technical Community and the stability and reliability of tools for users.
I believe that we should e.g.
- raise priority for implementing a code review process for JS/CSS pages on Wikimedia sites
- start thinking about a technical sysop user right
- make it clear which user scripts/gadgets/tools are maintained, which are stable and which are proofs of concept or prototypes (for example: provide a (central) 'store' of maintained gadgets/tools with different levels: "stable version", "experimental version" ¦)
Let's start refactoring.