Think for a moment about all the tools and features you can use on Wikia to create and share content. There are editors, chat rooms, forums, photo galleries, categories, talk pages, and article comments, just for starters. To make this all work, a lot of code of many varieties - PHP, JavaScript, AJAX, HTML, and MySQL - is worked on every day by our engineers.
Unfortunately, coding is a difficult task. Sometimes, even simple things can have large consequences. I can’t tell you how many times I’ve forgotten to add a single comma or semi-colon to a piece of code I was writing, and then have to confusedly spend time trying to figure out why my code wasn’t working right. Other times, users ask a feature to do something we didn’t think about. For example, the other day a user let me know that if they put Tabber (<tabber>) code inside Tabview (<tabview>) code, the Tabber feature stopped working. This simply something we never anticipated someone trying, so the code failed.
Finding & Fixing Bugs[]
Whenever a piece of software produces an incorrect result or behaves in an unexpected way, that is called a “bug”. Unfortunately, Wikia is not immune to software bugs. I want to talk to you today about how Wikia reacts when we spot a bug and a recent way Wikia pulled together to “patch” (to fix a bug) as many bugs as possible.
A look inside Wikia's bug reporting system.
Maintaining a healthy balance between developing new features and fixing existing bugs can be tough. While Wikia genuinely strives to patch every bug we document, the simple demands of having a large, agile technical operation honestly means that some bugs take longer to get to than others. To help us identify and patch major bugs faster, Wikia uses a priority system to rank bugs in order of their severity, type of impact (is it blocking functionality or is it simply a nuisance?), scale (number of users affected), and types of users affected (editors versus anonymous, admins versus chat moderator).
As such, Wikia schedules time every few months to focus solely on the backlog of bugs. Product development stops for a two-week span and all of our engineers are freed up to work on as many bugs as they possibly can within that time. We call this bug-fighting effort a “Quality Blitz”.
Our most recent Quality Blitz occurred when we came back from the Holidays and wrapped up last week. During this particular Blitz, our engineers decided to split up into five teams and address a specific set of product bugs per team. In total, our engineers addressed and resolved 154 bugs!
Statistics may be nice, especially 154 squashed bugs, but you may be asking what actually goes into fixing a bug? Let's look at one particular bug that was addressed during the Quality Blitz, start to finish, to illustrate generally how a bug gets fixed by our engineering team.
Inside Look at Bug Investigations[]
Late last fall, one of our users wrote into Special:Contact to let us know about unexpected behavior in their wiki navigation. When adding the text “Places” to their MediaWiki:Wiki-navigation page, the saved text was rendered as “Places on this wiki”. My colleague Bert tested this with the user for a time, confirmed and took a screenshot of the problem, and filed a bug ticket with our engineering staff.
Bert uploaded this screenshot into the navigation bug ticket. Screenshots are a helpful way to illustrate what a bug looks like.
Another one of our Community Support members, Kirkburn, was able to determine the navigation issue occurred because an extension on Wikia has a system message called “MediaWiki:Places” and the Navigation tool automatically converted any system message page name into the value of the system message.
Our engineering team eventually determined there were three options - add logic to the wiki navigation code to handle the specific case of the Places extension, change the system message name in the Places extension, or change how the Navigation feature converted the MediaWiki:Wiki-navigation message into navigation text. While the third option required the most work, it was deemed to make the most sense over the long-term, so it was added to the Quality Blitz list. The team decided the best way to implement the fix was to make only the “On The Wiki” tab convert system messages, and remove the conversion method from the other navigation tabs.
One of our engineers, Damian, picked up the ticket and made the necessary code changes, checking each step of the change on a testing environment called a "devbox". Then he committed the code change to our open source code repository. Finally, the ticket was marked as fixed and went back to the bug reporter (Bert, in this case) for confirmation and ticket closure.
So that is an inside look at how a bug fix works on Wikia. I know some of that may have been a little technical, but hopefully this illustrates the amount of testing, collaboration, and teamwork Wikia Staff brings to improving our code quality. Imagine applying all of that conversation and work 154 times over in two weeks, and you can see we definitely kept busy this January.
Quality Blitz Fixes[]
Here are some of the other bugs we addressed during our latest Quality Blitz:
- The “Are you sure you want to leave...” warning was appearing when you tried to leave an edit page, regardless of whether or not you had made any edits. Now, the message only appears if you have actually changed something on the page.
- The “view source” screen on pages that users did not have permission to edit or create was not displaying helpful permission messages.
- The "minor edit" checkbox was appearing when creating a new page. Conversely, blog post edits could not be marked as minor.
- Tab ordering when on an edit page should make more sense now. Tabbing from the editor moves to the summary field then minor edit button then preview and publish.
- Usernames with , (comma) in them could not send/receive private messages in Chat.
You can always see what bugs are processed on a weekly basis by reading and following our Technical Updates blog. Also, Wikia can’t fix bugs if you don’t report them. As always, the best quality assurance group is our user base, a few million extra eyes around the site.
Thanks as always for your patience as Wikia strives to give you the best of both worlds: A high-quality, high-functioning site, and a site with unique and new features that push your community forward.
Click here to follow the Fandom staff blog.
Click here to sign up for the From the Desk of Community email newsletter.
Join our Official Discord server for registered editors!