Wiktionary:Votes/pl-2016-09/No headings nested inside templates or tags

No headings nested inside templates or tags
Voting on: Adding this rule to WT:NORM:
 * No headings nested inside templates or tags, as in  or.

Note:
 * WT:NORM applies to entries only. Some talk pages use headings inside templates, but they won't be affected.

Rationale:
 * No entry does this anyway, and explicitly disallowing this would make parsing of entries easier, because it would not be necessary to determine if a heading is "real" or is nested within a template or an HTML tag.

Schedule:
 * Vote starts: 00:00, 30 September 2016 (UTC)
 * Vote ends: 23:59, 29 October 2016 (UTC)
 * Vote created: --Daniel Carrero (talk) 03:41, 23 September 2016 (UTC)

Discussion:
 * [[Image:Wikt rei-artur3.svg|20px]] Beer parlour/2016/August
 * [[Image:Wikt rei-artur3.svg|20px]] Beer parlour/2016/September
 * [[Image:Wikt rei-artur3.svg|20px]] Wiktionary talk:Votes/pl-2016-09/No headings nested inside templates or tags

Support

 * 1)  --Daniel Carrero (talk) 06:39, 30 September 2016 (UTC)
 * Of the 35 rules currently in WT:NORM, most of them would never be broken in a normal entry (like the "don't add useless spaces in categories like " thing). I think it's normal and desirable to list some things that we won't do, but the software would accept. If this vote fails and someone tries to nest headings inside templates, or tags, we'll revert and say: "we never do it!" But if this vote passes, we'll be able to say: "You are breaking a voted and approved layout rule, see WT:NORM." --Daniel Carrero (talk) 21:16, 30 September 2016 (UTC)
 * , but I agree with those in the Abstain section that we should include this in a section with stuff that only happens in rare circumstances. Nesting a header inside of something isn't ever good here, although on most Wiktionaries, entry headings literally depend on templates (frwikt is a good example), which confuses me as to why we don't. PseudoSkull (talk) 22:30, 30 September 2016 (UTC)
 * 1)  &#x200b;—msh210℠ (talk) 19:59, 13 October 2016 (UTC)
 * 2) . Doesn't look like it'll make it, but I can't see why adding this would be a bad thing. —Μετάknowledge discuss/deeds 17:20, 25 October 2016 (UTC)
 * 3)  - I like this behavior so might as well make it law. - TheDaveRoss 17:29, 25 October 2016 (UTC)
 * - Nesting headers in templates causes all sorts of problems. It would be good to explicitly discourage this. Kaldari (talk) 19:46, 3 November 2016 (UTC)
 * : I'm converting your normal vote into a late vote, by removing it from the numerical order. The current voting already ended a few days ago. Feel free to cast late votes whenever you want, because they build up and demonstrate better where the consensus lies. This may help the proposal to be revisited inthe future, if people want. --Daniel Carrero (talk) 19:52, 3 November 2016 (UTC)

Oppose

 * 1) . Why don't we add a paragraph prohibiting pigs from flying instead? --WikiTiki89 20:12, 30 September 2016 (UTC)
 * I don't understand. Pigs can't fly. Are you saying people can't nest headings in templates or tags? They may not do it because we have an unwritten tradition of not doing so, but the software would accept it. --Daniel Carrero (talk) 21:03, 30 September 2016 (UTC)
 * Sorry my analogy wasn't perfect, but the point is that we don't need to prohibit things that no one does. --WikiTiki89 21:09, 30 September 2016 (UTC)
 * 1)  I don't think "makes it easier to code a parser" is a good reason for anything. Write a proper parser. Equinox ◑ 21:10, 30 September 2016 (UTC)
 * Even a proper parser would not know what to do in such a case. The issue here is that the wikitext itself would be wrong in such a situation, which is why no one would ever do this, and is also why no one does do this, which is the real reason we don't need to explicitly prohibit it. --WikiTiki89 21:14, 30 September 2016 (UTC)
 * 1) Weak  per above. Andrew Sheedy (talk) 21:35, 30 September 2016 (UTC)
 * 2)  -Xbony2 (talk) 23:56, 7 October 2016 (UTC)

Abstain

 * no-one cares. Renard Migrant (talk) 21:38, 30 September 2016 (UTC)
 * The People reading the policy pages care that they have to sift through all of the nonsense before they find anything useful. --WikiTiki89 21:44, 30 September 2016 (UTC)
 * Putting all the absurdly rare stuff last might make sense. However the number of things we don't want in entries is basically an infinite set and writing out infinitive sets is foolhardy. Still since WT:NORM can be edited without a vote, I don't understand why we're voting on this. Renard Migrant (talk) 21:50, 30 September 2016 (UTC)
 * WT:NORM can't be edited without a vote. This is written in the heading, and was voted on Votes/pl-2015-07/Normalization of entries 2. --Daniel Carrero (talk) 21:55, 30 September 2016 (UTC)
 * The heading actually says it can. Renard Migrant (talk) 22:08, 30 September 2016 (UTC)
 * Fair enough, there are some situations where we can edit the policy without a vote. But this is the same heading as WT:EL and WT:CFI. I'd say that anything that changes actual regulations is substantial, don't you agree? Last time someone tried to add rules in WT:NORM without a vote, it got reverted, around October 2015. Either way, I believe that the oppose votes here are enough to prove that the change would be contested. --Daniel Carrero (talk) 23:51, 30 September 2016 (UTC)
 * 1)  I refrain from supporting per WikiTiki and Renard. I feel somewhat uneasy about the proliferation of low-added-value regulations. Regulations are something people are supposed to read, in this case bot operators. If no one ever does this, then I tend to think we don't need a statement covering this. There could be value in this piece of regulation, but I cannot see it. --Dan Polansky (talk) 15:07, 22 October 2016 (UTC)

Decision
Fails 5–4 (56%). &#x200b;—msh210℠ (talk) 22:10, 29 October 2016 (UTC)
 * This is traditionally treated as no consensus. —Μετάknowledge discuss/deeds 00:49, 30 October 2016 (UTC)
 * Tomato, tomato: the proposal doesn't get implemented. &#x200b;—msh210℠ (talk) 09:17, 31 October 2016 (UTC)
 * Thanks for closing the vote, msh210. Personally, I agree that "No consensus" is best, but you can consider it just a suggestion on my part. My reason to suggest that is: The vote would pass if 1 opposer changed their vote to support, so it's a weak form of "fail"; it could have passed. If possible, I'd just like to keep WT:VTIME consistent, with "no consensus" instead of "failed" in all the right votes. When this vote enters the timeline, I plan to use "No consensus" for this one, too. --Daniel Carrero (talk) 09:36, 31 October 2016 (UTC)