Template talk:Incorrect: Difference between revisions
→What about example needs attention?: How about a two-stage process?
(Deprecate?) |
(→What about example needs attention?: How about a two-stage process?) |
||
| (One intermediate revision by one other user not shown) | |||
Line 15:
--[[User:Dgamey|Dgamey]] 22:08, 18 April 2010 (UTC)
: I'm thinking [[Template:Incorrect|<nowiki>{{incorrect}}</nowiki>]], 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. --[[User:Short Circuit|Michael Mol]] 02:21, 23 April 2010 (UTC)
::I think that it is worth ''formally'' distinguishing <nowiki>{{incorrect}}</nowiki>"does not meet task requirements", <nowiki>{{needs-review}}</nowiki> "might be incorrect, I as task editor can't tell", "is sloppy/hard to read/unenlightening", and <nowiki>{{improve}}</nowiki>"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.
::—[[User:Kevin Reid|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. --[[User:Short Circuit|Michael Mol]] 02:09, 24 April 2010 (UTC)
| |||