Wikipedia:Don't give the developers ideas
This is a humorous essay. It contains the advice or opinions of one or more Wikipedia contributors and is made to be humorous. This page is not one of Wikipedia's policies or guidelines, as it has not been thoroughly vetted by the community. Some essays represent widespread norms; others only represent minority viewpoints. This essay isn't meant to be taken seriously. |
Over time, Wikipedians come to appreciate the amount of time the development and network operations teams put into keeping the site running as well as possible.
In addition to learning this, another vital rule is picked up fairly early on in the learning process:
Don't give the developers ideas.
Thou shalt not take the name of blocking in vain
[edit]One minute you're joking about pwnage and running vandal bots. Next, you're getting 403 errors from all the sites. You discover that a network operator has blacklisted your entire ISP with a well-placed line in the Squid configuration. Who's pwned now?
- We know the blocking mechanism experiences frequent suckage. Some plans are in place to improve it some time soon. Soon. Promise. Just don't whinge about T550 too often.
Keep your hands, feet and unhelpful interface quirks to yourself
[edit]Taste varies. Don't ever let the developers get the impression you're not totally satisfied with the quality of the skins in MediaWiki. All hell can break loose when CSS goes wild.
You say: Man, Vector needs an overhaul.
They hear: We want pink ponies!
Picture it. No, it's not pretty, is it?
- User tastes are diverse and sometimes freakish. We don't adjust the interface massively (except for when we do) unless it's adding "functionality"; that's what the skin system and custom CSS and JavaScript are for.
Don't bug war
[edit]WONTFIX is a bitch. So is life. Get used to both, and don't revert the former. Actually, don't revert the latter, either.
- ...it's irksome and it's counterproductive. There are reasons behind such an action. Feel free to query them with the developer concerned if an explanation isn't provided. But don't REOPEN the bug unless you're absolutely sure you can justify it.
Developers are deletionist
[edit]Just don't go there. Asking for stuff to be deleted is a real minefield. You're liable to end up responsible for half the Wikimedia wikis being dissolved or something. Ever seen 48,302,780 pissy Anglophones wander up after their featured articles have gone walkabout? You don't want to. It gets messy.
You say: Developer, can you please delete [article]?
They hear: Can you please nuke the German Wikipedia?
- Please don't file bug reports asking for stuff to be fixed when it's a content issue or when a local sysop or a bureaucrat can help out. By all means, let us know if you're having difficulties stopping a spam bot or deleting personal information from page histories, but don't bug us about trivial stuff.
Overengineering is a staple
[edit]Ask them to make a simple template for true false statements, a module was created. Ask them to make Wikipedia slightly more responsive for mobile users, they make an app and an entirely different skin for it. Ask them to make a bot that fixes a specific set of typos, now it is hosted on Toolforge and fixes all known misspellings in the English language.
Heck, give them a coffeepot and then they would make an internet protocol for it.
- Many of Wikipedia's edit tools right now, is the result of overengineering, overcomplicating, and truthfully, an excitement that goes too far. If you think something could have been done manually, simplistically, don't create a harder way.
Don't reinvent the wheel!
[edit]That's just it, don't reinvent the wheel. You have a cool idea, you imagine it would help the many, feed the starving and enrichen the abundant, you create it with all your available time, with all the wit and grit, you stay at the computer for so long, you finally publish it. But there is one unfortunate thing, it's already created.
- Duplicate prospects happens often, that is why you should try to search what you want to create, and see if it has been realized yet.