Rosetta Code talk:Add a Task

I've been asked numerous times about how to create a task. I've never had a good answer. This page represents a draft of my best idea of it.

• Please examine, edit, refine, review and debate it.
• Go through our existing set of tasks and use this page as a benchmark for gauging task quality. If the task seems of good quality (i.e. matches the prerequisites), despite not matching this page well, then the page likely requires modification.
• Build a list (somewhere, anywhere, wikicode or semantic query, be as practical or creative as necessary) where we can see our existing task set and see how well the task description matches this page. --Michael Mol 17:41, 20 September 2010 (UTC)

First implementation

I certainly like the requirement for an implementation. It almost always makes things much easier for other implementers if they can study a working example. Perhaps the requirement for graduating a task from draft status should be taken to be multiple implementations of it and a consensus that the task is clear enough (typically formed by having multiple implementations that people can agree are all correct). –Donal Fellows 21:06, 21 September 2010 (UTC)

Hi Donal, I would think that you don't actually have a task, draft or not, without that first implementation. They go together for me.
I don't often use the draft task status, and its usually when I find something that interests me, but I am unsure of wider interest, or might shift the focus of a task, as in Talk:Simple Quaternion type and operations, and Talk:Short-circuit evaluation, and Talk:Extreme floating point values, and Horner's rule for polynomial evaluation - started as a draft I think because I couldn't get the formatting of the equations in the description right. --Paddy3118 05:47, 22 September 2010 (UTC)

Other Algorithms

There needs to be a mention of the use of 'other' algorithms when the task allows - for example using regexps instead of an example using string search; or some other technique when brute-force search is the current solution method. We usually welcome them -sometimes on their own - other times in addition to other methods of solution. (Various Knapsack problem solutions have better methods than brute-force search for example). --Paddy3118 15:59, 8 October 2010 (UTC)

Suggest creating a "what to expect" section, noting common variations and the like, noting that the task author is likely to be surprised by creative (but not necessarilly inappropriate) solutions. "other algorithms" would fall under that, pretty much as a single bullet point. --Michael Mol 16:24, 8 October 2010 (UTC)

Semantic annotations?

Could we get a bit more on semantic annotations? I am not sure if I have ever seen them before here. And the illustrative example does not help me since, when I currently go to the referenced page it does not seem to have any examples of semantic annotations (but it does have a lot of :: which makes checking for what I think I am looking for frustrating). --Rdm 21:08, 9 November 2010 (UTC)

Hm. I'll try to explain it better here, so the page body can be updated in a more clear fashion after it's been vetted and I'm sure I really know what I'm talking about. (I'm not entirely clear on it myself, I just know a couple ways the feature can be used/abused to RC's benefit.) Semantic properties take the form of '[[property name::this page's relationship to that property.]]. I don't know what happened to the semantic notations on the delegate page. It's possible I never committed my changes to that page while I was writing this one. For a list of current properties and their usage, check out Special:Properties. It might also help to look at smw:Help:Properties and types. --Michael Mol 21:16, 9 November 2010 (UTC)