Talk:Strategy/Wikimedia movement/2018-20/Recommendations/Iteration 1/Product & Technology/6

The following discussion is closed. Please do not modify it.

Most likely, new comments will not be taken into account by the new three Working Group members in their work of developing the final Recommendations. You are free however to continue discussing in the spirit of "discussing about Wikipedia is a work in progress". :)

Comments

The recommendations are totally vague whilst the outcome sounds like recommendations. LOL. But, the topic is very very important. Winged Blades of Godric (talk) 13:19, 11 August 2019 (UTC)

Technical side of volunteer attraction & retention

Hi,

This recommendation, as I understand it, is about improving the attraction & retention of new (volunteer) developers ; and to do so, by improving the social mechanisms.

This is good, but I’m missing some things: what would they be developing, and how, ie using which platforms (both execution environment regarding the platforms on which these new developers will be working.

For the what: There are various regions of the Wikimedia technical ecosystem that developers (mostly volunteers but other too) can be involved with − while it’s dated I still often refer to the 'taxonomy' made by Erik for this 2014 FOSDEM talk (I’m sure there must be something more current somewhere :-) ; there are currently roughly: server-side scripting, client-side scripting, autonomous editing programs (bots), desktop and web applications (and of course MediaWiki coding, via extensions and Skins). Is that it? Can we think of other ways for people to be involved?

As for how: the movement provides execution platforms (not sure it is the right word) for these: server-side scripting via templates (both ParserFunctions and Lua based) ; client-side scripting via JS-based user-scripts and gadgets. Bots and web-apps have a home on Cloud VPS and Toolforge.

Are these existing platforms good enough to be “the essential infrastructure of the ecosystem of free knowledge” and enabling Knowledge as a Service? And related and more on-point, how do they need to evolve (or with what do they need to be replaced/supplemented) to attract and retain new developers? For example, would a 2020 front-end developer used to developing on other platforms feel “at home” writing gadgets, is she able to use paradigms or libraries in wide use elsewhere?

The platforms provided as part of Cloud Services in particular need a clear strategy. Let me first say how amazed (and proud) of the resources made available to volunteers developers via Cloud Services − I don’t think it’s everywhere that you can get something like that (by comparison, speaking as hobbyist OSM mapper, it seems that the OSM web-tools I use do not have such a central home available). In particular, I love how these services are imbued with values: shared ownership on toolforge, mandatory FLOSS, strong privacy commitment… At the same time, I don’t think it’d be unfair to feel that these platforms do not provide some services one could reasonably expect in 2019 (to list a couple of personal favourites: centralized logging, instrumentation, and monitoring in general). Would a developer recently attracted to the movement and used to run her stuff on AWS or Heroku would be happy on Tooforge? I know some experienced Wikimedia developers who avoid running their stuff on Toolforge/Cloud VPS because they just don’t want to bother. While I think it’s sad, I certainly understand their point.

I won’t talk much about MediaWiki extensions and skins, as I don’t know much about them (my last experience a couple of months ago was trying to write unit tests for an extension − I gave up hours later trying to figure out the test running system ^_^') ; as I understand it, getting an extension deployed to the Wikimedia cluster is an extremely long and painful process.

The movement also provides some support infrastructure for the development life-cycle: issue tracking, code-hosting, code-review, build & testing, deployment. Yet, many volunteer developers avoid Gerrit, Phabricator or Jenkins and rather host their code on commercial platforms like GitHub or Bitbucket, running tests with Travis-CI, etc. And that is mostly for web-applications: the life-cycle for client scripting is still very barebones (no central gadgets, no code-review process, no way to write or run tests).

I don’t mean this as a rant ; and nothing I write here is particularly new: the shortcomings of our platforms have been identified by others before, in particular by the folks who tirelessly work to run and improve them. I’m sure some of the issues I took as example are being worked on, and might even be close to solved (eg I understand we will soon be able to deploy tools on Cloud Services using containers, which is great).

The point I’m trying to make is that in my opinion there is little sense in perfecting the social components of our developer acquisition pipeline, if the technical components do not follow. I mentioned leading platform like AWS above, and some might say that it’d be unfair to compare the resources of Wikimedia with those of Amazon ; of course, but then again, as we have the ambitious goal to be the essential infrastructure to free knowledge, we need an equally ambitious strategy for the platforms underpinning that infrastructure.

Hope that helps, Jean-Fred (talk) 21:29, 31 August 2019 (UTC)

I agree with Jean-Fred here -- An excellent opportunity for community involvement is the many tools and bots that are run out of Toolforge. Many of these projects are not well supported and this code is much simpler and less critical to the sites overall operations and look and feel. Directing community development resources to this area would be a substantial contribution to the movement in an area where the Foundation currently struggles to find funding and operational models that are effective. The movement is large and sprawling and we need better models to support critical tools and processes that aren’t part of the core readers and editor experiences.TNegrin (WMF) (talk) 01:18, 3 September 2019 (UTC)

Thanks, Jean-Fred, that's a very insightful comment and we ended up adopting several of your points in the next version of the recommendation. --Tgr (talk) 12:33, 8 September 2019 (UTC)