Talk:Strategy/Wikimedia movement/2018-20/Working Groups/Product & Technology/Recommendations/1
- 1 Wikidata
- 2 What is external entities ?
- 3 On Q 4-2 What could be done to mitigate this risk?
- 4 On Q 2-1 What assumptions are you making about the future context that led you to make this Recommendation?
- 5 I think
- 6 Thoughts on decentralization
- 7 Shared goals and shared responsibilities
- 8 From Catalan Salon
Hi, nice recommendation. Wikimedia Deutschland has a major software development department which developed and launched Wikidata six years ago. In your piece Wikidata is nowhere mentioned. In general I favor decentralization. Do you envision more affiliates setting up software development department? Wikipedia comes in 300 language editions with 300 communities. Will all these Wikipedias use the samen Mediawiki contentmanagementsoftware, or do you envision that each separate language version of Wikipedia will be hosted on a different version of Mediawiki? With communities in the lead to command and instruct software development, how will they coordinate their decision among the 300 language versions? Ad Huikeshoven (talk) 08:53, 10 August 2019 (UTC)
What is external entities ?
Before reading the above comment is that external entities might be things like Wikimedia Deutshland, with stay inside the wikimedia movement with basiacally same values and assumptions than WMF, wikipedia, wikitonary, ... (non profit, knowledge targeted) whihc is perfectly ok. My first idea was that the idea was that to build some kind of development for profit startup for mediawiki, which in my opinion will end to have direct conflict with WMF goals, and as significantly more powerful will end to destroy the whole wikimedia movement as we know it. So maybe some precision on the meaning of external entities should be done to everybody that it is Wikimedia Deutshland who is called an external entity in mind.
And just a stupid point from my mind, when I read the only point decentralized, my only thought is that it was about the distributed software hype , bittorrent, bitcoin (which I disagree mainly for wikimedia technical needs uses) , and clearly it is neither the point of the recommendation or even the whole purpose of working group. some something like "distribued development process" in the title of the recommendation, or "Product & Technology development process" in the working group would be useful to make clear that the idea is not to make technical decision in the behave of the crowd as such technical decision should be done in my opinion by expert such as developers or similar. Xavier Combelle (talk) 07:20, 11 August 2019 (UTC)
On Q 4-2 What could be done to mitigate this risk?
I think this could be called Product lifecycle management. If funding of a feature doesn't exceed conceiving, designing, and realizing, into servicing, and possibly even eventual;y sun setting or replacing of the feature, maintenance will always become a problem. Require the maintenance phase to be funded with the project for a set time, because if you don't, your problem will be certain. Siebrand (talk) 21:08, 11 August 2019 (UTC)
On Q 2-1 What assumptions are you making about the future context that led you to make this Recommendation?
For my is necessary the decentralize the data and source code. But this it's make here [ https://en.wikipedia.org/wiki/Kiwix ] only necessary for my and next step it's a federation. --1984 free (talk) 10:03, 14 August 2019 (UTC)
Thoughts on decentralization
The recommendation, as I understand it, is about decentralizing the software development (which is currently mainly done by WMF).
This is a good proposal, which goes in a similar direction as the recommendations of the Roles & Responsibilities working group. However, it does not seem to go far enough in my opinion.
While it explicitly mentions infrastructure, this recommendation seems in practice to mainly concern product development. Together with Deployment Council & Product governance, these recommendations seem to keep the WMF as the gatekeeper of which software runs where. I don’t think this is good (it’s still heavily centralized), nor viable: in a future where there are many many units developing software, then the WMF could become the bottleneck for that software to be deployed.
Of course, running a top-5 website needs a certain know-how and skill sets that will not necessarily be present in all the decentralized units, nor can it be improvised there. However, I believe enabling it is the direction we should be aiming for.
To be concrete, if we have an independent team “owning” the development of Wikisource, then I believe that team should at some point have full latitude to deploy the improvements they’re making to Wikisource. If there are technical issues preventing that vision to come true − lack of isolation (so that a bad change in the Wikisource part can take down Wikipedia), lack of confidence (test, roll-back), not-granular-enough access levels, etc. etc. − then there should be a political commitment to lift them eventually ; as well as to build the requiredcapacity in each unit.
While I totally understand why decentralizing product development would be appealing to the movement, I think I’d be interested in understanding what the benefits of this idea are (specifically what problem are we trying to solve). My experience is that major architectural issues (MediaWiki & platform upgrades) and product features (mobile contributions/structured data on commons/apps) were not addressed until the Foundation made them a focus. To be clear, I’m not anti-decentralization but I’m seriously concerned about the movement’s ability to respond to changes in the internet and take our mission to new generations and geographies. The movement needs to be able to make the big decisions and then do the difficult technical and design work needed to carry it out successfully.
There are a couple of projects which have been helpful in understanding how decentralization could be structured. The Foundation funds Wikidata development in Wikimedia Deutschland and the two organizations have recently signed a multi-year collaboration agreement that provides a useful framing to these kinds of relationships. The Foundation also funds Kiwix development directly via a yearly grant. These relationships have been challenging and positive and I think we've all learned a lot from them about how to work together.
I've found there are three principles that are helpful in thinking about decentralization:
- The relationship must be accretive in the sense that the organizations working together must be able to accomplish more than a simple assigning of development tasks or transfer of funds. Product focus, particular areas of expertise or context or access to resources such as grants that cannot be accessed by the WMF are all examples of win-wins. The Wikidata relationship is a clear example of how this works. The language from the WMDE grant “shared goals, shared responsibilities” has resonated with both organizations. The relationship with Kiwix occupies a similar gap in the products -- after some analysis in the New Readers program, the Foundation decided that the needs of offline users would be better met by the community and Kiwix has significant experience and expertise in offline Wikipedia.
- There is a difference between demonstrating competence in product development and aspiring to it. Just as the Foundation’s product development efforts have benefitted from significant investment and maturation in the past several years, we need to not only share funding but also the lessons learned during this process. Things are very different now than when the projects were started and design, product management, data analytics and functions of that nature are critical to successful internet products and the WMF must continue to foster the level of understanding present in community projects.
- The foundation has been very involved in working with Kiwix to help develop a multi-year strategy and manage engineering resources during the grant and I see this as being critical to the success of these initiatives. The Foundation should be a central part of helping organizations manage these types of projects operationally and from a capability building perspective.
For me, these are the pillars of a successful decentralization strategy and I’d like to see the governance aspirations and structures and designed with these in mind. —The preceding unsigned comment was added by TNegrin (WMF) (talk) 23:31, 2 September 2019