1

For those of you who don’t know me, hi! I’m Jack Phoenix , a MediaWiki developer since May 2008 (MediaWiki is the software that powers sites like Wikipedia, wikiHow, Wikia and many other wiki sites). wikiHow is sadly using a very outdated version of MediaWiki, MediaWiki 1.12, which was released around four years (!) ago. Thankfully wikiHow is open source and anyone interested in obtaining a copy of the source code, such as I, is free to do so. I’m not much of an article writer, but I still want to help out wikiHow whereever I can, and improving the software is something I can do. However, the source code dump page at src.wikihow.com states that wikiHow doesn’t accept patches to the code – regrettable, but understandable, given that the developers have plenty of things to do already, so they really can’t review and apply other people’s patches all the time. Inspired by this, a friend of mine and a fellow MediaWiki developer, Lewis Cawte, set up a Google Code project at http://code.google.com/p/wikihow/ . The goal of this project is to improve the wikiHow codebase, provide better international compatibility (so that starting a new wikiHow in a foreign language would be easier and they’d have more features readily available) and more! We’re hoping that in time we’d have enough contributors that we can get the codebase in a usable shape so that wikiHow could start using it instead of the current codebase, which is based on MediaWiki 1.12. I invite you to read my e-mail message to the MediaWiki developers’ mailing list and this quick info page on MediaWiki.org for further info on the project and how youcan help out. If you are a PHP programmer or you know one who’d be interested in working on the project, spread the word and help us out. Together we can make the wikiHow codebase even better! (And if it’s not totally obvious yet, this is not an official wikiHow project — this is just a project that two volunteer MediaWiki developers set up on their spare time because we want to help wikiHow out.)

2

I’ve heard of you, Jack. The fact is that the MediaWiki codebase is utterly stagnant. I’ve learned this from being around the Wikimedia Commons since 2005; it took years for us to be able to do even basic shit like renaming images. Try using " ~~~~" within a <gallery> tag even today , once again, years later after the New and Improved ™ parser code was written, that bug has not been fixed and nobody cares to fix it. The wikiHow codebase might be based on a “very outdated” version of MediaWiki, but it is far more actively developed than MediaWiki is. We’re actually adding features , all the time, while the MediaWiki folks can’t even fix bugs and take years to add basic functionality. Quite frankly, I’ll take a MediaWiki developer’s opinion about our “very outdated” code about two minutes after I take Harold Shipman’s medical advice.

3

Hi there - welcome to wikiHow! It’s great that you want to help out… any project which allows the international versions of the site to flourish puts a huge tick in my box… they’ve always lagged behind due to a lack of technical resources, and this has got to be a great step forward. I’d love to say my knowledge of PHP was good enough to help out, but unfortunately I’m just a bit of a hack-it-together person and I’d be a bit of a bull in the proverbial china shop if I even attempted to help! Oh yeah, and I’ll add that I have no idea about the state of MediaWiki code either… so my comments may be out of place, but I’d still prefer to keep a positive view on these things. I hope you are able to accomplish your goals and perhaps talk to wikiHow back office about the ultimate goal of streamlining the codebase… this is what community and open-source is truly about eh?:smiley:

4

Wouldn’t switching to a newer version of MediaWiki make us have to start customizing site features from scratch? If so, that would take a pretty long time - we have a lot of great features already, regardless of what platform the software runs on.

5

Kudos for starting this project, “Ashley” and Lcawte!:slight_smile:

6

It’s a slow process and the engineers have a lot on their hands. Upgrading requires a lot of merging with existing wikiHow code and ensuring all the custom features work properly. MediaWiki does have some newer functionality and security fixes since 1.12, but I think for the most part hand-merging all of these would not be efficient. That is for the engineers to decide – if there’s an issue it is usually promptly fixed, or a feature we need is implemented so there is hardly critical need for all the updates from original MediaWiki.

7

Well, kinda, but the whole idea of upgrading is that lots of new stuff has been added since then, and one version upgrades (so in future, 1.18 > 1.19) will require a lot less effort, and since we’re planning to fix up anything from the wikiHow dumps at the moment, and try and avoid core hacks, stuff should be very easy to fix up… and should reduce the amount of re-customizing needed… I don’t think that made sense, but I’ve only just woken up… and yes, ‘stuff’ is a technical term.

8

@Lewis Collard: I can see where you’re coming from, but despite that, your attitude still surprises me. Yes, image renaming feature was long overdue when it was finally implemented and category moving still isn’t supported (for example). Yes, again, there are plenty of open bugs. However, I think you’re assuming too much when you say that “nobody cares to fix it”. Just like everyone else, MediaWiki developers are also humans from different backgrounds. Some are paid full-time developers, whereas others (such as me) hack the codebase on our spare time. Due to the nature of the project, you can’t really boss people around and tell them “GO FIX BUG N RIGHT NOW OR ELSE”; this isn’t a paid, closed-source project and as such, it has its own, special flaws. You claim that the wikiHow codebase is far more actively developed than the codebase powering Wikipedia and most other MediaWiki-based sites out there. Care to throw some references into the discussion, too? I claim that the standard MediaWiki codebase is more actively developed than any other MediaWiki-based codebase there is, including wikiHow’s, due to its sheer popularity, thanks to Wikipedia and other Wikimedia Foundation projects. Here are some references: gerrit , the current code review tool for git-based things (since March 20, 2012), such as the MediaWiki core and extensions deployed on Wikimedia Foundation sites and CodeReview on MediaWiki.org , the old code review tool for SVN-based things. Please take a look at the number of (core) code commits per day and compare them to the amount of changes done to the wikiHow codebase during a week ; you can see a good, recent example on the wikiHow source code cleanup Google Code page . MediaWiki developers, just like wikiHow’s or Wikia’s or [insert your favorite third-party user of MediaWiki], are actively adding features and fixing bugs. Sometimes good features are reverted due to a variety of reasons, but most of the time they make it into the trunk and thus into the next official release. Most software developers, myself and Lcawte included, are trying to help youby keeping your data safe and secure; no-one can guarantee that you’re safe when you’re using an outdated version of the software which most likely has knownsecurity issues. So yes, I don’t really appreciate your Harold Shipman reference. @Busbyhead : Thank you! You don’t need to be a 1337 geek in order to help us out — you can also help with CSS and JavaScript, and of course, with actual testing and bug reporting!:slight_smile:This indeed is what open source is about: making wikiHow even better than it was today. @IShareMahKnowledgeWisely : The situation you described is pretty much exactly what we’re hoping to avoid by improving the code.:wink: @Tiagoroth : Thank you, I’m glad to see that you’re interested in the project! @SudoKing : You’ve been around here much longer than I (or Lcawte, or both of us!) so I trust that you know how things work around here. That being said, you don’t need to be a wikiHow employee to write articles for the site — and since the source code is open, we believe that you shouldn’t need to be a wikiHow employee to fix a bug or translate a feature to your mother tongue, either!

9

Yeah, I take that back. I did take exception to wikiHow’s codebase being called “old” when it is anything but, and I could have made that point much more effectively if I didn’t punch mainline MediaWiki in the face while doing so.

“Most likely” doesn’t inspire me with confidence that you have actually checked to see whether fixes for said security issues were integrated into the wikiHow codebase or not. If they were, then I don’t see why being on an old version of MediaWiki is an issue. If they weren’t , then I could see cause for concern. Incidentally, I’d actually like Jack and friends to accept patches. I’d even be willing to spend some of my time on it, too. But we have had this discussion before, and every time the answer is “we do not accept patches because We Do Not Accept Patches” and that seems to be that.

10

How so? If updating the code actually would require us to re-customize, then if we don’t update the code we merely keep our customizations and add new ones when necessary. Right?

11

Hi Jack, We are using an old version of Mediawiki, and we do in fact want to upgrade to the latest. One of the things Wikimedia Foundation (WMF) has done so well is to architect their software to scale and allow Wikipedia to become a top 10 website with what many would consider few resources. We love that aspect of the code at wikiHow and we’ve drafted off of it. That said, Wikipedia has dealt with a whole other class of scaling problems in newer versions of their code that are only future problems for us, because we’re so much smaller than them. This is part of the reason we have less impetus to move later versions. Another reason we haven’t been quick to upgrade is, as @Lewis Collard points out, Mediawiki’s newest versions of their software don’t have the same focus on new features as wikiHow’s does. Their focus in new updates is generally performance rather than new features. WMF has developed some awesome features in the past couple years, but many of these features were duplicated by us in our source in different ways, which would make the move to 1.18 even more complex. As an example of an amazing (and possibly revolutionary!) product they’ve been working on, we are very excited about their visual editor project. Although this particular product hasn’t hit beta yet, we plan to move forward our code base to the latest Mediawiki version once it’s stable and ready for production. We are also strained for engineering resources with many new project ideas, as @SudoKing and others note. We don’t have a clear roadmap of when to upgrade to Mediawiki 1.18 right now. We expect it to take a huge effort, but we recently discussed starting this project within the next 6 months. (This hopefully will coincide with the Mediawiki visual editor’s release.) As part of that upgrade, we want to make our previous changes to Mediawiki’s core classes more patch friendly by introducing more hooks that can easily be merged into future versions. Accepting patches from the community is something we’ve always wanted to do but simply don’t feel like we have the time for currently. As you may remember, it was even a big deal for us to create tarballs of our source from our repository weekly because of concerns over security. We are in fact moving to git internally and along with that we may even move to a system of code reviewing and patch accepting similar to how WMF operates. (As you noted, they use gerrit along with git so that external patches can be easily reviewed and merged into the source.) This system would be ideal, especially for enthusiastic community developers like yourself and @Lcawte . Even with a system like this, we’d still have to consider carefully before changing our policy to accept patches from outside, though, just because we have to expect it could take a significant amount of internal developer time or affect community dynamics. About the international aspect, @Jordansmall has worked to keep our code internationalized, and even recently upgraded aspects of our infrastructure for the primary international sites. It’s something that’s definitely on our radar. Internationalizing the code is definitely important, but we feel that it should be based on the needs of the international cliques within the community. wikiHow Engineering Team

12

@Jack Pheonix: I tried a while ago to allow wH to accept patches. As someone who programs PHP regularly and loves OSS software, being able to add to the backbone of wikiHow was something I had great interest in. You can read the relevant thread here . I would be interested in pitching in, but I’m very hesitant. I’ve talked to Krystle and Jack both privately and basically it comes to manpower. Unlike Wikipedia, wikiHow is a for-profit company. Their very life-blood comes from this site staying stable. I would hate to contribute code to a potentially very good replacement to wH, only to have it not be used. If Jack or Krystle can get behind this, at least experimentally, then I’ll jump on board. Perhaps they can set up a duplicated database on a new domain (e.g. beta.wikihow.com ).