Archive for category wikimedia
Iframe bugs
The usability initiative recently deployed some changes to the beta features, most notably the replacement of the textarea on the edit page with a content-editable iframe (mistakenly referred to as a “rich text editor” by some users). Users at various wikis have reported some issues resulting from this change. We’re fixing these bugs as fast as we can and deploying fixes as soon as possible (once properly tested of course). Below is a list of bugs associated with the rich text editor and their status; we’ll keep this page up to date as we push out fixes. If you’re bothered by these bugs and don’t want to wait for fixes, you can turn off the iframe by leaving beta (click the “Leave Beta” link at the top of any wiki page).
Roan Kattouw (Catrope)
- bug 22311 (Pressing tab in edit box should go to summary box): fix deployed
- bug 22393 (Charinsert tools at the bottom of the edit page and old toolbar don’t work): fix deployed. Charinsert may have to be fixed in site JS on some wikis, depending on the local Charinsert implementation; this has been done on the English and Portuguese Wikipedias as well as Commons; I checked the other top 10 Wikipedias but they didn’t need a local fix. You may heve to Shift-Refresh for this to work on Commons.
- bug 22394 (Pasting formatted text preserves formatting): fix ready, needs more testing.
- bug 22398 (Extra line breaks inserted when pasting text)
- bug 22402 (Leaving beta doesn’t turn off experimental features like TOC and dialogs): fix deployed.
- bug 22413 (Old toolbar disappears when TOC enabled): inadvertently fixed when bug 22393 was fixed (love it when that happens)
- bug 22428 (Line breaks in pasted text not saved in Safari, Chrome): unconfirmed fix in SVN.
- bug 22435 (Literal and <p> in article text gets removed on save): fix deployed.
- bug 22440 (Random cursor jumps in Firefox on Ubuntu)
Wikimedia donates servers to deserving non-profits.
Posted by RobH in hardware, open-source, wikimedia on February 3rd, 2010
Every year, Wikipedia usage goes upward, and every year the technical folks working and volunteering with Wikimedia have to plan, purchase, and implement new servers to keep up to the growing popularity of Wikipedia and its sister projects. With the advances in computing, running 9 new application servers this year took the load of 36 application servers from 3 years ago.
So when we upgrade, what happens to the old equipment that is too slow for Wikipedia, but not too slow for MANY other non-profits? We donate them! These systems were 1U rackmount servers, dual cpu 2.5-3, single core, 2-4GB of RAM, and 2-4 HDD Bays with 1-2 80-250GB HDDs. This year, we have three non-profits who received our older systems (in alphabetical order): Drupal.org, OpenStreetMap Foundation, and Sugar Labs.
Drupal is a free software package that allows an individual or a community of users to easily publish, manage and organize a wide variety of content on a website. Tens of thousands of people and organizations are using Drupal to power scores of different web sites.
The OpenStreetMap Foundation is an international non-profit organisation supporting but not controlling the project. It is dedicated to encouraging the growth, development and distribution of free geospatial data and to providing geospatial data for anybody to use and share.
OpenStreetMap is an open initiative to create and provide free geographic data such as street maps to anyone who wants them.
The mission of Sugar Labs® is to produce, distribute, and support the use of the Sugar learning platform; it is a support base and gathering place for the community of educators and developers to create, extend, teach, and learn with the Sugar learning platform.
We hope the recipients of our servers will be able to put them to good use!
Below are some common questions involving Wikimedia and the server donation process:
Q. How can I get some of the decommissioned donation servers?
A. The best place to follow the goings on of our technical team is here, on the Wikimedia Technical Blog. When we have a batch of servers up for decommissioning and donation, we will announce it on the tech blog, and instructions on how to apply to receive some servers.
Q. Who is eligible to apply for servers?
A. We try to only donate servers to other non-profits whose core values are similar or in support of our own. This means we do not donate them for individual use. Since these servers were purchased with donations to support Wikimedia, we feel we need to further donate them to other like-minded organizations, since that is how the money for the servers was meant to be spent.
Q. How often does this happen?
A. Most servers are kept in use by Wikimedia beyond three years. Many of our servers that we have turned off in this batch are anywhere from 3 to 5 years old. We only replace them when it makes sense from the technical standpoint to do so. This means we cannot just say ‘we will do this every X months.’ We try to get the most use out of every server, as they were donated or purchased with donations. So there is no set date, just keep checking the Wikimedia Technical Blog, when we have more to donate, we will say so there!
Q. I am a student/person/so and so, and I want to learn to develop and do such and such. Can you send me a server?
A. Sorry, unfortunately it is just not realistic or fair of us to try to sort out which personal use requests for servers are legitimate and which are folks wanting computers for any other reason. We choose to limit our donations to other like minded non-profit organizations.
Rob Halsell
Systems Administrator
Bugzilla upgrade.
Posted by aZaFred in linux, open-source, wikimedia on January 18th, 2010
Thanks to Priyanka’s wonderful work in theming Bugzilla and ironing out the last couple bugs and extensions, we are finally ready to move on with the upgrade.
As a side effect, Bugzilla will be down for a couple of hours (let’s say 2 to be on the safe side) around lunch-time. (Edit Addition: 2010-01-19 between 20:00 GMT and 22:00 GMT)
Flagged Revisions: Your questions answered!
Posted by William Pietri in mediawiki, wikimedia on January 6th, 2010
There has been a lot of interest lately in Flagged Revisions, a quality control mechanism for MediaWiki. In particular, people want to know when and how that’s getting used on the English language Wikipedia.
I’m William Pietri, a San Francisco software consultant who recently came on part time to do project management for this. In addition to my long experience building web software for on-line communities, I’m also a Wikipedian. Although I haven’t done much more than small corrections lately, I started editing in 2004, and became an admin in 2007.
My job on this has two main parts. The first is to make sure that everybody working on this gets everything they need to make progress. The second is to communicate progress to the wider world. In the spirit of open communication, this is an update in question-and-answer form. Mostly from real questions people have actually asked me, but I’m going to sneak in a couple that I expect somebody will ask shortly.
What is Flagged Revisions?
You can find more detail here, but Flagged Revisions is basically a way to insert a quality review step between someone editing an article and that article version being published for the general public to see. It has been in use on the German Wikipedia since May 2008, and implemented in other languages and projects since then (see this page on Meta for a full list). Typically, in those use cases, every single article is treated in this way, and every change by a new user has to be reviewed. There are a number of ways Flagged Revs can be used, and the proposed implementation for English Wikipedia (described below) is quite different.
Fundamentally, the objective of this technology is to reduce the exposure of readers both to subtle and not-so-subtle malicious changes in articles (whether it’s the insertion of blatant nonsense, or claiming the death of a celebrity), and to reduce the workload of people patrolling these changes by reducing duplication of effort.
What about the English language Wikipedia?
The use of Flagged Revisions on the English Wikipedia has been under discussion for a long time. Ultimately, the English Wikipedia volunteer community developed a proposal titled “Flagged protection and patrolled revisions“, which garnered strong support. It is fundamentally different from the way the technology has been used so far. Instead of requiring every change by a new or untrusted user to be reviewed, the mechanism would be activated on a per-page basis only, as an alternative to existing tools to restrict editing.
Notably, thousands of articles in the English Wikipedia, typically pages with a very high risk of malicious editing (e.g. major political figures), are currently “semi-protected”, meaning that new or unregistered users cannot make any changes at all. This new tool would make it possible to open up these pages for editing, provided that potentially problematic changes receive positive review. As a result of the more open approach, more high-risk pages could be made subject to this level of community moderation.
Initially, the English Wikipedia volunteer community wants to trial the system for two months. In addition to this alternative to page protection, the proposal calls for implementation of a new feature called “patrolled revisions”, which doesn’t impact what readers see, but is designed to make it easier for change patrollers to organize their work.
How is the Wikimedia Foundation responding to this proposal?
The Wikimedia Foundation (WMF), together with Wikimedia Germany, has driven and funded the development of the FlaggedRevisions technology since 2007 to the point where it has been able to scale to more than a year of production use in our second-largest project, the German language Wikipedia. WMF has carefully reviewed the English Wikipedia proposal, and allocated resources to assess its impact and support implementation along the principles outlined in the proposal.
The technology as proposed markedly differs from the way it’s been used before, so it’s a substantial development and design effort to get it right. For example, the notion of a per-page setting necessitates an entire set of user interface changes that allow changing the setting of a page, and that make it clear to a reader what the state of a particular page is. See this mock-up by Howie Fung as an example of what revised per-page controls could look like. WMF will post further mock-ups for feedback and prototypes for testing as they are built.
Who is currently working on the project?
- Aaron Schulz, a contract developer with Wikimedia, is the lead developer of FlaggedRevisions.
- Howie Fung, a contract product manager who also works with Wikimedia’s Usability Initiative, is supporting usability and product review of the software.
- I, William Pietri, support the project management of the English Wikipedia roll-out as described above.
- Erik Zachte, Wikimedia’s Data Analyst, will develop metrics specifically assessing the impact of the English Wikipedia rollout.
When will it be done?
This question has been asked a lot lately. Because this isn’t the flipping of a switch but a software development project, answering it requires me to let you in on a secret about software development projects. There are basically four ways to deal with dates, but only three of them are sane:
- It’s done when it’s done. Nobody mentions dates. The developers code until they’re finished. Then you release, get feedback, and code some more.
- Measure progress and project dates. You lay out all the work, estimate relative size, and then measure how much you get done over time. That data is used to figure out release dates.
- Pick a date and release whatever you finish. If you’re building, say, annual tax return software, it’s better to ship on time and drop features than it is to finish late with everything.
- Make up dates to please people. This is very popular, and has the advantage of making people happy at first, but it rarely works out well.
Until recently, we were using the first approach. That’s how most Mediawiki development (and most other open source development) works, and it has many advantages. But because a lot of people are eager for this project to launch, we’re shifting to the second approach.
The developer, Aaron Schulz, has estimated all of the items on the work list and already started in on them. The holidays complicate things some, but I expect we’ll have enough data to make a first guess at the estimated release date by the middle of January.
Wait, there’s only one developer on this? Is the Wikimedia Foundation taking this seriously?
Yes, absolutely. Aaron has been working on the Flagged Revisions extension for years, and nobody knows it better. We talked about adding developers, but unfortunately adding more people now wouldn’t help. I haven’t dug into the history much, but it looks like the real slowdown lately wasn’t in the coding; it was in turning the many-voiced community response into a clear set of things to do.
Having spent time with all the people involved, it’s clear to me that the Foundation takes this project very seriously. It’s one of small number of high-priority projects, which include things like keeping the site running, organizing the annual fundraiser, and Wikimedia’s usability initiative.
How can I keep track?
There are a few ways. First, we’ll mention big updates (and the eventual release) here on this blog. Second, keep an eye on the labs site. That will be updated regularly with the latest code and configs. You can judge for yourself how we’re doing, and make sure we do it right. And third, I’ve put the work queue into a public web-based tool called Pivotal Tracker. It’s one of the few software project management tools made for the measure-and-project approach we’re using; if you’re the sort of person who likes way too much detail, you can find real-time updates there.
How can I get involved?
Go to the labs site, play with the current implementation, give feedback, post your own user interface design suggestions, report bugs, and so forth. Further community discussion in the English Wikipedia about the proposed roll-out is happening on the page about flagged protection and patrolled revisions. I’m always glad to hear feedback, either on my talk page or via email. And of course, you can comment on this very blog post.
William Pietri
Contractor, Wikimedia Foundation
Priyanka Dhanda joins Wikimedia tech team
I’m very pleased to welcome Priyanka Dhanda to the Wikimedia Foundation as Code Maintenance Engineer. Priyanka joins us from SourceForge Inc., where she worked since 2002 as a software developer and also was involved in operations, working on most pieces of the infrastructure, and integrating third party software with the SourceForge platform (including MediaWiki). Priyanka holds a Master’s Degree in Computer Science from the University of Toledo, Ohio, and a Bachelor of Technology in Computer Science and Engineering from the Pondicherry Engineering College in India.
She is starting today and will work in the San Francisco office.
Priyanka will be a key interface between software developers and the operations team, helping us to catch up with our code and bug review backlog, to mentor new developers, to push projects to completion, and to improve testing and automation. Please don’t swamp her immediately with requests as she’ll need some time to get more deeply oriented in the MediaWiki codebase. :-) You’ll be seeing her in the IRC channels, on SVN, Code Review, BugZilla, wikitech-l, and so forth.
Please join me in welcoming Priyanka to the Wikimedia team! :-)
– Erik Moeller
Deputy Director, Wikimedia Foundation
LiquidThreads almost ready to deploy
Hi all,
With the Foundation’s support, I’ve spent the last few months churning away at LiquidThreads, a new discussion system that is proposed for use on Wikimedia projects.
Essentially, it’s an attempt to marry the radical openness of the wiki paradigm with the usability and practicality of a forum-like system. As the name implies, LiquidThreads is designed to allow any user to easily refactor discussions while maintaining edit history, to edit other users’ comments, and to collaborate on a summary of an ongoing discussion. LiquidThreads also brings many standard communication features lacking from wiki discussion pages, such as watching and protecting individual discussion threads, RSS feeds of comments in a discussion or on a discussion page. In the world of online communication, its approach is entirely unique.
LiquidThreads has been in alpha testing on Wikimedia Labs for several months, and, more recently, it’s been used in a production context on the strategy wiki, where it has been quite well-received. It’s been easy to run these smaller trials, as the extension allows the activation and deactivation of LiquidThreads discussions on individual pages with a simple parser function.
While there are still some issues remaining before wider trials, I believe I can resolve most of them quite quickly (within a few weeks when my vacation finishes at the end of next month), and I’d like to get the ball rolling in proposing small-scale trials on some of the larger wikis, so that a full discussion can be had, and so that adjustments can be made on the basis of ongoing feedback. I’d especially like to see LiquidThreads used on some of the higher-traffic discussion pages on English Wikipedia (such as the technical village pump), and progressive rollout on some of our mid to large sized wikis.
So, I’d like to encourage you to have a play with LiquidThreads, either on the strategy wiki or on the test site (which generally runs a newer version). Tell me what you like about it, and (far more importantly) what improvements you think it needs before we can expand our trials to wider parts of the Wikimedia Universe, and perhaps move towards a full rollout of this very exciting technology.
I should give the following caveats about LiquidThreads as it stands. These are all issues that I intend to address before any trial expansion occurs.
- Presently the system is somewhat vulnerable to abuse. I intend to make changes to the way signatures work, and improve tracking and listing of thread actions by specific users.
- While LiquidThreads allows for thread summaries and discussion headers, the system does not currently have support for collaboratively-edited posts which are unsigned or signed by a group of people. These are a key piece of any decision-making framework, and I intend to make adjustments to make this possible.
- There is no support for embedding LiquidThreads discussion pages on other pages.
- There are plenty of minor interface issues which I intend to clean up.
Feedback is best directed to the dedicated feedback page, or, alternatively, to bugzilla (although before filing a bug, you should check the list of existing LiquidThreads bugs).
Thanks,
Andrew Garrett
Software Development Contractor
Fun with Subtitles
Posted by Michael Dale in wikimedia on November 9th, 2009
You can select your subtitle language
We have just finished up the Multimedia Usability Project Meeting here in France. I am sure there will be more general wrap up coverage of the meeting shortly… but I wanted to share a hack we worked here.
For a long time people have requested subtitle support for mediaWiki embed videos and at this meeting we were finally able to sit down and hack up an initial solution. The system works by putting the srt files into the wiki so people can collaborate on translation and contribution. The naming scheme is “TimedText” followed by the file name followed by the language code followed by .srt . We include a basic editor to upload srt files and switch between between languages. We presently display the subtitles on the side of the video but they should make there way below the video soon. There are lots of supporting projects to work on if anyone is interested ;)
How do I try it out
To try it out install the mwEmbed gadget and then visit either video linked to in this post. Hopefully we can produce some more documentation soon :)
Some quick ideas for enhancements ( I am sure you can think of some too) :
- A translation interface maybe borrowing from the techniques used on translatewiki.net
- A simple search of subtitles from the current video
- A more complex search system for subtitles across all videos
- Timed metadata a-la-metavid
subtitles on commons using the mwEmbed gadget
Localization Update: As mentioned in the comments we are still missing some of the localizations msgs. They should be making their way in there soon, along with some other updates.
Usability Beta Enhancements
New watch/unwatch and cascading tabs
Thanks for trying out the usability beta. Close to 280,000 people tried out the usability beta and about 220,000 people continue using it. One of the most-frequently reported frustration about the beta was that (1) watch/unwatch was hidden under the drop-down menu and (2) tabs overlaps when the browser is scaled down or the resolution is low. Tab issues were more significant for language communities whose words tend to be long such as German. We are also simplifying the search box to simplify the interface and in order to minimize the overlapping side-effect. Those new features are currently staged on the prototype wikis in English, German, Japanese, Arabic, Serbian, Russian, and Sinhala. You need to log-in in order to see watch/unwatch tabs. The screenshot on the right is the shot when the browser window is scaled down to 640×480. “View History” is moved to drop down menu in order to keep “Read” and “Edit” tabs visible. Let us know your feedback here.
- Naoko
Update on November 18th: Thank you for your support and feedback. These features are now available in the usability beta across all Wikimedia projects.
New Media Features Gadget
Posted by Michael Dale in wikimedia on October 10th, 2009
I would like to announce that some of the new media features are now available in gadget form on Wikimedia Commons and the English Wikipedia. These include a new ogg player, the add media wizard, and firefogg upload support. I hope having these components in gadget form will enable some more testing and feedback :)
Getting Started to enable these components you must turn on the mwEmbed gadget. You can turn it on by visiting your preferences page. Once you enable the gadget you should shift reload to ensure you have a fresh copy of the JavaScript. (note you will need to enable the gadget for each wiki you want to test (ie both for wikimedia commons and Wikipedia). Once enabled you can check out the following features: Read the rest of this entry »
Click Tracking on Edit Toolbar deployed
After many a hearty SQL battle, we finally have click tracking deployed on the wikimedia projects!
Data on button usage
What’s being tracked?
Which buttons are clicked on the toolbar during editing
What information is being recorded?
The button clicked, the time of the click, total edit count of the user clicking, and edit count for the last 1, 3, 6 months
What information is NOT being recorded?
Individually identifiable information of any sort (eg who exactly clicked what) and anything that would violate our privacy policy in general
Why?
As we revamp the UI, rather than randomly throwing buttons up there we think are pretty (we think they’re all pretty), we thought we’d put buttons up and features that people actually use. Novel, right?
What about the edit history and stuff?
We figure the way a novice editor uses the toolbar is different form a ‘power’ editor, and that there’s probably some gradation in between. Is there? Well, that’s what we hope to find out…
–Nimish
Image renaming fix
Fixed an ugly internal caching bug which could break renamed image redirects on Commons being accesses from other non-English sites. Hopefully that’s most of those solved now. :)
SVG Open
Posted by brion in open-source, wikimedia on October 2nd, 2009
I’m hanging out down in Mountain View for the SVG Open conference this weekend, to speak a bit on how we use and plan to use SVG at Wikimedia and to get up to date on the state of the art. I’ll post my full talk slides on Sunday after my talk…
One of the most exciting new developments in the SVG world right now is svgweb, a very cool tool which brings high-quality SVG rendering support — including full support for the SVG DOM and interactivity — to any browser that supports Flash. This essentially fills the “SVG gap” for most Internet Explorer users, which opens up a huge world of possibilities for both interactive content and tools for building, editing, and localizing SVG-based diagrams, charts, maps, etc right in the browser.
Google web standards evangelist Brad Neuberg gave a great talk about the background of how something like svgweb was needed and showed some great demos, including a quick preview of an inline SVG pan-and-zoom tool for Wikipedia / Wikimedia Commons; we’ll have some even funner demos based on that Sunday!
Also saw a good talk from Sam Ruby on some of the gotchas in the current state of HTML vs XHTML vs HTML5 and how SVG is (or isn’t) supported in various profiles and various browsers. Most interesting was his proposal to rethink how we deal with markup validators in the webdev world — right now most validators give you a lot of errors about things that don’t really make a difference (font vs style?), but freely ignore problematic but “legitimate” structures (say, unclosed list items).
MediaWiki’s new discussion system in testing on Wikimedia Labs
Posted by andrew in mediawiki, software, summer of code, wikimedia on October 1st, 2009
I’m very excited to announce that LiquidThreads, the next-generation discussion system that I’ve spent the last few months developing for the Wikimedia Foundation, is now in beta testing on liquidthreads.labs.wikimedia.org.
Sample of the LiquidThreads interface
Wikimedia XML data sets released on Amazon Public Data Sets
For our community members that do analysis on Wikimedia project data, I’m happy to announce the release of our XML snapshots within Amazon Public Data Sets.
http://aws.typepad.com/aws/2009/09/new-public-data-set-wikipedia-xml-data.html
To those curious about why this happened … earlier this year I had gotten approached multiple times from researchers and community members wanting to parse our data but frustrated at the costs and time of doing it on their own infrastructure.
Many of them were already familiar with academic computational clusters and were wondering if there were any similar solutions available for them to do large scale processing. The tool sever was one option but sometimes it didn’t provide the level of flexibility that they needed and/or their projects were too computationally intensive to run alongside other tasks.
Instead I mentioned that I had already been thinking of pushing our data sets in the Amazon cloud as they had a wealth of the infrastructure in place and had an infrastructure that our users who were familiar with.
Fast forward to now, we have our first release ready to be worked on and I’m sure that we will hear back about new and exiting discoveries that our communities make.
This isn’t the first Wikipedia data set to exist in Public Data Sets but it will be the first that Wikimedia is committing to supporting on a regular release cycle. Amazon will be picking it up every month and retaining copies for at least three months.
I’m excited to see the stats of how many people use it.
–tomasz
Supporting translatewiki.net
Translatewiki.net is a core part of the MediaWiki ecosystem. While not a Wikimedia Foundation project, it’s used by hundreds of volunteers to improve the localization of MediaWiki and its extensions, alongside other open source projects, which has led to MediaWiki being one of the most internationalized software packages available.
We’re very pleased to be able to recognize the incredible volunteer efforts behind translatewiki.net at least in a small way. Starting tomorrow, Siebrand Mazeland will be able to devote one day a week to the support of the project on a contract with the Wikimedia Foundation. We’ve identified core priorities for the next year as an increase in the number of volunteer developers supporting the translatewiki.net infrastructure, and the number of volunteer translators working on localization for the most widely spoken languages.
Welcome, Siebrand, and a big thank you to the entire translatewiki.net community for their work. :-)
Erik Moeller
Deputy Director, Wikimedia Foundation
Announce: Brion moving to StatusNet
I’d like to share some exciting news with you all… After four awesome years working for the Wikimedia Foundation full-time, next month I’m going to be starting a new position at StatusNet, leading development on the open-source microblogging system which powers identi.ca and other sites.
I’ve been contributing to StatusNet (formerly Laconica) as a user, bug reporter, and patch submitter since 2008, and I’m really excited at the opportunity to get more involved in the project at this key time as we gear up for a 1.0 release, hosted services, and support offerings.
StatusNet was born in the same free-culture and free-software community that brought me to Wikipedia; many of you probably already know founder Evan Prodromou from his longtime work in the wiki community, launching the awesome Wikitravel and helping out with MediaWiki development on various fronts. The “big idea” driving StatusNet is rebalancing power in the modern social web — pushing data portability and open protocols to protect your autonomy from siloed proprietary services… People need the ability to control their own presence on the web instead of hoping Facebook or Twitter always treat you the way you want.
This does unfortunately mean that I’ll have less time for MediaWiki as I’ll be leaving my position as Wikimedia CTO sooner than originally anticipated, but that doesn’t mean I’m leaving the Wikimedia community or MediaWiki development!
Just as I was in the MediaWiki development community before Wikimedia hired me, you’ll all see me in the same IRC channels and on the same mailing lists… I know this is also a busy time with our fundraiser coming up and lots of cool ongoing developments, so to help ease the transition I’ve worked out a commitment to come into the WMF office one day a week through the end of December to make sure all our tech staff has a chance to pick my brain as we smooth out the code review processes and make sure things are as well documented as I like to think they are. ;)
We’ve got a great tech team here at Wikimedia, and we’ve done so much with so little over the last few years. A lot of really good work is going on now, modernizing both our infrastructure and our user interface… I have every confidence that Wikipedia and friends will continue to thrive!
I’ll start full-time at StatusNet on October 12. My key priorities until then are getting some of our key software rollouts going, supporting the Usability Initiative’s next scheduled update and getting a useful but minimally-disruptive Flagged Revisions configuration going on English Wikipedia. I’m also hoping to make further improvements to our code review process, based on my experience with our recent big updates as well as the git-based workflow we’re using at StatusNet — I’ve got a lot of great ideas for improving the CodeReview extension…
Erik Moeller will be the primary point of contact for WMF tech management issues starting October 12, until the new CTO is hired. I’ll support the hiring process as much as I can, and we’re hoping to have a candidate in the door by the end of the year.
– brion vibber (brion @ wikimedia.org)
CTO, Wikimedia Foundation
San Francisco
Update: Evan’s announce is up on the StatusNet blog.
Theora 1.1 Released
Posted by Michael Dale in wikimedia on September 28th, 2009
Theora 1.1 has been released
Theora 1.1 has been released. This release reflects the efforts of xiph.org developers who over the past year have done incredible work to greatly improve the core free codec video library. This effort has been support by Mozilla Foundation, Red Hat and others. These improvements include:
Chris Blizzard from Mozilla has a detailed blog post about the improvements and what they mean for open video creators, distributors and viewers. Wikimedia foundation makes exclusive use free/open formats and has been a long time supporter of ogg theora and makes use of the free codec in its websites. Wikimedia also helped organize some improvements by administrating a theora improvement grant from Mozilla earlier this year.
Also a new version of ffmpeg2thora has been released using this new codebase making it easy to take advantage of these new features. If you would like to give the new encoder a spin you try it out with the web based firefogg encoding app.
Server Donation Entry Period Ending
Just to let folks know, we have had quite a large interest in our donation of some of our decommissioned servers. In fact, I have way too many emails!
So to be fair, rather than just stop today, we will stop accepting submissions for this next Monday, September 28th. That means if you want your proposal/request in the running, you have to have it emailed to servers@wikimedia.org by Midnight GMT this coming Sunday, Sept. 27th.
For ease of reference, here is a copy of the post from the start of this process:
It is that time again. We have approx 35 servers to donate to a good home. These are servers that Wikimedia has used on the projects for 3+ years, so they are out of warranty and just not fast enough for us to keep using on the cluster.
The servers will go out to homes for folks who are willing to pay for the freight. They are as follows:
- Dual CPU 2.5 GHz AMD
- 3-4GB RAM Each
- Most have 80 GB or larger HDD
Disclaimers: The Wikimedia Foundation does not guarantee the operation or use of these servers in any shape or form. They are old, some may have dying fans, bad hdd sectors, and the like. Servers have been wiped of information, and they ran through that, but no promises on function!
If you would like to receive some of these servers for your NONPROFIT use, please email servers@wikimedia.org. Please include in your email how you will be using the servers, and the address they would be shipped to. We will review all requests and try to fairly pick out where they go. (Selection process may be refined, but it also may just include throwing darts at a board to break up ties.)
Additions: Due to request, the servers are indeed located in Tampa, FL USA. Zip code 33602 for shipping purposes. This means that if you are international, shipping this hardware is really not cost effective for you. If you want to be in the running still, and are comfortable with personally handing all customs, duties, export, and tax issues, go ahead and email us.
Correction: Dates were off.
Feature deployment updates
Quick note for those who have been asking — we’re starting to maintain a list of feature & extension deployments that we’re rolling out in the very near future and their status on the Wikitech wiki.
Note that some things like the English Wikipedia FlaggedRevs deployment aren’t on there yet; we’ll start prepping something for these in the next round in a couple weeks.
– brion
Help us make Commons work better
It’s come to my attention that Commons has had some more problems than we saw on the other wikis… I want to make sure we get that cleaned up!
Andrew has just deployed some more fixes which should eliminate the ‘file already exists on Commons’ bug. It would be a huge help if folks who’ve been reporting problems can go through the lists on the Village Pump and collect just the problems that are still current:
- Uploads via Commonist — fixed or do we still have problems?
- (Who’s the best person to contact about debugging or developing fixes for Commonist?)
- Missing description page immediately after edit — is this still happening?
- Anything else?
Please add info about confirmed problems or fixes at the Commons Village Pump. Thanks to everybody — your feedback is important; we need to know which bugs are affecting you guys the most!
– brion
Update 2009-09-22 23:49 UTC: I’ve fixed the problem with Commonist by relaxing the edit token check in the form handler (this is safe for uploads via the web, which can’t be injected in a CSRF attack; we still enforce it for upload-by-URL). This probably fixes most of the other client-side upload tools and bots as well — please test!
Babaco Preview
Screenshot of Navigable Table of Contents
As brion’s earlier post stated, the new set of usability features (nickname: Babaco)are integrate into the source code but disabled until these features are stable. New features include, navigable table of contents and content generation dialogues for links, tables, search and replace. These features are currently staged on the usability prototype environment, and you are welcome to check them out and encouraged to push them hard to find bugs. :-)
We are also hoping to integrate add-media-wizard created by Michael Dale in Babaco. While API to extend the toolbar is being worked on, media import functionality can be played at the usability sandbox environment. Click the “Edit” tab and click an image gallery icon in the toolbar. You will see a nice media import function there. Feel free to create an article and import image from Commons using this neat feature.
Browser compatibility matrix for Babaco is found here. As always, share your thoughts and experience through the usability wiki. Feedback on Babaco goes this discussion page.
- Naoko
Server Donation Time Again!
It is that time again. We have approx 35 servers to donate to a good home. These are servers that Wikimedia has used on the projects for 3+ years, so they are out of warranty and just not fast enough for us to keep using on the cluster.
The servers will go out to homes for folks who are willing to pay for the freight. They are as follows:
- Dual CPU 2.5 GHz AMD
- 3-4GB RAM Each
- Most have 80 GB or larger HDD
Disclaimers: The Wikimedia Foundation does not guarantee the operation or use of these servers in any shape or form. They are old, some may have dying fans, bad hdd sectors, and the like. Servers have been wiped of information, and they ran through that, but no promises on function!
If you would like to receive some of these servers for your NONPROFIT use, please email servers@wikimedia.org. Please include in your email how you will be using the servers, and the address they would be shipped to. We will review all requests and try to fairly pick out where they go. (Selection process may be refined, but it also may just include throwing darts at a board to break up ties.)
Additions: Due to request, the servers are indeed located in Tampa, FL USA. Zip code 33602 for shipping purposes.
… few hundred megabits at a time
Posted by Domas Mituzas in wikimedia on August 28th, 2009
We’re sitting here in Wikimania Underground, where our “hacking days” at Buenos Aires happen. Seeing each other face to face can allow us to discuss much faster how we should approach some of possible changes, that could make the site faster for everyone.
We eliminated quite a few web response headers (which cannot be compressed, due to how HTTP works), especially some of large ones we are using inside the cluster to achieve better caching, or debugging information – causing few hundred megabit savings (it is difficult to know exact numbers, due to the nature of caching).
Also, we’re experimenting with trade offs in content compression – by choosing more expensive compression methods, we decrease size of transmitted pages by up to 15%, though doubling compression costs on our side. We still think that we may end up doing different levels of compression for different types of content (something what will be efficiently cached from anonymous users will have way higher relative wins).
Of course, we will have reduced bandwidth bills, probably more than the additional hardware to cover the change would cost us in resources.
Presentations from Wikimania and More
Many folks do not know, but we actually try to upload and make available all our presentations. Presently, you can see a list of them on our Wikitech wiki. You can follow this link to see them all.
Keep checking back, because the conference isn’t finished!!
Wikimania talk videos
Yesterday’s tech talks from Wikimania are online at our temporary video file staging location (Ogg Theora format). They should appear on Commons soon. :)
Update: Some of the movies have encoding problems; reencoded versions should be reposted within a couple days. Sorry!