User:Mwn3d/Personal policies: Difference between revisions

← Older edit

User:Mwn3d/Personal policies (view source)

Revision as of 19:28, 22 August 2011

2,177 bytes added , 12 years ago

m

→‎Example correction

Anonymous user

rosettacode>Mwn3d

Revision as of 05:30, 29 May 2011 (view source) rosettacode>Mwn3d (→‎Upgrading tasks from "draft": adding a section about new tasks) ← Older edit		Latest revision as of 19:28, 22 August 2011 (view source) rosettacode>Mwn3d m (→‎Example correction)
(4 intermediate revisions by the same user not shown)
Line 1: 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\|of places]] [http://www.facebook.com/pages/RosettaCodeorg/199439093012 to ask] about it. __NEWSECTIONLINK__ ==Example removal== In general, alternative examples should be added ~~along side~~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"== Line 21 ⟶ 23: "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== Line 32 ⟶ 36: ==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.