One of the more baffling things this issue was the humour section, which has either aged terribly or was always odd. Moving on, though, newswise, there's two things worth pulling out from this month. From "In the media":

Tajikistan Demands Wikipedia "correct spelling mistakes": The state language committee of Tajikistan has threatened legal action over spelling mistakes in the Tajik language Wikipedia; the committee "warns the errors violate the country's state-language law and therefore make Wikipedia legally liable for the mistakes." (Reported by Radio Free Europe/Radio Liberty)

There doesn't appear to be an update, but as the original source says, "It remains unclear whether or even how Tajik authorities could potentially take legal action against Wikipedia".

Secondly, there's a rather good interview with Kiwix creator Emmanuel Engelhart (aka "Kelson") was featured in this issue, but given readers might not be familiar with Kiwix, I think we'd be wise to take our sample from the "What Kiwix is" part of the interview:

As we noted in a 2014 profile of Kiwix, the software "uses all of Wikipedia's content through the Parsoid wiki parser to package articles into an open source .zim file that can be read by the special Kiwix browser. Since Kiwix was released in 2007, dozens of languages of Wikipedia have been made available as .zim files, as has other free content, such as Wikisource, Wiktionary and Wikivoyage."

In addition to Wikimedia content, Kiwix now contains TED talks, the Stack Exchange websites, all of Project Gutenberg, and many YouTube educational channels. Anne and Emmanuel chatted about how video and smart phones are changing the offline landscape—and where Kiwix plans to go from here.

In October 2012, we had a proposal for formalising crossovers between education and Wikipedia – failed, from what I can tell; the process to bring Wikivoyage into Wikimedia continued, and video support was massively upgraded. However, the 1 October issue had two huge stories I'd like to focus on, starting with an interview with Jimmy Wales about paid editing. Now, in my opinion, the inciting factor for the interview was overblown: A Wikipedian's company worked with Monmouth and Gibraltar to put up QR codes linking to Wikipedia pages for various landmarks, and was paid for it, which is... rather borderline.

However, Jimmy Wales sets out a clear distinction that helps explain how to judge what is and isn't acceptable. Here's a sample of the interview:

When was the first time paid editing came onto your radar? When you conceived of Wikipedia, did you ever imagine that editors would be financially compensated for their work, or that companies would employ people to influence articles?

From the beginning, it was something I thought we should pay attention to and prevent to the maximum extent possible. I remember the feeling of the Internet community – the appropriate cynicism – when Yahoo introduced a system whereby you could pay them for expedited review of your website for possible inclusion in their directory. Allegedly, such review would be neutral with no guarantees, but many people quite properly had doubts.

It was obvious even then that there are some people who are willing to act immorally.

You've been the most visible and strident promoter of the "bright line" rule prohibiting direct editing by paid editors. What influenced your thinking around this practice, and why do you think it is so important?

The "bright line" rule is simply that if you are a paid advocate, you should disclose your conflict of interest and never edit article space directly. You are free to enter into a dialogue with the community on talk pages, and to suggest edits or even complete new articles or versions of articles by posting them in your user space.

I've been an advocate of this because I think it makes a lot of complicated problems vanish completely. First, it avoids the sort of deep embarrassment and bad press for the client that has become common. Second, it answers the concerns that some people have about how to interact with Wikipedia as an advocate. It's almost impossible (assuming you behave in a polite manner) to get into trouble suggesting things on a talk page. And finally: it works. There are easy means to escalate issues if you are having a problem. There is simply no excuse for editing directly.

In my reading, WP:COI at least allows uncontroversial or minor changes, and at most permits any non-promotional edits, even major ones, although they are "strongly discouraged". From the 2009 paid editing RfC to the 2012 COI RfC, a direct prohibition of paid editing has failed to gain consensus. Yet you've described those who support or tolerate paid editing as an extreme minority. Do you agree that the bright line rule is not policy? If it's not, why do you think the community hasn't implemented it yet?

One of the biggest problems in this area is a lack of precision in talking about this. Even in your question, you say "paid editing" but that's much too broad and tends to confuse the issue quite badly. If a university decides to encourage their professors to edit Wikipedia as a public service as a part of their paid duties, that's a wonderful thing (so long as they steer clear of advocacy!). It's paid advocacy that we should be talking about.

I'm unaware of any serious arguments that we should welcome paid advocates into Wikipedia to edit articles about which they have a financial conflict of interest. (To be clear, there are a few people who argue in favor of that, but their arguments are so implausible that it is difficult to take them seriously.)

You've made a distinction between an employed academic versus a PR professional – the first editing in their free time in the area of their expertise and the second as a tainted advocate who shouldn't edit directly at all. Does 'advocacy' lie in the person (and their context) or only the person's behavior?

Both are relevant. If you're a PR professional editing on behalf of your client, then hiding behind the excuse that you're only making NPOV edits doesn't cut it with me at all. There's simply no reason to do that, when working with the community openly, honestly, and editing only talkpages is more effective.

Secondly, this was the start of the problematic phasing out of Toolserver in favour of Wikimedia Labs, as reported in our "Technology report" for 1 October:

The Toolserver is an external service hosting the hundreds of webpages and scripts (collectively known as "tools") that assist Wikimedia communities in dozens of mostly menial tasks. Few people think that it has been operating well recently; the problems, which include high database replication lag and periods of total downtime, have caused considerable disruption to the Toolserver's usual functions. Those functions are highly valued by many Wikimedia communities, comprising data reports on the relationships between pages, categories, images, and external links; support for Wiki Loves Monuments, OpenStreetMap and GLAM projects; talk-page archiving services; edit counters; and tools aimed at easing many automated administrative processes such as the account and unblock request processes on several major wikis, as well as cross-wiki abuse detection.

How did the Toolserver start?

It was originally set up in 2005 through the donation by Sun Microsystems of servers to Wikimedia Deutschland (WMDE); so it was almost by coincidence that the German chapter was prompted to take on responsibility for the project. WMDE has since invested heavily in Toolserver infrastructure and its operations—an unusually global role for a chapter, resulting from the particular nature of its revenue streams and German charity laws. There has been in-kind support from the Wikimedia Foundation, mostly in the form of database replication and space in its Amsterdam data centre (valued at US$65k a year), as well as financial grants to expand the hardware (example). Nevertheless, WMDE still makes up the bulk of the general budget of about €100k (US$130k); other chapters, such as Wikimedia UK, have also made smaller contributions.

Wikimedia Labs vs Toolserver: a comedy of errors?

In 2011, the Foundation announced the creation of Wikimedia Labs, a much better funded project that among other things aimed to mimic the Toolserver's functionality by mid-2013. At the same time, Erik Möller, the WMF's director of engineering, announced that the Foundation would no longer be supporting the Toolserver financially, but would continue to provide the same in-kind support as it had done previously.

DaB is the volunteer who administers the Toolserver, and who in the process has acquired unique expertise for running the system. (WMDE has also contracted Marlen Caemmerer to assist in Toolserver administration since October 2011.) DaB told the Signpost that there is a simple reason for the recent degradation in performance: the Toolserver's hardware was not added to in 2012, while more tools have been written and more people are using the tools. The German chapter, he says, has refused his request to extend the hardware infrastructure, giving only a vague commitment of support. But its September forward planning allocates just a fraction of last year's funding.

That said, our reporting was out of date even then. As documented on the Meta page Future of Toolserver, in September:

Erik (WMF) clarified that it's WMF's decision, on its end, to discontinue services to Toolserver at some point:

However, for our part, we will not continue to support the current arrangement (DB replication, hosting in our data-center, etc.) indefinitely. The timeline we've discussed with Wikimedia Germany is roughly as follows:

• Wind down new account creation on toolserver by Q2 of 2013 calendar year
• Decommission toolserver by December 2013

However, we did explain the disaster that inevitably did ensue in our report:

[...]Hersfold was closely involved in writing the "unblock ticket request system" (UTRS), which allows blocked users—including innocent parties caught up in range-blocks—to appeal their blocks. UTRS, created only recently and now officially mandated by the Foundation, is written for the Toolserver, not the Labs environment. Hersfold told the Signpost:

How Labs functions seems to be almost completely different from how the Toolserver functions. We've been told multiple times that Labs will provide lots of "beefy" infrastructure for tools development; ... users will be able to set up virtual machines, or "instances" ... to handle their development, and submit new programming code to a shared location. As one may expect from the Foundation, it's a very collaborative setup. Once inside their instance, a user can more-or-less do whatever they want; install MediaWiki, run a bot, set up web pages for tools, whatever. But most people on the Toolserver don't need "beefy"; we just need a web server that will let us run our tools and access the databases holding information about Wikipedia and the other projects. If someone needed "beefy," they'd have set up their own server ages ago. While Labs is all swishy and fancy (and presumably has less downtime than the Toolserver), it's an environment we're all completely unused to, and perhaps worst of all, it provides no access to the Wikimedia databases, which will prevent most tools and bots from working at all. Supposedly this functionality will be available at some point in the future [editor's note: planned for the first quarter of 2013] ... I don't think either organization fully realizes how much Wikipedia, the Commons, and all the other projects rely on the tools provided by the Toolserver ... [if it goes,] most of the tools and bots we take for granted will suddenly cease to function.

It was an awkward transition that would take years and a ridiculous amount of recoding to fully recover from. There's an entire page listing replacements, some of them without all the same functionality, that could be used after Toolserver's final shutdown in 2014. Here's a list of all the tools Toolserver had, several of which I believe never actually migrated.

October 2007 introduced WikiProject reports to The Signpost, a feature that, while less used nowadays (because no-one's been interested in writing it, and WikiProjects as a whole seem to be a lot less active, with a few major exceptions), would be a regular feature for most of the Signpost's run; we saw a WikiWorld comic that was since deleted, Wikimedia Commons reached two million files (it now has around eighty-six million). In sadder news, we reported on the death of historian Roy Rosenzweig, author of one of the first scholarly papers to study Wikipedia, and the death of Wikipedian Robert Braunwart from melanoma.

I think the "In the News" for 1 October best reflected that strange early period of Wikipedia:

Jimbo sparks deletion debate

Wikipedia wars erupt - Jimmy Wales created a one-sentence article about a popular gathering spot in South Africa, Mzoli's, which was originally speedily deleted and then taken to AfD. Some accused others of affording a God-like status to the Wikipedia co-founder, while Wales accused his detractors of bad faith. This incident has refocused attention on the debate between quality and quantity, and because the site has just reached the two-million article mark, the article notes that making an original contribution is harder. The debate between inclusionists and deletionists is framed as one between newer members of the project, and older members who understand that some of the deletions they have made are wrong.

...Whereas the "In the News" for 15 October showed just how much things stay the same:

Deletionists and inclusionists

Delete generation rips encyclopedia apart - The article presents the view that administrators are divided into deletionists and inclusionists, two diametrically opposed schools of thought about the inclusion of content into Wikipedia. The article reviews the deletionist and inclusionist arguments, and states that "notability debate has spread across the discussions like a rash". There is a focus on the deletion of stubs - in particular, the debate over Mzoli's - and how some Wikipedians have changed their ways, reflecting back on the "old times".