Page MenuHomePhabricator

Gadgets enabled by default should be held to a higher level of quality
Closed, DuplicatePublic


Gadgets are great for experimentation and innovation but occasionally are enabled by default¹ on a given wiki (and can also be imported to other wikis, by default, without any tracking - T35355). When this happens we must ensure the code quality is kept to the highest possible coding standard. As a member of the developer community it is very unclear what gadgets are enabled by default and on what projects and how they might effect me and where the code lives and what the code looks like.

How to do this is unclear (what tools/processes are needed), but ideally the process of enabling a gadget by default should

  1. Delay enabling a gadgets by default to give time for feedback
  2. Allow members of the developer community to review these kind of gadgets beforehand to flag things like xss problems.
  3. Provide greater transparency of which gadgets are enabled where and when


See also



Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 22 2014, 2:21 AM
bzimport set Reference to bz58462.
bzimport added a subscriber: Unknown Object (MLST).

(In reply to comment #0)

Gadgets are great for experimentation and innovation but occasionally gain
status of global.

The present tense of this sentence looks inappropriate: there is no such a thing as global gadgets yet. Is there any reason to think that global gadgets wouldn't automatically be at a higher quality thanks to centralisation?

Whatever the semantics:
Gadgets can currently be turned on by default for all users. Whether that translates as global gadgets or something else feel free to clarify. Hopefully it is clear what I mean from the conversation linked to.

Besides the issue of global gadgets not being a thing, this seems like a social problem not a technical problem. Discussion on say meta (or mailing lists) seems like a more appropriate venue, and if the conclusion reached requires development effort, then file a bug about whatever needs to be implemented.

Ah, thanks for the clarification. (1) is called talk page, (2) doesn't currently have any assigned resources to perform such code review on community request and (3) is two feature requests which are a) probably impossible for MediaWiki:.+js pages and b) quite hard for the Gadgets extension which is (still) only local and both not yet filed as separate bugs even. Adjusting priority accordingly.

[[Special:Gadgets]] on every project will tell you what scripts and CSS every gadget uses and whether they are enabled by default. If you want to automate it, there's also an API module -|desc|metadata&format=jsonfm

I think this bug is a putting the cart before the horse. If the WMF wants to start requiring formal review of local code, there should be a wider discussion of that beyond wikitech-l and Bugzilla isn't really the place for that either (meta would be best, or a ML with a more diverse audience). And there should be some sort of formalized policy before we decide how to implement it, unless the WMF is just going to unilaterally impose their preferred solution regardless of what the projects say.

Not a while ago I have created a a page on meta for global overview of gadgets:

We can use the list on
as priority list for review.

It would be great if you could create guidelines (it doesn't have to be "formal" policy), under [[meta:Gadgets/guidelines]] and write some important points, or "checklist". Such guidelines would at least allow the gadget developers themselves (and to the admins that enable them) to be aware to common pitfalls and security issuses (such as XSS).

I'm almost sure that Ricordisamoa has been shocked by my js code, running into it.wikisource, and that he has been inspider by it. Yes, some of my gadgets (written into an horrible js slang and far from being "at highest possible coding standard") turned out, after some personal use, useful for basic users and gained the status of "default gadgets".

I tried to enhance my coding standard, but I failed; my gadgets come out from a heavy editing work, and it's almost impossible to find needed time to edit hard, to write needed js code, and to study the best of js coding style; so I've been a little bit discouraged, and I stopped my caotic js production. But I feel the need to have a very simple place (both Github and Phabricator aren't!) to share rough ideas and rough running js code, so that experienced fellows could translate them into good scripts, if they like.

@Alex_brollo, since you mentioned both phabricator and github not being
sufficient, can you describe the process or system that you would like?

I think we will go to a code review system, but it sounds like you're
looking for a way to quickly try out and prototype js with other users.
Which I think would come as a step before the final patch is sent to code
review and merged.

I'd like a wiki approach, t.i. something like a "stub page" into a central wiki project (mediawiki) where to post the running code, even if far from "professional", coupled with a comment about its aim and its use. Just as experienced wiki users browse stubs I'd like that good programmers would browse such "stubs", and go ahead if they like them; what is to be avoided is to ignore them, or to post a suggestion "please post your project into Github.... but first read this and this and this....[follows some tons od exoteric documentation about best programming style]". This is a good strategy, if the real aim is to discourage most users from producing code, at their best, when their programming skill is poor.

While I'm amazed by @Alex_brollo's leadership on the Italian Wikisource and his willingness to experiment with new editing patterns, I believe the community as a whole would strongly benefit from tougher evaluation of its tools together with WMF devs.

PS: to me, coding conventions e.g. spaces between parentheses are irrelevant.
What I feel is a lack of medium-term planning to develop robust, broad-range solutions.

There is some movement at T31272#2877122, it seems. (Sorry for wrong target in the first merge.)

At best, this task is blocked by T31272: Implement Gadgets 2.0, but I don't think it's appropriate to merge it. If T31272 got declined, this would still be a valid task…