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 preferably) to see if the time "feels right" to upgrade a draft task.

A task could be upgraded when "most or all of" the following have happened:

• "A couple" of users other than the original task writer have contributed correct examples
• There are "at least 4" different languages implementing the task (since that is when the TOC automatically shows up)
• "Like a week or two" has gone by since all questions on the talk page have been "answered"
• "Like a week or 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 supported by GeSHi.
• Lang tags should be kept "in the 1-7 character range" depending on other similar language names.

Run times

These should only be added for comparison of two different methodologies in the same language. Comparing run times between languages could lead to language superiority complexes and plain old flaming. Listing a run time for a single approach to a task has almost no value since hardware and other configurations will vary drastically among readers. The goal of RC is to help people learn, not to write the fastest (or shortest or least memory-intensive) programs.