User:Mwn3d/Personal policies

I'll try to adhere to these policies when evaluating the things going on on the site. Call me out if I go against them, but they may change as new information comes in or new experiences happen. I'm sure I'll come up with more as I go as happened with User:Mwn3d/Word mincing.

In general, if you're not sure, there are lots of places to ask about it.

Example removal

In general, alternative examples should be added along side older examples (with subheadings added to describe them). Examples should not be removed simply because someone used a slightly different algorithm that "works better". If a better/clearer/more idiomatic version of the same general approach could be done, the example could be changed (but be prepared for undo's and discussions). Examples should be removed if they are malicious code. An example could be removed if it is so far off from the task description that a corrected version would look almost nothing like it. In some cases (e.g. an example in a language with a very small community), it may be worthwhile to keep a grossly incorrect example around with proper annotation.

Upgrading tasks from "draft"

This has been called "touchy-feely". I will quote phrases which require ad hoc evaluation (on the talk page preferrably) to see if the time "feels right" to upgrade a draft task.

A task could be upgraded when:

• "A couple" of users other than the original task writer have contributed correct examples
• There are "at least 4" different langauges implementing the task
• "Like a week or two" has gone by since all questions on the talk page have been "answered"
• "Like a week ot two" has gone by without any "significant" changes to the task description

Creating categories/templates

This is usually fine. If you want to create some templates and try them out use Sandbox or make a subpage of your user page to try them out (like User:Mwn3d/Sandbox). If you're going to categorize pages, try to do it in a way that does not overwrite current categorization strategies. This will make it easier to revert your changes if they don't work so well.

Lang tags for new languages

• Every language should have a unique lang tag name even if that language shares keywords with another language. This makes it easier to deal with new languages diverging from other languages as they grow.
• Every language should have a tag even if it is not suppoerted by GeSHi.
• Lang tags should be kept "in the 1-7 character range" depending on other similar language names.