Wiktionary:Votes

Definition from Wiktionary, the free dictionary
(Redirected from Wiktionary:V)
Jump to: navigation, search

Wiktionary > Votes

The page Wiktionary:Votes consolidates policy votes and procedural votes that take place on Wiktionary. It formalizes and documents the consensus building and voting policy. For an archive of previous votes, see Wiktionary:Votes/Timeline and Wiktionary:Votes/. This header is at Wiktionary:Votes/header.

Main sections of this page: #Current and new votes, #Recently ended votes and #Proposed votes. See also /Timeline.

Current and new votes

Migrating from Template:term to Template:m

Support

  1. Symbol support vote.svg Support --Vahag (talk) 18:23, 29 August 2014 (UTC)
  2. Symbol support vote.svg SupportCodeCat 19:28, 2 September 2014 (UTC)
  3. Symbol support vote.svg Support Mulder1982 (talk) 19:45, 12 September 2014 (UTC)
  4. Symbol support vote.svg Support, but I would like the final result to be {{term}} redirecting to {{m}} (or vice versa). --WikiTiki89 19:46, 12 September 2014 (UTC)
    To do that, we would first need to orphan {{term}}, as the parameters are not compatible. And at that point there is no need for a redirect anyway, is there? —CodeCat 20:03, 12 September 2014 (UTC)
    Yeah there is: so that people can start using {{term}} instead of {{m}} if they feel like it suits them better. --WikiTiki89 20:05, 12 September 2014 (UTC)
    We should aim at there being one template in the mainspace. We should aim at at least a semblance of professionalism. Keeping term with old parameter order to make old revision legible is fine. --Dan Polansky (talk) 20:13, 12 September 2014 (UTC)
    Actually, that's also a good idea. --WikiTiki89 20:31, 12 September 2014 (UTC)
  5. Symbol support vote.svg Support — It's better to have one term (whichever) than two - since the newbie suspects there's a subtle difference between them. Since most will look for an example (like me) either would do, but m is shorter — Saltmarshαπάντηση 19:30, 5 November 2014 (UTC)
  6. Symbol support vote.svg Weak support — I can agree that "term" is more descriptive than "m", which can be confusing. On the other hand, not needing a named language parameter makes things a lot easier. ObsequiousNewt (ἔβαζα|ἐτλέλεσα) 00:14, 25 November 2014 (UTC)
  7. Support "term" does not mean what it says, and it's NOT more descriptive; it's misleading, beside being longer. "m" would force the newbies to read the docs, which is eventually a good thing, because by seeing "term" they probably think that they already know what the template does, while they usually don't. --Z 10:07, 1 December 2014 (UTC)
  8. Symbol support vote.svg Support per Z. --Fsojic (talk) 10:53, 1 December 2014 (UTC)
  9. Symbol support vote.svg Support --Anatoli T. (обсудить/вклад) 02:05, 8 December 2014 (UTC)
  10. Support per Z. Keφr 08:02, 9 December 2014 (UTC)

Oppose

  1. Symbol oppose vote.svg Oppose No user will ever guess what {{m}} means, while the meaning of {{term}} is rather obvious. We need to think about non-regulars and casual contributors too. -- Liliana 18:05, 29 August 2014 (UTC)
    At least the name of {{m}} is intriguing while term is misleading - one may take it for only a decorating template (like I did until recently xD).--Dixtosa (talk) 19:07, 29 August 2014 (UTC)
    Just to note, {{m}} is now a shortcut for the more descriptive name {{mention}}, while {{l}} is likewise a shortcut to {{link}}. —CodeCat 21:10, 5 November 2014 (UTC)
    I always thought {{l}} stood for "list-item", not just "link". Keφr 09:05, 8 December 2014 (UTC)
    I also thought that. --WikiTiki89 09:33, 8 December 2014 (UTC)
  2. Symbol oppose vote.svg Oppose. It's a cryptic and unhelpful name. But I think the parameter order of {{m}} is better. Perhaps it would be nice to migrate all existing uses of {{term}} to that parameter order. This, that and the other (talk) 07:37, 31 August 2014 (UTC)
  3. Symbol oppose vote.svg Oppose deleting Template:term. No opinion regarding any other action. —Mr. Granger (talkcontribs) 19:32, 2 September 2014 (UTC)
  4. Symbol oppose vote.svg Oppose. The name term is more comprehensible. The old revision histories will be clearer (not that that's a strong argument in my opinion, but it's worth something). And even if all were equal (m and term were equally good), there'd be no reason to specifically change from one to the other. I have no opposition, however, to reordering the parameters of either template to match those of the other, provided that that's done without introducing errors.​—msh210 (talk) 16:35, 18 September 2014 (UTC)
    Changing {{term}}'s parameters to match {{m}} would break the old revision histories anyway. --WikiTiki89 20:45, 18 September 2014 (UTC)
  5. Symbol oppose vote.svg Oppose. As above - term means what is says; m will always mean masculine to me. SemperBlotto (talk) 08:51, 13 October 2014 (UTC)
  6. Symbol oppose vote.svg Oppose Per others, especially Liliana's argument. User: PalkiaX50 talk to meh 09:19, 13 October 2014 (UTC)
  7. Symbol oppose vote.svg Oppose --Dijan (talk) 19:33, 14 October 2014 (UTC)
  8. Symbol oppose vote.svg Oppose strong. Another unnecessary merge. Purplebackpack89 14:14, 2 November 2014 (UTC)
  9. Symbol oppose vote.svg Oppose – I read the ‘rationale’ but can't see any explanation…does this new template do something different? If not, why can't we just change how {{term}} works? And why ‘m’?! Basically, no. Ƿidsiþ 08:15, 17 November 2014 (UTC)
    If we change term to work like m... that's basically what the support camp is arguing for. That's basically support but under another name. Renard Migrant (talk) 18:54, 7 December 2014 (UTC)
    @Renard Migrant: I don't think so. The disagreement seems to be about the template name. I don't see anyone insisting that term should be used like {{term|...|lang=en}} instead of {{term|en|...}}. --Dan Polansky (talk) 18:59, 7 December 2014 (UTC)

Abstain

  1. Symbol abstain vote.svg Abstain I can't decide between the pros and the cons. --Dan Polansky (talk) 17:18, 26 September 2014 (UTC)
  2. Symbol abstain vote.svg Abstain, I prefer {{m}} but I see no reason to 'ban' {{term}}. Renard Migrant (talk) 18:50, 7 December 2014 (UTC)
    @Renard Migrant: Would it be accurate to say you support "Replacing all uses of Template:term with Template:m" but not "subsequently discontinuing Template:term"? --Dan Polansky (talk) 18:56, 7 December 2014 (UTC)

Decision


Templates context and label

  • Polling on: Clarifying which template to use to tag definition lines as "countable", "transitive", "colloquial", "geography" and the like. Currently available templates are {{context}}, {{cx}}, {{label}}, {{lb}}. The choice is about template name, not about syntax of its parameters. Two choices are presented: one between (context, cx) and (label, lb), and another one between long form (context, label) and short form (cx, lb).

    The syntaxes might look like this, assuming the language as the first parameter of the template:

    • {{context|es|colloquial}}
    • {{cx|es|colloquial}}
    • {{label|es|colloquial}}
    • {{lb|es|colloquial}}

I prefer label over context

  1. Symbol support vote.svg Support Because {{label}} takes the language as the first parameter, whereas {{context}} requires lang=. —CodeCat 19:25, 2 September 2014 (UTC)
    The vote text makes it clear this is about the template name, not about the parameter order and syntax. We can make {{context}} behave exactly like {{label}}, yielding syntax like {{context|es|colloquial}}. --Dan Polansky (talk) 17:28, 3 September 2014 (UTC)
  2. Symbol support vote.svg Support More accurate when dealing with grammatical categories like "transitive" or "passive", or "with accusative", and still fits the idea of a context semantically. ObsequiousNewt (ἔβαζα|ἐτλέλεσα) 00:20, 25 November 2014 (UTC)
  3. Symbol support vote.svg Support embryomystic (talk) 23:37, 6 December 2014 (UTC)

I prefer context over label

  1. Symbol support vote.svg Support We want to make it clear that you aren't supposed to write definitions like "(tree) oak", and context does a better job at that. -- Liliana 10:57, 30 August 2014 (UTC)
    That could be addressed by template documentation. And how often has this been a problem in practice? Keφr 15:28, 2 November 2014 (UTC)
  2. Symbol support vote.svg Support I prefer to make clear that register and other context information is the primary purpose of information so position on a definition line. DCDuring TALK 16:51, 25 October 2014 (UTC)
  3. Symbol support vote.svg Support, and in addition, I'd like to note that I prefer slang and certain other things being decoupled from context. Purplebackpack89 14:16, 2 November 2014 (UTC)
    Nonsensical. Of all things, "slang" is definitely a context label. Keφr 15:28, 2 November 2014 (UTC)
    @Kephir:: And? The main jist of my comment is I believe context covers too many things that would be better covered in other templates Purplebackpack89 22:55, 28 November 2014 (UTC)

I prefer short template name over long template name

  1. Symbol support vote.svg Support Dan Polansky (talk) 09:50, 30 August 2014 (UTC) I dislike the introduction of {{context}}, but if we need to have a template before "colloquial" and the like, let it be short. --Dan Polansky (talk) 09:50, 30 August 2014 (UTC)
  2. Symbol oppose vote.svg OpposeCodeCat 19:27, 2 September 2014 (UTC)
  3. Symbol support vote.svg Support I don't care whether the short name is botically changed afterward to a longer, more communicative name: I just like to save keystrokes. DCDuring TALK 16:47, 25 October 2014 (UTC)
  4. Symbol support vote.svg Support Ivan Štambuk (talk) 21:49, 26 October 2014 (UTC)
  5. Symbol abstain vote.svg Abstain Too amorphous, depends on what the short and long template names are Purplebackpack89 14:17, 2 November 2014 (UTC)
  6. Symbol support vote.svg Support, but also in agreement with This below. ObsequiousNewt (ἔβαζα|ἐτλέλεσα) 00:20, 25 November 2014 (UTC)

I prefer long template name over short template name

  1. Symbol support vote.svg Support again, for clarity purposes. -- Liliana 10:57, 30 August 2014 (UTC)
  2. Symbol oppose vote.svg OpposeCodeCat 19:27, 2 September 2014 (UTC)

Oppose the poll

  1. Why can't we have them all, as redirects to the one central template? Or is this vote to choose a "canonical" name for the template? This, that and the other (talk) 07:39, 31 August 2014 (UTC)
    This is a poll about which template editors prefer. This poll does not propose any deletion of a template. A participant in the poll may clarify in their comment that they oppose deletion of any template. Right now, at least one editor is performing a particular conversion in the mainspace, and we do not know whether that conversion matches editor preferences. --Dan Polansky (talk) 15:55, 31 August 2014 (UTC)
  2. Moo. Keφr 14:05, 4 September 2014 (UTC)

Abstain


Migrating from Template:context to Template:cx

  • Voting on: Replacing all uses of {{context}} with {{cx}}. First making sure {{cx}} is unused, then changing {{cx}} to use "cx|en|colloquial" syntax instead of "cx|colloquial|lang=en" syntax, then furnishing {{cx}} with the fastest code currently available in Wiktionary templates and modules for the purpose, and then performing the replacement. No proposal is being made about whether {{context}} should be retained afterwards, e.g. to simplify reading of revision history.
  • Rationale: For a rationale, see Wiktionary talk:Votes/2014-08/Migrating from Template:context to Template:cx#Rationale. The voters only vote on the proposed action, not on the rationale.
  • Vote starts: 00:01, 5 October 2014 (UTC) (delayed by one month)
  • Vote ends: 23:59, 5 November 2014 (UTC)
    • Vote extended to 23:59, 30 December 2014. (UTC) --Dan Polansky (talk) 22:51, 28 November 2014 (UTC)

Support

  1. Symbol support vote.svg Support Dan Polansky (talk) 08:40, 5 October 2014 (UTC)
  2. Symbol support vote.svg Support --Anatoli T. (обсудить/вклад) 00:49, 3 December 2014 (UTC)

Oppose

  1. Symbol oppose vote.svg Oppose due to the fact that it needlessly complicates things. Why are we moving templates away from things that can be remembered again? "context" is a lot clearer to newer editors to use than "cx", and always will be. --Neskaya sprecan? 17:50, 29 October 2014 (UTC)
  2. Symbol oppose vote.svg Oppose Whenever you migrate a template, you kill a kitten and drive an editor off the project. Purplebackpack89 19:43, 2 December 2014 (UTC)
    No, I actually read a study this the other day. There is no statistically significant correlation between template migration and kitten deaths. --WikiTiki89 00:44, 3 December 2014 (UTC)
    I think you missed the point. The point is template migration confuses the heck out of editors. IMO, it's in the top 5-10 of reasons editors throw up their hands and leave the project. So it should be avoided whenever possible. It's possible to avoid it here. Purplebackpack89 14:33, 3 December 2014 (UTC)
    I think you missed my point: I was joking. --WikiTiki89 15:52, 3 December 2014 (UTC)

Abstain

  1. Moo. Keφr 09:21, 5 October 2014 (UTC)
    What an interesting self-disclosure. As per moo, are you (a) a cow, (b) a bull or (c) a foolish woman? --Dan Polansky (talk) 09:23, 5 October 2014 (UTC)
    I think he means mu#Etymology 2. —Aɴɢʀ (talk) 13:11, 5 October 2014 (UTC)
  2. Symbol abstain vote.svg Abstain There are too many options that are not accounted for in this vote. --WikiTiki89 00:54, 3 December 2014 (UTC)
  3. Symbol abstain vote.svg Abstain because polls are evil. —Aɴɢʀ (talk) 14:34, 3 December 2014 (UTC)
    Policy votes in English Wiktionary -- transparent, fair, open-to-discussion and timely collective decision making enabling broad editor participation since 2006. --Dan Polansky (talk) 17:10, 5 December 2014 (UTC)
    Policy votes in English Wiktionary — replacing discussion and consensus-seeking with divisiveness and the tyranny of the majority since probably earlier than 2006. —Aɴɢʀ (talk) 20:35, 5 December 2014 (UTC)
    I ask the reader to check English Wiktionary votes to verify the presence of plentiful open discussion (a) before the votes in locations referenced by the votes, (b) directly on the vote pages, and (c) on the talk pages of the votes. I also ask the reader to verify in the votes that plain majority does not get to decide in English Wiktionary votes as evidenced by the closure of the votes; we actually decide by supermajority, at the very least 2/3 of voters, although higher thresholds have been mentioned. I also submit to the reader that I saw no unjust or cruel rule imposed by the votes, so no case of "tyranny" can be confirmed. To the contrary, I point to my favorite vote Wiktionary:Votes/pl-2010-05/Names of specific entities, which relaxed stringent requirements on proper names required by a vocal minority; via that vote, a rule by a minority via inflexible application of unvoted-on policy in RFV process was removed. --Dan Polansky (talk) 21:58, 5 December 2014 (UTC)

Decision


Renaming rhyme pages

Support proposal 1

  1. Symbol support vote.svg Support Even if it wasn't a fait accompli I would still have supported it. This, that and the other (talk) 10:24, 23 September 2014 (UTC)
  2. Support Having a slash (/) after the language name is a natural extension of our appendix names like "Appendix:Frankish/kawa". Keφr 07:55, 9 December 2014 (UTC)

Oppose proposal 1

  1. Symbol oppose vote.svg Oppose Having colon (:) after the language name is a natural extension of our category names like "Category:en:Physics". --Dan Polansky (talk) 19:58, 23 September 2014 (UTC)
    But we only do that with language codes, while the Rhymes pages currently use language names. --WikiTiki89 20:19, 23 September 2014 (UTC)

Abstain from proposal 1

  1. Symbol abstain vote.svg Abstain It really makes no difference to me. --WikiTiki89 14:50, 23 September 2014 (UTC)

Support proposal 2

  1. Support, though quite weakly, on the grounds that it makes some string processing simpler. The hyphen carries zero entropy; or in plain English, everyone already knows that we are dealing with suffixes, indicating that explicitly is unnecessary. If we ever find ourselves making pages in rhymes namespace which are not rhymes lists, I might change my mind. Keφr 07:55, 9 December 2014 (UTC)
    You mean that Lua code does not need to drop the leading "-"? That is very straightforward for Lua code to do. Is that the reason why we should not prioritize human ease of recognition of what is presented on the user interface? --Dan Polansky (talk) 12:28, 14 December 2014 (UTC)

Oppose proposal 2

  1. Symbol oppose vote.svg Oppose Makes it clear that we're talking about suffixes. This, that and the other (talk) 10:24, 23 September 2014 (UTC)
  2. Symbol oppose vote.svg Oppose What he^ said. --WikiTiki89 14:50, 23 September 2014 (UTC)
  3. Symbol oppose vote.svg Oppose The rhyme pages are organized by what is an auditory analogue of a suffix. Since suffixes are usually denoted with a leading dash (e.g. -ness), using dash in rhyme page names seems natural. --Dan Polansky (talk) 19:58, 23 September 2014 (UTC)
  4. Symbol oppose vote.svg Oppose What they↑ said.​—msh210 (talk) 12:09, 15 October 2014 (UTC)

Abstain from proposal 2

Decision


Entries which do not meet CFI to be deleted even if there is a consensus to keep

  • Voting on: making it official policy to delete entries which do not meet WT:CFI to be deleted even if there is a consensus to keep.

Rationale: deletion debates have turned into a matter of personal opinion, whether certain editors like a certain entry, made it themselves, etc. This vote would meet that admins have an obligation to delete entries that do not satisfy the criteria laid out in WT:CFI even if there as a consensus (by which I mean a numerical consensus, by counting the number of votes) to keep the entries. Instead of simply counting up the number of votes, the closing admin should look at the arguments made to see if the entry meets CFI (rather than keep because I made this entry or keep because my mother used this word 20 years ago).

As a result, debates would become about whether an entry meets CFI rather than just about the number of votes an entry gets.

  • Vote starts: 00:01, 24 November 2014 (UTC)
  • Vote ends: 23:59, 23 December 2014 (UTC)

Support

  1. Symbol support vote.svg Support Consensus should reflect CFI. If not, then CFI itself is the problem and it should be modified, not just circumvented whenever people feel like it. —CodeCat 13:28, 24 November 2014 (UTC)
    Then why did User:CodeCat create {{hot word}} on 6 March 2014‎ to label and keep certain words not meeting current CFI, without first changing CFI? --Dan Polansky (talk) 11:23, 14 December 2014 (UTC)
    Why do you ask? —CodeCat 14:38, 14 December 2014 (UTC)
  2. Symbol support vote.svg Support Renard Migrant (talk) 18:04, 24 November 2014 (UTC)
  3. Symbol support vote.svg Support. — Ungoliant (falai) 21:37, 24 November 2014 (UTC)
  4. Symbol support vote.svg Support Agree with CodeCat. I also more or less agree with the opposing comment that it's impossible to implement, but still support in theory. Equinox 21:55, 24 November 2014 (UTC)
  5. Symbol support vote.svg Support It would be nice if arguments in favor of keeping were couched in terms of CFI. CFI can be changed. DCDuring TALK 18:19, 7 December 2014 (UTC)
  6. Symbol support vote.svg Support Consensus should reflect CFI. Leasnam (talk) 10:49, 11 December 2014 (UTC)
    It is the other way around: CFI should be updated to reflect consensus. Since we have not managed to make CFI reflect consensus so far, rigid application of CFI is undesirable. We have plentiful evidence about the history and origin of CFI, and we know that it did not originate by consensus. --Dan Polansky (talk) 09:31, 14 December 2014 (UTC)
    Right, CFI should reflect consensus. —Stephen (Talk) 20:37, 14 December 2014 (UTC)

Oppose

  1. Symbol oppose vote.svg Oppose Impossible to implement. Requires little or no ambiguity of CFI; CFI will likely forever remain ambiguous and will probably never satisfactorily address every possible case. I continue to believe that RfD discussions should be decided primarily on consensus of the participants, and am disheartened that this proposal could potentially lead to the deletion of a greater number of articles. Purplebackpack89 05:15, 24 November 2014 (UTC)
    • Query:
    How often do we get situations where there is consensus to keep a term, but that consensus is in opposition to WT:CFI?
    If there is consensus to keep a roterm, there should presumably be a rationale, something based on Wiktionary norms and policies that backs up this consensus. If CFI does not describe these norms and policies sufficiently, then the error is in the CFI.
    Note: We do not need CFI to be explicit in all details and to cover all cases. That would be ideal, but that just ain't gonna happen in the real world: process documentation never exactly matches reality, that's just a given. That said, CFI can be updated to cover the broader majority of cases, and to leave wiggle room for those cases that it does not cover. The fact that CFI cannot be revised to describe everything is not a valid argument for ignoring it entirely. ‑‑ Eiríkr Útlendi │ Tala við mig 06:41, 24 November 2014 (UTC)
    @Renard Migrant:: How many? This is really a question for you, not I. I know you believe it to be a significant number, and a too-high one, but I don't know what that number. Purplebackpack89 21:24, 3 December 2014 (UTC)
    Of course it comes down to interpretation of CFI. The question I would ask myself is how many entries are kept where there's no interpretation of CFI to justify them. It would be very difficult to talk about numbers. Maybe a couple a week in recent weeks? Renard Migrant (talk) 21:45, 3 December 2014 (UTC)
  2. Symbol oppose vote.svg Oppose We should add various other rules to CFI, namely - translation target when an English term is a SoP but it is a single term in a few foreign languages, Lemming test - when a term is used in certain dictionaries (the list can be agreed on). It still won't cover all situation, like gas station, mobile phone, foreign language, nominative case, lung cancer, etc. where a vote would still be required. Translation target and Lemmings would heavily reduce valuable time spent on RFD's. --Anatoli T. (обсудить/вклад) 06:54, 24 November 2014 (UTC)
    • @Atitarev: It sounds like you're saying that CFI should be updated, in order to make CFI more useful in evaluating RFDs. This sounds like you don't oppose the underlying idea -- that CFI should be used for arbitration, rather than just group agreement without regard for CFI.
    Am I understanding you correctly here? If so, your vote would be support or abstain, no? ‑‑ Eiríkr Útlendi │ Tala við mig 07:59, 24 November 2014 (UTC)
    Yes, until CFI is updated to include the above two, I am opposing. I would change or reconsider, if there are changes to CFI. --Anatoli T. (обсудить/вклад) 08:02, 24 November 2014 (UTC)
    I've always supported the proposal of such a policy (allow words from other major dictionaries). I would oppose it but, I'm not convinced it would be massively unpopular. I'm surprised nobody's proposed it at all in vote form. Renard Migrant (talk) 18:09, 24 November 2014 (UTC)
    Yeah, I've been meaning to get around to it. But if I propose it, that'll automatically be 2-3 oppose votes right there. BTW, what's the answer to Eirikr's question about how often there is a consensus to ignore CFI? Purplebackpack89 19:00, 24 November 2014 (UTC)
  3. Symbol oppose vote.svg Oppose If there is a consensus to keep a word and CFI states that it should be deleted, then CFI must be changed accordingly, because CFI should reflect this consensus. Discussions are useful when intelligent arguments can be exchanged: if reflection is forbidden because CFI must be applied blindly, then discussions are useless. Lmaltier (talk) 21:01, 24 November 2014 (UTC) In other terms, the sequence should not be: 1. delete. 2. improve CFI. 3. restore (this is illogical). but rather: 1. take the keep decision. 2. discuss on how CFI should be improved to reflect this consensus. 3. improve CFI. Lmaltier (talk) 21:18, 24 November 2014 (UTC)
    CFI has a much stronger consensus than a single RFD discussion. So it's not illogical; it would be illogical if the consensus of the few people who participated in the RFD would trump the consensus of the dozens of people who were involved in shaping CFI over the years. —CodeCat 21:34, 24 November 2014 (UTC)
    • Similar to CodeCat's argument, I would caution strongly against assuming that consensus should be taken at face value just because it's consensus. Iff the consensus is based on reasoned argument, and that reasoned argument calls for an outcome in contravention of CFI, then yes, CFI probably needs changing. If, however, the consensus is not backed up by reasoned argument, then this consensus must be ignored in favor of CFI, which at least has been through an extensive vetting process that (presumably) involves reasoned argument and consensus. ‑‑ Eiríkr Útlendi │ Tala við mig 21:59, 24 November 2014 (UTC)
      • Of course, I fully agree with you. Lmaltier (talk) 17:50, 25 November 2014 (UTC)
        • I think that's more of an argument for deleting CFI all together and just going purely with consensus. I mean, how could you possibly update CFI after every deletion debate. And more importantly, why bother? Renard Migrant (talk) 12:02, 28 November 2014 (UTC)
          • There's a happy medium between the two poles you posit. It's called making CFI a guideline. Something that's generally accepted, but need not be followed to the letter. Purplebackpack89 22:29, 3 December 2014 (UTC)
        • Anyway, nothing is perfect, and certainly not CFI. CFI must be improved with time. Lmaltier (talk) 06:50, 8 December 2014 (UTC)
  4. Symbol oppose vote.svg Oppose We can create policies. We can't compel everyone to interpret said policies in precisely the same manner. There will always be cases in which it isn't clear-cut whether or not a term meets CFI because not everyone has the same interpretation of things like "sum of parts." Such cases require a subjective judgment about the term's fitness for inclusion to be made. The RfD process exists so that all Wiktionarians can partake in such determinations, sharing their individual thoughts on the inclusion-worthiness of nominated words, and thus help reach a consensus. Allowing for the outcome of RfD discussions to be overridden at the personal discretion of administrators would be completely contrary to the community-driven nature of this project. -Cloudcuckoolander (talk) 08:55, 26 November 2014 (UTC)
    Allowing for the outcome of RfD discussions to be overridden at the personal discretion of administrators” -- I don't follow you. Where does administrator whim come into the discussion? ‑‑ Eiríkr Útlendi │ Tala við mig 10:03, 26 November 2014 (UTC)
    When it's closed. Purplebackpack89 17:09, 26 November 2014 (UTC)
    "Instead of simply counting up the number of votes, the closing admin should look at the arguments made to see if the entry meets CFI."
    That means that, under this proposal, the closing admin would make a subjective judgment about which arguments hold the most merit, and thus decide whether the entry warrants keeping. But there is no single correct interpretation of CFI (particularly SOP). Two people can look at the same entry and reach differing conclusions about its inclusion-worthiness. And that's why the RfD process allows us to weigh different viewpoints and reach a consensus. Leaving it up to admin whim, in short, would be a disaster. It would be giving the closing admin license to favour arguments with which they agree over arguments with which they disagree, and thus give them the power to impose their own personal personal preferences over community consensus. -Cloudcuckoolander (talk) 22:47, 27 November 2014 (UTC)
    But if the result of RFD is consensus, then how do we know what that consensus is unless someone decides what it is? —CodeCat 23:03, 27 November 2014 (UTC)
    No one needs to decide that consensus exists. It will be objectively apparent. -Cloudcuckoolander (talk) 23:24, 27 November 2014 (UTC)
    Nothing will ever be apparent to Purple unless it is what he wanted. Equinox 02:51, 28 November 2014 (UTC)
    What's consensus is apparent to me, thank you very much. I see no reason why you needed to say it wasn't. This is about CFI, not about me. Purplebackpack89 14:19, 28 November 2014 (UTC)
    Symbol oppose vote.svg Oppose (This is Zeggazo btw). I believe the existing process is fine. There are some words which are very common in blogosphere but have unluckily not been picked up in permanently recorded media. If we allow some grey areas wiktionary will get more of these blogosphere type words. 2.96.221.56 10:23, 28 November 2014 (UTC)
    I don't think unregistered users are allowed to vote. If I knew the name of the vote I'd look it up. Renard Migrant (talk) 11:44, 28 November 2014 (UTC)
    Indeed they are not (the instructions cannot be understood any other way). Struck. Keφr 09:51, 29 November 2014 (UTC)
    See Wiktionary:Votes/2010-04/Voting policy. --Dan Polansky (talk) 11:47, 29 November 2014 (UTC)
  5. Symbol oppose vote.svg Oppose --Dan Polansky (talk) 22:43, 28 November 2014 (UTC). It must be possible to override CFI on a case-by-case basis, as e.g. for olinguito. The long-standing tradition in RFD of keeping terms for which there is no consensus for deletion should be continued. Translation target should continue to be a consideration for those who feel this is a valid extra-CFI concern, as well as lemmings (keep a possibly sum-of-parts term when certain monolingual dictionaries, not WordNet, include the term; see also the Beer parlour discussion), and set phrase. The CFI as a whole as it is without modification is not supported by consensus, and the principle of consensus should prevail over any statutory document like CFI. That said, CFI should be used as a recommendation (rather than an inviolable rigid rule), with exceptions being justified, and thus should not be entirely ignored when deciding whether to keep an entry. Each argument for keeping should be based on CFI as far as possible. The non-rigid approach I have outlined seems to be implemented in WT:ELE as per WT:ELE#Flexibility, a section that is lacking from CFI: "While the information below may represent some kind of “standard” form, it is not a set of rigid rules." --Dan Polansky (talk) 22:43, 28 November 2014 (UTC)
    If this vote fails, what we oughta do is demote CFI from policy to guideline. I think you're correct that most of the major editors here are dissatisfied with CFI as written. Having the "what's in, what's out" page as policy and not guideline is unusual for a project anyway. If CFI was demoted to guideline, that would allow the overriding you want. Purplebackpack89 02:14, 29 November 2014 (UTC)
    What is a "guideline"? Keφr 19:13, 29 November 2014 (UTC)
    A guideline is one step down from policy. The main difference is that policy has to be followed 100% of the time, but guidelines don't. Purplebackpack89 19:38, 29 November 2014 (UTC)
    I don't think we'll need to 'demote' it. It'll become a lame duck. In fact I don't think any policies will have any weight any more. People will just say if there's no vote forcing me to apply this policy, why bother? Renard Migrant (talk) 22:16, 29 November 2014 (UTC)
    You seem to be taking the de facto, and I the de jure. Purplebackpack89 00:20, 30 November 2014 (UTC)
    Re: "I don't think any policies will have any weight any more.": I don't agree with this all-or-nothing view. CFI is a useful policy and is largely followed, with exceptions being argued on a case-by-case basis. The entries kept despite current CFI are fairly few and are mostly exceptions to WT:CFI#Idiomaticity rather than WT:CFI#Attestation; have a look e.g. at google:"translation target" site:en.wiktionary.org and google:"set phrase" site:en.wiktionary.org to see how many they are. "Sum of parts" is still a valid reason for nomination for RFD, just that multiple editors are in the habit of examining redeeming qualities of terms so nominated. CFI still does a useful service as a policy applied with a certain, fairly low, flexibility. --Dan Polansky (talk) 09:43, 30 November 2014 (UTC)
    There's a term for a policy with flexibility. It's called a guideline. And CFI should be one, preferably one with SOP stripped from it. The problem with CFI being policy is not only the lack of flexibility afforded, but the need for it to apply universally. I think it's clear there are blind spots in CFI. If CFI were a guideline, that wouldn't be as much of an issue, and we could address the blind spots as they come up with routine consensus. Purplebackpack89 21:51, 3 December 2014 (UTC)
    If there is truly "routine consensus" then you ought to have no problem getting it voted in as policy! Equinox 22:08, 3 December 2014 (UTC)
    You seem to be arguing that I posit that WP:IDIOMWT:IDIOM be merged into WP:CFIWT:CFI. There's no reason for CFI to mention every little thing that survived an RfD. Far better to have it be a guideline with gray areas that can just be addressed when they come up. Purplebackpack89 22:21, 3 December 2014 (UTC)
    What is "WP:IDIOM" and "WP:CFI"? Keφr 22:33, 3 December 2014 (UTC)
  6. Symbol oppose vote.svg Oppose The situation does not arise. If there's a consensus to keep, then there's a consensus that the entry does meet WT:CFI. CFI has more than one possible interpretation; it's not objective, nor should it be. —Aɴɢʀ (talk) 07:32, 29 November 2014 (UTC)
    Re: "If there's a consensus to keep, then there's a consensus that the entry does meet WT:CFI": Not really. If I vote based on translation target consideration and I know that it is not part of WT:CFI, then my vote does not indicate that I want to keep the entry via CFI. It is fair to say that translation target consideration is not part of current CFI. --Dan Polansky (talk) 08:25, 29 November 2014 (UTC)
    Yeah this is clearly false; I could vote to delete an entry based on a prejudice because of who created the entry; would you argue that that's part of CFI? If so where is it? Renard Migrant (talk) 13:17, 29 November 2014 (UTC)
    If you wanna talk about stuff like that, look up how often "redundant" and "redundancy" appear in CFI. Purplebackpack89 19:40, 29 November 2014 (UTC)
    Why? Renard Migrant (talk) 22:16, 29 November 2014 (UTC)
    Because neither word is used in CFI. There are a number of legitimate arguments that you, I, or anyone would agree to that are not explicitly spelled out in CFI Purplebackpack89 00:20, 30 November 2014 (UTC)
    Indeed. In fact CFI says nothing about content being correct. Renard Migrant (talk) 12:26, 30 November 2014 (UTC)
    Maybe I missed some sarcasm, but I think "correctness" is covered by WT:CFI#Attestation. Keφr 12:49, 30 November 2014 (UTC)
    I suppose it is. Renard Migrant (talk) 13:06, 30 November 2014 (UTC)
    Redundancy and correctness are different issues Purplebackpack89 16:01, 30 November 2014 (UTC)
    I fully agree (in case that wasn't clear). Accord to CFI, there's no reason not to have two identical meanings, because if one meets CFI, so does the other. Renard Migrant (talk) 16:49, 30 November 2014 (UTC)
  7. Symbol oppose vote.svg Oppose I can't think of any good reason to support this proposal. The main problem with CFI is that the rules are overinterpreted or misinterpreted by beady-eyed would-be deletionists. There is nothing in CFI which specifically says that SoP entries should be deleted. Yet birthday present was deleted and Christmas present survived for devious reasons. I know common sense should prevail, thus red dress doesn't qualify, but little black dress does, and little black number has been overlooked. One problem I find is with translation targets, especially from languages where compound words are commonplace: I was trying to find a home for barnesoldat (child soldier) on the English side, and had to settle for an entry under soldier and hope that it would be seen there. So I think provision should be made in CFI for translation targets. Donnanz (talk) 11:50, 8 December 2014 (UTC)
    Actually, [[Christmas present]] was deleted in the nominated sense. That another sense was considered idiomatic is a separate matter. Keφr 12:08, 8 December 2014 (UTC)
    I think that using soldier for the translation barnesoldat was the right place. I fully agree with you, except for using translation target as a criterion in CFI, which would make the objective of the project very confusing (e.g. thousands of little ... pages would be created). The only criterion should be does this belong to the vocabulary of the language?. This would be a clear and simple basic principle. Lmaltier (talk) 22:26, 10 December 2014 (UTC)
    I am happy for you agreeing with me, but why are you replying to me right here? Keφr 18:10, 11 December 2014 (UTC)
    I think Lmaltier's comment was directed at me. Donnanz (talk) 18:42, 11 December 2014 (UTC)
    I agree. That's what paper dictionaries use, limited by the amount of paper they have. Purplebackpack89 23:12, 10 December 2014 (UTC)
    Paper dictionaries are limited by what they can squeeze into one volume. The more comprehensive dictionaries are published in more than one volume, and are rather expensive I imagine. The Oxford Dictionary of English has 2088 pages; my Duden Deutsches Universalwörterbuch has 2016 pages and is falling apart due to poor binding. An online dictionary such as Wiktionary doesn't have this restriction with modern technology, and can be super-massive and cater for translation targets. It may not be as bad as you fear, Lmaltier. Donnanz (talk) 09:45, 11 December 2014 (UTC)
    Of course, it would be feasible, I agree. But it would be confusing: users of a dictionary don't look for translations targets, they look for a term of a language. For the same reason, I would group all phrasebook entries in topical appendices and remove them for the mainspace, but I would add attested words from fictional universes to the mainspace from appendices (with special rules for proper nouns, of course). Lmaltier (talk) 21:29, 11 December 2014 (UTC)
    Kindersoldat appears in Duden online, but not my copy; this may prove my point about online dictionaries, they can be updated more quickly than paper dictionaries anyway - in fact paper dictionaries may be phased out in the future, who knows?. Donnanz (talk) 10:15, 11 December 2014 (UTC)
    Paper dictionaries are likely to be used less and less, but they keep real advantages: 1. The pleasure of paper book pages. 2. They are available at any moment, no need to start a computer. 3. They must be bought once, but consulting them is 100% free. We are not bought, but users consulting us spend some money at each consultation (think to power they use). Lmaltier (talk) 21:36, 11 December 2014 (UTC)
    Paper dictionaries have a lease on life until we adopt the lemming principle. As long as there are words print dictionaries have that we don't, people will have to buy them rather than get those words here for free. Purplebackpack89 21:50, 11 December 2014 (UTC)
  8. Symbol oppose vote.svg Oppose —Stephen (Talk) 03:06, 9 December 2014 (UTC)
    Stephen: Any particular reasons? Keφr 11:29, 14 December 2014 (UTC)
    CFI has too many flaws. It was written and edited by inexperienced amateur lexicographers. If we start to attract editors with more experience in lexicography, I don’t think they should be hobbled by earlier editors with little knowledge of the field. CFI can be edited and rewritten, but it seems to be rather difficult to make any substantive changes to it. Perhaps if there is a consensus to keep some terms, it will be an incentive to improve CFI. —Stephen (Talk) 20:34, 14 December 2014 (UTC)
    Though a few users argued that habitually ignoring CFI at the whim of circumstance will disincentivise improving CFI (as in "why bother conducting bureaucracy over updating something that is ignored on a daily basis anyway?"). Your comment on that? Keφr 21:12, 14 December 2014 (UTC)
    I think it’s nonsense. The difficulty in getting enough agreement to improve CFI, coupled with the problem of inexperienced lexicographers trying to come up with improvements, is what disincentivizes improving CFI. —Stephen (Talk) 23:06, 14 December 2014 (UTC)
    How much incentive we have to fix CFI doesn't override my belief that CFI is broken beyond repair. There's no way it's ever going to be able to mention every reason we've used to keep an article. This is why it is foolish for CFI to be policy. Purplebackpack89 23:35, 14 December 2014 (UTC)
    Nonsense. It's true that WT:CFI can never specify every case, but it doesn't have to, as long as it doesn't claim to. Some things can be explicitly included by policy, and some things can be explicitly excluded by policy, and some things can be (either explicitly or implicitly) left open by policy. In fact, there are already some cases where WT:CFI explicitly doesn't specify whether or not they can be included: see Wiktionary:Criteria for inclusion#Names of specific entities. —RuakhTALK 05:08, 15 December 2014 (UTC)

Abstain

  1. I abstain for reasons I already stated in the linked BP discussion. Keφr 21:40, 24 November 2014 (UTC)
  2. Symbol abstain vote.svg Abstain --Romanophile (talk) 18:04, 26 November 2014 (UTC)
  3. Symbol abstain vote.svg Abstain We've already had enough problems with admins enforcing their unilateral interpretations of the CFI by listing words at WT:RFV and making up rules that the citations supposedly have to meet. The proposal here seems to be that even admins who would prefer to make decisions consensually, will instead be expected to make them unilaterally. I definitely recognize the problem that this proposal is trying to address, and I agree with most of the "support" voters' comments — if there is a consensus that something should be kept, then we should fix WT:CFI rather than flout it — but I just can't bring myself to support the proposal as written. —RuakhTALK 22:01, 14 December 2014 (UTC)

Decision


Require third-party closures of RfD discussions

  • Voting on: At present, it is perfectly acceptable for someone to close an RfD they started or that they voted in. I believe that this is a conflict of interest and that deletion and verification discussions should be closed by an uninvolved editor (who need not be an administrator if the consensus is anything but deletion of an entire entry). Some would say our community is not large enough for this, but I would respectfully disagree. Speedy deletions would be exempt from this. Purplebackpack89 00:35, 18 November 2014 (UTC)

I propose to change the text of the head of RfD to read as (new text in bold italic):

  • Closing a request: A request can be closed by an uninvolved editor when a decision to delete, keep, or transwiki has been reached, or after the request has expired.


  • Vote starts: 00:01, 25 November 2014 (UTC)
  • Vote ends: 23:59, 24 December 2014 (UTC)

Support

  1. Symbol support vote.svg Support as nom Purplebackpack89 16:00, 25 November 2014 (UTC)
  2. Symbol support vote.svg Support Ivan Štambuk (talk) 21:48, 30 November 2014 (UTC)
  3. Symbol support vote.svg Support This is the policy for closing article deletion discussions on Wikipedia. I don't see why we should do things differently. The smaller size of our editor pool does not justify dispensing with such a basic principle as striving to avoid conflicts of interest. Fairness and transparency outweigh convenience. Also note that the proposal only holds that the closer not be someone who "started" or "voted in" the RfD. I don't see a problem with closing admins commenting in RfD discussions - e.g. giving information or views for others to consider — but not with them being actively involved in shaping the outcome of the discussion. -Cloudcuckoolander (talk) 01:30, 1 December 2014 (UTC)
    An editor abstaining from posting a boldfaced vote is not guaranteed to have no stance or bias. Under the proposed regime, it would be advantageous to not post anything, and have a final say when closing the nomination. There are no "conflicts of interest" in RFD in the sense of business administration and government; people cannot buy shares in words, collect dividents per word per year, and thereby have an objectively existing benefit deriving from keeping the words. Even if such conflicts of interest existed, the proposed regime would do nothing to limit their harmful influence. --Dan Polansky (talk) 20:28, 1 December 2014 (UTC)
  4. Symbol support vote.svg Support in principle. Donnanz (talk) 13:46, 1 December 2014 (UTC)
  5. Symbol support vote.svg Support We have enough participants to allow this. DCDuring TALK 18:20, 7 December 2014 (UTC)
    There are enough RFD participants, but few editors actually help to close RFDs. I know of an editor who posts a lot of RFD nominations but almost never closes any. By contrast, bd2412 does not post many nominations but does a lot of work in closing them. It seems not very nice to punish bd2412 for helping with the key bottleneck action of the process--closing--by preventing him from boldface voting. --Dan Polansky (talk) 18:41, 7 December 2014 (UTC)
    Actually the wording is "uninvolved editor" — which probably means they should not even participate in the discussion proper. And I disagree even about there being enough RFD participants. (Also: since I was curious who it is that you might be referring to, I compiled a list of most frequent RFD initiators. Counting closures will be harder, unfortunately.) Keφr 20:14, 7 December 2014 (UTC)
    Whether it's possible and whether it's desirable are two different things. Renard Migrant (talk) 20:54, 7 December 2014 (UTC)
    Could you disambiguate "it"? Keφr 22:32, 7 December 2014 (UTC)
    Whether it's possible to have uninvolved closes and whether it's desirable to have uninvolved closes are two different things.Purplebackpack89 16:32, 9 December 2014 (UTC)

Oppose

  1. Strong oppose, for the following reason.
    1. A small number of editors do most of the RfD closures. I happen to be one of them. Discussions tend to linger for many, many months before someone gets around to closing them, and putting additional restrictions on closure would eliminate some of the more active participants in the page from keeping it reasonable. To my knowledge, no one has ever suggested that I have closed a discussion incorrectly due to a bias derived from my involvement in the discussion. To the contrary, I have frequently closed discussions wherein I have participated, and where the closure went against my expressed preference. In fact, I am not familiar with a situation where any editor has been claimed of making a closure biased by their own participation in the discussion.
    2. As has been pointed out elsewhere, under such a rule, potential closers who do have a personal preference for an outcome may merely avoid participating in the relevant discussion so that they will be free to close it as they prefer.
    3. Our discussions (and their closures) are completely public and transparent, and our rules require that a closed discussion be left on the page for a week following the closure. There is, therefore, ample time for an objection to be raised following the close of a discussion, if concerns about closer bias need to be aired.
    4. Though we do have some contentious discussions, many of our discussions overwhelmingly favor one side. If there is a discussion where a half dozen editors have voted to delete an entry, and only one has voted to keep it, then it shouldn't matter who is closing the discussion in favor of the overwhelming majority. bd2412 T 19:05, 25 November 2014 (UTC)
  2. Symbol oppose vote.svg Oppose per bd2412. Let me take this opportunity to thank bd2412 for his job of closing RFD nominations and helping make the RFD page so much smaller. I encourage editors to close even their own nominations, and do so fairly, with view on the principle of consensus and our common RFD practice. --Dan Polansky (talk) 00:46, 29 November 2014 (UTC)
  3. Symbol oppose vote.svg OpposeΜετάknowledgediscuss/deeds 05:32, 30 November 2014 (UTC)
  4. Symbol oppose vote.svg Oppose. This will just worsen the piling-up of unclosed RFDs. — Ungoliant (falai) 17:43, 1 December 2014 (UTC)
  5. Symbol oppose vote.svg Oppose --Anatoli T. (обсудить/вклад) 01:31, 3 December 2014 (UTC)
  6. Symbol oppose vote.svg Oppose basically per BD. Equinox 01:33, 3 December 2014 (UTC)
  7. Oppose pretty much per what DP said under Cloudcuckoolander's vote. Keφr 21:50, 3 December 2014 (UTC)
  8. Symbol oppose vote.svg Oppose If it ain't broke don't fix it. --Fsojic (talk) 21:56, 3 December 2014 (UTC)
  9. Symbol oppose vote.svg Oppose, I'd oppose if nothing else for the poor drafting. What's an 'uninvolved editor'? Also transwiki is not a valid outcome of an RFD debate. BD2412 covers everything else, see above. Renard Migrant (talk) 20:39, 7 December 2014 (UTC)
    @Renard Migrant: An uninvolved editor is one who didn't start or vote in the deletion discussion. It said that in the head. Purplebackpack89 16:29, 9 December 2014 (UTC)
    But not in the proposed change to the page intro. Keφr 17:31, 9 December 2014 (UTC)
    Also policies are on their way out. If this passed, we could still ignore it by consensus. Renard Migrant (talk) 15:06, 10 December 2014 (UTC)
    @Renard Migrant: I think it's wrong to interpret the impending failure of your vote as an indictment of all policy. What the failure of your vote means is that people are not comfortable with CFI having to be followed 100% of the time. That may mean that they are not comfortable with CFI being policy, but it could still be a guideline (AKA a policy that's allowed to be ignored from time to time by consensus). Purplebackpack89 17:49, 10 December 2014 (UTC)

Abstain

Decision


Adding RFEs to all lemma entries where etymology is missing

Support

Oppose

  1. Symbol oppose vote.svg Oppose --Dan Polansky (talk) 09:03, 14 December 2014 (UTC) I have never seen substantive numbers of etymologies added by people filling in RFE requests. The people whom I saw add larger numbers of etymologies did not go by requests; similarly, the people whom I saw add larger numbers of Latin lemma entries did not go by requests. The presence of RFE in every lemma entry may possibly slightly increase the rate of addition, but only at the cost of flooding Wiktionary mainspace with information-free etymology sections for many years.

    An editor mentioned that placing requests worked well for inflection. I do not know whether this is true, but even if it is true, we have to realize that, for native speakers, inflection is largely trivial and easy-to-fill, whereas etymology requires research in sources unless it is folk etymology.

    As for evidence, I have seen presented no evidence to support claims about efficacy of placing these sorts of request boxes to pages. Such evidence could be collected from dumps. --Dan Polansky (talk) 09:03, 14 December 2014 (UTC)

  2. Symbol oppose vote.svg Oppose I always try to add etymology where I can, but this info is not always available, or incomplete. Entering the etymology of compound words can be a lot easier. The mass addition of RFE to entries tends to make them look untidy. Donnanz (talk) 09:15, 14 December 2014 (UTC)
  3. Symbol oppose vote.svg Oppose, but I wouldn't be opposed to lemmata missing an etymology being placed in a hidden category (according to language, e.g. "Category:English lemmata with no etymology section"). This, that and the other (talk) 06:03, 18 December 2014 (UTC)
  4. Symbol oppose vote.svg Oppose, but I agree that a hidden category is fine. —Mr. Granger (talkcontribs) 15:17, 18 December 2014 (UTC)

Abstain

Decision


User:Anglom for administrator

  • Nomination: I hereby nominate Anglom (talkcontribs) as a local English Wiktionary Administrator. He has worked on Old English, Proto-Germanic, and other modern and older Germanic languages. He seems knowledgeable and willing to help, if asked. DCDuring TALK 03:25, 12 December 2014 (UTC)
  • Vote starts: as soon as the nomination is accepted
  • Vote ends: 03:59, 30 December 2014 (UTC) (4 extra days for days lost due to holidays)
  • Acceptance: I accept this nomination, if you'll have me. I edit mainly Germanic languages, having done some Ancient Greek in the past. I like to fill out entries with all the possible information I can get, if I can get it/have access to it. Sometimes I make mistakes, feel free to point them out to me. Thank you again to User:DCDuring for the nomination. Anglom (talk) 03:59, 12 December 2014 (UTC)
    • Languages: en, ang-1, de-1, gem-pro-2, got-1, ine-pro-1, non-1
    • Timezone: UTC -5

Support

  1. Symbol support vote.svg Support. Good workmanlike editor, will make good use of the tools. Also, first. bd2412 T 04:18, 12 December 2014 (UTC)
  2. Symbol support vote.svg Support. --Vahag (talk) 08:05, 12 December 2014 (UTC)
  3. Symbol support vote.svg SupportAɴɢʀ (talk) 12:31, 12 December 2014 (UTC)
  4. Symbol support vote.svg Support per nom(;)}. DCDuring TALK 21:26, 12 December 2014 (UTC)
  5. Symbol support vote.svg Support Contribs and logs are clean. Nearly 10,000 edits over two years. I'll take the other editors' words for his trustworthiness. --WikiTiki89 23:00, 12 December 2014 (UTC)
  6. Symbol support vote.svg SupportJohnC5 (Talk | contribs) 00:12, 13 December 2014 (UTC)
  7. Symbol support vote.svg Support --Fsojic (talk) 10:54, 14 December 2014 (UTC)

Oppose

Abstain

Decision


Recently ended votes

Votes that have recently ended, to be ultimately moved to /Timeline:

Proposed votes

The following are proposals for new votes, excluding nominations, such that the proposer of the vote prefers that the vote is written collaboratively, or such that the vote appears to require substantial revision. If you have not created a passing vote yet, it is recommended that you use this section and actively solicit feedback by linking to your proposal in discussion; your vote may have a better chance of passing if it is first reviewed.

Votes may linger here indefinitely. If changes in policy make a proposal irrelevant, the voting page will be requested for deletion. On the other hand, you do not have to be the creator to initiate one of the votes below. Place any votes with a live start date in the section above at least a few days before that start date arrives.

Votes intended to be written collaboratively or substantially revised: