Village Pump/Approximate fit solutions: Difference between revisions

m
A policy would be sufficient
(in good faith)
m (A policy would be sufficient)
Line 10:
 
:I see this as a consequence of your [[Pi#GUISS]] "solution" being rejected and you are trying yet another way to weasel out of it. I don't think there is any place for such a template. For a task, there are correct solutions, and there are not-so-correct soutions written in good faith. What constitutes "in good faith" is subjective, so people must be allowed to scrutinize them instead of letting them hide under some umbrella tag. Case in point: by most people's standard, the GUISS pi digits "solution" would not be a good faithed attempt (want a bet?), yet you still want a tag there so you can point at it and say "don't remove it, it's tagged such, thus acceptible". --[[User:Ledrug|Ledrug]] 19:27, 24 July 2011 (UTC)
::It's nothing to do with that. I am trying to make the documents as good as they can be, and I think being relaxed and inclusive is the best way forward. I don't think we need to be quite so strict with an "this is not an exact match, so it must be deleted" type of approach. After all, the solution was valid, whether it gets published here or not. I can always publish it on another website. That is not a problem. It's just convenient to work with Rosetta Code, because it has similar goals to a project that I have been developing, and the infrasture is already in place here, and I quite like how the project is evolving. FWIW, a policy would alleviate the need for the tag, or it is easy to add "If your language cannot achieve this task exactly, then make an approximate implementation, and state divergencies and limitations in the provided solution" to every task. But I think this is extreme. A policy would be sufficient (if only really for the purpose of clarification of conflict between different developers ideas). [[User:Markhobley|Markhobley]] 20:47, 24 July 2011 (UTC)
 
==Policy==