This is the second post about FOSDEM 2013; see 1/3: I18n in the WEB, Mozilla i18n and L20n for the first. Links to the abstracts in the headers.
Open Sourcing Documentation
Don’t keep documentation to yourself, release it with an open license. Others might see the forest from the trees when you are too close to the problem. Translators can translate the documentation, but this needs proper tools, something which was not mentioned in the presentation.
Also mentioned in the presentation, webplatform.org (greetings sent to Ryan Lane who helped to build it) and the problems of Mozilla having to support both webplatform and its own MDN, where the latter has wider scope and more restrictive license than the former.
Coping with the proliferation of tools within your community
Entering the MediaWiki community and contributing to MediaWiki is hard for many reasons
I got the impression that XWiki is the everything and a kitchen sink of wikis. It has several nice points related to having everything in one place (one wiki):
- Only one place to have account and one place to sign in.
- Can search everything like bugs, commits, IRC logs and documentation at once.
In my opinion it’s a nice starting point for projects, but in the end it’s also about the quality of individual tools that matters when projects grow. I don’t see how MediaWiki could replace Gerrit or Bugzilla with something provided by XWiki.
XWiki is among one of the candidates to take over MediaWiki if MediaWiki is not able to revitalize its community by improving the extension and gadget development ecosystem. XWiki being written in Java can be a deterrent for some over PHP (but the opposite is certainly true, too).
How we made the Jenkins community
It’s not enough to lower the barriers, the barriers must be removed wherever possible. While Wikipedia is/was quite open and easy to use (not going too deep into that), MediaWiki development had and still has many barriers. It was not long ago that getting commit access took ages and you had to present your CV. Nowadays commit access is easier to get because we use Gerrit to review code before it is merged. But Gerrit is quite a complex beast and we still don’t have GitHub integration to accept drive-by patches. Lack of documentation and difficulty of getting patches reviewed is also a problem, not to mention the lack of a shared vision where MediaWiki should go.
Another problem that I think is not being realized is that MediaWiki code, while not as bad as it was, is in my humble opinion not improving fast enough. MediaWiki core is a huge monolithic piece of code, entangled in many places to the extent that it is impossible to extend without refactoring the affected code first. This greatly affects the innovation and creation of new extensions and thus is a problem for the MediaWiki ecosystem. The core code needs to become cleaner and more modular. The modularity and quality of Jenkins APIs seemed to be a major reason for the applaudable growth of its community.
Wish: Can we have an integrated search that provides results from mediawiki.org, Bugzilla, IRC logs, mailing lists and other relevant places and not just a service on labs known to the lucky few? There is also lots of stuff in etherpads, Google documents and even on blogs that will probably never be searchable.
Improving Stability of Mozilla Products
Something we lack compared to Mozilla is the crash metrics (note the diversity at their booth)
This talk made me wish for information on what actual problems MediaWiki users and developers are facing. Unfortunately, due to the nature of PHP, fatal errors and warnings can be caused by so many things, including syntax errors users made in their LocalSettings.php, that the data would need lots of filtering. There are also privacy concerns, but it should be possible to do something by collecting exceptions and JavaScript errors and aggregating them for some selected few to see. This would help to prioritize bugs, as Bugzilla and IRC channels are bad indicators of how many people are actually encountering a particular issue.
I’d like to be optimistic, but the best thing we have so far is translatewiki.net, which collects PHP errors, warnings and exceptions as well as JavaScript errors. However, aside from the PHP warnings and notices that are announced on IRC in #mediawiki-i18n, that information is only available to me and few others, and after all translatewiki.net is just a minor piece of the total system. One of my personal wishes is to have more priority given to the issues affecting translatewiki.net, as experience learns us that issues discovered on translatewiki.net, will most often also surface as issues in Wikimedia wikis. Mozilla can state things like: This bug affects 10% of all active users or hundred million users every day. Can we please have that, too?
It would be so awesome if the Wikimedia Foundation could release similar kinds of information to the wider public.
Shorts
IonMonkey: Yet Another JIT Compiler for JavaScript?
Why is yet another JIT compiler needed? Because the new one is better! Sometimes it makes sense. IonMonkey is based on well-understood techniques like static single assigment.
WebRTC: Real time web communication
The open source technology stack to kill Skype and Google Hangout is in process, but will still take a while to reach a browser near you. Check out http://reveal.rs.af.cm/ with a recent version of Google Chrome for a preview of what can also be accomplished with WebRTC.
PDF.js – Firefox’s HTML5 PDF Viewer
This is something that the Wikimedia Foundation could perhaps use too, though limited browser support is an issue.
The presentation had some nice tidbits on how the PDF standard includes everything and a kitchen sink like a 3D model viewer. It also explained what is easy to port to HTML5 (many things can be done with Canvas specification) and what is not. HTML5 specifications are going to see additions due to this work.
Changesets evolution with Mercurial
A cool idea: Tracking the changes to the commit history itself, so you can alter the history without deleting any parts of it. Questionable though if this will see wide spread use, and it’s only (coming to) in Mercurial now, not in Git.
For now I’ve made a simple custom Google search for people to test, with bugzilla, mediawiki.org, mailing lists, commits and code review comments, IRC, doxygen, etherpads (if linked from somewhere)…
@Nemo, you should place the list of URLs for the custom search engine somewhere public, preferably in source control (github?) so people could contribute additions / tweaks.
Specifically, I’d love if the search included blog posts from Planet Wikimedia and Open Planet Wikimedia. Also, technical village pumps and perhaps template talk pages would be good places to search, also.
Finally, it seems obvious that code itself should be searchable (e.g. single-line comments that don’t make it to doxygen, or even class/function/variable names, etc.
@Nike: the changesets evolution thing sound pretty cool! Are you aware of any discussions regarding a possible similar feature for git?
Also, requiring registration for commenting (involving a trip to the email to get the initial password) is quite a barrier to contribution. Have you considered a wordpress plugin such as Disqus?
@Waldir: I’ve just placed the list on the wiki: there isn’t any way to sync it automatically, is there? Planets can’t be searched, they’re ephemeral resources without archives so you’d be searching only the last few days, is this ok? Technical village pumps and template_talk namespaces are quite a challenge but I guess they may be included if someone made a list. Or you can add them yourself, I’ve added you as admin.
I agree that registration is quite burdensome…
@Nemo, thanks, let’s continue the discussion there.