https://bugzilla.wikimedia.org/show_bug.cgi?id=69445

Jon <jrob...@wikimedia.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jrob...@wikimedia.org

--- Comment #12 from Jon <jrob...@wikimedia.org> ---
I don't think MediaWiki should invent its own code review software. I
completely agree with every Gilles Dubuc and C. Scott said above.

Code review software is /hard/ to build and for us to build it would 1) be a
waste of resources and 2) be suboptimal.


That aside, The existing MediaWiki:Common.js is a serious hack and huge
security hole that I can't believe has not been exploited yet and we really
should be thinking about better ways to replace it with something else.

I too think Gadgets and extensions are the place for these things. Anything
site wide should be in an extension, anything goes in a gadget as long as user
has the choice to opt into it.

MZMcBride is spot on and makes a good suggestion that we should be starting at
the source.
To take English wikipedia as an example [1]
When I look through the code I see:

* Main page layout fixes - why is this code running across the entire site?
* A redirect script that sends User:Name/skin.js to User:Name/skin.js to
vector.js or monobook.js - again why is this running across the entire site and
not a feature of the software?
* Some deprecation notices... shouldn't deprecation happen in the software?
* Then a bunch of imported scripts:
** if you are on an edit page 'MediaWiki:Common.js/edit.js'
** on the watchlist MediaWiki:Common.js/watchlist.js
** on the file page MediaWiki:Common.js/file.js

At this point I gave up reading. All these indicate to me is that there are
holes in the software that need fixing for all users and are being neglected to
be fixed in the software because "code review is too cumbersome". This is
completely irresponsible and upsets me. We should be striving to make MediaWiki
as customisable and flexible as possible without having hacky compromises like
this.

"sysops are going to download and learn to use git." if a person is not able to
learn git then personally I worry about them tinkering with software that hits
site wide. Tinkering with gadgets that are available for opt in is a great
thing and I believe important for community innovation but site wide just
scares me.

My suggested way forward would be:
* Audit all uses of Common.js
* Open bugs for all the problems they are solving (I think we'll be surprised
at how much overlap there is between projects)
* Work with the community to fix the issues in the software they have
identified in Common.js and remove the code from Common.js. In doing so build
up a trust that through code review we can fix things just as quickly and
better without resorting to needing a wikipage.
* With a cleaner Common.js wikipage and better process see the wood through the
trees and reevaluate what we need this page for.

[1] https://en.wikipedia.org/wiki/MediaWiki:Common.js

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

Reply via email to