Wiktionary:Votes

Definition from Wiktionary, the free dictionary
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

Planned and running votes [edit this list]
Ends Title Status/Votes
Feb 4 User:RileyBot decision?
Feb 8 Uncle G for de-sysop decision?
Feb 14 NORM: 10 proposals 83 (18 people)
Feb 23 EL introduction Symbol support vote.svg5 Symbol oppose vote.svg0 Symbol abstain vote.svg0
Feb 27 Definitions Symbol support vote.svg1 Symbol oppose vote.svg1 Symbol abstain vote.svg0
Feb 28 References Symbol support vote.svg4 Symbol oppose vote.svg0 Symbol abstain vote.svg0
Mar 5 Short blocking policy Symbol support vote.svg4 Symbol oppose vote.svg2 Symbol abstain vote.svg0
Mar 6 Literal translations in translation tables Symbol support vote.svg4 Symbol oppose vote.svg3 Symbol abstain vote.svg0
Mar 7 Translations of taxonomic names Symbol support vote.svg3 Symbol oppose vote.svg0 Symbol abstain vote.svg3
Mar 8 Entry name: sign languages 6 (3 people)
Mar 9 Pronunciation Symbol support vote.svg1 Symbol oppose vote.svg3 Symbol abstain vote.svg0
Mar 10 Notes about pronunciations Symbol support vote.svg1 Symbol oppose vote.svg0 Symbol abstain vote.svg0
Mar 11 Placement of "Usage notes" starts: Feb 11
Mar 12 Language 2 starts: Feb 12
Mar 13 Automated transliterations starts: Feb 13
Mar 14 Entry name 3 starts: Feb 14
Mar 15 Multiple pronunciation sections starts: Feb 15
Mar 16 Placement of "Alternative forms" starts: Feb 16
Mar 17 Removing "Flexibility" starts: Feb 17
Mar 18 Removing "Quotations" starts: Feb 18
Apr 22 Remove "The essentials" starts: Mar 22
Apr 23 Etymology starts: Mar 23

User:RileyBot for bot status

And while I'm asking.. Cleaning of broken and double redirects. -Riley Huntley (SWMT) 09:52, 27 January 2016 (UTC)

  • Vote starts: 09:52, 27 January 2016 (UTC)
  • Vote ends: 23:59, 10 February 2016 (UTC)

Support

Symbol support vote.svg Support as BO. -Riley Huntley (SWMT) 09:52, 27 January 2016 (UTC)
Vote struck due to user not being eligible to vote. —Μετάknowledgediscuss/deeds 17:23, 31 January 2016 (UTC)
  1. Symbol support vote.svg Support this isn't a very exciting vote :P it certainly won't hurt to have a bot for that. -Xbony2 (talk) 01:08, 31 January 2016 (UTC)
  2. Symbol support vote.svg Support --Daniel Carrero (talk) 01:35, 31 January 2016 (UTC)
    Symbol support vote.svg Support as although I'm actually active at the English Wikipedia, and not here at Wiktionary, this seems beneficial. Cheers, SwisterTwister (talk) 07:29, 31 January 2016 (UTC)
    Vote struck due to user not being eligible to vote. —Μετάknowledgediscuss/deeds 17:23, 31 January 2016 (UTC)
  3. Symbol support vote.svg Support -- I don't have a problem with this and Riley has very graciously answered my questions. I do think some consensus should be sought on how often to clean the sandbox since that was an issue last time around. Benwing2 (talk) 00:56, 3 February 2016 (UTC)

Oppose

  1. Symbol oppose vote.svg Oppose Ambiguous nomination, per the Comments below.​—msh210 (talk) 07:45, 2 February 2016 (UTC)
    I apologize for being ambiguous, I assumed I wouldn't have to go into depth about a script that has already been previously approved for other bots to run on this wiki. -Riley Huntley (SWMT) 05:14, 3 February 2016 (UTC)
  2. Symbol oppose vote.svg Oppose See also Wiktionary:Votes/bt-2013-02/User:RileyBot. We don't know how often the bot is going to clean the page. --Dan Polansky (talk) 12:40, 6 February 2016 (UTC)
    If you're opposing simply based on frequency of how often the bot would clean the page, you're more than welcome to join in on the specific discussion in the comment section. -Riley Huntley (SWMT) 20:49, 6 February 2016 (UTC)
    Above all, I don't think SANDBOX needs cleaning by an automaton. But if it should be cleaned, the frequency would have to be specified in the vote as part of the proposal voted on, and the frequency would have to be much lower than every 1 hour since, in Wiktionary:Votes/bt-2013-02/User:RileyBot, Stephen said 6 hours, SemperBlotto said once per day, and Michael Z. said "a couple of hours". From the previous vote, you could have known that the frequency was an issue. From looking at the recenty history at WT:SAND, I get a glimpse of RileyBot test activity, and this confirms to me my opposition. --Dan Polansky (talk) 10:02, 7 February 2016 (UTC)
    Why does RileyBot's test activity confirm your opposition? Wiktionary:Bots#Process specifically states that test edits are a part of the process. There have been 27 edits (33 total, but let's not count my bot) since I opened this bot trial, I think that is backing enough for the need for automation. I agree, there isn't consensus for how often it should be cleaned, but for a proposal to be opened for such a minor thing seems unneeded. I will open a proposal at a 'crats request, but otherwise I'd prefer to establish consensus in the comment section. -Riley Huntley (SWMT) 02:30, 8 February 2016 (UTC)

Abstain

  1. Symbol abstain vote.svg AbstainΜετάknowledgediscuss/deeds 01:34, 31 January 2016 (UTC)
  2. Symbol abstain vote.svg Abstain I just don't think these bot tasks are particularly important or worthwhile. Equinox 00:28, 3 February 2016 (UTC)

Comments

Riley ... I see there was a failed bot vote a few years ago for doing the same thing. The issue there seemed to be how often to clean the sandbox ... you had proposed once an hour, some people thought that was too often. Any ideas how often you're planning on cleaning it? You might want to seek a consensus on the Beer Parlour about how often to do that; if you're willing to do that, you might want to state above that you won't start actually cleaning the sandbox until the issue of how often to clean it is resolved. Doing that might help others be willing to vote for the bot. I think the reason you aren't getting more votes is people don't recognize you here, since you haven't contributed that much; for this reason, you might want to state what your background is (e.g. it looks like you work on maintenance of small wikis).
Standard procedure for all wikimedia projects [that I know of] is one hour, it can be adjusted for longer. I don't see any reason why to extend that time, but it can be modified as desired. A someone who has opened dozens of bot task requests, generally consensus is only taken to a page like above if it is having a major effect, which this is not. In most cases, it'd just be discussed in this very section. Whichever your preference, I am happy to accommodate. -Riley Huntley (SWMT) 20:30, 2 February 2016 (UTC)
I would suggest changing the timing from hourly to when the page has been stale for an hour. If someone is actually working on something and happen to run into the cleaning that would be a bummer for them. - TheDaveRoss 20:41, 2 February 2016 (UTC)
I would agree here. Benwing2 (talk) 00:56, 3 February 2016 (UTC)
Sounds good, the script will run hourly, but it will delay reverting until the page has been stale for an hour. :) -Riley Huntley (SWMT) 05:14, 3 February 2016 (UTC)
@Riley Huntley Also, how will your bot operate when cleaning broken and double redirects? Double redirects should be straightforward to fix, but I'm not quite sure what "broken redirects" refers to. Benwing2 (talk) 06:45, 1 February 2016 (UTC)
My bot would operate using the very script that is used globally by most pywikipediabots. It's a bit difficult to explain if you're not familiar with what broken redirects are, but heres my best attempt: Broken redirects would attempt to be fixed, and if they cannot, they'd be tagged for deletion as they are pages redirecting to a non-existent page. If they are indeed fixable, but the bot cannot detect them as so, they're still being tagged for an admin to manually fix. The broken redirects script only operates in the main and talk namespaces, therefore not interfering with userpages. Double redirects, are as said, straight forward. It will fix any double redirects, but leaves redirect loops/triple redirects to be handled by a human. -Riley Huntley (SWMT) 20:30, 2 February 2016 (UTC)
Sorry, I know what broken redirects are, what I meant is, how do you automatically fix them? Benwing2 (talk) 00:56, 3 February 2016 (UTC)
Ah I see, that makes more sense. I run the double redirects automatic, and then broken redirects I run manually supervised. As aforementioned, this script has been previously approved on this wiki, the bots just aren't actively running the program anymore. If you wish to read more in depth, I recommend mw:Manual:Pywikibot/redirect.py. -Riley Huntley (SWMT) 05:14, 3 February 2016 (UTC)
  • As requested, my bot's background: I operate RileyBot, which has 72,000+ global contributions/edits and eleven bot flags running dozens of tasks. The above three tasks I already perform on at least five other wikimedia projects. My background: I work primarily with the CVN and SWMT teams to monitor contributions globally and assist with small wikis that are struggling. -Riley Huntley (SWMT) 20:30, 2 February 2016 (UTC)
Thanks! Benwing2 (talk) 00:56, 3 February 2016 (UTC)

Decision


Uncle G for de-sysop

  • Voting on: Removing admin and bureaucrat powers from User:Uncle G. No edits or other actions in over 2 years.
    • Psst! I do not have bureaucrat powers. Uncle G (talk) 23:17, 11 January 2016 (UTC)
    • Note that "No edits or other actions in over 2 years" is no longer true.​—msh210 (talk) 21:01, 12 January 2016 (UTC)
  • Vote starts: 00:00, 10 January 2016 (UTC)
  • Vote ends: 23:59, 8 February 2016 (UTC)

Support

  1. Symbol support vote.svg Support Special:Log/Uncle_G suggests Uncle G does not need the tools. The next-to-last logged action is from July 2009, which is about 5.5 years ago. The single last logged action is from 2012.

    Furthermore, the magic keyword {{NUMBEROFADMINS}} gives 102 admins, and therefore, there is no risk that removing admin rights creates unhealthy concentration of power. --Dan Polansky (talk) 11:11, 23 January 2016 (UTC)

  2. Symbol support vote.svg Support per DP and because he gave no response to msh210's ping asking him whether he even had an argument against desysopping, despite having edited the page after msh210 did. —Μετάknowledgediscuss/deeds 20:59, 23 January 2016 (UTC)
    • What is the argument for that one has to "argue against"? It has not been stated. Uncle G (talk) 12:36, 31 January 2016 (UTC)
      • I don't know and can't speak for Metaknowledge, but let me ask, @Uncle G: will you find use for your tools? Are you willing to state a preference as to keeping or not keeping the tools? (You can legitimately oppose in this vote, I think.) Do you think that admins who do not use their tools should eventually lose them--after a rather considerable period of time--or do you think somethink else? --Dan Polansky (talk) 12:41, 31 January 2016 (UTC)
        • The only major arguments that I've heard the times over the years when people talk of de-sysopping are those of risk. Risk that the account is stolen or compromised. Risk that the account-holder will go barmy and start mis-using the tools. Clearly, I am still in sole charge of my accounts. Clearly, I haven't gone wild with the tools in approaching ten years. ☺ Uncle G (talk) 13:14, 31 January 2016 (UTC)
          • @Uncle G: That does not entirely and expressly answer my questions, but is interesting anyway. I think the chief benefit of desysopping is the reduction of the list of admins, making it approach the state of actually active admins, even minimally active, but active in the capacity of an admin. I admit that the list will be excessively large anyway. My gut-feeling heuristic is that an admin with >= 5 years of admin-inactivity should be desysopped unless the number of admins in the wiki is <= 20, or the like. --Dan Polansky (talk) 13:23, 31 January 2016 (UTC)
  3. Symbol support vote.svg Support SemperBlotto (talk) 10:41, 2 February 2016 (UTC) Inactive sysops are totally pointless. By the way, If you notice that I am inactive for more than, say, three months - you can assume that I am dead and may desysop me. There will probably be a death notice in my local newspaper.
  4. Symbol support vote.svg Support per SemperBlotto -Xbony2 (talk) 00:49, 3 February 2016 #
  5. Symbol support vote.svg Support per SemperBlotto, too :) Zezen (talk) 21:35, 4 February 2016 (UTC)(UTC)
    Symbol support vote.svg Support Removal of tools due to inactivity is by no means unusual and it doesn't leave the editor under a cloud. If you're not actively swinging a mop you don't need it. Chris Troutman (talk) 10:58, 5 February 2016 (UTC)
    Vote struck due to user being ineligible to vote. —Μετάknowledgediscuss/deeds 16:41, 5 February 2016 (UTC)
  6. Symbol support vote.svg Support--Dixtosa (talk) 11:39, 6 February 2016 (UTC)

Oppose

  1. Symbol oppose vote.svg Oppose — He responded, so it's not like he's gone from the project. I don't see the benefit of desysopping him. — I.S.M.E.T.A. 01:13, 17 January 2016 (UTC)
  2. Symbol oppose vote.svg Oppose per ISMETA, and per Dan's admission that the list of admins will unfortunately never reflect the reality of who is active. This, that and the other (talk) 10:34, 2 February 2016 (UTC)
    Symbol oppose vote.svg Oppose. (Indenting since this is technically past the vote close.) --Yair rand (talk) 05:56, 10 February 2016 (UTC)

Abstain

Decision


NORM: 10 proposals

Contents

Voting on:

Proposal 1. Renaming Wiktionary:Normalization of entries (WT:NORM).


Proposal 2.

Adding the sentence "This applies to the part of a page that the bots edit, not to the entire page." to the introduction of the policy.


Proposal 3. Formatting some mentions of wikicode using <code></code>.


Proposal 4. Renaming the section "Whitespace and characters" to "General", moving 1 rule to a new section "Templates" and adding two rules about line breaks.


Proposal 5.

Renaming the section "Categories and interwikis" to "Categories" and moving some information to the section "Interwikis" which already exists.


Proposal 6. Adding a few rules to WT:NORM concerning contents that should be on their own lines.


Proposal 7.

Editing the rule about spaces after #, * and :.


Proposal 8. Adding this rule to WT:NORM:

  1. No multiple spaces in a row.

Proposal 9.

Adding a section "Boxes and images" and editing the "Example entry" accordingly.


Proposal 10. Deciding whether there should be a blank line before the first language section, if other content (such as {{also}}) precedes.


Schedule:

  • Vote started: 00:00, 15 November 2015 (UTC)
  • Vote ends: 23:59, 14 February 2016 (UTC) (duration: 3 months)

Discussions:


Proposals: 1 · 2 · 3 · 4 · 5 · 6 · 7 · 8 · 9 · 10

Proposal 1

Support option 1: Wiktionary:Entry markup (WT:EM)

  1. Symbol support vote.svg Support --Daniel Carrero (talk) 03:38, 15 November 2015 (UTC)
  2. Symbol support vote.svg SupportCodeCat 20:36, 18 November 2015 (UTC)
  3. Symbol support vote.svg Support SemperBlotto (talk) 20:49, 18 November 2015 (UTC)
  4. Symbol support vote.svg Support --WikiTiki89 03:19, 25 November 2015 (UTC)
    Suppport Seems better than "normalization". Seems to nicely completement "layout" in WT:Entry layout. --Dan Polansky (talk) 14:13, 29 November 2015 (UTC)

Oppose option 1: Wiktionary:Entry markup (WT:EM)

  1. Symbol oppose vote.svg Oppose "Wiktionary:Entry markup". The page is clearly not a guide to the markup you can use, only to how to format it. Would be an extremely frustrating page to open if you were looking for a guide to Wiktionary's markup. Really needs "normalization" (or perhaps "style") in the title. This page is most useful for programmers who would understand the meaning of "normalization" to mean exactly what this page describes. Pengo (talk) 15:44, 7 December 2015 (UTC)
    @Pengo: Do you oppose renaming WT:NORM to any name, or do you oppose only renaming WT:NORM to Wiktionary:Entry markup? --Daniel Carrero (talk) 07:56, 15 December 2015 (UTC)
    @Daniel Carrero: I'd support renaming it if options 3 & 4 were fixed per your suggestions. i.e. Renaming it to either "Wikitext normalization" or "Wikitext style guide" would be fine, but as proposed I don't support any of the options. Pengo (talk) 15:28, 15 December 2015 (UTC)
    @Pengo: I understand, but to clarify, using "wikitext" rather than "wikicode" was a suggestion of @This, that and the other, not mine. Also, if you want, you can use the option 5 in this vote to support as many custom options you might think, including "Wikitext normalization" and "Wikitext style guide". --Daniel Carrero (talk) 15:34, 15 December 2015 (UTC)
    @Daniel Carrero: Ah, sorry for the mixup. Yep. Ok I've added support for that change, however I still strongly oppose "Wiktionary:Entry markup" as the page is not a guide to entry markup. Maybe this "oppose" should have gone under that heading. Pengo (talk) 02:14, 16 December 2015 (UTC)
  2. Symbol oppose vote.svg Oppose per Pengo. "normalization" is not particularly good, but having read Pengo's response, I realized "entry markup" is really too suggestive of e.g. which templates to use. WT:NORM is actually largely about the use of whitespace. --Dan Polansky (talk) 09:06, 31 January 2016 (UTC)
  3. Symbol oppose vote.svg Oppose --Dixtosa (talk) 08:05, 7 February 2016 (UTC)
  4. Symbol oppose vote.svg Oppose -Xbony2 (talk) 00:19, 9 February 2016 (UTC)

Support option 2: Wiktionary:Entry source code (WT:ESC)

Support option 3: Wiktionary:Wikicode normalization (WT:WCN)

Oppose option 3: Wiktionary:Wikicode normalization (WT:WCN)

  1. Symbol oppose vote.svg Oppose; it's called "wikitext", not "wikicode". This, that and the other (talk) 01:48, 25 November 2015 (UTC)
    For CFI purposes, wikicode looks attestable: it has 270 Google Books hits. We also have entries for wikitext and wiki markup. --Daniel Carrero (talk) 07:06, 29 November 2015 (UTC)
    @Daniel Carrero I don't dispute that the word exists, but this is a vote, not RFV. I am saying that the term almost exclusively used by MediaWiki developers and technicians is "wikitext" (and those that don't use "wikitext" use "wiki markup"). "Wikicode" is simply not an accepted term. This, that and the other (talk) 09:32, 16 December 2015 (UTC)
  2. Symbol oppose vote.svg Oppose per TTATO -Xbony2 (talk) 00:20, 9 February 2016 (UTC)

Support option 4: Wiktionary:Wikicode style guide (WT:WSG)

  1. Symbol oppose vote.svg Oppose; it's called "wikitext", not "wikicode". This, that and the other (talk) 01:48, 25 November 2015 (UTC)
  2. Symbol oppose vote.svg Oppose per TTATO -Xbony2 (talk) 00:20, 9 February 2016 (UTC)

Support option 5: Other name. Specify.

  1. Symbol support vote.svg Support : Wiktionary:Wikitext normalization (WT:NORM) The page does not tell you about the "entry markup" you can use, only how to normalize it. The word normalize is used this way in software and other contexts and its meaning is unambiguous. —Pengo (talk) 02:14, 16 December 2015 (UTC)
  2. Symbol support vote.svg Support "Wiktionary:Wikitext normalization" per Pengo. This, that and the other (talk) 06:45, 9 February 2016 (UTC)

Oppose

  1. Symbol oppose vote.svg Oppose any title without the word "normalization" in it. I'm quite happy with the existing title. This, that and the other (talk) 01:48, 25 November 2015 (UTC)
    My opinion is different from yours. I commented about the word "normalization" in this discussion:
    • The name "Normalization of entries" is unclear. Since Wiktionary:Entry layout, too, provides rules for "normalization" of "entries", the uninformed reader cannot tell at a glance why we have two different policies currently named as "Entry layout" and "Normalization of entries".
    --Daniel Carrero (talk) 14:16, 25 November 2015 (UTC)

Abstain


Proposal 2

Support

  1. Symbol support vote.svg Support --Daniel Carrero (talk) 03:38, 15 November 2015 (UTC)
  2. Symbol support vote.svg SupportCodeCat 20:36, 18 November 2015 (UTC)
  3. Symbol support vote.svg Support. Closes up an anti-bot loophole. --WikiTiki89 03:18, 25 November 2015 (UTC)
  4. Symbol support vote.svg SupportΜετάknowledgediscuss/deeds 17:49, 25 November 2015 (UTC)
  5. Symbol support vote.svg Support I would phrase it something like "This applies to the parts of a page that the bot edits. The bot may also normalize other parts of the page." Pengo (talk) 15:34, 7 December 2015 (UTC)
  6. Symbol support vote.svg Support, but see my comment below.--Dixtosa (talk) 08:20, 7 February 2016 (UTC)
  7. Symbol support vote.svg Support -Xbony2 (talk) 00:23, 9 February 2016 (UTC)

Oppose

  1. Symbol oppose vote.svg Oppose Sentence is pretty meaningless. It seems to say that bots can do what they like with those parts of a page which fall outside "the part of a page that the bots edit", which isn't very helpful to anyone trying to code a bot or enforce the policy. This, that and the other (talk) 01:51, 25 November 2015 (UTC)
    I don't follow: "It seems to say that bots can do what they like with those parts of a page which fall outside 'the part of a page that the bots edit'".
    The part of the page that the bots edit should obey this policy. How can the bot do " what they like" on the rest of the page without editing the rest of the page? --Daniel Carrero (talk) 02:50, 25 November 2015 (UTC)
    This basically ensures that if a bot is editing only part of a page, it is not responsible for fixing any violations of this policy that our outside of that part of the page. It just reinforces common sense. --WikiTiki89 03:21, 25 November 2015 (UTC)
    Oh, that makes some more sense. So what it should really say is "bots are not obliged to correct all violations of this policy when editing a page; they may restrict their attention to certain sections of the page, or the entire page, as they choose". This, that and the other (talk) 10:17, 25 November 2015 (UTC)
    I oppose making bots responsible for fixing violations outside the part of the policy they are editing. If the only thing a bot does is adding/removing interwikis, it makes sense obeying the section about interwikis: "Interwikis are placed at the very end of a page.", "Each interwiki on its own line.", etc. But should that same bot look for, say, incorrect spacing everywhere? (== English ==, [[Category: English nouns]]) It makes sense that a bot can fix any mistakes they find, but it should not be held responsible for any mistake left alone which is unrelated to the part of the policy they edit. Having the requirement that bots fix everything means extra bureaucracy and work/coding when creating/running a bot. --Daniel Carrero (talk) 13:56, 25 November 2015 (UTC)
    OK, but that isn't really my point. What I am wondering is, do you think my proposed sentence above is clearer than that put forward in the vote? This, that and the other (talk) 10:29, 27 November 2015 (UTC)
    @This, that and the other I've thought about your question. I think your sentence could be an improvement, in the direction of allowing/encouraging bots to fix any mistakes they find. For example, a bot approved for adding/removing interwikis might still go beyond its duty to fix some incorrect spacing without the need to ask for permission first. At least, that's my interpretation of your proposed sentence, I don't know if you were thinking exactly about something like I described. (Your exact question "do you think my proposed sentence above is clearer" seems to assume both "This applies to the part of a page that the bots edit, not to the entire page." and "bots are not obliged to correct all violations of this policy when editing a page; they may restrict their attention to certain sections of the page, or the entire page, as they choose" serve the same purpose or convey the same idea, which I think they don't.)
    For the moment, I'm still going to support the original proposal "This applies to the part of a page that the bots edit, not to the entire page." because I think it's straightforward and it fulfills the purpose of freeing bots from the responsibility of fixing every mistake they find on a page -- which in my view is an important thing to do, as discussed before. We could consider changing the rule later to encourage bots to fix mistakes even when it's not their responsibility, but I think of this as a possible next step, not necessarily a priority. --Daniel Carrero (talk) 06:49, 29 November 2015 (UTC)
    For credit purposes, I'd like to clarify that the proposal of "This applies to the part of a page that the bots edit, not to the entire page." was not originally mine. I got it from @msh210 in Wiktionary:Votes/pl-2015-07/Normalization of entries 2 and a number of people already supported his idea in the vote, with statements on the likes of "I support Msh210's qualifier." --Daniel Carrero (talk) 06:53, 29 November 2015 (UTC)
    Note that, as mentioned at Wiktionary:Votes/pl-2015-07/Normalization of entries 2#Decision, this sentence is already policy. All we're voting on here is whether it should be in the text of NORM or, on the other hand, remain policy without being in the text of NORM. Ping Daniel Carrero, Wikitiki89, because I'm coming late to this discussion (and because what I'm saying here seems to contradict what they said above).​—msh210 (talk) 21:53, 30 November 2015 (UTC)
    Thanks, I was not aware of that. Although I don't see how it contradicts what I was saying. --WikiTiki89 22:04, 30 November 2015 (UTC)
    You said "This basically ensures that if a bot is editing only part of a page, it is not responsible…", but in fact that's already ensured.​—msh210 (talk) 22:37, 30 November 2015 (UTC)
    Then I guess it's a semantic question of whether one can ensure something that is already ensured. --WikiTiki89 23:10, 30 November 2015 (UTC)

Abstain

Comments

  • We could make a function that correct or detect these anomalies and make it mandatory to include this function in their sources. --Dixtosa (talk) 08:20, 7 February 2016 (UTC)

Proposal 3

Support

  1. Symbol support vote.svg Support --Daniel Carrero (talk) 03:38, 15 November 2015 (UTC)
  2. Symbol support vote.svg SupportCodeCat 20:37, 18 November 2015 (UTC)
  3. Symbol support vote.svg Support. In the future, I don't think we need to vote on minor formatting changes like this. --WikiTiki89 03:17, 25 November 2015 (UTC)
  4. Symbol support vote.svg Support and per Wikitiki89 as well. This, that and the other (talk) 06:35, 30 November 2015 (UTC)
  5. Symbol support vote.svg Support, and what Wikitiki says. IMO it's easier to read for beginning editors. —Aryamanarora (मुझसे बात करो) 23:32, 15 December 2015 (UTC)
  6. Symbol support vote.svg Support Helps to distinguish code from normal text. Also "----" looks awful and unrecognizable. —suzukaze (tc) 12:26, 31 December 2015 (UTC)
  7. Symbol support vote.svg Support, and I agree that something this minor probably doesn't require a vote. Also, as Pengo says below, it should probably be "e.g." rather than "i.e." (and I don't think that change requires an additonal vote). Andrew Sheedy (talk) 01:58, 2 February 2016 (UTC)
  8. Symbol support vote.svg Support -Xbony2 (talk) 00:24, 9 February 2016 (UTC)

Oppose

  1. Symbol oppose vote.svg Oppose We should use plain typography, IMHO, rather than enclosing wikicode in <code></code> --Dan Polansky (talk) 14:17, 29 November 2015 (UTC)

Abstain

  1. Symbol abstain vote.svg Abstain "i.e." should be "e.g." Also is it possible to format the "good" and "bad" examples so they have green and red borders? But I agree we shouldn't really need to vote on minor formatting issues like this. Pengo (talk) 15:24, 7 December 2015 (UTC)

Proposal 4

Support

  1. Symbol support vote.svg Support --Daniel Carrero (talk) 03:38, 15 November 2015 (UTC)
  2. Symbol support vote.svg SupportCodeCat 20:37, 18 November 2015 (UTC)
  3. Symbol support vote.svg Support --WikiTiki89 03:15, 25 November 2015 (UTC)
  4. Symbol support vote.svg Support Adds the useful allowance of newlines in template markups. --Dan Polansky (talk) 14:19, 29 November 2015 (UTC)
  5. Symbol support vote.svg SupportAndrew Sheedy (talk) 01:59, 2 February 2016 (UTC)
  6. Symbol support vote.svg Support -Xbony2 (talk) 00:26, 9 February 2016 (UTC)

Oppose

Abstain


Proposal 5

Support

  1. Symbol support vote.svg Support --Daniel Carrero (talk) 03:39, 15 November 2015 (UTC)
  2. Symbol support vote.svg SupportCodeCat 20:38, 18 November 2015 (UTC)
  3. Symbol support vote.svg Support --WikiTiki89 03:13, 25 November 2015 (UTC)
  4. Symbol support vote.svg SupportΜετάknowledgediscuss/deeds 02:24, 2 January 2016 (UTC)

Oppose

  1. Symbol oppose vote.svg Oppose The amendment, although logically separated by subject, feels like a poor use of space as it ultimately says to do the same thing. If they had different instructions it would be a different story. —suzukaze (tc) 12:28, 31 December 2015 (UTC)
  2. Symbol oppose vote.svg Oppose per suzukaze -Xbony2 (talk) 00:27, 9 February 2016 (UTC)

Abstain


Proposal 6

Support

  1. Symbol support vote.svg Support --Daniel Carrero (talk) 03:39, 15 November 2015 (UTC)
  2. Symbol support vote.svg SupportCodeCat 20:38, 18 November 2015 (UTC)
  3. Symbol support vote.svg Support DTLHS (talk) 20:43, 18 November 2015 (UTC)
  4. Symbol support vote.svg Support --WikiTiki89 03:12, 25 November 2015 (UTC)
  5. Symbol support vote.svg SupportAndrew Sheedy (talk) 02:00, 2 February 2016 (UTC)
  6. Symbol support vote.svg Support -Xbony2 (talk) 00:28, 9 February 2016 (UTC)

Oppose

Abstain


Proposal 7

Support

# Symbol support vote.svg Support --Daniel Carrero (talk) 03:40, 15 November 2015 (UTC)

  1. Symbol support vote.svg SupportCodeCat 20:39, 18 November 2015 (UTC)
  2. Symbol support vote.svg Support, although this is unnecessary, since putting a space in between the characters will break the functionality anyway. --WikiTiki89 03:11, 25 November 2015 (UTC)
    True, this just formalizes existing practice. --Daniel Carrero (talk) 18:34, 25 November 2015 (UTC)
    It's not a "practice", it's a necessary circumstance. Just like we don't say "Template invocations must begin with with two opening curly braces and end with two closing curly braces." There's no other way to do it. --WikiTiki89 18:54, 25 November 2015 (UTC)
    Point taken. --Daniel Carrero (talk) 06:57, 29 November 2015 (UTC)

Oppose

  1. Symbol oppose vote.svg Oppose per Wikitiki89. Just adding complication to the language. Pengo (talk) 15:27, 7 December 2015 (UTC)
  2. Symbol oppose vote.svg Oppose due to pointlessness. —Μετάknowledgediscuss/deeds 02:23, 2 January 2016 (UTC)
  3. Symbol oppose vote.svg Oppose per Wikitiki89. --Daniel Carrero (talk) 08:10, 18 January 2016 (UTC)
  4. Symbol oppose vote.svg Oppose -Xbony2 (talk) 00:29, 9 February 2016 (UTC)

Abstain

  1. Symbol abstain vote.svg Abstain I don't like the second sentence. Something like "#, *, :, or combinations such as #: on the start of a line" in the first sentence would be sufficient. —suzukaze (tc) 12:33, 31 December 2015 (UTC)

Proposal 8

Support

  1. Symbol support vote.svg Support --Daniel Carrero (talk) 03:40, 15 November 2015 (UTC)
  2. Symbol support vote.svg SupportCodeCat 20:39, 18 November 2015 (UTC)
  3. Symbol support vote.svg Support DTLHS (talk) 20:42, 18 November 2015 (UTC)
  4. Symbol support vote.svg SupportEnosh (talk) 12:01, 15 December 2015 (UTC)
  5. Symbol support vote.svg SupportΜετάknowledgediscuss/deeds 02:25, 2 January 2016 (UTC)
  6. Symbol support vote.svg SupportAndrew Sheedy (talk) 02:05, 2 February 2016 (UTC)
  7. Symbol support vote.svg Support -Xbony2 (talk) 00:30, 9 February 2016 (UTC)

Oppose

  1. Symbol oppose vote.svg Oppose for usability reasons, as described at Wiktionary_talk:Normalization_of_entries#Collapse_multiple_spaces_into_one_space. ‑‑ Eiríkr Útlendi │Tala við mig 20:27, 18 November 2015 (UTC)
    I don't see any usability reasons mentioned there. Is there a particular advantage to having multiple consecutive spaces in the wikitext? —CodeCat 23:38, 15 December 2015 (UTC)
    As described in the linked thread, greater spacing between sentences improves legibility. ‑‑ Eiríkr Útlendi │Tala við mig 00:11, 16 December 2015 (UTC)
    @Eirikr: But different browsers may use different fonts thus showing different views, don't they?--Dixtosa (talk) 08:40, 7 February 2016 (UTC)
    • I've tested Chrome + Firefox + IE on Windows, and Chrome + Firefox + Safari on Mac. Windows browsers consistently use a monospace font. On Mac, Firefox uses monospace, while Chrome and Safari use proportional.
    That said, whitespace in the editor is not normalized, so regardless of font, two spaces appear wider than a single space. ‑‑ Eiríkr Útlendi │Tala við mig 08:58, 7 February 2016 (UTC)
  2. Symbol oppose vote.svg Oppose proposal "No multiple spaces in a row"; for more, see the above Eiríkr link. --Dan Polansky (talk) 14:15, 29 November 2015 (UTC)
  3. Symbol oppose vote.svg Oppose I like 'em. DCDuring TALK 21:01, 9 February 2016 (UTC)

Abstain

  1. Symbol abstain vote.svg Abstain I would support, but I think the wording is too general. Perhaps it should say "There should not be more than one space in a row within running text." --WikiTiki89 03:09, 25 November 2015 (UTC)
    @Wikitiki89 The proposed rule is: "No multiple spaces in a row." In practice, it does not feel much different from your suggested change, except it mentions running text. Are you thinking of places other than running text, where you'd like to let people use 2 spaces in a row? --Daniel Carrero (talk) 22:08, 1 December 2015 (UTC)
    There could be. I can't think of very many off the top of my head. Maybe to align templates? Since this rule is envisioned as applicable to running text, I think that should be made an explicit part of the rule. --WikiTiki89 22:22, 1 December 2015 (UTC)
    In the proposal 4, there is an example about using line breaks to visualize a table in the code when calling {{ru-decl-noun}}. It is conceivable that using multiple spaces inside a template call could be helpful to align parameters and/or values, particularly if the user edits the page using a monospaced font. By "maybe to align templates", did you think of anything else? If there are no other exceptions, we could change the rule to: "No multiple spaces in a row, except within templates."
    The original "No multiple spaces in a row." was designed to try and make the life of the bot owner easier -- by converting all instances of multiple spaces into single spaces. The suggested "No multiple spaces in a row, except within templates." adds a single exception to that. --Daniel Carrero (talk) 00:14, 2 December 2015 (UTC)
    Templates are a rather bad place to have spaces, as they tend to mess up stuff, particularly modules that do text processing. —CodeCat 01:09, 2 December 2015 (UTC)
    My point is that neither you nor I know whether there are any other exceptions, which is why we should not generalize beyond our field of view. --WikiTiki89 01:10, 2 December 2015 (UTC)
  2. Symbol abstain vote.svg Abstain I was going to vote "Oppose" because who cares about spacing after a sentence???? but then remembered that the main issue is that no-one wants to see ten meaningless consecutive spaces in a row in wikitext. However, I think that having two spaces after a sentence-ending period is harmless and not an issue and should not be outlawed. —suzukaze (tc) 12:21, 31 December 2015 (UTC)

Proposal 9

Support

  1. Symbol support vote.svg Support --Daniel Carrero (talk) 03:40, 15 November 2015 (UTC)
  2. Symbol support vote.svg Support Rules 3 and 4 are redundant though, as the blank lines next to headers are already regulated. —CodeCat 20:41, 18 November 2015 (UTC)
  3. Symbol support vote.svg Support Only natural. --WikiTiki89 03:06, 25 November 2015 (UTC)
  4. Symbol support vote.svg SupportAndrew Sheedy (talk) 02:06, 2 February 2016 (UTC)
  5. Symbol support vote.svg Support -Xbony2 (talk) 00:31, 9 February 2016 (UTC)

Oppose

  1. Symbol oppose vote.svg Oppose Subject: Boxes and images. The example contains [[File:Example.png|100px]], with hardwired pixel width, and someone explained to me a long time ago that hardwired widths are a bad idea. --Dan Polansky (talk) 09:14, 31 January 2016 (UTC)
    I'm curious. What is the problem with hardwired widths? --Daniel Carrero (talk) 17:39, 1 February 2016 (UTC)
    If you don't give the MediaWiki software a "hardwired" width it's going to assign the picture its own width anyways. MediaWiki doesn't do responsive design (yet). —suzukaze (tc) 06:49, 9 February 2016 (UTC)

Abstain


Proposal 10

Support option 1: "One blank line"

  1. Symbol support vote.svg Support One blank line before all headers, so why not before the first? —CodeCat 20:41, 18 November 2015 (UTC)

Support option 2: "No blank lines"

  1. Symbol support vote.svg Support --Daniel Carrero (talk) 03:40, 15 November 2015 (UTC)
    Same as Wikitiki89 vote below, I am supporting this because it has been our standard practice for a long time. --Daniel Carrero (talk) 06:57, 29 November 2015 (UTC)
  2. Symbol support vote.svg Support It is very easy to accidentally introduce a visible blank paragraph at the top of an entry. Doing this will stop this problem from happening so often. This, that and the other (talk) 01:54, 25 November 2015 (UTC)
  3. Symbol support vote.svg Support This has been our standard practice for a long time. --WikiTiki89 03:05, 25 November 2015 (UTC)
  4. Symbol support vote.svg SupportΜετάknowledgediscuss/deeds 03:17, 25 November 2015 (UTC)
  5. Symbol support vote.svg Support --profesjonalizmreply 01:45, 4 January 2016 (UTC)
  6. Symbol support vote.svg Support -Xbony2 (talk) 00:32, 9 February 2016 (UTC)

Oppose

Abstain


Decision


EL introduction

Voting on: Adding some text as the introduction to WT:EL (diff):

This is a list of norms that govern how an entry should be formatted. This includes what are allowed sections and what are the contents expected to be found in them. These rules reflect what editors think as best concerning the standard format of an entry.[1]

References
  1. ^ Wiktionary:Votes/pl-2015-12/EL introduction

Rationale and changes:

  • Quickly states that WT:EL is and what it does, for those unacquainted with the policy.
  • The first sentence was based on WT:NORM's "This is a list of aspects that govern how the wiki code behind an entry should be formatted."
  • The second sentence is a generic, all-encompassing statement but it also suggests that we have some standards concerning specific allowable headers and contents.
  • The third sentence was based on WT:NORM's "[...] they do make the pages conform more to a standard format reflecting what we think of as best for the wiki code."

Schedule:

  • Vote starts: 00:00, 24 January 2016 (UTC)
  • Vote ends: 23:59, 23 February 2016 (UTC)

Discussion:

Support

  1. Symbol support vote.svg Support --Daniel Carrero (talk) 13:24, 25 January 2016 (UTC)
  2. Symbol support vote.svg SupportAndrew Sheedy (talk) 02:07, 2 February 2016 (UTC)
  3. Symbol support vote.svg Support --Droigheann (talk) 01:57, 6 February 2016 (UTC)
  4. Symbol support vote.svg SupportAɴɢʀ (talk) 09:44, 9 February 2016 (UTC)
  5. Symbol support vote.svg Support but I would prefer "what sections are allowed" rather than "what are allowed sections" and "what contents are expected to be found" rather than "what are the contents expected to be found". --WikiTiki89 16:49, 9 February 2016 (UTC)

Oppose

Abstain

Decision


Definitions

Voting on: Editing WT:EL#Definitions.

See diff.

Current text:

Definitions

The definitions are the most fundamental piece of dictionary information but do not have their own header. They are simply added in one big block, line after line, each beginning with a number sign (#). Each definition may be treated as a sentence: beginning with a capital letter and ending with a full stop. The key terms of a definition should be wikified.

The vote “2006-12/form-of style” is relevant to this section, without specifying text to be amended in this document, so please see it for details.
The vote “2010-08/Italicizing use-with-mention” is relevant to this section, without specifying text to be amended in this document, so please see it for details.
Abbreviations (subsection)
See Wiktionary:Entry layout explained/POS headers for discussion of the appropriate part of speech for different types of abbreviation

The “definitions” of entries that are abbreviations should be the expanded forms of the abbreviations. Where there is more than one expansion of the abbreviation, ideally these should be listed alphabetically to prevent the expanded forms being duplicated. The case used in the expanded form should be the usual one — do not capitalise words in the expanded form of an abbreviation that is made up of capital letters unless that is how the expanded form is usually written.

Where the expanded forms are entries that appear (or should appear) in Wiktionary, wikify them. Expanded forms that are encyclopedic entries should also be wikified and linked to the appropriate Wikipedia entry. When the expanded form does not merit an entry of its own, either in Wiktionary or Wikipedia material, wikify its component words and give a gloss (italicised, in parentheses) after the expansion explaining what the term means (see SNAFU for an example).

See PC for an example entry.

Context labels (subsection)

A context label identifies a definition which only applies in a restricted context. Such labels indicate, for example, that the following definition occurs in a limited geographic region or temporal period, or is used only by specialists in a particular field and not by the general population.[1]

Many context label templates also place an entry into a relevant category, but they must not be used merely for categorization (see category links, below).[1]

One or more labels may be placed before the definition:[1]

wikitext result

# {{context|informal|lang=en}} An [[informant]] or [[snitch]].

  1. (informal) An informant or snitch.

Details in Wiktionary:Context labels.[1]

References
  1. 1.0 1.1 1.2 1.3 Wiktionary:Votes/pl-2009-03/Context labels in ELE v2

Proposed text:

Definitions

Each entry contains one or more definitions, within the POS section, below the headword line. They are numbered using the character # in the wikitext. Sometimes, they are grouped into subsenses. The key terms of a definition should be linked to the respective entries.[1]

Some definitions are treated as sentences: beginning with a capital letter and ending with a full stop. In language sections other than English, the definition generally consists of a simple translation into English, rather than a full definition. If necessary, additional information (such as a gloss) should be included to ensure that a translation is not ambiguous or broader than intended. For example, run can indicate a motion of the legs, but it can also refer to the flowing of a liquid. Words that cannot be easily translated can have full definitions.

If appropriate, use context labels at the start of the definition to indicate that it only applies to a certain context: for example, to indicate that it occurs in a limited geographic region or temporal period, or is used only by specialists in a particular field and not by the general population. Many context label templates also place an entry into a relevant category, but they must not be used merely for categorization. See also Wiktionary:Context labels.[2]

wikitext result

# {{lb|en|informal}} An [[informant]] or [[snitch]].

  1. (informal) An informant or snitch.

For non-lemma definitions (plurals, conjugations, superlatives, etc.), templates are used with predefined text, linking back to the main entry. In the definition generated by these templates, the link to the main entry is bold when written in the Latin script. The rest of the definition is italic.[3][4]

  1. plural of word

For abbreviations, (Examples: PC, USA, SNAFU) do not capitalise words in the expanded form unless that is how the expanded form is usually written. Where the expanded form is an entry that exists (or should exist) in Wiktionary, link to it. Otherwise, if appropriate, link it to the appropriate Wikipedia article, if it exists. When the expanded form does not merit either a Wiktionary entry or a Wikipedia article, link it to its component words. You may expand the definition with a gloss if appropriate.

Some languages have romanizations linking back to the main entries. It is required that each romanization entry contain at least one definition line in the wikitext.[5]

References
  1. ^ Wiktionary:Votes/pl-2015-12/Definitions
  2. ^ Wiktionary:Votes/pl-2009-03/Context labels in ELE v2
  3. ^ 2006-12/form-of style
  4. ^ 2010-08/Italicizing use-with-mention
  5. ^ pl-2013-03/Romanization and definition line

Rationale and changes:

  • Removing "The definitions are the most fundamental piece of dictionary", it's a comment rather than a rule.
  • Removing "[definitions] do not have their own header", no need to say what they don't have. Arguably, the POS header is their header.
  • Expanding upon the idea that "Each definition may be treated as a sentence: beginning with a capital letter and ending with a full stop.", mentioning other type of definitions: "In language sections other than English, the definition generally consists of a simple translation into English, rather than a full definition."
  • Mentioning: "Sometimes, they are grouped into subsenses."
  • Writing out the actual formatting rules of Wiktionary:Votes/2006-12/form-of style and Wiktionary:Votes/2010-08/Italicizing use-with-mention, rather than just linking to them.
  • Removing "The “definitions” of entries that are abbreviations should be the expanded forms of the abbreviations." Sometimes, the expanded abbreviation is in the etymology section, not in the definition.
  • Removing "Where there is more than one expansion of the abbreviation, ideally these should be listed alphabetically to prevent the expanded forms being duplicated.", does not seem common practice.
  • Compressing the explanation of where to link the expanded forms in a single paragraph; arguably, that information does not need its own subsection.
  • In particular, replacing "Expanded forms that are encyclopedic entries should also be wikified and linked to the appropriate Wikipedia entry." by "Otherwise, if appropriate, link it to the appropriate Wikipedia article, if it exists." Arguably, existence in Wikipedia is a more objective criterion than whether an entry is "encyclopedic".
  • Mentioning three abbreviation examples (PC, USA, SNAFU), together in the same line. The original text had two examples (PC and SNAFU) in separate lines.
  • Removing bold formatting from "a definition which only applies in a restricted context"; arguably, it's unnecessary.
  • Compressing the explanation of context labels in a single paragraph; arguably, that information does not need its own subsection. In particular, "Details in Wiktionary:Context labels." does not to be in a separate line.
  • Adding an example of non-lemma definition, properly formatted: "plural of word".
  • Removing three separate references to the same vote (Wiktionary:Votes/pl-2009-03/Context labels in ELE v2) in consecutive paragraphs.
  • Reordering some of the ideas. Original order: introduction, form-of definitions, abbreviations, context labels. Proposed order: introduction, form-of definitions, context labels and abbreviations.
  • Using {{lb}} rather than {{context}}, as approved at Wiktionary:Votes/2015-11/term → m; context → label; usex → ux.
  • Replacing "wikify" by "link"; "wikified" by "linked".
  • Mentioning the fact that some entries are romanizations linking back to the main entries. The requirement that each romanization entry have at least one definition line was voted at Wiktionary:Votes/pl-2013-03/Romanization and definition line.
  • Making sure another WT:EL section is voted, a step in the direction of having WT:EL completely voted.

Schedule:

  • Vote starts: 00:00, 27 January 2016 (UTC)
  • Vote ends: 23:59, 27 February 2016 (UTC)

Discussion:

Support

  1. Symbol support vote.svg Support --Daniel Carrero (talk) 13:50, 27 January 2016 (UTC)

Oppose

  1. Symbol oppose vote.svg Oppose The treatment of some definitions as "sentences" and some as simple "translations" is controversial. It would be better to leave this whole bit out (for now, at least). --WikiTiki89 16:40, 8 February 2016 (UTC)
    The proposed text does not instruct on how to choose between sentences and translations, it merely documents that we have these types of definitions. I know they are controversial, but is there any way we can mention these two types of definitions in the least controversial way possible? I'm not sure the fact that these two types of definitions exist is controversial; but I know some attempts to unify or standardize them are. The status quo of the policy is: "Each definition may be treated as a sentence: beginning with a capital letter and ending with a full stop."
    Also, WT:EL#Variations for languages other than English says: "However, a translation into English should normally be given instead of a definition, including a gloss to indicate which meaning of the English translation is intended." If WT:EL#Definitions is able to explain about this accutrately, I'd like to propose the removal of that sentence from WT:EL#Variations for languages other than English later. --Daniel Carrero (talk) 06:23, 10 February 2016 (UTC)

Abstain

Decision


References

Voting on: Editing WT:EL#References.

Current text:

References

The validity of the dictionary has a profound effect on its usefulness. There is a need to balance respect for copyrights with definitions so inventive as to be inaccurate. References to dubious claims, such as the etymology of windhover, are also important to the credibility of Wiktionary. In due course, every entry should have one or more references which can be used to verify the content.

References here may be given in a normal bibliographic format showing author, title, place of publication, publisher and year of publication. Reference templates (beginning with “R:”) are used for some of the most common sources. Thus, for the 1913 Webster, we have {{R:Webster 1913}}, which gives:

Entry layout in Webster’s Revised Unabridged Dictionary, G. & C. Merriam, 1913

References

(none)

Proposed text:

References
Main article: Wiktionary:References

The References section contains external sources where users can verify the information available on our entries. This improves the reliability and usefulness of Wiktionary. References are especially encouraged for unusual or disputable claims in etymologies — such as the etymology of windhover — or usage notes.[1]

References are listed using bullet points (the character *). References may be given in a normal bibliographic format showing author, title, place of publication, publisher and year of publication. Reference templates (beginning with “R:”) are used for some of the most common sources. See the example below for two references used in the entry water:

Code:

* {{R:Century 1911}}
* {{R:Webster 1913}}

Result:

References
  1. ^ Wiktionary:Votes/pl-2015-12/References

Rationale and changes:

  • Adding the rule: "References are listed using bullet points".
  • Adding 1 more usage example + the result of the usage examples.
  • Formatting the usage examples with bullet points, showing actual usage.
  • Removing "There is a need to balance respect for copyrights with definitions so inventive as to be inaccurate." For semantics, we go by attestation.
  • Removing "The validity of the dictionary has a profound effect on its usefulness." It's a comment rather than a rule.
  • Minor change of punctuation and word order.
  • Making sure another WT:EL section is voted, a step in the direction of having the WT:EL completely voted.
  • Disclaimer: The References section probably could be expanded with more information. This is proposed as an improvement to the current text, not as the "final" version of it.

Schedule:

  • Vote starts: 00:00, 28 January 2016 (UTC)
  • Vote ends: 23:59, 28 February 2016 (UTC)

Discussion:

Support

  1. Symbol support vote.svg Support --Daniel Carrero (talk) 03:01, 28 January 2016 (UTC)
  2. Symbol support vote.svg SupportΜετάknowledgediscuss/deeds 16:18, 28 January 2016 (UTC)
  3. Symbol support vote.svg Support - -sche (discuss) 10:55, 29 January 2016 (UTC)
    Symbol support vote.svg Support Chris Troutman (talk) 19:35, 7 February 2016 (UTC)
    Vote struck due to user being ineligible to vote. —Μετάknowledgediscuss/deeds 19:53, 7 February 2016 (UTC)
  4. Symbol support vote.svg SupportAɴɢʀ (talk) 09:43, 9 February 2016 (UTC)

Oppose

Abstain

Decision


Short blocking policy

  • Voting on:

1. Removing all non-policy contents from Wiktionary:Blocking policy, leaving it only with policy contents.

The non-policy contents are already available at Help:Blocking and are free for editing, like any help page.

The full policy contents consist of exactly 2 lines, as previously voted on Wiktionary:Votes/pl-2010-01/New blocking policy:

# The block tool should only be used to prevent edits that will, directly or indirectly, hinder or harm the progress of the English Wiktionary.
# The block tool should not be used unless less drastic means of stopping these edits are, by the assessment of the blocking administrator, highly unlikely to succeed.

2. Editing the policy box.

Current text:

The portion of it which is policy may not be modified without a VOTE.

Proposed text:

It should not be modified without discussion and consensus. Any substantial or contested changes require a VOTE.
  • Vote starts: 00:00, 7 December 2015 (UTC)
  • Vote ends: 23:59, 5 January 2016 (UTC)
    Vote extended to: 23:59, 5 February 2016 (UTC)
    Vote extended to: 23:59, 5 March 2016 (UTC)

Discussion:

Previous vote and related discussion:

Support

  1. Symbol support vote.svg Support --Daniel Carrero (talk) 03:06, 7 December 2015 (UTC)
  2. Symbol support vote.svg Support. Let's make the page clearer, less complex and less open to abuse. Let's remove avoidable complexities including (a) the need to say "The portion of it which is policy may not be modified without a VOTE" in the box at the top of the page, (b) the text "This policy page consists of two sections. ...", and (c) the Policy heading and "The blocking policy itself is as follows". Let's remove the temptation for an admin to treat the non-policy part as if it were policy. Let's remove the inaccurate "Explanation" heading; I do not believe the text under that heading is an explanation of what is above the heading; it is rather the former text of the policy. Also, if there should be a further guideline for blocking, let that be made part of policy, introduced with such keywords as "usually" and other softening words. Let the complete text of the page be vote-controlled in the same way as WT:CFI and WT:ELE. As for Help:Blocking, that should only really contain how-tos; it should not contain anything that looks like a policy or guideline. Again, sentences that are to act as a guideline can be part of the policy, and contain softening words such as "usually", "most often" and the like. ---Dan Polansky (talk) 11:16, 13 December 2015 (UTC)
  3. Symbol support vote.svg Support — I.S.M.E.T.A. 01:11, 17 January 2016 (UTC)
  4. Symbol support vote.svg Support -Xbony2 (talk) 01:18, 31 January 2016 (UTC)

Oppose

Symbol oppose vote.svg Oppose SimonP45 (talk) 02:39, 13 December 2015 (UTC)
Permablocked user. —Μετάknowledgediscuss/deeds 04:42, 13 December 2015 (UTC)
  1. Symbol oppose vote.svg Oppose. Instead, unprotect Wiktionary:Blocking policy and rename it to Wiktionary:Blocking or something similar. I know it is custom for policy pages to be fully protected – but look! There is some policy on this page (WT:V) that is not protected. So it doesn't have to be that way. The focus of Wiktionary:Blocking should shift from being a policy page that happens to contain some non-policy information, to an informational page that happens to contain some policy – just like WT:V. This, that and the other (talk) 05:01, 23 December 2015 (UTC)
    I'd prefer if Wiktionary:Voting was created as the actual voting policy page. I'd like to officially write somewhere that the 2/3 supermajority is required for votes to pass, for example. --Daniel Carrero (talk) 05:08, 23 December 2015 (UTC)
  2. Symbol oppose vote.svg Oppose The rest of the verbage needs to be somewhere. Also, blocking isn't a precise science, probably better to have it governed by guidelines rather than policy. Purplebackpack89 00:18, 27 December 2015 (UTC)
    @User:Purplebackpack89: 'Again, sentences that are to act as a guideline can be part of the policy, and contain softening words such as "usually", "most often" and the like.' --Dan Polansky (talk) 11:50, 27 December 2015 (UTC)
    That sentence doesn't make sense. Either call it a guideline or call it policy. Don't try to make something both. Purplebackpack89 16:38, 27 December 2015 (UTC)
    @User:Purplebackpack89 In fact, it can be a policy that contains guide-sentences. An example of a guide-sentence, an invented example, is "The first block against a user should usually be no longer than 3 days." Since the sentence contains the word "usually", it contains the flexibility of a guideline, but is still a policy. In a policy, any "usually" has to be explicit; in a non-policy guideline, all sentences contains the built-in "usually" or "unless deemed inapplicable" implicitly. --Dan Polansky (talk) 19:19, 27 December 2015 (UTC)

Abstain

  1. Note: (1) [[Help:Blocking]] was created only a week ago, seemingly in order to get this vote to pass. A more neutral course of action would be to include "and spin off the non-policy part into [[Help:Blocking]]" as part of the proposal here and await passage of this vote before creating that page. Indeed, were this vote necessary, I'd say that the early creation of [[Help:Blocking]] would smack of bad faith. However: (2) This vote is not necessary: the part of [[Wiktionary:Blocking policy]] that's not policy can be edited without a vote (and of course so can [[Help:Blocking]]).

    Because this vote is not necessary and because [[Help:Blocking]] is a fine-looking' page, I cannot bring myself to vote against the proposal here. Because the page we're voting on is also fine as is and is not improved by the proposal (cf. my comments on this vote's talkpage), I certainly cannot bring myself to vote for the proposal. I Symbol abstain vote.svg abstain.​—msh210 (talk) 19:15, 8 December 2015 (UTC)

    Even if this vote is possibly not strictly necessary, it can serve as a stronger evidence of consensus about the proposed action concerning a page that contains, among other things, policy. And having stronger evidence in such a case seems a good thing to me. --Dan Polansky (talk) 11:08, 13 December 2015 (UTC)
    One case where this vote would have been useful is in the block log of Purplebackpack89, from 1 November 2015. The blocking summary says this: 'Per WT:BLOCK: "1-7 days - Primary blocks for behavior which is counter to policy, productivity or community." [...]'. Therefore, the blocking summary uses the non-policy parts of WT:BLOCK as if they were policy. --Dan Polansky (talk) 20:27, 22 January 2016 (UTC)
    That case is not actually a good example: see this vote's talkpage for more discussion on that.​—msh210 (talk) 18:57, 27 January 2016 (UTC)

Decision

  • Fails due to no consensus (4–2).​—msh210 (talk) 21:25, 5 February 2016 (UTC)
    • I disagree. This is 2/3 in support and this 2/3 was supported by quite many people in various discussions to be consensus, although we have no formal decision that 2/3 is good enough. This is a perfect vote to be extended to gain more votes and a clearer decision. Does anyone object extending this vote? --Dan Polansky (talk) 10:21, 6 February 2016 (UTC)
      • Support extending. I believe msh210 closed the vote in good faith, but he did it approximately 2h and 30min before the actual scheduled time of 23:59 (UTC), denying the possibility of other people to cast their votes in the metaphorical last minute. People rushing to cast their votes in the last day of voting seems to be a common occurrence in my experience, and is probably related to the fact that in the last day of voting, the end date is highlighted red in the vote box that appears in our watchlists. --Daniel Carrero (talk) 12:01, 6 February 2016 (UTC)
        • I usually like to wait for the end date to at least be yellow before voting, to see what other users say before formulating an opinion. -Xbony2 (talk) 14:18, 6 February 2016 (UTC)
        • People extend a vote before it's up. Therefore, it only makes sense for a closing admin who thinks the vote should not be extended to be able to close it then also. Otherwise, he is allowing anyone who thinks it should be extended to do so without recourse.​—msh210 (talk) 16:51, 8 February 2016 (UTC)
      • I do, but that's water under the bridge now.​—msh210 (talk) 16:51, 8 February 2016 (UTC)

Literal translations in translation tables

Voting on: Editing one item in WT:Translations.

Current text:

Do not give translations back into English of idiomatic translations. For example, when translating “bell bottoms” into French as “pattes d’éléphant”, do not follow this with the literal translation back into English of “elephant’s feet”. While this sort of information is undoubtedly interesting, it belongs in the entry for the translation itself.

References

(none)

Proposed text:

If the translated term is an idiom, you can give the literal translation back to English. For example, the idiom “none of your beeswax” cannot be translated into German literally as “nicht dein Bienenwachs”, as this does not have the same meaning in German; an idiomatic translation is “nicht dein Bier” (which means, literally, “not your beer” in English).[1]

References
  1. ^ Wiktionary:Votes/pl-2016-01/Literal translations in translation tables

Rationale:

  • Some entries already have FL-to-English literal translations of idioms. This is expected to clarify users that the idiom is not translated the same literally as in English. This points out the difference between idioms like "bells bottoms" and "pattes d’éléphant" without requiring the user to check the actual foreign-language entry(ies).

Schedule:

  • Vote starts: 00:00, 6 February 2016 (UTC)
  • Vote ends: 23:59, 6 March 2016 (UTC)

Discussion:

Support

  1. Symbol support vote.svg Support --Daniel Carrero (talk) 00:22, 6 February 2016 (UTC)
  2. Symbol support vote.svg Support Matthias Buchmeier (talk) 22:02, 6 February 2016 (UTC)
  3. Symbol support vote.svg Support (and any arguments against apply equally against putting genders in translations, so how come nobody is drafting a vote to get rid of those?). —Μετάknowledgediscuss/deeds 02:21, 7 February 2016 (UTC)
    I mentioned that in the BP discussion. But essentially, they just don't take up enough space for me to care. --WikiTiki89 02:56, 7 February 2016 (UTC)
    (1) This is not a vote to get rid of literal translations in translation tables, they are already deprecated there, this is a vote to allow them. (2) A gender is represented by a single letter. Adding literal translations is more like adding all three forms for three-gender adjectives, eg for "infinite" inserting {{t|cs|nekonečný|m}}, {{t|cs|nekonečná|f}}, {{t|cs|nekonečné|n}}. --Droigheann (talk) 03:16, 7 February 2016 (UTC)
    Objection: "Do not give translations back into English of idiomatic translations." was not voted, so I'd argue it's not a real rule. Maybe it's a rule at least in the opinion of the editor who added it there: diff 1, diff 2. --Daniel Carrero (talk) 03:29, 7 February 2016 (UTC)
    Not every rule needs to have been voted on. It's been there uncontested since 2007 and has for the most part been followed. --WikiTiki89 03:34, 7 February 2016 (UTC)
    @Daniel Carrero: Neither was there AFAICT any vote about e.g. WT:About Czech, WT:About French &c. Do you mean I can happily ignore them as just an advice from senior editors telling me "you know, we like it better like this, but never mind that if you don't want to"? Do you mean new editors shouldn't waste their time reading our policies and study instead all the former votes to find out what is and what is not a rule? --Droigheann (talk) 18:56, 7 February 2016 (UTC)
    Ok, I apologize and take back that unvoted rules are not real rules. --Daniel Carrero (talk) 19:03, 7 February 2016 (UTC)
  4. Symbol support vote.svg Support I guess, especially when the foreign-language term is a red link, meaning there's no entry for a literal translation to appear in. If it's a blue link, I'd sort of play it by ear, preferring to include shortish literal translations while avoiding longish ones. —Aɴɢʀ (talk) 09:12, 9 February 2016 (UTC)

Oppose

  1. Symbol oppose vote.svg Oppose This creates too much duplication of information and bulks up translation tables too much. A little literal translation should be supplied at the translation's entry. --WikiTiki89 01:53, 6 February 2016 (UTC)
  2. Symbol oppose vote.svg Oppose per Wikitiki89 (provided "literal" rather than "little" translation is meant). --Droigheann (talk) 02:00, 6 February 2016 (UTC)
  3. Symbol oppose vote.svg Oppose. Translations in translation tables are like soft redirects; they're only meant to get the user to the information they need. —CodeCat 02:08, 6 February 2016 (UTC)

Abstain

Decision


Translations of taxonomic names

Voting on: Editing an item in WT:EL#Translations.

Current text:

Translations are to be given for English words only. In entries for foreign words, only the English translation is given, instead of a definition. Any translation between two foreign languages is best handled on the Wiktionaries in those languages.

References

(none)

Proposed text:

Translations should be given in English entries, and also in Translingual entries for taxonomic names. Entries for languages other than English and Translingual should not have Translations sections; usually, the English translation is given, instead of a definition. Any translation between two foreign languages is best handled on the Wiktionaries in those languages.[1]

References
  1. ^ Wiktionary:Votes/pl-2016-01/Translations of taxonomic names

Rationale and changes:

Schedule:

  • Vote starts: 00:00, 7 February 2016 (UTC)
  • Vote ends: 23:59, 7 March 2016 (UTC)

Discussion:

Support

  1. Symbol support vote.svg Support --Daniel Carrero (talk) 02:00, 7 February 2016 (UTC)
  2. Symbol support vote.svg Support In reply to DTLHS, "should" is not as strong a word than "must". I see "should" as suggesting that the eventual goal of Wiktionary is to have translation tables for all terms. So long as everyone agrees that it is OK to have entries whose translations sections consist solely of "trans-see" templates, then I have no problems with the proposed text. This, that and the other (talk) 08:25, 9 February 2016 (UTC)
  3. Symbol support vote.svg Support profesjonalizmreply 09:49, 9 February 2016 (UTC)

Oppose

Abstain

  1. Symbol abstain vote.svg Abstain I'd like to see the "for foreign words, only the English translation is given" sentence gone because of course not every FL word has an English translation, and I hate to be nitpicking again, but the current proposed wording implies to me that e.g. "common seal" should have a translation table both at common seal and at Phoca vitulina. Droigheann (talk) 19:40, 8 February 2016 (UTC)
    As discussed before, if both common seal and Phoca vitulina are 100% identical, (not always the case, apparently) then one of those could use {{trans-see}}. In theory, all taxonomic names and all colloquial names could have translation sections, but some of those could have real translation tables and others could have {{trans-see}}. --Daniel Carrero (talk) 04:05, 9 February 2016 (UTC)
    Just to be clear for everyone, "for foreign words, only the English translation is given" is part of the current text. The proposed does remove this part. To be fair, the proposed text replaces it by "usually, the English translation is given, instead of a definition." --Daniel Carrero (talk) 04:52, 9 February 2016 (UTC)
    I'm not certain I wasn't misunderstood: I abstain because I don't want to oppose a vote which proposes to change the "for foreign words &c" bit, while at the same time I don't want to support a vote which doesn't state that a taxonomic name should have a translation table under Translingual if and only if it doesn't have an English equivalent. (Incidentally when there is an English equivalent, {{trans-see}} in Translingual can do no harm but is unnecessary because the link should appear as a translation in the sense line.) --Droigheann (talk) 06:49, 9 February 2016 (UTC)
  2. Symbol abstain vote.svg Abstain I don't like the wording: it sounds like this is proposing that all English entries and all Translingual taxonomic names must have translation sections. DTLHS (talk) 04:54, 9 February 2016 (UTC)
    Is there any reason why we shouldn't have translation sections in all English entries and all Translingual taxonomic names, provided {{trans-see}} is available for repeated instances? --Daniel Carrero (talk) 05:07, 9 February 2016 (UTC)
    I think that whether Translingual entries can have translations should be a separate discussion and vote than whether they must have translations. DTLHS (talk) 05:25, 9 February 2016 (UTC)
  3. Symbol abstain vote.svg Abstain I'd like there at the very least to be restrictions on translations entered for taxonomic names, such as: (1) Do not add a term that is identical to the existing Translingual term, so don't add "German: {{t|de|Mammalia}}" to the translation table Mammalia. (2) Do not add a term that is the same as (or simply the plural of) the language's vernacular equivalent of the taxonomic name, so don't add "German: {{t|de|Säugetiere}}" to the translation table at Mammalia, as that is simply the plural of the German word that should be entered in the translation table at mammal. (3) You may add transliterations of the taxonomic name into other scripts (provided these transliterations are actually attestable in the language in question), so it is acceptable to add "Russian: {{t|ru|го́мо са́пиенс}}" to the translation table at Homo sapiens. —Aɴɢʀ (talk) 09:38, 9 February 2016 (UTC)
    Questions: Should we have a German section "Mammalia" with a declension table and separate entries for inflected forms? If yes, then would that justify including "* German: {{t|de|Mammalia}}" as a translation of Translingual "Mammalia"? --Daniel Carrero (talk) 21:08, 9 February 2016 (UTC)

Decision


Entry name: sign languages

  • Voting on:

Proposal 1. Adding the following text to WT:EL#Entry name at the end of the section. (diff)

For entry names in sign languages, see Wiktionary:About sign languages#Entry names.[1]

References
  1. ^ Wiktionary:Votes/pl-2015-12/Entry name: sign languages

Rationale (proposal 1): WT:EL#Entry name explains entry names in general but it does not explain sign language entry names; WT:ASGN#Entry names does. The proposal links the former to the latter, thereby making the former a more comprehensive guide on understanding entry names in Wiktionary.


Proposal 2. Adding the following text to WT:ASGN#Entry names at the end of the section. (diff)

The "Sign gloss:" namespace links to these entries using glosses as the page names: Sign gloss:FOOD links to the ASL entry FlatO@Mouth-PalmBack.[1]

References
  1. ^ Wiktionary:Votes/pl-2015-12/Entry name: sign languages

Rationale (proposal 2): The "Sign gloss:" namespace was introduced in 2010 (see Wiktionary:Beer parlour/2010/July#Proposal for a new namespace: "Sign Gloss:") but WT:ASGN was not updated yet to reflect that. This proposal introduces "Sign gloss:" to the policy.


Schedule:

  • Vote starts: 00:00, 8 February 2016 (UTC)
  • Vote ends: 23:59, 8 March 2016 (UTC)

Discussion:


Proposal 1

Support

  1. Symbol support vote.svg Support --Daniel Carrero (talk) 03:13, 8 February 2016 (UTC)
  2. Symbol support vote.svg Support Should be fairly uncontroversial. This, that and the other (talk) 07:03, 9 February 2016 (UTC)
  3. Symbol support vote.svg SupportAɴɢʀ (talk) 09:40, 9 February 2016 (UTC)

Oppose

Abstain


Proposal 2

Support

  1. Symbol support vote.svg Support --Daniel Carrero (talk) 03:13, 8 February 2016 (UTC)
  2. Symbol support vote.svg Support This, that and the other (talk) 07:03, 9 February 2016 (UTC)
  3. Symbol support vote.svg SupportAɴɢʀ (talk) 09:40, 9 February 2016 (UTC)

Oppose

Abstain


Decision


Pronunciation

Voting on: Editing WT:EL#Pronunciation.

See diff.

Current text:

Pronunciation
Main article: Wiktionary:Pronunciation

A typical pronunciation section may look like the following example based on the word portmanteau:

* {{a|RP}} {{IPA|/pɔːtˈmæn.təʊ/|lang=en}}
* {{a|US}} {{enPR|pôrtmă'ntō}}, {{IPA|/pɔɹtˈmæntoʊ/|lang=en}}; {{enPR|pô'rtmăntōʹ}}, {{IPA|/ˌpɔɹtmænˈtoʊ/|lang=en}}
* {{audio|en-us-portmanteau-1.ogg|Audio 1 (US)|lang=en}}
* {{audio|en-us-portmanteau-2.ogg|Audio 2 (US)|lang=en}}

The region or accent [(UK), (US), (Australia), et al.] is first if there is regional variation, followed by the pronunciation system (such as enPR[1] or IPA), a colon, then the pronunciation. (See Wiktionary:Pronunciation key for an outline of these two systems.) The phonetic transcriptions are normally placed between diagonal strokes. Use an established system of pronunciation transcription, such as IPA.

Ideally, every entry should have a pronunciation section, and perhaps a sound sample to accompany it. However, pronunciations vary widely between dialects, and non-linguists often have trouble writing down pronunciations properly.

For audio pronunciations, upload the Ogg file to Commons and link here using Template:audio.

Homophones (subsection)

List any homophones of the word in alphabetical order, wikifying each one. For example, the Pronunciation section of the English word right contains the line

* {{homophones|rite|wright|write|lang=en}}

which results in

which are the English words that sound identical to right.

If a word is a homophone in a particular dialect, it may be added provided the dialect is referred to (for example, rider is a homophone of writer[2] in accents with flapping, and beater is a homophone of beta in non-rhotic accents). Examples (for beater and right, respectively):

The following must not be added to the homophones section:

  • Words that are “nearly” homophones or rhymes (for example, for right, the words white or light);
  • Words that are homophones if they are mispronounced in some way (e.g. for miss, the word myth when pronounced with a lisp);
  • Words from other languages (which are unlikely to be true homophones anyway).

(Note that the term used here is homophone; the term homonym used by some is ambiguous as it can mean either “homophone” or “homograph”.)

Rhymes (subsection)

Add a link to the page in the “Rhymes” namespace that lists the rhymes for the word. So, for example, on the entry for hat, add the line

* {{rhymes|æt|lang=en}}

to the code. This displays as

To see the usage instructions for {{rhymes}}, see Template:rhymes/documentation.[2]

Do not list the rhymes themselves in the main namespace.[3]

References
  1. ^ previously called AHD, but renamed per 2007-02/Renaming AHD and 2007-02/Renaming AHD (run-off)
  2. 2.0 2.1 Wiktionary:Votes/pl-2010-08/Minor policy page changes
  3. ^ Wiktionary:Votes/2012-01/Modify WT:ELE rhymes section

Proposed text:

Note: The example word is carrot for illustrative purposes only, and shall be replaced by the word that is chosen in the informal poll Wiktionary talk:Votes/pl-2016-01/Pronunciation#Poll: example word.

Pronunciation
Main article: Wiktionary:Pronunciation

Ideally, every entry should have a pronunciation section, with the phonetic transcription and usually including an audio file. Note that pronunciations may vary widely between dialects, and non-linguists often have trouble writing down pronunciations properly.[1]

A typical pronunciation section may look like the following (simplified) example based on the word carrot:

Code:

* {{a|GA}} {{IPA|/ˈkæɹət/|/ˈkɛɹət/|lang=en}}
* {{a|RP}} {{IPA|/ˈkæɹət/|lang=en}}
* {{audio|en-us-carrot.ogg|Audio (US)|lang=en}}
* {{rhymes|æɹət|lang=en}}
* {{homophones|caret|karat|carat|lang=en}}
* {{hyphenation|car|rot|lang=en}}

Result:

Notes:

  • The region or accent [(General American), (Received Pronunciation), (Australia), et al.] is first if there is regional variation, followed by the pronunciation system (such as enPR[2] or IPA), a colon, then the pronunciation. (See Wiktionary:Pronunciation key for an outline of these two systems.) The phonetic transcriptions are normally placed between diagonal strokes. Use an established system of pronunciation transcription, such as IPA.
  • For audio pronunciations, upload the Ogg file to Commons and link here using Template:audio.
  • Rhymes are listed in the "Rhymes" namespace; do not list rhymes in the main namespace. Instead, in each entry, add a link to the respective rhymes page. See {{rhymes}} for usage instructions.
  • Homophones are words in the same language that have the same sound. (Avoid using the ambiguous term homonym, as it can mean either homophone or homograph.) Don't add: 1) words that are “nearly” homophones or rhymes (for example, for right, the words white or light); 2) words that are homophones if they are mispronounced in some way (e.g. for miss, the word myth when pronounced with a lisp); 3) words from other languages (which are unlikely to be true homophones anyway). Homophones should be listed in alphabetical order using the {{homophones}} template. If a word is a homophone in a particular dialect, it may be added provided the dialect is referred to (for example, rider is a homophone of writer in accents with flapping, and beater is a homophone of beta in non-rhotic accents).
  • Use the template {{hyphenation}} for hyphenations.
References
  1. ^ Wiktionary:Votes/pl-2016-01/Pronunciation
  2. ^ previously called AHD, but renamed per 2007-02/Renaming AHD and 2007-02/Renaming AHD (run-off)

Changes and rationale:

  • More compact version of the same policy. No rules were intended to be changed, they are just described in a way that takes up less space.
  • Using a bulleted list to organize the ideas. The order of ideas changes in a few places.
  • The subsections (Homophones and Rhymes) were removed. The same information was kept, albeit in the bulleted list.
  • The current text uses 4 entries as examples of multiple types of pronunciation information: portmanteau, beta, right and hat. The proposed text uses only 1 entry as an example of all the types of pronunciation information previously mentioned: carrot. Bonus: The example shows the transcription, the audio, the homophones and rhymes in order in the carrot example.
  • Added hyphenation.
  • Another step in the direction of having WT:EL completely voted.

Schedule:

  • Vote starts: 00:00, 9 February 2016 (UTC)
  • Vote ends: 23:59, 9 March 2016 (UTC)

Discussion:

Support

  1. Symbol support vote.svg Support --Daniel Carrero (talk) 01:55, 9 February 2016 (UTC)

Oppose

  1. Seems like no-one got in fast enough to copyedit this. Daniel Carrero, do you object to the changes I made in this diff? (If you do, or disagree with my abuse of process, you are of course free to revert them.) Even so, I feel obliged to Symbol oppose vote.svg Oppose, because the text no longer specifies how to implement the sentence "If a word is a homophone in a particular dialect, it may be added provided the dialect is referred to." - the example of how to format the context label in this scenario has been removed. This, that and the other (talk) 06:56, 9 February 2016 (UTC)
    I don't mind that you changed the vote. (To clarify, when he changed the vote, I was the only one who voted.) --Daniel Carrero (talk) 07:09, 9 February 2016 (UTC)
  2. Symbol oppose vote.svg Oppose I'm not sure why the example word is still carrot after it clearly lost in the poll on the talk page. --WikiTiki89 16:22, 9 February 2016 (UTC)
    It's because we New Englanders are not respected here on Wiktionary, as I have just seen myself earlier, with someone trying to insist that "squ-ehhr" (as opposed to "squeir") is the pronunciation for "square", and claiming that I am "in the minority" in thinking that it is not. Tharthan (talk) 16:24, 9 February 2016 (UTC)
    @Wikitiki89, are you opposing the vote just because of the word carrot? Please read again the "Procedural note" in this vote and the poll introduction. The poll started only a few days ago, the word that passes should be able to replace carrot here, without the need for another formal vote. --Daniel Carrero (talk) 16:34, 9 February 2016 (UTC)
    I didn't notice that. In that case, why not delay the start of the vote? --WikiTiki89 16:40, 9 February 2016 (UTC)
    That could be done if people want, but I thought the example word to be a minor issue that does not actually change the regulations so I just started the vote in the scheduled date. When "Reconstruction:" pages were voted, there was a vote for the creation of a new namespace and a poll to see what exactly would be the name. Technically, the poll could go on as long as we want. --Daniel Carrero (talk) 17:21, 9 February 2016 (UTC)
    In the Reconstruction vote, I made sure to specify in detail exactly where and how the name of the namespace would be used. Here it is not clear what the text of the example will be, and that should be part of the vote. --WikiTiki89 18:14, 9 February 2016 (UTC)
    I replaced the procedural note by a note that makes it clearer. (diff) --Daniel Carrero (talk) 20:24, 9 February 2016 (UTC)
    That does help, but unless you actually create the text of the example for each possible word, I wouldn't know what I would be voting for. --WikiTiki89 20:51, 9 February 2016 (UTC)
    Can't we just consider the current pronunciation section of all the current entries in the poll? But, if needed for formal voting purposes, I can create a separate page and copy all the pronunciation sections of these entries there. --Daniel Carrero (talk) 21:24, 9 February 2016 (UTC)
    The problem is that I might disagree with how some of the examples are currently laid out in their entries. I think the text of the example is an important part of what we are voting on, and I can't vote without knowing what it would be. Perhaps we should just omit the example section entirely from this vote and vote on it in a later vote. --WikiTiki89 21:33, 9 February 2016 (UTC)
  3. Symbol oppose vote.svg Oppose per Wikitiki. Carrot shouldn't be used, but several of the entries that could replace carrot need to be tweaked (e.g. the narrow transcriptions of wholly should be checked). I think it's be best to shelve this vote until we work out an example. - -sche (discuss) 04:54, 10 February 2016 (UTC)

Abstain

Decision


Notes about pronunciations

Voting on: Adding a new rule to WT:EL#Pronunciation:

  • Entries should not have a "Usage notes" section whose only purpose is having notes about the pronunciation. Pronunciation notes can be added directly in the "Pronunciation" section.

Rationale:

  • In some entries, "Usage notes" sections have been found directly below the actual pronunciations, for notes about the pronunciations. Some users have been removing the "Usage notes" section and placing the notes in the "Pronunciation" section. (sources: see the discussions linked below) This vote is meant to officialize the "Pronunciation" section as the correct place for pronunciation notes.

Schedule:

  • Vote starts: 00:00, 10 February 2016 (UTC)
  • Vote ends: 23:59, 10 March 2016 (UTC)

Discussion:

Support

  1. Symbol support vote.svg Support --Daniel Carrero (talk) 01:00, 10 February 2016 (UTC)

Oppose

Abstain

Decision


Placement of "Usage notes"

Terminology:

  • The term inflection section henceforth in the text of this vote refers to any Inflection, Conjugation, Declension, or Mutation section, or any other section whose purpose is to list non-lemma forms of the lemma in question.

Voting on:

  • Proposal 1:
    • Fix the placement of the "Usage notes" section after the definitions and before any non-inflection section. sections, leaving the relation to any inflection section up to proposal 2 below.
  • Proposal 2:
    • If the proposal 1 passes, where exactly should the "Usage notes" section be placed, in relation to any inflection section. If the result is inconclusive, it remains unspecified whether the "Usage notes" section goes before or after the inflection section.
      A. Always before the inflection section.
      B. Always after the inflection section.
      C. Up to personal preference.
      D. Depending specifically on the contents of the usage notes.

Rationale:

Schedule:

  • Vote starts: 00:00, 11 February 2016 (UTC)
  • Vote ends: 23:59, 11 March 2016 (UTC)

Discussion:


Proposal 1

Support

Oppose

Abstain


Proposal 2

Support option A (before inflections)

Support option B (after inflections)

Support option C (personal preference)

Support option D (depending on content)

Abstain


Decision


Language 2

Editing WT:EL#Language. This is a follow-up to Wiktionary:Votes/pl-2015-12/Language.

Current text:

Language

Each entry has one or more L2 (level-two) language sections. For example, the entry sea has different meanings in English and Spanish, both on the same page. Priority is given to Translingual: this heading includes terms that remain the same in all languages. This includes taxonomic names, symbols for the chemical elements, and abbreviations for international units of measurement; for example Homo sapiens, He ‎(helium), and km ‎(kilometre). English comes next, because this is the English Wiktionary. After that come other languages in alphabetical order. Language sections should be separated from each other by a horizontal line, generated with four dashes (----).[1]

For languages that have multiple names, a single name is chosen that should be used throughout Wiktionary. Typically, this is an English name for the language. See Wiktionary:Languages for more information.

References
  1. ^ Wiktionary:Votes/pl-2015-12/Language

Proposed text:

Language
  • Every entry should have one or more language sections.
  • All language sections should be level-two.
  • The order of language sections is: Translingual, English, then other languages in alphabetical order
  • Language sections must be separated from each other by a horizontal line.
  • For languages that have multiple names, a single name is chosen that should be used throughout Wiktionary. See Wiktionary:Languages.[1]

See Help:Language sections for more information.

References
  1. ^ Originally, Wiktionary:Votes/pl-2015-12/Language. Revised by Wiktionary:Votes/pl-2016-02/Language 2.

Changes:

  • Removing all the how-to parts and explanations from WT:EL#Language and leaving only the actual regulations plus a link to Help:Language sections. (The help page is freely editable. Currently, it contains more comprehensive explanations, directed at new users.)

Rationale:

Schedule:

  • Vote starts: 00:00, 12 February 2016 (UTC)
  • Vote ends: 23:59, 12 March 2016 (UTC)

Discussion:

Support

Oppose

Abstain

Decision


Automated transliterations

Voting on:

Removing this rule from WT:EL#Translations:

  • Add a transliteration or romanization of a translation into a language that does not use the Roman alphabet. Note however that only widespread romanization systems may be used. See Wiktionary:Transliteration.

Adding this rule in its place:

  • Translations not in the Latin script should display a transliteration according to that language's transliteration policy, unless the policy states otherwise.

Rationale:

  • This vote is expected to codify common practice. It is believed that people are not supposed to "add a transliteration or romanization" at all times; rather, there are times when automatic transliterations are to be used, as described in the proposed text.
  • The statement "Note however that only widespread romanization systems may be used." is incorrect. Not just any random transliteration system may be used, it should follow the appropriate Wiktionary-established conventions, as states in the proposed text.

Notes:

The earliest versions of the current rule apparently are:
  • diff: "If that language does not use the Roman alphabet, it is helpful to add a transliteration or romanization." (by Eclecticology on 28 December 2005)
  • diff: "If a word is translated into a language that does not use the Roman alphabet, it is helpful to add a transliteration or romanization. Note however that only widespread romanization systems may be used. See Wiktionary:Transliteration." (by Ncik on 15 March 2006)
This was before the advent of Lua/Scribunto, and automatic romanizations.

Schedule:

  • Vote starts: 00:00, 13 February 2016 (UTC)
  • Vote ends: 23:59, 13 March 2016 (UTC)

Discussion:

Support

Oppose

Abstain

Decision


Entry name 3

Voting on:

Adding some text in WT:EL#Entry name. (added text is underlined)

The name of the entry is the term, phrase, symbol, morpheme or other lexical unit being defined.[1][2]

For languages with two cases of script, the entry name usually begins with a lowercase letter.[3] For example, use work for the English noun and verb, not "Work". Words and phrases which begin with a capital letter in running text are exceptions. Typical examples include proper nouns (Paris, Neptune), German nouns (Brot, Straße), and many abbreviations (PC, DIY). Compare: you can't judge a book by its cover and Rome wasn't built in a day. If someone tries accessing the entry with incorrect capitalization, the software will try to redirect to the correct page automatically.

Omit an initial article unless it makes a difference in the meaning. E.g., cat's pajamas instead of the cat's pajamas. For multi-word entries, prefer the generic personal pronoun for the main entry. (one, oneself, someone, one's, etc.) Common forms with other pronouns are usually redirected to the main form. For example, fall over oneself would be the main entry and these are some entries that would redirect to it: fall over himself, fell over himself, falling over himself, fall over herself, fall over themselves, etc. Use the infinitive form of the verb (but without to) for the principal verb of a verbal phrase, for example: rain cats and dogs. In English, sometimes the lemma should include a specific personal pronoun. For example, the proverb you can't fight City Hall would be the lemma, not one can't fight City Hall. For prefixes, suffixes and other morphemes in most languages, place the character "-" where it links with other words: pre-, -ation, -a-, etc.

When multiple capitalizations, punctuation, diacritics, ligatures, scripts and combinations with numbers and other symbols exist, such as pan (as in "frying pan"), Pan (the Greek god), pan- (meaning "all-") and パン ‎(pan) (Japanese for "bread"), use the template {{also}} at the top of the page to cross-link between them. When there are too many variations, place them in a separate appendix page, in this case Appendix:Variations of "pan".

Use the "Alternative forms" header for variations of the same word kept in multiple pages, including:

Some page titles can't be created because of restrictions in the software, usually because they contain certain symbols such as # or |, or are too long. The full list of those entries is at Appendix:Unsupported titles. They are named using the descriptive format "Unsupported titles/Number sign", while using JavaScript to show the correct title like a normal entry.

Matched-pairs, such as brackets and quotation marks, can be defined together as single entries. The entries are named with a space between the left and right characters. Examples: ( ), [ ], “ ”, ‘ ’, " ", „ ”, « », ⌊ ⌋, ¡ ! and ¿ ?.[5][6]

References
  1. ^ Wiktionary:Votes/pl-2015-10/Entry name section
  2. ^ Wiktionary:Votes/pl-2016-02/Entry name 3
  3. ^ Wiktionary:Votes/pl-2005-03/First letter capitalization
  4. ^ Wiktionary:Votes/pl-2015-12/Entry name section 2
  5. ^ Wiktionary:Votes/2015-08/Allowing matched-pair entries
  6. ^ Wiktionary:Votes/2015-10/Matched-pair naming format: left, space, right

Removing the whole section WT:CFI#Entry name.

Idiomatic phrases

Many phrases take several forms. It is not necessary to include every conceivable variant. When present, minor variants should simply redirect to the main entry. For the main entry, prefer the most generic form, based on the following principles:

Pronouns (subsection)

Prefer the generic personal pronoun, one or one’s. Thus, feel one’s oats is preferable to feel his oats. Use of other personal pronouns, especially in the singular, should be avoided except where they are essential to the meaning.

Articles (subsection)

Omit an initial article unless it makes a difference in the meaning. E.g., cat’s pajamas instead of the cat’s pajamas.

Verbs (subsection)

Use the infinitive form of the verb (but without “to”) for the principal verb of a verbal phrase. Thus for the saying It’s raining cats and dogs, or It was raining cats and dogs, or I think it’s going to rain cats and dogs any minute now, or It’s rained cats and dogs for the last week solid the entry should be (and is) under rain cats and dogs. The other variants are derived by the usual rules of grammar (including the use of it with weather terms and other impersonal verbs).

Proverbs (subsection)

A proverb entry's title begins with a lowercase letter, whether it is a full sentence or not. The first word may still be capitalized on its own:

Rules moved from WT:CFI#Idiomatic phrases to WT:EL#Entry title:

  • prefer the generic personal pronoun, one or one’s
  • omit the initial article
  • use the infinitive form of the verb (without to)
  • a proverb entry's title begins with a lowercase letter

New rules added to WT:EL#Entry title which weren't taken from WT:CFI#Idiomatic phrases:

  • use redirects in some cases
  • explaining the difference between {{also}}-related entries and alternative forms
  • mentioning that sometimes, different scripts are found in the headword line

Rationale:

  • Having a more complete WT:EL#Entry name by adding some entry name information that wasn't there yet.
  • Removing WT:CFI#Idiomatic phrases; arguably, the affected rules are not about criteria for inclusion.

Schedule:

  • Vote starts: 00:00, 14 February 2016 (UTC)
  • Vote ends: 23:59, 14 March 2016 (UTC)

Support

Oppose

Abstain

Decision


Multiple pronunciation sections

Voting on:

  • Proposal 1: In the case of multiple pronunciations:
    Option A: We should have multiple pronunciation sections.
    Option B: We should put multiple pronunciations in one pronunciation section (but special exceptions may be made for specific languages).
    Note: Proposals 2, 3 and 4 below only come into effect if we use multiple pronunciation sections.
  • Proposal 2:
    Option A: If there are multiple pronunciation sections, they should be numbered.
    Option B: If there are multiple pronunciation sections, they should be repeated unnumbered.
  • Proposal 3:
    Option A: If there are multiple pronunciation sections, the content to which the pronunciation applies should be nested under the pronunciation section.
    Option B: If there are multiple pronunciation sections, the content to which the pronunciation applies should follow the pronunciation section.
  • Proposal 4:
    If there are multiple pronunciation sections, etymology sections should not be nested under pronunciation sections.

Rationale:

  • Deciding if there should be some standardization of the formatting of multiple pronunciation sections.

Schedule:

  • Vote starts: 00:00, 15 February 2016 (UTC)
  • Vote ends: 23:59, 15 March 2016 (UTC)

Proposal 1

Support Option A

Support Option B

Oppose

Abstain


Proposal 2

Support Option A

Support Option B

Oppose

Abstain


Proposal 3

Support Option A

Support Option B

Oppose

Abstain


Proposal 4

Support

Oppose

Abstain


Decision


Placement of "Alternative forms"

Voting on:

  • Fix the placement of the "Alternative forms" section directly above the "Synonyms" section, as a subsection of the POS section.

Rationale:

  • Arguably, synonyms and alternative forms are related concepts.
  • Removing "Alternative forms" from above the definitions is a way to promote the definitions.

Simplified entry examples:

==English==

===Noun===
{{en-noun}}

# Definition.

(possibly other headers between the definitions and the alternative forms)

====Alternative forms====
* {{l|en|hard-working}}

====Synonyms====
* {{l|en|industrious}}
==Portuguese==

===Pronoun===
{{pt-pron}}

# Definition.

(possibly other headers between the definitions and the alternative forms)

====Alternative forms====
* {{l|pt|vosmecês}} {{q|archaic}}

====Synonyms====
* {{l|pt|vós}} {{q|archaic or regional}}, {{l|pt|os senhores}} {{q|Brazil, formal}}

Schedule:

  • Vote starts: 00:00, 16 February 2016 (UTC)
  • Vote ends: 23:59, 16 March 2016 (UTC)

Support

Oppose

Abstain

Decision


Removing "Flexibility"

Voting on:

Removing the section WT:EL#Flexibility. (diff)

Flexibility
While the information below may represent some kind of “standard” form, it is not a set of rigid rules. You may experiment with deviations, but other editors may find those deviations unacceptable, and revert those changes. They have just as much right to do that as you have to make them. Be ready to discuss those changes. If you want your way accepted, you have to make the case for that. Unless there is a good reason for deviating, the standard should be presumed correct. Refusing to discuss, or engaging in edit wars may also affect your credibility in other unrelated areas.

Disclaimer:

  • Removing this section does not mean opposing all that is being said in the text. It's possible that some of the information is true but would be better placed somewhere else.

Rationale:

  1. "While the information below may represent some kind of “standard” form, it is not a set of rigid rules."
    • This is a meta-rule, not a layout rule, and could be part of a help page concerning how rigid are the rules in our policies.
  2. "You may experiment with deviations, but other editors may find those deviations unacceptable, and revert those changes. They have just as much right to do that as you have to make them."
    • Same as above.
  3. "Be ready to discuss those changes. If you want your way accepted, you have to make the case for that."
  4. "Unless there is a good reason for deviating, the standard should be presumed correct."
    • Arguably, this sentence could be added to any policy without changing the content in any way.
  5. "Refusing to discuss, or engaging in edit wars may also affect your credibility in other unrelated areas."

Schedule:

  • Vote starts: 00:00, 17 February 2016 (UTC)
  • Vote ends: 23:59, 17 March 2016 (UTC)

Support

Oppose

Abstain

Decision


Removing "Quotations"

Voting on:


Proposal 1:

  • Allowing all entries to be edited by bot, to remove the "Quotations" section when the only purpose of the section is linking to pages in the Citations: namespace.

Example (proposal 1):

Quotations

Rationale (proposal 1):

  • This is a duplication of the link to the citations namespace that is found at the top of all entries.

Proposal 2:

  • Allowing all entries to be edited by bot, to remove the "Quotations" section when it has actual quotations in it, with the requirement that all affected quotations shall either be moved the respective Citations: pages, or moved manually to the appropriate senses in the entries.

Rationale (proposal 2):

  • Quotations are more helpful when found under the respective senses. A bot is unable to arrange quotations in the right senses, but it can move the quotations to the Citations: page, where they can either be kept without that arrangement, or be manually sorted into senses later.

Schedule:

  • Vote starts: 00:00, 18 February 2016 (UTC)
  • Vote ends: 23:59, 18 March 2016 (UTC)

Proposal 1

Support

Oppose

Abstain


Proposal 2

Support

Oppose

Abstain


Decision


Remove "The essentials"

Voting on:

If all these votes pass:

Then, remove this text from WT:EL:

The essentials
  1. Language lets you know the language of the word in question. It is almost always in a level two heading (See Wiktionary:How to edit a page for some basic terminology we use). In most cases the language header contains a language in its traditional meaning. Priority is given to ==Translingual==; this heading includes terms that remain the same in all languages. The symbols for the chemical elements and the abbreviations for international units of measurement are but two examples of translingual terms. English comes next because this is the English Wiktionary. After that come the other languages in alphabetical order.
  2. Part of speech may be a misnomer, but it seemed to make sense when it was first chosen. Most part-of-speech headings represent the lexical function of the term, such as Noun, Verb, Adjective, or Interjection. Others, such as Symbol, Suffix, Initialism, Phrase, or Proverb, classify the various terms in Wiktionary. Each entry has one or more part of speech sections, where the definitions themselves are found. The sections are most frequently level three, but may have a lower level for terms that have multiple etymologies or pronunciations.[1]
  3. References are becoming more important as we strive to improve the reliability of Wiktionary. While we may be lax in demanding references for words that are easily found in most paper dictionaries, references for more obscure words are essential. References may be added in a separate header of adequately chosen level or added directly to specific senses.
Rerefences
  1. ^ Wiktionary:Votes/pl-2012-04/Editing the "part of speech" paragraph in ELE

Schedule:

  • Vote starts: 00:00, 22 March 2016 (UTC)
  • Vote ends: 23:59, 22 April 2016 (UTC)

Discussion:

Support

Oppose

Abstain

Decision


Etymology

Voting on: Editing WT:EL#Etymology.

Current text:

Etymology
Main article: Wiktionary:Etymology

The first header below the language heading is usually the level 3 “Etymology” header. The etymology is given right below the header without indentation. Etymology essentially shows where the word comes from. This may show the forms in other languages that underlie the word. For many modern words it may show who coined the word. If a word is derived from another in the same language by a regular rule, such as formation of an English adverb by adding “ly”, it is not necessary to repeat the complete details of the word’s origin on the page for the derived word.[1]

Sometimes two words with different etymologies belong in the same entry because they are spelled the same (they are homographs). In such a case there will be more than one “Etymology” header, which we number. Hence for a word like lead the basic header skeleton looks like this:

===Etymology 1===
====Pronunciation====
====Noun====
===Etymology 2===
====Pronunciation====
====Noun====
====Verb====

Note that in the case of multiple etymologies, all subordinate headers need to have their levels increased by 1 in order to comply with the fundamental concept of showing dependence through nesting.

The vote “2007-10/style for mentioned terms” is relevant to this section, without specifying text to be amended in this document, so please see it for details.
References
  1. ^ Wiktionary:Votes/pl-2010-08/Minor policy page changes

Proposed text:

Etymology
Main article: Wiktionary:Etymology

The “Etymology” section contains the origins of the word, from the same or other languages. It is usually the first in each language section, except it is located below the “Alternative forms” header when it exists.[1]

For many modern words, it may show who coined the word. If a word is derived from another in the same language by a regular rule, such as formation of an English adverb by adding “-ly”, it is enough to use a template linking to the original word and the suffix/prefix or other morphemes; it is not necessary to repeat the complete details of the word’s origin on the page for the derived word.

For words with multiple etymologies in the same language, they are numbered like this: “Etymology 1”, “Etymology 2”, etc. and the sections below it gain +1 indentation level. See WT:EL#Headings for more information.

Don't use abbreviations such as esp. ‎(especially) or cf. ‎(compare); write in full form.

Etymology sections use a variety of templates. A simple example, with the wiki markup, followed by the result:

From {{etyl|la|en}} {{m|la|absolūtus}}.

From Latin absolūtus.

Here are some examples of templates used in etymologies. To change the languages, use the apropriate language code.

  • {{etyl}} (parameter 1: origin language; parameter 2: target language)
    Both {{etyl|ang|en}} and {{etyl|ang|-}} generates the word Old English. The difference is that the former categorizes the entry
  • {{der}}, {{inh}}, {{bor}} (parameter 1: target language; parameter 2: origin language)
    These behave in a way similar to {{etyl}}. Unfortunately, the language parameters are reversed.
    {{der}} means derivation, {{inh}} means inheritance (for example, a term inherited from Middle English to English) and {{bor}} means borrowing
  • {{m}}
    {{m|pt|palavra}} mentions the Portuguese word palavra in running text. If the mentioned word is written in Latin script, it is going to be italicized.[2]
  • {{prefix}}, {{suffix}}, {{affix}}
    These templates connect words with morphemes and format them accordingly with the symbol + between them.
  • {{blend}}, {{compound}}
    These templates accept multiple words as parameters and format them accordingly with the symbol + between them.
  • {{abbreviation of}}, {{acronym of}}, {{initialism of}}, {{contraction of}}, {{short for}}
    These templates are usually used in definition lines. Sometimes, they are used in etymologies.
Rerefences
  1. ^ Wiktionary:Votes/pl-2015-12/Etymology
  2. ^ Wiktionary:Votes/2007-10/style for mentioned terms

Schedule:

  • Vote starts: 00:00, 23 March 2016 (UTC)
  • Vote ends: 23:59, 23 April 2016 (UTC)

Discussion:

Support

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: