Editing wikis for developers

Many times as a developer and/or as a WMF employee, you might want to (or have to) make a (technical) change to one of the many wiki's that are out there. You are sure you know what you are doing, but is it appropriate for you to make the change ? This is a guide that might help you make that decision.

It's a community

If the community can trust you to not make mistakes, they generally accept your edits. Learn and build trust by:

1. Discussing problems on talk pages or a relevant forum page. Propose a solution before executing a solution.
2. If there is positive response or no response at all, make the change, or request that it is made by a community member/sysop.
3. Leave an edit summary, it's like a commit message.
4. Keep checking in for a few days to verify if there has been any fallout. Don’t disappear, if you are making edits to the wiki, you are part of the wiki.
5. Remember each wiki is a community in itself, with it's own rules, where you need to gain trust all over again.

Helpful tips

Be bold

Don't endlessly wait for the community to answer your suggestion/request. Just change the wiki, it's a wiki after all, edits can be rolled back.

Do not charge into the china shop

Big changes with big words and big effects will cause turmoil. It's a guarantee. Bold is good, a bull in a china shop is bad.

Be open for feedback

A line like: "If you have any questions about this change, please contact me on my Talk page" can do wonders.

Wiki code is not MediaWiki PHP or JS

There are conventions and methodologies in templates, Lua modules and MediaWiki namespace, which can be quite unfamiliar to MediaWiki developers or WMF employees. The more matured wiki's have very strict community rules on their templates regarding; setup, structure and usage. Use the talk page or forums.

Sandboxes and testcases

Most important templates on the bigger wiki's have sandboxes and testcases. Use them.

Temporary workarounds

Please add a comment with the phabricator ticket number, or at least give a descriptive comment, and very important, note the time by which the workaround can be reverted. (remove by 2016-01-15)

Code is content

If your code affects the presentation of community authored content, then it is part of the content. People spend a huge amount of time not only writing, but also dealing with presentation. Positioning, styling etc are all a part of this and if you change it, you have changed 'the creative work' of editors. You therefore should be considerate.

Code is workflow/process

Outside of the content namespace are the places where people work. From the UI of the site, to the discussion pages, the templates, or the forums. There is often hidden structure in place for both humans and bots to make everything work. What you might see as a 'hack' or a mistake can be the result of a 10 year long evolution from a missing piece in the software to a process that gives the editors just enough functionality to get their work done.

Emergencies

Be clear about the fact that it is an emergency. Make clear what it is about or when you can share what it is about. Make clear that you are doing it in your official capacity as an employee, operations engineer or senior developer. Link to a ticket, procedure or feedback location if possible.

You have no authority

Authority in a community is earned. You have no authority by default. As a WMF employee to most people you are at most an authority figure. As a developer you might have authority in a different field, but it does not count. Neither do PhD's. It's the wiki way.

You are the expert

Working on the software or for the WMF, the communities will expect you to know how a wiki community operates. You don't get the luxury of messing up the first times you interact with wiki communities, because you are 'representing' these organizations, who are expected to know. Ask your colleagues for assistance, many of them are community members with thousands of edits under their belt.

Sign your posts

~~~~