View source for 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 [[Rosetta Code:Village Pump|lots]] [http://twitter.com/rosettacode of] [[Special:WebChat|places]] [http://www.facebook.com/pages/RosettaCodeorg/199439093012 to ask] about it.
__NEWSECTIONLINK__
==Example removal==
In general, alternative examples should be added alongside 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 even a corrected version would look almost nothing like how it does now. In some cases (e.g. an example in a language with a very small community, or a language with limited capability), it may be worthwhile to keep a grossly incorrect example around with proper annotation.
===Example correction===
Try not to get too emotionally attached to your code. If someone comes and changes it (calling it a correction or improvement), try to evaluate if it's better from multiple angles (adherence to the task requirements, clarity, performance, etc.). If you don't think it is, politely bring it up on that user's or that task's talk page. If they change your example to something that is marginally better but a completely different approach, maybe consider keeping both examples in separate sections. If you do that, make sure you note the advantages and disadvantages of each (and try not to add passive-aggressive insults into those notes).

==New tasks==
You should always [[:Category:Programming Tasks|check around]] first to make sure your task isn't already on the site. Check the [[:Category:Draft Programming Tasks|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 (especially if you are restricting users to a specific algorithm).

==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

It's also a good idea to explicitly declare on the talk page that you will be promoting the task and allow a time for additional comments (a day, a week, just say how long). Sometimes discussions die out with questions still unanswered. Sometimes people get distracted by other discussions and forget that they were in the one on this draft task. It's not safe to [http://www.imdb.com/title/tt0065329/quotes?qt=qt0244406 assume] that since no one has said anything for a while that the task is perfect.

==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. Talking about it somewhere in the community doesn't hurt either.

==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.

==Exact match on output==
Unless the task is to draw something (a picture, a table, a shape, etc.), slight differences in output are not usually a problem. It's better to present the output in a form that is natural to the language (or natural to the reader if it's not too complicated to do so in the language). Tasks here are not tasks for programming competitions or any other kind of evaluation of someone's programming skills. It's usually pretty easy to pick out the "meat" of a task (the specific algorithm, the pieces of information that need to be calculated/presented, etc.)--that is, the part that ''needs'' to be the same across languages. The output is usually just proof that it works.