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
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. These include (but aren't strictly limited to):
- Practical problems
- Problems which demonstrate concepts
- Simple entertainment.
As for discouraged areas, remember that Rosetta Code is a tool of education, not a code repository. "Code golf", or the finding of the absolute most succinct expression of a solution as its own goal, is rarely idiomatic or practical use of the languages in question, and so is also difficult to justify in a demonstrative context.
The common theme across all tasks must be increasing competence and understanding of the tools in question, by example or by annotated counterexample if necessary.
Task focus exclusion
A task should not be so specific as to invoke a particular language as being the only one allowed to solve a task. Tasks which specify a particular language will not tend to achieve many useful comparisons or solutions, as languages are the richest resource on Rosetta Code.
A task should also not be so specific with its other requirements that there is only one language capable of solving it. Specifically requiring language features et al such that it is unlikely that there would be multiple nominally-distinct languages that can satisfy the task requirements is equivalent to invoking a specific language, and so leads to the same problems.
A caveat, however, is that 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 task needs a few basic components. It neeeds a simple description of the problem. Having a solution to the task allows you to tune the task description such that the run times and/or size of outputs are reasonable.
Inline references to specifically-related information are important. While offsite links are often necessary (if only for appropriate citation), enough cited, excerpted information should be included such that the task may still be solved.
Where relevant, sample input should be included; it gives task solvers something to work with.
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.
Extreme Language
Schools, libraries and parental filters may filter pages that contain what some call extreme language. RC tries to include this audience so asks you to self-censor such content. (For an example, see the discussion page for language Category talk:Brainf***).