Rosetta Code:Village Pump/Old draft tasks: Difference between revisions

From Rosetta Code
Content added Content deleted
(Thoughts)
(Cull some ?)
Line 10: Line 10:
:If the problem is that a task is too complicated or large, that doesn't mean the task isn't poor. Generally, in these cases, the original author might be asked to provide a few more examples in different languages. That's likely to provide enough differentiation in examples to cause some folks around here to question the task's description.
:If the problem is that a task is too complicated or large, that doesn't mean the task isn't poor. Generally, in these cases, the original author might be asked to provide a few more examples in different languages. That's likely to provide enough differentiation in examples to cause some folks around here to question the task's description.
:Otherwise, perhaps simply creating something like {{tmpl|WillNotImplement}} which takes a parameter as to some reason "why" might be enough to get some tasks out of the doldrums. I see no reason a draft should be archived or set fully aside without some discussion or attempt to get it up to snuff, first. --[[User:Short Circuit|Michael Mol]] 19:35, 11 May 2011 (UTC)
:Otherwise, perhaps simply creating something like {{tmpl|WillNotImplement}} which takes a parameter as to some reason "why" might be enough to get some tasks out of the doldrums. I see no reason a draft should be archived or set fully aside without some discussion or attempt to get it up to snuff, first. --[[User:Short Circuit|Michael Mol]] 19:35, 11 May 2011 (UTC)

:I think that someone who starts a task off should only do so with the intent of providing one good implementation in a short order of time. Mainly because the disciplin of providing both, would raise such a task, even if it remains draft, above the level of a task with no agreed, good, implementation. Without that first good implementation and task description , the task has very little to differentiate itself from some entry on the Suggest a programming task page, and should, in fact be somehow deleted and replaced by an entry there if the task page is abandoned without gaining those twin things of:
:# An improving/good enough description.
:# One correct implementation.

:By adopting the above, would we then have a sizeable problem of tasks with one good implementation and a good task description but no further activity for some time? Not sure :-)<br> --[[User:Paddy3118|Paddy3118]] 21:51, 11 May 2011 (UTC)

Revision as of 21:51, 11 May 2011

Old draft tasks
This is a particular discussion thread among many which consider Rosetta Code.

Summary

Discussion on what to do about draft tasks which don't seem to be getting attention

Discussion

There are some draft tasks that end up sitting around for a long time with no one adding examples or discussing anything about it (someone noted this on EBNF parser recently). I don't really want to push a hard rule on draft tasks, since everything about them is pretty ad hoc. I'm wondering if we should "clean out" some of the drafts that didn't really take off. Or maybe we could mark them as "failed drafts" (but use a nicer word)? It would be nice to keep the information around in case someone wants to pick them back up (especially if they have a correct example), but I feel like they should at least be marked somehow. It may be fine to delete them and try to come up with a coherent task suggestion for the ever-growing task suggestion box. What do you guys think? --Mwn3d 18:15, 11 May 2011 (UTC)

Draft tasks remain so primarily because nobody adds content to them. To understand why that is, we'd have to ask each person who chose not to write an example. (To that end, it'd be awesome to be able to do something like this;
  1. look at a user's known-languages set.
  2. Ask the user if they'd try to implement a task in (language they know that the task isn't implemented in).
  3. If they decline, ask them why.
If the problem is that a task is too complicated or large, that doesn't mean the task isn't poor. Generally, in these cases, the original author might be asked to provide a few more examples in different languages. That's likely to provide enough differentiation in examples to cause some folks around here to question the task's description.
Otherwise, perhaps simply creating something like {{WillNotImplement}} which takes a parameter as to some reason "why" might be enough to get some tasks out of the doldrums. I see no reason a draft should be archived or set fully aside without some discussion or attempt to get it up to snuff, first. --Michael Mol 19:35, 11 May 2011 (UTC)
I think that someone who starts a task off should only do so with the intent of providing one good implementation in a short order of time. Mainly because the disciplin of providing both, would raise such a task, even if it remains draft, above the level of a task with no agreed, good, implementation. Without that first good implementation and task description , the task has very little to differentiate itself from some entry on the Suggest a programming task page, and should, in fact be somehow deleted and replaced by an entry there if the task page is abandoned without gaining those twin things of:
  1. An improving/good enough description.
  2. One correct implementation.
By adopting the above, would we then have a sizeable problem of tasks with one good implementation and a good task description but no further activity for some time? Not sure :-)
--Paddy3118 21:51, 11 May 2011 (UTC)