Page MenuHomePhabricator

Wikimedia Technical Conference 2019 Session: Developing in Mediawiki without breaking Gadgets
Open, Needs TriagePublic

Description

Session

  • Track: Standardization Decisions
  • Topic: Developing in Mediawiki without breaking Gadgets

Description

Gadgets are the essential part of working on wikis, especially for experienced and active users. When creating new features Product Managers often formulate a quite reasonable requirement to developers that no gadgets should be broken when the new things is being shipped.
While there is no other interface that gadgets rely on than HTML/DOM structure of the page, such requirement makes introducing new functionality and doing any user-facing changes quite challenging. Taken to the extreme not wanting to break gadgets would mean that nothing can be changed.
Lack of defined interface gadgets use, and also not knowing, nor being able to predict what gadgets could be affected by changes results in bug reports from gadget authors. Apart from social impact, this also extends the length of the development and release cycle of new software, hence negatively affects developer productivity. It also stops innovation, or significantly limits it.

In the lack of well-defined gadget interface, knowing what gadgets cannot be broken would allow, to certain degree, to reverse-define what parts of page structure should be kept in what form to allow these gadgets to continue working.

In this workshop-style session we'll share our experiences of successes and failures in the development of software in MediaWiki environment and how it worked with existing gadgets. What helped and what we find particularly problematic? Have we identified which gadgets to particularly look after? Are there any other ideas and practices that others could adapt in their work? Is introducing a dedicated API for gadgets the only ultimate solution? Would it be useful to create some sort of inventory of gadgets (not necessarily names/URLs of the most used/important user scripts, but possibly an inventory of functionalities and workflows that editors use gadgets for)? If so, could we leverage the know-how in the room to make a start?

Questions to answer and discuss

Question:
Significance:

Question:
Significance:

Related Issues

  • ...
  • ...

Pre-reading for all Participants

  • [add links here]

Notes document(s)

[link to notes document (gdoc and / or etherpad)]

Notes and Facilitation guidance

https://www.mediawiki.org/wiki/Wikimedia_Technical_Conference/2019/NotesandFacilitation


Session Leader(s)

Session Scribes

  • [name]
  • [name]

Session Facilitator

  • [name]

Session Style / Format

  • [what type of format will this session be?]

Session Leaders please:

  • Add more details to this task description.
  • Coordinate any pre-event discussions (here on Phab, IRC, email, hangout, etc).
  • Outline the plan for discussing this topic at the event.
  • Optionally, include what this session will not try to solve.
  • Update this task with summaries of any pre-event discussions.
  • Include ways for people not attending to be involved in discussions before the event and afterwards.

Post-event summary:

  • ...

Post-event action items:

  • ...

Event Timeline

WMDE-leszek removed kaldari as the assignee of this task.Tue, Oct 8, 4:31 PM
WMDE-leszek created this task.
Amire80 added a subscriber: Amire80.Tue, Oct 8, 6:30 PM

I stopped counting the number of times I ran into problems of this kind as the product manager for Content Translation and Compact Language Links. I fixed them in Indonesian, Russian, English, Georgian, Portuguese, and lots of other wikis.

The obvious solution is to make Gadgets properly global and robustly translatable, like extensions. This way they will be visible everywhere, and developers will be able to test them in any wiki that is comfortable for them, without being repeatedly surprised by unfamiliar gadgets in wikis in languages they don't know (and I refer not just to English-speaking developers).

Superficially, there are a lot of similarities between making gadgets global and making templates and modules global. Implementing the solution, however, will be quite different. So it's good to split the discussion about it from T234661, if time allows.

@WMDE-leszek - This seems like a good session idea. Can you format it to match the other session proposals and put yourself as the session leader if you're interested in leading it?

WMDE-leszek updated the task description. (Show Details)Wed, Oct 9, 10:02 PM
debt added a comment.Wed, Oct 9, 10:45 PM

@WMDE-leszek - This seems like a good session idea. Can you format it to match the other session proposals and put yourself as the session leader if you're interested in leading it?

Thanks for updating the format, @WMDE-leszek -- I hadn't gotten around to doing it (sigh). :)

Tpt awarded a token.Thu, Oct 10, 9:17 AM
Tpt added a subscriber: Tpt.
Addshore added a subscriber: Addshore.

@WMDE-leszek - Don't forget to add yourself as the Session Leader above (or ping anyone you think might want to lead this).

WMDE-leszek updated the task description. (Show Details)Fri, Oct 11, 2:02 PM
kaldari renamed this task from Session proposal: Developing in Mediawiki without breaking Gadgets to Wikimedia Technical Conference 2019 Session: Developing in Mediawiki without breaking Gadgets.Fri, Oct 11, 2:30 PM

Hey all, please have a look at T234661#5567256 - a proposal how this session here could become a part of Developer Productivity and onwiki tooling (T234661).

Tgr added a subscriber: Tgr.Sun, Oct 13, 9:31 PM

Would it be useful to create some sort of inventory of gadgets (not necessarily names/URLs of the most used/important user scripts, but possibly an inventory of functionalities and workflows that editors use gadgets for)?

Very useful, and not primarily for interaction with MediaWiki changes (although that's useful as well). The increased discoverability of gadgets used by other communities would be a huge boon in itself.

Is introducing a dedicated API for gadgets the only ultimate solution?

An API that can be put between the DOM and some kind of sandbox would be super interesting from a security perspective as well. It would both decrease risk and allow users other than the most trusted ones to contribute code.

Would it be useful to create some sort of inventory of gadgets (not necessarily names/URLs of the most used/important user scripts, but possibly an inventory of functionalities and workflows that editors use gadgets for)?

Very useful, and not primarily for interaction with MediaWiki changes (although that's useful as well). The increased discoverability of gadgets used by other communities would be a huge boon in itself.

Strongly agreed.
Note we do already have the former type of inventory at https://meta.wikimedia.org/wiki/Gadgets (see the 16 subpages) albeit they are incomplete project-wise (not listing metawiki, wikidata, commons, etc). Those pages are kept auto-updated by @eranroz's bot (thank you!).
But it would be wonderful to also have the latter type of inventory, so that [developers/PMs/other wiki communities/etc] can easily learn more about each of them.
A small handful of the gadgets have simple documentation on metawiki (in links from that former-type inventory, e.g. at https://meta.wikimedia.org/wiki/Special:PrefixIndex?prefix=Gadgets%2F&namespace=0 ) but expanding it to include more than a screenshot and 1-sentence, and possibly reorganizing how it is stored & displayed, would be great.