Rosetta Code:Add a Task
Prerequisites
Draft vs non-draft
Not all tasks are immediately ready to be thrown at the casual Rosetta Code participant. Some need a review or draft phase before they're in good shape.
- For a non-draft task, one would use Template:Task by putting {{task}} at the top of the page.
- To note that a task is a draft, use Template:draft task, by putting {{draft task}} at the top, rather than {{{task}}}.
It's up to you to decide which you start with, but another community member may choose to change your created task to a draft. If there is some question on the general suitability of the task then create a draft task and discuss the reason for it being a draft in the talk page. This will warn potential contributors that there may be substantial changes in the task description whilst still in draft status.
Reasons for draft status might include, but not be limited to:
- A task that is too large.
- A task that is too general and so hard to compare implementations.
- A task that may be too specific and so only implementable by a single language.
Task focus inclusion
Generally speaking, the goal is to address a problem a programmer may face or want to think about. This could be a practical problem, a demonstrative one, or even one of entertainment. However, the common theme across all tasks needs to be increasing competence and understanding of the tools in question, by example or by annotated counterexample if necessary.
Task focus exclusion
As languages are the richest resource of comparison on Rosetta Code, a task should not be so specific as to invoke a particular language as being the only one allowed to solve a task. A task should also not be so specific with its other requirements that there is only one language capable of solving it. Best-effort solutions ("this isn't exactly possible in Ayrch, but something practical solving the language's idiomatic analog would be") are often fine, so a task writer may find that styles "use technique X to solve problem" and "solve problem using technique X" may need to be interchanged to make a useful number of solutions possible.
Basic information
- A simple description of the problem.
Having a solution to the task allows you to tune the task description so that the size of outputs or run times are reasonable. - Inline references to specifically-related information.
Although links to offsite information do help in a task description, it is best to have enough of a description of the task on the R.C. site itself. - Sample input (where relevant; it depends on the task)
Example code
- At least one example implementation.
It is usually a good idea to have this one example implementation completed, tested, and working before you start writing the description of the task, as well as a sample of correct output. It is usually a good idea if this first example shows its output even if it isn't strictly necessary for the completion of the task as it helps other implementers.
Additional information
Sample output
- Matching sample input
Semantic annotations
- Identify problem concepts that the task invokes.
Lurk!
- Read present R.C. task descriptions that you like, and maybe follow a new one closely so you have some idea of what happens in the birth of a new task, and have some idea of the (unwritten), 'house style'.
- Hang around, answer and ask questions; especially in the early days of the task.
This ensures that people have enough information to implement the task in other languages and to fine tune the task description as needed, to end up with something many can implement without ambiguity.- If you provide the site with your email address in Special:Preferences, you can Watch the page, so the site will email you when it changes.
Jargon
It helps to explain jargon as about the only common jargon that might be understood would be in the field of programming or computer science. Be especially aware of unexplained maths jargon, and watch the talk page and other implementations for signs of things maybe needing more explanation, either in the talk page - or a change in the task description.