Template talk:Incorrect
parameter for reason
Can we add a parameter to this template that allows the user to note why he thinks the solution needs review? At the moment, if one catches the template when it's added, or within in a few days, because it's usually related to a change in task specifications (and usually applied to every language on a page after a spec change).
But if you're reviewing the "Tasks needing attention list", or happen to come across the template months after it's added, the context is lost, and it's not clear WHY the task "needs review", and having to do a detailed analysis is demotivating.
--DanBron 19:32, 1 December 2009 (UTC)
- The parameter is already there, but it seems people don't use it sometimes. There's no real way of making it "required" (a "{{{1}}}" would show instead of a reason if we didn't check for the parameter's existence), so I think the best we can do is try to make it really obvious that the option is there and nice to use. --Mwn3d 23:39, 18 April 2010 (UTC)
What about example needs attention?
The example needs attention template is missing. In some cases this is more desirable than using incorrect, especially where the example works but may not be the best example.
--Dgamey 22:08, 18 April 2010 (UTC)
- I'm thinking {{incorrect}}, along with most (all?) of the other example-targeted maintenance templates, should be deprecated, in favor of a single ENA template that takes two parameters, the first argument a short-reason (one or two words), and the second one a sentence or two suggesting a possible resolution. --Michael Mol 02:21, 23 April 2010 (UTC)
- I think that it is worth formally distinguishing {{incorrect}}"does not meet task requirements", {{needs-review}} "might be incorrect, I as task editor can't tell", "is sloppy/hard to read/unenlightening", and {{improve}}"could be extended to add interesting features". Some advantages of having templates for these are:
- You need not invent the phrasing of the notice yourself; it falls into a standard category which people know what to do with/what it means. In particular, personally writing "This is incorrect" is more likely to cause offense if it's slightly misphrased.
- We can (but don't currently) programmatically distinguish the bad cases (incorrect) vs the improvement cases (improve, novice example, ENA in general).
- The more serious cases are visually distinguished by different colors for the infoboxes.
- —Kevin Reid 20:49, 23 April 2010 (UTC)
- I dislike a formal approach for a few reasons, but I think a two-stage approach could avoid most of the problems:
- It requires greater familiarity/experience/training with the template set for proper use, and we already have cases where people are using the wrong template just because that's the one they've seen before; over-formalization has already put us in a position of having several ENA templates that see little or no use at all.
- This could be averted by having a generic ENA template, and have instances of that generic template replaced with a small set of more formal ones on an as-needed basis.
- We've seen the wrong concerns raised about code examples not just because of unfamiliarity with more appropriate templates, but because of a misconception of the reviewer of either the code, the task description, or some other factor like "is this allowed?", and formalizing those concerns will give weight to a likely incorrect impression.
- This could be also be averted with the two-stage ENA process as well, as long as the person replacing the ENA instance applies critical thinking.
- Think of bad vs improvement cases as a form of triage. Triage is only really helpful when there is a shortage of resources to meet demand, and I don't think there are any languages with enough examples marked as requiring attention where it's unreasonable to think that a contributor wouldn't be able to review the complete set for his language in a short period of time; I don't think prioritization of ENA instances will affect the general tendency to deal with the easy problems first. --Michael Mol 02:09, 24 April 2010 (UTC)
- I dislike a formal approach for a few reasons, but I think a two-stage approach could avoid most of the problems:
- I think that it is worth formally distinguishing {{incorrect}}"does not meet task requirements", {{needs-review}} "might be incorrect, I as task editor can't tell", "is sloppy/hard to read/unenlightening", and {{improve}}"could be extended to add interesting features". Some advantages of having templates for these are: