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.

New tasks

You should always check around first to make sure your task isn't already on the site. Check the draft tasks as well. Also check for alternate names. If at all possible, ask in the IRC channel.

New tasks should also always start as drafts at least for a little bit. This is to make sure a bunch of people understand it and to make sure it's not too complicated. Demonstrating the Artin-Zorn theorem may seem simple to a mathematician, but it's probably more complex for other users.

Try to provide as much information as you can on the actual task page. Do not rely on wikipedia or other websites to give basic information about the task. If possible, provide a pseudocode algorithm for solving your task.

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.