MediaWiki's big code & usability push
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 70 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/39525 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSDEM 200938 / 70
3
4
6
16
17
18
19
20
21
22
23
24
25
26
27
29
30
31
32
33
35
40
41
44
46
47
48
50
51
54
55
57
58
59
60
62
65
67
68
69
70
00:00
MultimediaWikiStandard deviationScalabilityOpen setContent (media)Source codeSoftware developerDesign by contractMarkup languageScale (map)Hacker (term)Web pageData storage devicePhase transitionNetbookWeb 2.0GoogolEndliche ModelltheorieKeyboard shortcutTotal S.A.WikiTable (information)HypermediaTemplate (C++)Single-precision floating-point formatScripting languageSoftwareGroup actionServer (computing)Open setInternet forumLink (knot theory)Physical systemOpen sourceProxy serverStandard deviationWebsiteStorage area networkComputer fileInheritance (object-oriented programming)Block (periodic table)Greatest elementPhysical lawOffice suiteInsertion lossControl flowContent (media)QuicksortMetropolitan area networkProjective planeRevision controlBitRight angleDesign by contractCombinational logicSelf-organizationStaff (military)Installation artKey (cryptography)MultiplicationPatch (Unix)Web pageRepository (publishing)Multiplication signEmailElectronic mailing listOperator (mathematics)DatabasePoint (geometry)FreewareSystem administratorInternetworkingSystem callDemosceneEntire functionTerm (mathematics)Coma BerenicesFingerprintFitness functionNeuroinformatikArithmetic meanSoftware bugAdditionIndividualsoftwareCache (computing)MultimediaLattice (order)Markup languageStructural loadNumbering schemeFlow separationDirectory serviceRegular graphXMLComputer animationLecture/Conference
08:22
Software developerHill differential equationWikiData storage devicePhase transitionSoftwareMessage passingCodeTime evolutionCompilerMaxima and minimaCore dumpDesign by contractMachine codeExtension (kinesiology)Scaling (geometry)Core dumpDatabaseTotal S.A.Projective planeEndliche ModelltheorieScalabilityCentralizer and normalizerRevision controlBitInstance (computer science)Multiplication signExtension (kinesiology)Point (geometry)Computer fileAreaQuicksortSubject indexingWikiCodeWebsiteLatent heatRootServer (computing)Scripting languageCommitment schemeLocal ringElectronic mailing listNumbering schemeDifferent (Kate Ryan album)Graph (mathematics)Installation artUser interfacePresentation of a groupRight angleUniform resource locatorSoftwareTouchscreenState of matterStaff (military)PlanningRoutingHypermediaSource codeScaling (geometry)Network topologyScatteringStack (abstract data type)Electronic program guideMathematicsLimit (category theory)Office suiteOpen setPhysical systemDisk read-and-write headView (database)Table (information)Lecture/Conference
16:38
Extension (kinesiology)Machine codeCodeProcess (computing)Scaling (geometry)Core dumpMultimediaPort scannerSource codeBEEPSoftware testingForm (programming)Row (database)Computer fontSoftware engineeringWordUsabilityFunction (mathematics)Video game consoleRevision controlArchaeological field surveyComputer programOffice suiteForm (programming)Open sourceSoftware testingCodeVideoportalVideo projectorInformationShared memoryProcess (computing)FlickrFormal languageWebsiteDependent and independent variablesProjective planeComputer fileQuicksortMultiplication signSoftware maintenanceOffice suiteVideo game consoleUser interfaceUsabilityBitMultiplicationRight angleStack (abstract data type)Arithmetic progressionReal numberSystem identificationSpacetimeSemantics (computer science)Extension (kinesiology)Data storage deviceLocal ringInteractive televisionLatent heatVideoconferencingAdditionSystem administratorNumbering schemeSequenceDifferent (Kate Ryan album)Presentation of a groupVector potentialNetbookElectronic visual displayWeb 2.0Electronic mailing listHypermediaFile archiverMedical imagingTable (information)WikiPoint (geometry)Optical disc driveSheaf (mathematics)DatabasePhysical lawPRINCE2Pattern languageSoftwareScaling (geometry)BlogWater vaporLogic gateUser interfaceUniverse (mathematics)Mixture modelLecture/Conference
25:12
UsabilityComputer programOffice suiteCapability Maturity ModelStability theoryWikiConvex hullReduction of orderNegative numberOvalFinitary relationComputer configurationRevision controlPhysical systemAdditionBackupRevision controlPrice indexBitOcean currentQuicksortComputer hardwareOnlinecommunityUsabilityException handlingCore dumpPatch (Unix)Extension (kinesiology)WebsiteConfiguration spaceWeb pageType theoryDatabase normalizationCapability Maturity ModelProjective planeWikiProcess (computing)MereologySmoothingScalabilityDisk read-and-write headMathematicsCodeHypermediaAreaSemantics (computer science)FlagLatent heatDesign by contractDistribution (mathematics)Game controllerDivisorStability theorySelf-organizationKey (cryptography)Level (video gaming)Multiplication signTheoryMachine visionDigital mediaInternet forumPunched cardWorkloadInformationNP-hardLevel of measurementScaling (geometry)DigitizingStorage area networkLecture/Conference
33:46
Revision controlSoftware testingOnline helpDesign by contractWebsiteInformation securityWikiDigital filterVideoconferencingWeb browserSource codeStandard deviationMultimediaTheoryGateway (telecommunications)Mobile WebMarkup languageMaizeClient (computing)Computing platformUser interfaceHypermediaOffice suiteCodeHypermediaDesign by contractAdditionRobotEndliche ModelltheorieFreewareVirtual machineInternetworkingElement (mathematics)Connected spaceType theoryReading (process)Revision controlSoftware testingElectric generatorTraffic reportingStorage area networkMultiplication signBitWebsiteVideoconferencingFlagDivision (mathematics)Web browserFormal languageIntegrated development environmentSingle-precision floating-point formatCycle (graph theory)Moving averageServer (computing)Gateway (telecommunications)Projective planeMobile WebSemiconductor memoryDisk read-and-write headTerm (mathematics)Android (robot)Medical imagingMereologyFile formatGoodness of fitConnectivity (graph theory)CodeWikiWeb 2.0Information securityTablet computerExtension (kinesiology)Computer programmingThomas BayesSpacetimeBuildingSelf-organizationMilitary baseService (economics)Standard deviationInterior (topology)Gastropod shellTwitterResultantLibrary (computing)Series (mathematics)Web pagePoint (geometry)Mobile appAnalytic continuationPhysical systemGroup actionProcess (computing)WeightLecture/Conference
42:20
User interfaceMobile WebHypermediaFeedbackData miningDisintegrationLine (geometry)TelecommunicationRing (mathematics)Directed setVector potentialSoftware developerGame theoryProcess (computing)Self-organizationEvent horizonLine (geometry)WikiSelf-organizationSource codeWebsiteRight angleMultiplication signProjective planeTelecommunicationGoodness of fitProcess (computing)Regular graphCuboidMarkup languageSoftware bugSoftwareEmailOnline helpElectronic mailing listFormal languageType theoryDifferent (Kate Ryan album)Numbering schemeSubsetPatch (Unix)Online chatTouchscreenTwitterInternet forumBuildingOpen setExtension (kinesiology)Latent heatPhysical systemDescriptive statisticsInstance (computer science)AdditionFlow separationDigital photographyProduct (business)Open sourceTouch typingUniverse (mathematics)BlogForm (programming)Identity managementFeedbackMathematicsHypermediaMetropolitan area networkReading (process)Lecture/Conference
50:55
Maxima and minimaUniform resource locatorError messageMenu (computing)Core dumpSlide ruleCodeDisk read-and-write headObject-oriented programmingLecture/Conference
52:31
Event horizonSelf-organizationPatch (Unix)Formal grammarStorage area networkMultiplication signNumbering schemeWikiLetterpress printingHypermediaOffice suiteMultilaterationMarkup languageLecture/Conference
54:29
XMLComputer animation
Transcript: English(auto-generated)
00:08
Hello, everybody. So you're hopefully here for the media wiki presentation, because if you're not, then I'm not giving the other talk, because they apparently moved some rooms around, which
00:22
is always fun. But if you're in the right room or if you think this might be fun anyway, then by all means stick around, because I hope it will be fun. So media wiki, we're doing stuff. It's good. Ooh, this actually works. I'm pleased.
00:41
Yeah, is anybody else using one of these fun little netbooks? Anybody? Anybody? Anybody's just thinking about getting them? One, two, ah, ah, I don't see one back there. Awesome. I'm really happy with this thing. Tiny little Dell. It actually fits on an airline tray table, so I could actually open it and do stuff
01:06
on it. My previous computer, I could open it enough to get at the keyboard, but not to get at the keyboard and see what I was typing at the same time. Kind of not good. Okay, media wiki. Hopefully you know what media wiki is. If you don't, now's your chance.
01:22
Media wiki is the fun, awesome wiki engine that we created way back in the ancient year of 2002, specifically to run Wikipedia. Wikipedia actually started in 2001, so there was a Wikipedia before media wiki, but there was no media wiki before Wikipedia.
01:42
It's free open software, obviously, otherwise I wouldn't be here at the free open software conference. We've been using GPL version 2. We're still on GPL version 2. Who knows? GPL version 3 may happen someday. Everyone thinks it's kind of weird and scary. We run on a pretty much standard kind of lamp stuff, and we scale anywhere from your
02:05
crazy little home install or your shared hosting account that offers super cheap, super free. We have MySQL and PHP onto the crazy super farm installations that we have at Wikipedia or Wikia or all kinds of other big hosting sites that run hundreds or thousands of wikis
02:26
and do all their crazy things with multiple servers and multiple database servers and multiple kinds of servers and ten layers of caching and insane stuff that most people don't have to worry about. Lucky them.
02:40
Wikipedia. Probably you've heard of it. If you haven't, then maybe you haven't been on the internet for a while. It's an open content encyclopedia, free, wonderful, we love sharing, blah, blah, blah. The actual content is all created by the volunteer community just sort of popping up, doing cool stuff.
03:01
So if you see anything on Wikipedia that you don't like, please don't call us at the office in San Francisco because we didn't actually write it. Everything's running on open source software, top to bottom, a lot of stuff that we've written ourselves such as media wiki and various little fun tools for certain kinds of monitoring, load balancing, blah, blah, blah, and then a bunch of standard stuff all year
03:23
regular LAMP stuff and squid proxy for our HTTP caching, all kinds of fun things. We've been contributing back patches to all those things that we use. We love it to bits and all the custom software that we write is done in an open source
03:44
manner with a combination of staff developers, volunteer developers, third party contractors, whatever, but all working in an open subversion repository, open bug tracker, open mailing lists, all that fun stuff.
04:02
We like it. Meet Wiki Foundation. You may or may not have heard of us. We are the actual silly company that performs the operation of Wikipedia. We're not writing it, we're just running the servers and providing some of the infrastructure
04:20
and fun stuff around that. We actually formed it as a nonprofit company in 2003 after a couple of years of just sort of stuff being around. When you're just starting up a new project, it's very easy to just, you know, you just throw it up, you throw it up on a few servers and see what happens and then eventually
04:41
there are legal questions or questions about what's going to happen in the future, blah, blah, blah. And that's where you start to do all these actual organization creation. It actually took a couple of years from 2003 on to get to the point where there wasn't just like one person in the foundation.
05:01
So I was actually brought on as I think the first employee in 2005, two years after we started the company, and we're only now getting to the point where we have more than like three people on the tech staff. We now have five in-house developers, a couple of system administrators, and then several
05:21
additional contract workers which we were generally taking out of the existing volunteer development community, which is something that we absolutely love to be able to do, supporting our contributors back in actually, you know, seriously working on creating the awesome things that we use. And just to get a general idea of the size of our operation, our budget for this fiscal
05:46
year, entire budget for the entire company, about six million dollars. That's not a huge amount of money for what is a very, very large website in terms of the, I believe, comScore statistics, all of our websites together make up something
06:05
like the number four total website, and we're just behind like Yahoo and Google and something else. I don't know, maybe AOL, believe it or not, people still use them.
06:26
Back to software. So way back when, 2001, we actually started using a preexisting wiki engine, which was usemod wiki. Now, the wonderful thing about usemod is it's really easy to install, it's a single Perl script.
06:42
Bam, single Perl script, put it on your server, set up as CGI, have a directory you can write to, wow, you've got a wiki, it's awesome. And for better or for worse, our mockup has derived from usemod system. So we have kind of, you know, weird little things for the way that we do bold and italic
07:03
and links and blah, blah, blah, and that all derives out of the usemod system. So we maintain pretty much compatibility with that over the years, but sometimes it's kind of quirky and kind of weird, and then of course we've extended it in fun, bizarre ways to add tables and templates, and so there's much scariness in the markup.
07:21
But that's the wonders of backwards compatibility. Now, the basic problem with usemod was that it just really wasn't built to scale. For a small site, just fine. But when, after about a year, we got to 10, 20,000 pages, we had a lot of people editing simultaneously, the system didn't really have a good way of protecting against multiple
07:44
people editing simultaneously. It theoretically did. It had a lock file. And whenever someone was actually making a save, it saved the lock file, and then you would wait until the lock file was removed, and then somebody else would save. But sometimes it would forget to remove the lock file.
08:02
So it would just sort of break for a few hours until someone went in and fixed it. Fun little stuff like that. So we went ahead and decided to create some specific software just for Wikipedia that would be developed specifically for our needs. This was built initially by Magnus Manske, a volunteer developer from Germany, who went
08:28
ahead and just said, okay, we've been talking about this for ages, I'm just gonna do it. So we went in, built it using the PHP MySQL stack. A lot of us who were kind of poking around at it, it was really our first big PHP project.
08:44
And some of us, well, we didn't really know what we were doing, so it was really very exciting and fun and new. Once we deployed the first version in February 2002, about a year after Wikipedia started, we found that it sort of worked. We actually had serious performance problems with it because, well, we forgot to put
09:03
indexes on the tables, and little newbie mistakes like that. So it ended up kind of getting totally rewritten based on our actual experience having deployed it, what was good, what was bad, what needed to be redone. And by July, Lee Daniel Crocker and a few others of us had just sort of
09:25
been around and completely redone it. So it was built on a similar model as that initial version of the PHP code, but everything just a little bit different and a little bit more geared towards efficiency. The downside with this is that I had to add Unicode support back in three times on
09:43
each version of the software. That kind of sucked. But the good news was that it was actually a workable code base, and we've actually been developing that same code base ever since. And it evolved into what is today's MediaWiki, which has become a little more
10:00
general than just the Wikipedia script, as we originally called it. So over time, we started adding things like an actual installer that people could use to install the software. The original version, you had to be running as root on your server to install
10:23
MediaWiki and run a command line script which copied the files into the right location, and if you did anything wrong, it broke and destroyed your site. So that was kind of not good. So once we had, you know, a basic little web-friendly installer, you know,
10:41
it's not the greatest thing ever, but it works. People are able to actually set it up as a third-party site. We had a few people come in and redo the UI. We went from, I don't have any screenshots with me, unfortunately, but our old UI was very plain, very drab, very kind of hideous.
11:05
Our new UI is very pretty, or at least it's pretty for 2003, 2004. Probably needs a few improvements now. We redid the database schema to be more efficient for scalability issues. We removed a lot of the hard-coded instances of Wikipedia in the user interface.
11:25
So now if you're not Wikipedia, it actually makes sense to use MediaWiki. Now, over the years, we have seen a lot of increase in activity in the actual development of the software. So I've got a little graph here of commits to our Subversion server
11:43
for each month from 2001, when actually it was a CVS server, all the way down to this last month. You know, back in the olden days, we had a few commits. Now we're getting to where we're over 1,000 commits every month,
12:02
just on MediaWiki and its associated projects. And not only do we have this increase in total commits, we have an increase in the number of people actually doing the contributions. We had a few contributors back in the day.
12:21
Last month, we actually had, it looks like 59 individual people making a commit during that month. So that's a lot of people doing some specialized work, working on maybe a particular extension, or working just on localization issues, or working just on the installer.
12:41
We have a guy who pretty much just does updates to our Lucene-based search engine, all kinds of things, both on the core and the extensions to MediaWiki, huge amount of activity going on. So we've seen this big growth in the actual development community, which has pluses and minuses.
13:03
So one of the minuses, of course, is that the core developers, who are actually, you know, those of us employed by Wikimedia to make sure that MediaWiki exists and does the needs of Wikipedia, well, we haven't really increased that much.
13:21
There's still just a very small number of us. And we have a limited amount of attention, unfortunately, and we're still kind of scattered, not always getting as much done as we want. So a lot of our core attention in the last few years has been on scaling, performance, specific features that Wikimedia needs,
13:45
like, oh, we need to make sure our fundraiser works. We need to do a bunch of stuff to make sure that this whole fundraiser season works, because otherwise, if we don't run our fundraiser at the end of the year, we're going to run out of money and not be able to run the site. That's kind of bad.
14:01
So that becomes a priority, and suddenly we're not able to do something else. Of course, in the last year, we've finally gotten to the point where we've been able to hire a few more people on in the core area. So Tom, where are you sitting? You're hiding in there. There's Tomas back there.
14:21
Awesome, dude. Tomas worked on our fundraiser stuff this year so that I didn't have to. I was able to do other stuff. Yeah! That was good. So we're able now to do a little more things, sort of maintain more stuff, have fewer bottlenecks in the central core developers,
14:45
but still kind of working on it. One of those things that I've been doing is, late last year, I created a code review extension to MediaWiki,
15:01
which basically integrates in our updates, all the commits into the Subversion system, into the wiki for review in there. And yes, that's you man right there. Wow, you've been committing a lot.
15:21
You've been busy. So we've got a nice little list of everything that's going in, and then people are able to mark that reviewed, or not reviewed, or problematic. Let's see if I can find something a little more exciting. There we go. So here we have a problem commit,
15:43
which was identified by people while I was... When was this? Yeah, I was on a plane or something. So I didn't actually have to review this myself, other people went ahead and took a look over it, blah, blah, blah, blah, blah, blah. We have comments down there, people encounter problems,
16:04
and it's been marked as fixed. And if I log in, I can actually probably go ahead and mark it as no longer being a fix me. But I don't think I have to do that, because I think you guys can do it. So that's pretty awesome, helping to reduce the bottlenecks there.
16:25
And uh-oh, looks like I've fallen back out. Where am I?
16:40
Yes, OpenOffice presenter is still a little new and exciting to me. I'm actually, for the first time in quite a while, switching my presentations back to Linux from my old Mac. I love my Mac, but it's just too damn big. Netbooks are great. So what's going on right now? We have...
17:01
We're starting to put these code review processes into place. It's helping, but we're still seeing some problems. We're starting to do an actual scheduled code review sequence, where every week, every Tuesday, I'll go ahead and make sure I run through everything that's been going on, fix up any remaining problems, and push it out live.
17:22
And I'm seeing that going through a week's worth of stuff actually takes all day. Which is kind of bad, because then if I miss a week, it takes two days, which is a long time. So we definitely still want to have some improvements in the processes there, but we have now stuff in place
17:41
to be able to share a lot of those responsibilities. There is a quarterly release, 1.14, that mini-wiki. Imminent, Tim is working on it right now, pushing out that release. It should be pretty awesome. And we have a bunch of extensions that are being worked on right now by folks in the office and elsewhere
18:01
that we're going to be pushing out pretty soon. Edit drafts, we're also putting in an abuse filter extension, which is able to reintegrate a lot of the basic identification and tagging of problematic edits that are very specific
18:22
repeatable patterns, and can be seen very easily, and either just stopping them outright or tagging them for human review in a somewhat easier fashion. So, big stuff coming up. One of the big things we're going to be doing this year, we started the Wikipedia usability project. We've got a grant from the Stanton Foundation
18:42
to go ahead and hire a couple of additional people specifically to do this. So we are currently hiring for a interaction designer to do usability testing and actual specific design and just review of user interface problems going on.
19:05
And a couple of developers specifically to implement that stuff, and most importantly, to actually find what's already out there that we can go ahead and pull in with relatively little work. There's a lot of extensions, customizations,
19:21
additions that have already been done based on either usability testing specifically, such as the Unimiki extensions, and some tests that have been sponsored in the past by some German universities, custom setups on various third-party sites,
19:41
Wikia, Wikihow, lots of others. A lot of those that we can pull in either directly or use it as an inspiration to finalize something that will actually fix up our needs. So being able to have dedicated resources to pull in existing stuff and to do actual testing
20:02
to make sure, yeah, this really works is going to be very, very helpful. Another big thing we've got going on is some video projects sponsored by Kaltura with the Medivid project. We've got Michael Dale and some others doing some advanced work with Ogg Fiora-based video
20:24
using FreeCodex and the new Ogg support that's going to be in Firefox 2.1 gives us additional assurance that, yes, we will have real free video on the web and we can do awesome, awesome things.
20:41
There's a online video sequencer that's being worked on, as well as simply being able to more actively grab existing videos, search both within our own sites on Wikimedia Commons, and to pull in freely licensed files from other sites
21:02
such as zener.archive, sites such as Flickr that have appropriate tagging of freely licensed images and videos, all kinds of awesome stuff going on. And hopefully we'll be able to start rolling some of that out later this year. So what else is going on? There are a huge number of awesome, awesome things
21:23
that have been going on in the MediaWiki space for quite some time. One of the coolest projects out there is Semantic MediaWiki, which is an extension to MediaWiki which adds capabilities to store data relationships between articles,
21:44
based on articles, and then be able to query that data back, display things in useful tables, display sensible lists. This has the potential on a site like Wikipedia to eliminate a lot of the sort of manual drudgery
22:01
in maintenance of certain kinds of lists, information tables, sharing of data between articles, possibly between different language sites if appropriately set up. Lots of fun, cool stuff. It's been worked on for several years. It's very mature. We would love to be able to actually start integrating this.
22:21
So in the next few months, we should be able to set up some actual testing of what are the actual needs as far as is it gonna impact the database? Is it gonna impact scalability? We know that this stuff is awesome. We know that we want it.
22:41
Let's make it happen. So Semantic MediaWiki, better support for TranslateWiki or BetaWiki. There's a lot of localization going on from all these awesome people. Pretty much as soon as I've made a commit,
23:00
there's a translation in like five languages. Sometimes before I make my next commit, there's already something in Hebrew from my last commit. Then there's six versions of German and Chinese and who knows what else. Tends to get kind of fun.
23:20
It's pretty exciting. And there's a lot of other little bits and pieces, form editors, improvements for working with tables, multiple sections, little WYSIWYG bits. Lots of things that we either want or think we could use that we're gonna be finding and adapting.
23:41
Now one project that I like to look at here and there is WordPress, which is a fairly well known open source blogging software. Like MediaWiki, it's open source based on a LAMP stack. It's frequently thought of as being too big and bloated. And yet, it often seems to be best of breed
24:02
in many situations and there's billions of people using it. WordPress has been making a lot of progress over the last year. They've been actually doing big pushes on usability, fixing up their user interface, identifying real problems with usage
24:20
and doing public mock ups of new user interfaces, surveying people to see what kind of works, actually doing some user testing and just generally getting people very involved in the process of making new things happen. I've been very excited to see that. Every time I upgrade my blog,
24:41
suddenly the administrator console is a billion times easier to use. If we can get that going on MediaWiki, I'll be very happy. Back at the home office. Yeah, pretty much already said most of this. We're hiring, or have been hiring a few more people to do some of the dirty work.
25:03
So, basically what we're doing within, within Wikimedia itself, our names are all too similar. It gets confusing. Is primarily just making sure that MediaWiki itself still works, making sure it works for us
25:22
with scalability and then doing specific projects that we ourselves need based on some identified strategic need. So there's a lot of the additional third party development which is going on, which we love and want to encourage more and more of.
25:42
In addition to the usability project, where we want not just our core team in San Francisco working on that, but we also want everybody who's a volunteer developer to be pitching in, everybody who's a user to be pitching in with their comments and actually really get a community voice in there
26:02
as well as just a few guys saying, well I think it looks good if we move this over there. That's not what we want. We want a real dynamic project that is a big awesome community thing. We're also looking at the possibilities of doing more kind of intern style projects
26:21
as well as some of the specific project contracting that we've been doing. Of trying to support people who are doing volunteer development, kind of bring more people in and be able to really get specific projects going so that not only does something get started,
26:41
but it gets finished and integrated once it's usable. So overall what is it that Wikimedia wants? Well our general organizational goals, which sound pretty boring, are organizational maturity,
27:00
financial stability, increase of quality and perception of quality, increasing distribution beyond the wikis, and encouraging and broadening participation. Really these are pretty straightforward things. Insofar as they apply to the technical world, which I'm in control of,
27:20
organizational maturity is primarily about making sure that we actually know what we're doing. Making sure that on the level of hardware and systems that we have stuff in place, not just able to run the site, but appropriate backups and redundancy. Yeah, makes sense. Also on the coder level,
27:42
it means that we wanna make sure that people who are contributing code feel welcome, that they feel like their code is welcome, that contributions are not being ignored, patches are getting reviewed, extensions that are useful are getting enabled,
28:01
new sites and configuration updates that need to be done for some community actually get done. This is still somewhat of an ongoing process, but it's very much one of the things we wanna accomplish. Additionally, in those general goals,
28:20
one of the big things is broadening participation for users on the wiki end. Increasing our reach, broadening our depth to get more and more people involved on the wiki sites. We're trying to broaden participation, make it easy for people to come in and contribute something.
28:42
Traditionally, in the wiki world, the way that you contribute is you edit. You go onto the article, you click edit, you punch in some information, you fix something that was wrong, maybe you add a comment to the discussion page. But honestly, that's a pretty high burden,
29:03
a pretty high bar for a lot of newbies to reach, just because it's not really obvious how some of this stuff works. Even if we make wonderful WYSIWYG editing that everyone understands, just the idea of going into a discussion page on a wiki and adding your comment,
29:21
it's not really obvious how it works. So we're interested in easier ways for people to just contribute a little something. Maybe instead of going in and adding a comment on a fancy ass wiki page, maybe they can just say, I like this article. Maybe they can say, I didn't like this article.
29:40
Maybe they can say, I like this article except for this bit. Or just describe what needs to be done on this. It needs some attention. Maybe they can add a little text comment. But in a way that's easier for people to participate in without necessarily being hardcore wiki user.
30:10
Yeah, that's pretty much what I said. But also part of that is when people are starting to actually do the editing, they frequently encounter problems
30:21
with other parts of the community. So of course every online community has trolls and people who are just, who mean well but they're very rude. And this is a problem in any kind of online community and certainly Wikipedia is not at all immune to that.
30:40
So we're gonna need to see some improvements on perhaps the social front of making sure that good behavior is encouraged, bad behavior is discouraged. This isn't always easy because inward facing
31:01
communities often can self-perpetuate some of that. So if you're a newbie, you don't understand the jargon, you don't understand what's going on. So somebody kind of pops up out of nowhere and says that you violated NPOV, RFA3, whatever. You don't know what the hell that is. I've been around for years, I don't necessarily know
31:21
what the hell it is. That's not too good. So a little of that may be some actual technical solutions can help to smooth out the workflow, smooth out the process, make it easier for people to not have to actually butt heads when they're interacting. But a lot of it is actually gonna need some real
31:41
social change that is maybe outside the scope of just the technical area. I already said semantic media wiki is awesome, but it bears repeating. It's a good thing.
32:01
Flagged revisions. One of the other things that we've been running experimentally for quite some time, and we finally started deploying it live on German Wikipedia a few months ago, is the flagged revision system. And it's one of these little additions to the wiki workflow where we take the ability to take a version of an article that we think
32:22
is pretty good, and mark it as saying, yeah, it's pretty good. And then maybe for just some visitor who comes in and doesn't know what's going on, maybe you'll actually get shown the, yeah, it's a pretty good version, instead of the, don't know about this yet version. Or at the least, you'll have some indication
32:40
that, yes, there are multiple versions, and we know this one has been reviewed, this one has not. So it helps to expose a little bit of the wacky editing process of what's current and what isn't, which as a reader isn't necessarily very obvious.
33:01
Somebody who just sort of pops onto Wikipedia and maybe doesn't quite understand that what it says right now isn't maybe what it said five minutes ago, and isn't maybe what Wikipedia says. So being able to just sort of self-moderate and kind of speed bump certain types of edits,
33:22
in theory, allows us to improve the actual quality and perhaps the perceived quality of a wiki site by indicating that, yeah, it's pretty good. But there are also some problems
33:40
in that it does slow down some of the workflow. It creates additional requirements to go around and make sure that things are reviewed and we've had reports that are just a bit of a backlog at German Wikipedia. There is some interest in deploying some variant of flag divisions on the English language Wikipedia,
34:01
which is, as the most popular one, also the most likely to run into certain kinds of problems with people going, oh, my article says something scary about me. But we wanna make sure that we actually solve some of those workflow problems. So that's still an ongoing thing, definitely want continued community involvement with figuring out what's actually going on on that.
34:26
But flag revisions has primarily been, oops, I didn't check my details there. I don't remember who actually was working on that. Was that Bruno? Awesome, cool, that's good. I'm glad that my memory's correct.
34:41
That's always a happy thing. Anyway, it's been primarily maintained the last few months by Aaron Schultz, one of our contract workers who's come out of our volunteer development community. Awesome stuff, we love it. One of the other things that we've been testing and we're gonna start doing some more deployment very soon, the abuse filter extension.
35:03
There's a whole bunch of cool new features in it, which unfortunately we didn't get a chance to deploy this week or I would be showing it to you right now. But it adds the ability to tag edits as they come in with a certain kind of tag based on some element of what the edit was.
35:26
It contained certain types of text, it removed large amounts of text, looks like a certain kind of vandalism, whatever. So in addition to just being able to automatically revert something, which is what a lot of the third party bot tools
35:41
are doing now, we can do more traditional Wiki soft security models by tagging things for human review. So maybe they'll get seen immediately, maybe they'll get seen in a few minutes, but by being able to tag them, we actually create an environment where someone can go in and specifically
36:01
pay more attention to the problem edits instead of having to review every single thing individually. And that's being developed right now by Andrew Garrett, another one of our long-time volunteer developers who's now doing some contract work for us. He's actually out in San Francisco right now visiting
36:22
and we've been able to do some very tight review cycles and get a lot of stuff done in a short amount of time. That's been really, really fun. And it's definitely one of the things that's encouraging me to look more into internship programs,
36:41
maybe bringing people out for a little time to our main office and just do some really serious hackfest stuff. I went a little bit into the media stuff already, but that's some awesome things. An additional part of that is we're now
37:05
administering a grant from the Mozilla Foundation. Is that the Mozilla Foundation or the Mozilla Corporation? I forget which one. They all blur together to me. But one of the Mozilla guys, to improve some of the Ock the Aura
37:21
and Ock Vorbis support in Firefox, both the base libraries, which not only Firefox but a lot of other tools are using, and the advanced encoder, which will allow the non-patent encumbered
37:40
Fiora format to actually really be pretty much head to head in terms of quality with things like MPEG-4, whereas traditionally it's been thought to be not quite as good because the first generation encoder was not quite as good. The advanced encoder is starting to use features of the Fiora standard, which were added after the original
38:02
version of the encoder was made. But they're in the baseline Fiora 1.0 spec as it was finalized, and now the code is actually starting to catch up. So we're helping to sponsor, making sure that stuff actually gets done. Much better support for free video on the web.
38:23
We love it, Mozilla loves it. It's all a big love fest. Also, we keep looking at mobile stuff, because a lot of people these days have stuff like this little guy, or maybe if they're not into evil proprietary Apple stuff,
38:40
maybe they have a Android-based machine or something else. There's all kinds of fun devices these days. Also a lot of fun Linux-based tablets, like the little Nokia 810, all kinds of cool stuff. But basic thing is they're relatively small, they have a small screen,
39:00
and they have some kind of crazy internet connection. It's pretty cool. So very frequently, we're out at lunch in San Francisco from the office, talking some kind of bull crap. Somebody says something or other, somebody else denies it's true. If only there was some way we could look it up, some kind of website.
39:21
Well, we can, thanks to the internet. So for some time we've had a semi-experimental mobile gateway. It's currently at mobile.wiki.org. But the version of the code that it's currently based on has been originally targeted to older
39:41
kind of WAP-based devices, which is the older mobile phones, which can get on the internet, but no one really knows how or wants to if they do. So people have never really used it very much, but this latest generation of awesome new internet devices
40:01
that have real browsers, such as the WebKit-based browsers in the iPhone, the Android system, even current blackberries have a kind of okay browser, are a lot more capable. Download speeds are faster.
40:21
They can actually do things like show CSS and images and run some JavaScript. All kinds of fun stuff. So we're now working on a more capable system, which currently we have in a test roll out on m.wiki.org, and we'll eventually start merging the two of them,
40:41
which is much more advanced. It's based on the original server component from the Ipedia or iWIC iPhone application, which was created by Hampton Catlin. Using a lot of Ruby-based stuff. He's open-sourced it for us,
41:00
and we're now currently doing some testing for going ahead and building that out as an official iPhone application, and then we're gonna roll it out to other platforms as well. Android, maybe BlackBerry, you know, whatever else we can see support on. But the primary part of it is the server-side component,
41:21
which does some reformatting and produces this very nice HTML page, which uses actual modern stuff, which a modern browser can render very nicely. And there's just a little bit of a native UI that you can wrap around that for a little happier things,
41:40
which can integrate a little nicer. But even just the server-side web component, awesome. We're having a great time with that. That's currently being developed via GitHub, rather than our subversion, so that's a fun little experiment. There's an IRC channel if you wanna pop right now on freenode.net into Wikimedia Mobile.
42:03
May or may not be anyone awake, but there may be some folks in there. So it's an ongoing, cool, awesome project. Currently, the mobile stuff is mostly just for reading. And reading Wikipedia is good, but contributing back is good too.
42:22
It's kind of a pain right now, you know, if you're on your iPhone or your G1 and you pop onto the regular Wikipedia site, you can, in fact, edit. You can click the edit tab and go into this giant text box and type some stuff in, but man, you really don't want to. It's a pain. The edit box is like this big
42:41
and your screen is this big. Yeah, that doesn't work very well. But there can be a lot of usefulness to being able to contribute. I often find that I'll run into a typo or something while I'm reading something on the road. So I like to be able to go in and fix it.
43:00
Also, maybe you're traveling, maybe you find an article in some place, there's no photograph, you wanna be able to take a picture of it, upload it, add a little description, stuff like that. Currently, we don't have any native support for that. We would love to add it. So hopefully that's something that we'll be able to get going. And if there's people excited about it,
43:22
dude, come on, let's make it happen. So in general, we have a lot of things that we want to pay attention to. Not just cool new things for the future, but stuff that actually is a problem now. So we want to pay a little more attention
43:42
to what are the problems that people are having, both within Wikipedia and for third-party users. Now Mozilla runs, for instance, a whole bunch of different community-facing sites for various different targets, and they run on various different technologies.
44:00
Some of them are specifically built, some of them are Wiki, some of them are blogs, some of them are forums. One of the Wiki sites that Mozilla's had for some time is the Mozilla Dev Center, or MDC, which is primarily developer-targeted documentation on HTML, JavaScript, all that stuff.
44:21
It was originally running on MediaWiki. Last year, they decided that they'd try transitioning to MindTouchDecky, which is a different Wiki system, which actually long, long ago forked from MediaWiki and then rewrote the entire thing. So they do some interesting things,
44:41
some of which we really like, some of which we think are kind of weird and bizarre. But they have their plus and minuses, and one of the cool things, for instance, that Mozilla wanted for the MDC was integrating multiple languages better into a single site, which currently we don't super well do, we mostly put them in separate sites.
45:02
But there are projects that we can do. It also has WYSIWYG editing, but they've actually ditched a Wiki markup entirely and just go straight to HTML, which has advantages and disadvantages. It makes the WYSIWYG process easier, but if you actually have to do source editing,
45:22
it ends up being more difficult because now you're editing WYSIWYG HTML. So I've seen pluses and minuses, complaints and praise from people who have been reacting to this change, and definitely it's one of the things that we're gonna wanna investigate.
45:40
What's good about that? What can we learn from? What can we adapt? What do we know that we don't wanna do because people are having problems with it on other sites? So in general we have all these separate little things, things that we wanna do, people we wanna talk to,
46:02
just stuff that we wanna have going on. And we have all these different ways of communicating with people. We have the Wikis, we have both a mediwiki.org, which is primarily documentation, but there's also some person-to-person communication on it. People ask for help.
46:20
People try to document weird little things that they do. We have the bug tracker, we're using Bugzilla. Bugzilla has some issues, and that's kind of big and scary and frightening, but it also does a lot of things. So are there ways that we can improve the bug tracker system, make it easier to use,
46:41
but still keep it very capable? We have a bunch of mailing lists that people can talk on. We have IRC chat rooms, we have unofficial help forums, there's various blogs, people are using Twitter and Identica and such. Of course we have conferences, people actually come together,
47:01
such as right here, lots of folks. Hi, how's it going? Awesome. And of course people will directly email or otherwise contact people individually to work on some specific issue. Is that too much stuff? Is that not enough stuff? Do we need more channels?
47:21
I don't know. But what we do want to make sure that we do is that we have clear communication. One of the kind of general problems that people have is they kind of do their awesome project and then no one really looks at it. Or maybe somebody looks at it,
47:41
but they don't really quite comment on it. So we want to make sure that stuff actually gets review. If somebody wants to build something that's for Wikipedia or for one of our other sites, we need to make sure that they have a very clear go or no go reaction on whether or not
48:01
we'll accept it in the first place. And then once they've actually produced it, whether or not it's acceptable as it is. If there's something wrong with it, we need to let them know exactly what's wrong with it and exactly what they need to change. Otherwise, people get very frustrated. It gets difficult to really continue on
48:23
when you're not getting the feedback, when you're not seeing this activity cycle of your stuff actually getting into production. And this is something that a lot of large software projects have seen. Certainly I remember contributing a number of patches
48:40
to Mozilla back in the day and really having to constantly push and follow up with people to make sure that my patch got reviewed, that it got implemented, that it got put into production. If there was anything wrong with it, I needed to actually know what was wrong so I could fix it. And it took a lot of effort.
49:01
And I recognize that sometimes we're not as responsive as we wish we were and people really have to come after me constantly to me or Tim or one of the others to make sure that we actually review it and fix it and awesome stuff happens. So we want to make sure that that process is easier to happen,
49:21
that we're not just dropping things on the floor and we need communications for that to happen. So one open question is maybe we need a slightly more formal process in there. Maybe we need to have some specific place that people can go and say, I want to do this thing. Is it okay or not?
49:41
Maybe something like the Python extension proposal system that the Python worlds use. Is that good, is that bad? I don't know. But it's something we definitely want to be thinking about. In addition, there's a problem of feature ideas or bug fixes or whatever that people really want
50:01
but those people aren't coders. And in the world of open source, most of the time, whoever's actually doing the coding wins because if there's something that people want but they're not writing the software, no one cares. We want to make sure that those things that are important actually get paid attention to.
50:26
Now we are definitely trying to see a little more organization going on as far as conferences, generally making sure that everybody kind of knows what's going on and everybody has those lines of communication open.
50:42
There's a MediaWiki developer conference, excellent, developer conference going on. Let me, in Berlin, in April, which let me pop up the URL to that.
51:12
Don't know if you can all read it from here but this is a small URL. Oops, that didn't work. Did I, yeah, I typed something wrong, didn't I?
51:21
Wee, mwmeet09, there we go. So this is going to be awesome, awesome fun. It's going to be at the C base in Berlin which if you haven't been there, sweet. I highly recommend it.
51:41
So we're not only going to have a lot of fun but we're also, I think, going to be very productive. We're going to have hopefully most of our core developers from the Wikimedia Foundation as well as a bunch of the awesome, awesome, awesome volunteer developers throughout Europe and elsewhere
52:01
get together, knock some heads together, knock some code out, make sure that we really get stuff happening. So everybody come to it, it's going to rock. And I think I had something else, oops. I have to find where I left.
52:21
So about like two minutes left or something. But I'm on like my last slide so I think I'm pretty good. So we're also looking at possibly doing another kind of hack fest near our main office in San Francisco sometime maybe this summer or later.
52:43
And we'll definitely be organizing some tech stuff at the Wikimedia Conference which is going to be in Buenos Aires, Argentina in August. Lots of crazy Wiki stuff, will be totally awesome. And the thing we need most is you.
53:03
So we just want to make sure that if there's something that you want in MediaWiki and it's not there yet, keep bugging us, don't forget, don't think that we've forgotten you, we're trying to get to everybody and we want to make sure that it happens. So keep it up, keep bugging us,
53:22
keep beeping me on IRC, that's what we want. And I don't think there's any time for, well we have one minute for questions. So if there's anything really good,
53:51
that is an excellent question. It's trying to write an offline reader and has the problem that the grammar for the markup sucks.
54:00
This is sad but true and hopefully we will find some way to improve that. It is a long-standing problem but definitely we are aware of it and there are a number of possible ways and we're going to make something happen on it, yes. And I guess that's about it. So thanks everybody for coming.
Recommendations
Series of 20 media