Guild Wars Wiki talk:Projects/Policy Cleanup

I noticed the other day there is no clear policy on Talk pages that I could find, whilst there is a section in GWW:USER that mentions the overriding policy, I could not locate it. Mainly regarding removing content without archiving. This could probably go in the Article Retention policy. --Lemming64 22:54, 30 July 2007 (UTC)

Policies about Talk pages are getting spread out already. Can think of at least 3 places. Perhaps it's time for a united policy? Backsword 23:31, 30 July 2007 (UTC)

I made a proposal about this at Guild Wars Wiki talk:Article retention#Talk page content. -- ab.er.rant 02:40, 31 July 2007 (UTC)

Before we start..

I would suggest something like this ("may", "must", "shall", "should") for our policies (maybe in combination of the formatting guide but with some more bindingness) to be sure what should be done and what can be done (etc). poke | talk 23:02, 30 July 2007 (UTC)

A policy about wording policies? ;) But I agree that it might not be a bad idea to formalize at least a certain set of language. Whether it needs to be a policy, or a guide, I'm not sure. A policy almost seems overkill, but I'm not sure how you'd get "more bindingness" without such. (Aiiane - talk - contribs) 23:04, 30 July 2007 (UTC)

Maybe something like "Policies have to follow the policy formatting guide before they can be accepted." on Guild Wars Wiki:Policy? poke | talk 23:11, 30 July 2007 (UTC)

Disagree. Such a page should be used as a reference for certain terms and wording, and for a general idea of what sections need to be included, not as a strict formatting guide. -- ab.er.rant 02:40, 31 July 2007 (UTC)

I agree with Aberrant. A small section explaining the terms like in that link is all that should be needed, I don't think we need to regulate when we are allowed to use certain wordings.. That would be to go to far. - anja 08:45, 31 July 2007 (UTC)

Word significance?

Just tossing some thoughts out here, feel free to comment, and these are entirely open to debate:

• "must" - specifies total compliance, any breach dealt with by a sysop (or other user) on sight (not necessarily unilaterally, but also potentially via making the user in violation aware, et cetera), regardless of whether there are pending complaints about the particular violation

• "should" - specifies required compliance upon complaint, potential violations left as-is unless a user takes issue with a potential violation, in which case compliance is required

• "encouraged", "recommended" - implies non-required compliance, for things that it is helpful to standardize but not necessary

• "may", "can" - specifies non-exclusive permission, to explicitly state things while not implicitly disallowing others

I anticipate my definition of "should" will be the major topic of discussion, and I'd welcome suggestions of a better (but still "common") word to use for such a definition. (Aiiane - talk - contribs) 20:14, 31 July 2007 (UTC)

I'd agree with that so far. Nothing jumps out as me as being needed. LordBiro 21:21, 31 July 2007 (UTC)

I'm fine with the definitions of those words as I've been mostly using them in that manner (I think). -- ab.er.rant 00:25, 1 August 2007 (UTC)

Like Aiiane forsaw, I disagree with the definition of "should". That is not how should is used in normal language. I am totally ok with the other ones though. Should is a word that "should" not feature in policies anyway (in my opinion), much more fitting for guidelines. --Xeeron 09:17, 1 August 2007 (UTC)

Agree with Xeeron. 'Should' is too ambiguous in normal usage. Backsword 09:53, 1 August 2007 (UTC)

As I said, I'm open for suggestions for an alternative word to use for such a meaning. Have any? (Aiiane - talk - contribs) 11:42, 1 August 2007 (UTC)

So how would you propose for soft limits to be worded? Take for example my proposed soft limit for the general rendered length/width of a person's signature. -- ab.er.rant 11:43, 1 August 2007 (UTC)

Soft limits are rather vague. Personally, I'd prefer things spelled out, possibly as a conditional. (eg. 'Must.... if...') Backsword 11:56, 1 August 2007 (UTC)

So for example, regarding the max number of characters allowed for a custom signature, you'd rather that it would say "a max of 75 characters not including any image links and not including any links to userspace" instead of "a max of 150 characters with leniency given to users with long usernames"? It's just an example I'm throwing out for where a "should" would be quite applicable. Others are like "User signatures and icons should not use colors that are too bright or too disturbing." Without a "should" (as Aiiane defined it) kind of meaning, that line would either need to be removed, or the problematic colors spelled out explicitly... Same thing with things like image sizes and total page size. "Should be less than 300 kB in total... if it becomes a hard limit, what if I go up to 301 kB? I would say some soft limits can't really be avoided. -- ab.er.rant 12:01, 1 August 2007 (UTC)

I think that "should" is perfectly acceptable in policies, provided it is not used when something stronger is required. LordBiro 12:06, 1 August 2007 (UTC)

I disagree not with the usage of "should" per se, but Aiianes definition of it. However since different people (like Aiiane and me) have different definitions of the word, it is a poor choice to use in policies. --Xeeron 12:11, 1 August 2007 (UTC)

How about a slightly clearer definition?

• "should" indicates that compliance is not required but strongly recommended; failure to comply might result in administrative action if an individual admin deems it appropriate.

Is that any better or just as bad? LordBiro 18:06, 1 August 2007 (UTC)

I don't think that was what Xeeron was getting at, LordBiro - his opposition (as far as I can tell) comes from the fact that a good portion of people will never bother to check what the wiki's definition of "should" is, and simply assume "should" means what they think it would mean. I'm fairly sure he doesn't mind the actual definition I gave as a unit, but rather the word I associated with said definition. That said, I'm still not sure what word would better be associated with such a meaning, and I think it's a crucial meaning to be able to convey.

I also happen to dislike the particular alternative you gave, LordBiro, simply because it seems a bit too encouraging of unilateral action, and also implicitly disallows regular users from lodging complaints (even though it doesn't explicitly disallow such). (Aiiane - talk - contribs) 20:29, 1 August 2007 (UTC)

I considered that as I was writing; "if an individual admin deems it appropriate" was the last thing that I added, but I think it is a positive addition. However, if you think this is too far from the current meaning then I would gladly omit that part of the definition. I don't want to rewrite policy, but I do think that "should" in a policy implies that compliance is not required, but potentially punishable if any sysop determines that violation has occurred. LordBiro 22:02, 1 August 2007 (UTC)

To me, that's contradicting Biro. "You are not required to follow this rule, but we punish you if you don't". That's what I call required. - anja 22:03, 1 August 2007 (UTC)

Well, perhaps you're right there. I was trying to say that there are instances when a rule is weakly enforced but that doesn't mean you can't get banned for it. I guess that's not the kind of thing we really want in policies though, is it? LordBiro 22:09, 1 August 2007 (UTC)

This is why I suggested the concept I did - that violations are not required to be corrected until and unless a user lodges a complaint regarding them. If we really had to, we could simply write up every policy using "musts" and then add a note to such an effect ("The above policy need only be enforced if a user takes issue with a particular instance yadda yadda"), but I think that would be even more confusing. (Aiiane - talk - contribs) 22:13, 1 August 2007 (UTC)

(Reset indent) how about - failure to comply after more than one request to comply may result in administrative action. --Lemming64 22:14, 1 August 2007 (UTC)

I would say that one complaint is not even grounds for forcing compliance. Which is why I worded the "should" sections of my user page and signature proposals to require "multiple valid and reasonable complaints". I'm actually not bothered with the potential misintepretation of the word Xeeron, because I feel that as long as we always add a clause regarding complaints and compliance for the "should" portions, the meaning of it should be rather clear. -- ab.er.rant 01:48, 2 August 2007 (UTC)

I would be wary of defining a word on this wiki as meaning something different from general understanding, and I don't think there is enough agreement as to what the word "should" means. I was of the opinion when I joined this conversation that "should" was a non-must (as Aiiane put it), but after looking at dictionary.com I'm not certain. "3. must; ought (used to indicate duty, propriety, or expediency): You should not do that." If "should" is synonymous with "must", even in some people's understanding, then I'm unsure if we should be defining them as separate terms. LordBiro 06:49, 2 August 2007 (UTC)

Then perhaps it might be better to replace all uses of "should" with "recommended" or "encouraged", prepending a "highly" if necessary. And then explicitly stating an expectation of conformance should there be complaints. -- ab.er.rant 07:44, 2 August 2007 (UTC)

I still disagree that anything not required can be forced to get changed by complaints. Either it is required and we tell people to follow this rule, or it's not required and we can do nothing about it, because our policy says it's not required. What kind of rule would you mean to put with a "highly recommended"? (Just so I can get a clear picture of what you mean) - anja 08:13, 2 August 2007 (UTC)

I was more or less thinking about "highly recommended" as being what's "should" above. So I would say that most soft limits fall into these. The only problem I have with only using "Do" and "Do not" is that it makes it difficult to restrict subjective issues. And it also does not lend well to situations which are not mentioned in a policy. In a strictly worded policy (do and don't), what happens if a user does something that's not mentioned but seems to be implied? I have nothing against using only "Do" or "Don't" but I've noticed that without using words like "should", some of the disagreements between what must be required and what must not be required are very difficult to resolve. -- ab.er.rant 10:20, 2 August 2007 (UTC)

Well, an alternate suggestion: although it seems a little kludgy, what are people's thoughts on simply using non-binding language for any "loose" requirements, and then using an asterisk/footnote to specify that such recommendations will be enforced as requirements if certain conditions are met (such as repeated complaints, et cetera)? I.e....

It is recommended that signatures not be more than 200 characters
of wikicode, as longer sigs clutter edit windows1.

and then, at the bottom of the section or potentially the policy page,

1 This recommendation may be enforced as a requirement by a sysop if there
are multiple complaints lodged in regards a signature which exceeds this recommendation.

Thoughts? (Aiiane - talk - contribs) 22:19, 10 August 2007 (UTC)

I like that solution. I'll write more when I get home after this weekend. - anja 08:06, 11 August 2007 (UTC)

I'd rather just repeat that paragraph once per policy where ever it's relevant. But then again, I just dislike footnotes, so it's just me. -- ab.er.rant 02:20, 13 August 2007 (UTC)

I happen to dislike repeating the same text over and over throughout a policy, if it's longer than a few words (especially given that there may be cases where recommendations are shorter than the above text, in which case it seems really odd to repeat it inline). You say "once per policy", but the problem is some parts of a policy might be flexible while others are not, and thus it'd be hard to be clear about it.

It doesn't even have to be a footnote, either - it could simply be a note at the beginning of the section where flexible restrictions are listed, saying "anything below marked with an asterisk may be enforced as a requirement if there are enough complaints" or the like. (Aiiane - talk - contribs) 02:31, 13 August 2007 (UTC)

Pinging this for further comment. (Aiiane - talk - contribs) 23:53, 18 August 2007 (UTC)

"Forgotten policies"

Looking at Guild Wars Wiki:Policy, one can spot a number of policy proposals and policy change proposals, which seem to have fallen out of interest before the discussion could be brought to an end. In some cases there was large opposition to the policy proposal, yet it was not moved to failed, in some cases the proposal meet rather positive feedback, yet was not implemented. To speed up the process and to focus discussion, I put a Policy proposal of the week link on this project page. Ideally, after a week of discussion, we could reach a decision to either make this proposal policy or reject it and go on to the next proposal. --Xeeron 13:27, 29 August 2007 (UTC)

Policy notice templates

Let's try to revive this project a bit! When I looked at the policy notice templates in the last time, that are those templates which are displayed at the top of each policy (proposal/draft/change/whatever), I noticed that they were used in a really confusing way. For example all modifications of an existing policy are tagged as a proposed policy or a policy draft and such categorized into the same categories as the new proposed/drafted policies although they are divided on the policy page. Another thing is, that we have templates for some detailed things like implemented policy change or inactive draft policy but for others they are simply missing so that we either leave the template in its wrong state, or we change an inactive policy modification proposal into a inactive draft policy, causing confusion and categorizes the page wrong.
This is why I started thinking about cleaning up the whole policy templates. I started with something in my sandbox, and I will add the template proposals later. First I would like to hear your opinions on that :) poke | talk 11:41, 27 May 2008 (UTC)

I like it. However I am not sure whether the differentiation between draft and proposal is really needed (seeing how we support drafts and edit proposals), but this is not a big matter for me. --Xeeron 11:53, 27 May 2008 (UTC)

Yeah, I wasn't sure about that either, but I think it is not bad to at least leave the possibility to create a draft first and expand it to a proposal then. poke | talk 11:59, 27 May 2008 (UTC)

I think it would be preferable to have one template for each status instead of one (or two) template which can be changed by a parameter, right? poke | talk 11:09, 28 May 2008 (UTC)

Personally, I can can use normal templates just as well ... but ... I know better than to take away your coding toys ... and, you know, it does look a bit more organised with one template ;-) --Xeeron 14:49, 28 May 2008 (UTC)

Ok xD poke | talk 14:53, 28 May 2008 (UTC)

Ok, what do you think: click? poke | talk 20:07, 28 May 2008 (UTC)

I think that the same thing could have been accomplished with fewer icons. :P But they look decent. (Aiiane - talk - contribs) 20:08, 28 May 2008 (UTC)

Haha :D I just thought that icons who actually fit to the specific status would look better ^^ poke | talk 20:09, 28 May 2008 (UTC)

Oh, the status is fine... just I don't think the subtle changes of the color of a few lines to differentiate between policy/guideline/modification were necessary. I know I'm not going to pay attention to whether the page is blue or green, if anything I'm going to look at the bold text saying "policy" or "guideline" or whatever. If you wanted to differentiate the types by color, you'd be better off using a different color scheme for the overall box - perhaps make the border of the box blue for policies, green for guidelines, and orange for modifications. (Aiiane - talk - contribs) 20:16, 28 May 2008 (UTC)

I like the icons :) I'd rather we take the opportunity to discuss the difference between a draft and a proposal. It needs to be made clearer and more intuitive, otherwise we would probably be better off dropping the "draft" state, since currently, there's really no difference when it comes to how we discuss a draft and a proposal. -- ab.er.rant 03:53, 29 May 2008 (UTC)

I'd personally prefer dropping it - K.I.S.S. generally works well. (Aiiane - talk - contribs) 07:48, 29 May 2008 (UTC)

I see the difference in draft and proposal simply in that way, that a draft has a basic idea but is missing important things so people should edit it whereas a proposal could be accepted in the exact way (or requires only minor edits). That's why I only added draft templates to guidelines and policies but not to policy modifications (which are normally based on the accepted one, so they should definitely have the level of a proposal). poke | talk 09:51, 29 May 2008 (UTC)