User:Scimonster/Newcomer Essay

Remember when you were a MediaWiki newbie? If you've been on for a while, probably not. I'd like to remind you about some of the challenges that we face getting started.

Introduction

Right now I'm a Google Code-in 2013 student, and writing this essay as part of a task. I already did [one task for MediaWiki, and I will write about my experience in that task. I've also been using a MediaWiki-based wiki for a while now, so I'm familiar with the system, but have never done any programming. I'm also not quite comfortable with the new WYSIWYG editor, and prefer the wikicode manner. :)

Coding

I took a 120 hour (five day) task in the Code-in to add a feature. I spent a little while reading the core modification documentation, and then I spent around an hour hacking in the feature. It wasn't the nicest code, but it worked, which was the important part. I uploaded my stuff to the Code-in site. I was told I should upload it to Gerrit (more on that later). So I uploaded to Gerrit, we discussed it, someone else came to talk about it, I modified the code, and repeat.

The rather strict coding styles, while understandable, are not the most friendly. I can completely respect, and even support, text almost never being included directly, but rather through messages. A strict line-length or spacing policy doesn't sound the most fair though. I mean, as a recommendation, that's fine, but to cause a warning in the console seems a bit over-the-top to me. Especially to a GCI student, who may or may not have had much experience programming before, it could almost put you off. As it happens, I have had programming experience, and am usually also particular about spaces/tabs, but never about line-length. Perhaps as a compromise, it should be a recommendation, but don't bother new developers about it.

Gerrit

I'll give my review in a single sentence: I don't like Gerrit. I've found GitHub to be a much better code platform. I can seamlessly pull, push, and commit with GitHub, I get a nice web interface, and I can use my GIT GUI client. With Gerrit, I can't push my commits using git push, which means my GIT GUI shows me outstanding commits. I also need to append that ugly change ID to my commit message, instead of just forking and discussing within the pull request. I couldn't find an online code-browser, which I found I have rather come to rely on. If there actually is one, it's obviously not well documented.

Each program has its own ways and long-established practices, and I totally understand and respect that, but I would find it very helpful if there was better documentation for how to use Gerrit.

Code Classes

When working on this project I had my first interaction with PHP classes. I think it was a great idea on MediaWiki's part to use them, with one problem. I had absolutely no idea what class these objects were, or what methods and properties they had, or what they inherited from. This isn't entirely MediaWiki's fault; it's partly PHP's. After all, there was no Node.js (my new favorite server-side language) when MediaWiki got started. What can be improved on MediaWiki's side is, as usual, better documentation. The classes in the comment above each function are helpful, but it would also be nice to know what $this is, and what methods/properties are available. A message at the top of the document telling where documentation on the classes would have helped tremendously. Additionally, late into the re-re-reviewing of my code, my mentor discovered an undocumented global that would work better. How was I supposed to know about that if even an experienced MediaWiki developer didn't?

Community

Even if I couldn't always count on the code to tell me what I needed, it was nice that some other people chimed in to help out with my task on Gerrit. (Don't think that all of a sudden I'm endorsing Gerrit; a GitHub pull request works at least as well.) When I tried passing $this to a static function in order to access methods, I was told I should pass $this->getContext(). I didn't know what that was, but I took the advice of a senior MediaWiki programmer, and it came out well. They then told me exactly what the context was for, which was great. It's very good that the community was willing to help out.

Conclusion

Overall, I must say that I'm quite satisfied with MediaWiki and WikiMedia. They have a nice community and nice software, even if hacking "properly" could be made easier.