Developing The Wiki Way

Mark A. Hershberger

mah@nichework.com

Who am I?

A really great guy!

profile-in-philly.jpg

First – and only! – Bugmeister for WMF

(They've since changed the title to Bug Wrangler)

Former member of MediaWiki Release Team

Mark y Markus

MediaWiki Consultant

Co-Organiser of #mwstake

More on that from Chris.

What the heck is "the wiki way"?

It's a book! (how retro!)

The_Wiki_Way.jpg

Summary from Wikipedia: The book is about how to install/customize/manage wiki systems, followed by a perspective on the nature of wiki-style online communication.

That's not what I'm talking about, though

From https://meta.wikimedia.org/wiki/The_wiki_way:

make bad edits easy to correct

The WikiWiki way is to make bad edits easy to correct, rather than hard to make. It is the whole reason for creating a wiki in the first place, rather than a website (like most websites) where editing is only allowed by a handful of approved editors, and any changes desired by the larger public must be submitted as suggestions to, and then implemented by, those authorized editors.

Apply The Wiki Way to code (i)

  • SMW & MediaWiki are not perfect.
  • MediaWiki misses input for 3rd party use cases
  • SMW is built around 3rd party use cases, but may need a tweak to fit yours

Apply The Wiki Way to code (ii)

  • Be bold. If you see a problem in MediaWiki or SMW don't be afraid to offer your changes.
  • What MW and SMW are not. All the changes you want will not be appropriate.

– Sometimes you'll need to create an extension. (Ex: SMW, ConventionExtension)

Three scenarios

FATAL errors – everyone can agree on these

Persistence required – These can last for years, sometimes being resolved without anyone noticing.

You may have to solve it yourself.

BONUS: Cindy's feature

FATAL error

Friday, Jan 9, 2015 10:18pm

Fatal Error: Call to a member function disable() on a non-object

fatal-error-report.png

Code that caused this was last touched in 2004!

original commit to GlobalFunctions.php ancient-code-commit.png

Patch to fix is created the next business day

Monday, Jan 12, 2015 4:50pm fatal-fix.png

This is how bug-fixing should work

But rarely does…

Persistence required

Autogenerated XML schema

May 7, 2008

ancient-creation.png

January 31, 2010

stalled-bug.png

About 1.5 years

The bug is crushed and revived

June 25, 2014 – January 1, 2015

unnecessary-cruft.png

But a solution has already been given, in disguise.

Back in Oct 4, 2012

hidden-solution.png

January 5, 2015

recall-solution.png

Start to Finish

2434 days

You may have to solve it yourself

Even if the problem is in core

File a bug report.

file-a-bug-report.png

The bug may be questioned.

ie-problem.png

This can be a bit depressing, but don't give up.

You can try to solve it yourself.

You may find something you didn't expect!

Reframe your bug to better describe the problem.

refine.png

Find a solution.

If you've given more details, it may help someone else provide a solution if you don't know how.

Submit it.

solution-1.png

Refine it.

Give feedback quickly.

comments.png

They're working with you to solve the bug

It is in your interest to make it happen.

It may take more time than you expected.

Your bug is fixed

final-solution.png

Time to celebrate!

letsdothis.png

Cindy's issue

Resources

Reporting

  • Phabricator issues can take a long time to get resolved. Use me or an established developer to get your issue eyeballs.
  • How you frame is important, Make it a puzzle and someone will WANT to solve it.

Hacking

Issue: Fixing wiki bugs takes patience and thick skin.

URLs:

Thanks

Questions?

Created with Emacs, org-mode, and reveal.js