Misplaced Pages

:Village pump (proposals): Difference between revisions - Misplaced Pages

Article snapshot taken from Wikipedia with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.
Browse history interactively← Previous editNext edit →Content deleted Content addedVisualWikitext
Revision as of 17:57, 5 October 2014 editFunkMonk (talk | contribs)Autopatrolled, Extended confirmed users, Page movers, File movers, Pending changes reviewers102,606 edits →Conflict infobox← Previous edit Revision as of 17:58, 5 October 2014 edit undoAFBorchert (talk | contribs)Extended confirmed users, Pending changes reviewers, Rollbackers2,819 edits →SUPPORT: +1Next edit →
Line 192: Line 192:
:# '''SUPPORT''' as RfC author. I want to make every effort of develop a more collaborative relationship between the community and the WMF. ] (]) 18:01, 3 October 2014 (UTC) :# '''SUPPORT''' as RfC author. I want to make every effort of develop a more collaborative relationship between the community and the WMF. ] (]) 18:01, 3 October 2014 (UTC)
:# '''Support'''. First we should try to work with them, FWIW. Then, when that will fail, ]. ] (]) 16:36, 5 October 2014 (UTC) :# '''Support'''. First we should try to work with them, FWIW. Then, when that will fail, ]. ] (]) 16:36, 5 October 2014 (UTC)
:# '''Support'''. The seven days give WMF sufficient time to implement this. Features that are switched on by default and problematic in regard to copyright law (two clicks to access complete copyright information) lie within the domain of the community. How can we with good conscience use images at en:wp if, by default, this feature hides essential copyright info? This is a problem of the community as many of them work with their real names and have consequently a different perspective than the WMF who sits in the safe harbour. --] (]) 17:58, 5 October 2014 (UTC)


===OPPOSE=== ===OPPOSE===

Revision as of 17:58, 5 October 2014

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts

New ideas and proposals are discussed here. Before submitting:


« Archives, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215

Centralized discussion
Village pumps
policy
tech
proposals
idea lab
WMF
misc
For a listing of ongoing discussions, see the dashboard.

"Prompt me when entering a blank edit summary" - option to suppress when "minor edit" is selected

Hi, I appreciate the "Prompt me when entering a blank edit summary" - it reminds me when I occasionally forget to enter one or rarely accidentally save the edit before finishing. But I find it a bit annoyoing when I'm just making a minor change and I have checked the "This is a minor edit" checkbox. Can we have an option (preferably just below the "Prompt me..." option) such as "Don't prompt me when I'm making a minor edit" - preferably turned on by default? Keep up the great work everyone! Facts707 (talk) 13:33, 24 September 2014 (UTC)

I have concerns that that might encourage editors to inappropriately mark edits as minor rather than dealing with the "inconvenience" of entering an edit summary. In any case, I may be amenable to the inclusion of the option, but I oppose having it turned on by default, especially when turning it on would require minimal effort for editors who wish to utilize it. DonIago (talk) 13:40, 24 September 2014 (UTC)
With the existing system, you just have to add a space to the edit summary and it will not prompt you; is this not sufficient? —Quondum 16:34, 24 September 2014 (UTC)
Comment Perhaps, alternatively, checking the 'minor edit' box can be made to force a space, or even the single letter, "m", into the edit box. No need to opt in or out, just an automatic entry. As far as @Doniago:'s concern, some editors do that now. GenQuest 19:12, 24 September 2014 (UTC)
Shouldn't all edits have a summary, even if they're minor? Personally, when RC patrolling if I see a minor edit without a summary, I give the edit extra scrutiny for potential vandalism. Ivanvector (talk) 19:48, 24 September 2014 (UTC)
It's hard enough to get people to leave summaries as it is. Please don't encourage them not to, particularly not on minor edits which can be anything. Britmax (talk) 19:50, 24 September 2014 (UTC)
Same here. I feel we should have more edit summaries, not less. DonIago (talk) 20:17, 24 September 2014 (UTC)
Nonsense. Those who leave edit summaries will continue to do so, those who usually don't leave edit summaries will continue to not leave edit summaries. The proposal addresses an issue which is a time saver for wikignomes and those editors who are constantly making maintenance and other minor edits to better the encyclopedia, and shouldn't be dismissed off-handedly. GenQuest 02:27, 29 September 2014 (UTC)
What sort of "maintenance edit" warrants a blank edit summary? I like knowing what changed without having to scour diffs. Ivanvector (talk) 03:03, 29 September 2014 (UTC)
I make lots of minor edits and I try to always use a summary. I don't see any valid reason to leave a summary off unless you're relying on WP:AES. --NYKevin 14:15, 2 October 2014 (UTC)

Distinguishing between New Pages Patrol reviews and AfC reviews

Following a discussion at the idea lab, I would like to propose specifying that New Page Patrols are patrols, not reviews, in user notifications. A common question I see asked at the Teahouse, Help Desk, and IRC help channel is from users who are confused about why their article draft/user page/sandbox has been 'reviewed' and yet they can see no change. This is particularly confusing for new users who have submitted an Article for Creation - their article being reviewed seems to suggest that an accept or decline decision has been made, and they are confused when no such decision is obvious. This stems from both New Page Patrol and AfC reviews being described as 'reviews'; when a page is patrolled the user receives an email and notification informing them that their "page has been reviewed" when in fact it has been patrolled. I suggest changing the following interface messages (thanks to Jackmcbarn for finding them) to specify that the page has been "patrolled" not "reviewed":

Additionally it could be beneficial to include either a brief explanation of what NPP is or some link to WP:NPP in the notification or email. Sam Walton (talk) 22:40, 2 September 2014 (UTC)

Hear hear, this word "review/reviewed/reviewing" has too many meanings in Misplaced Pages, as also seen in a recent discussion on user right naming: Noyster (talk), 09:37, 3 September 2014 (UTC)
Support, this also makes it consistent with the autopatrolled right. BethNaught (talk) 10:05, 3 September 2014 (UTC)
  • I would certainly support getting the terminology right. As one user who has been extremely concerned about NPP for many years I have never referred to NPP as anything other than 'Patrolling'. As I never create pages as a new user, I was oblivious to the confusion that it causes among the newbies. Kudpung กุดผึ้ง (talk) 10:54, 4 September 2014 (UTC)
  • What do you think of "checked" rather than "patrolled"? WhatamIdoing (talk) 22:29, 4 September 2014 (UTC)
    • In harmony with the current usage and the thousands of times the term has been employed around the site and on templates, etc., I think there's nothing broken that needs fixing other than the OP's original suggestion. Besides which, 'checked' evokes a cursory glance while patrolling requires somewhat more action, and carried out by competent users. Kudpung กุดผึ้ง (talk) 05:49, 5 September 2014 (UTC)
      • "Patrolled" is wikijargon that won't mean anything to new users. It's not even grammatically sensible, since patrolling is the act of going from page to page, not the act of marking this one as being okay. "A passing user said that your page probably didn't qualify for immediate deletion" would be the most accurate, but that's very wordy. "Okayed", "accepted", or "checked" might make sense to a new person. "Checked" has the advantage of evoking the checklist, even though most NPPers don't follow it. Outside the mainspace, pages are often marked as patrolled after only a cursory glance, and not everyone believes that patrolling requires tag bombing, so that would be an accurate implication. WhatamIdoing (talk) 18:56, 8 September 2014 (UTC
WhatamIdoing, 'Patrolled' is the best term we have and as it isn't broken, why fix it? The proposal is to change any confusing terminology to 'patroll/ed' and not to find some other term. "checked" evokes "passed"/"authorised" just as much as "Okayed" or "accepted", which at NPP are most usually not the case - almost all new pages are in need of some attention of one kind or another whether they are rife for deletion of not. We must avoid any suggestions that NPP is a cursory glance - it s not, or it is cerataily not supposed to be. I realise that there are some NPP skeptics out here, but NPP is not only our only firewall against unwanted/unsuitable/inappropriate content, but it should also, if used correctly, encourage those whose articles just scrape through, to do better, while nevertheless, tag-bombing is totally counter productive. KudpungMobile (talk) 08:59, 9 September 2014 (UTC)
I disagree that it "is the best term we have", and I disagree that it "isn't broken". Patrolled is not understood by new users. It is, therefore, "broken". It is merely the most common term among people who are familiar with wikijargon, which is not the same as "best" or "not broken". WhatamIdoing (talk) 16:02, 9 September 2014 (UTC)
  • Support - Reviewed is a poor choice as it infers that there is some sort of feedback process involved. Patrolled, although not ideal is consistent with the terms, 'New page patroller' and 'Autopatrolled'.--Ykraps (talk) 12:46, 6 September 2014 (UTC)
Doesn't the notification say "your page was approved", which is an adequate description of the "this draft or main namespace article has been accepted for main namespace"? Gryllida (talk) 22:15, 11 September 2014 (UTC)
I'm confused what this has to do with the above - "your page was approved" is a fine description of a draft being accepted. The confusion comes from WP:NPP being referred to as a 'review'. Sam Walton (talk) 22:21, 11 September 2014 (UTC)
I don't use Echo, but I thought it says 'your page was approved' for NPP, as well... --Gryllida (talk) 23:09, 11 September 2014 (UTC)
Umm, no, it definitely says reviewed. I have just checked my notifications.--Ykraps (talk) 04:56, 12 September 2014 (UTC)

AfC resubmit

One thing I've noticed on AfC is that there are a lot of resubmits without any changes, or ones that are resubmitted in minutes. We have over 2,500 AfC's that need to be reviewed at the moment, and that takes a long time. Therefore, I'm proposing that declined AfC's cannot be resubmitted without any changes, and/or that AfCs must wait 1 week to be resubmitted. The week will give the authors time to revise the article thoroughly. Origamite 17:50, 28 September 2014 (UTC)

I'd be more willing to support something like this if you were able to guarantee that all declined AFCs were validly declined, and not, e.g., because the AFC reviewer disapproved of the formatting of the sources or some other equally trivial point. WhatamIdoing (talk) 23:29, 28 September 2014 (UTC)
Note that new editors (who AfC is aimed at) aren't likely to know whether a decline is valid, so that's not really something this should focus on IMO. Anyway, I support this, and it's doable from a technical perspective. Jackmcbarn (talk) 14:23, 2 October 2014 (UTC)

Should we transition the rename process to m:SRUC?

Please see Misplaced Pages:Bureaucrats' noticeboard#Should we transition the rename process to m:SRUC? and discuss. –xeno 18:42, 29 September 2014 (UTC)

It looks like Outernet needs a little help

I believe it would be a noble move if the Misplaced Pages foundation assisted the Outernet project with server capacity or what minimal funding is required to cover (apparent) bandwidth limits on their web site during the start up phase. They share synergistic goals.

https://en.wikipedia.org/Outernet

https://www.outernet.is/ Over Quota This application is temporarily over its serving quota. Please try again later.

Perhaps someone who knows how such things are arranged would be kind enough to forward this suggestion to the correct offices.

Idyllic press (talk) 06:34, 2 October 2014 (UTC)

Move pronunciations, other names and other language names from lead to a note or sidebox

Take this example. This is the lead of Hebron.

Hebron (Arabic: الخليل al-Khalīl; Hebrew: .mw-parser-output .script-hebrew,.mw-parser-output .script-Hebr{font-family:\"Ezra SIL SR\",\"Ezra SIL\",\"SBL Hebrew\",\"Taamey Frank CLM\",\"SBL BibLit\",\"Taamey Ashkenaz\",\"Frank Ruehl CLM\",\"Keter Aram Tsova\",\"Taamey David CLM\",\"Keter YG\",\"Shofar\",\"David CLM\",\"Hadasim CLM\",\"Simple CLM\",\"Nachlieli\",Cardo,Alef,\"Noto Serif Hebrew\",\"Noto Sans Hebrew\",\"David Libre\",David,\"Times New Roman\",Gisha,Arial,FreeSerif,FreeSans}<\/style><span class=\"script-hebrew\" style=\"font-size: 110%;\" lang=\"he\" dir=\"rtl\">\u05d7\u05b6\u05d1\u05b0\u05e8\u05d5\u05b9\u05df<\/span>&#8206;"},"data":{"ipa":"","text":"","lang":"en","wikibase":"","file":"He-Hebron.ogg"},"classes":}">חֶבְרוֹן‎, Standard Hebrew: Error: {{Transliteration}}: unrecognized transliteration standard: $1 (help), Tiberian: Ḥeḇrôn ISO 259-3: Ḥebron; Ottoman Turkish Halilürrahman, Ancient Greek Hebrṓn, Χεβρών) is a Palestinian city located in the southern West Bank, 30 km (19 mi) south of Jerusalem.

What an average reader will wish to see is:

Hebron is a Palestinian city located in the southern West Bank, 30 km (19 mi) south of Jerusalem.

The problem here is, the pronunciations and other language names simply clutters the beginning of lead terribly decreasing its readability. This is worse in some other articles where there are other names for the subject of the article, meanings of each one explained inline.

Why shouldn't we make it a policy that such items should be placed in a note or a side-box? --PrinceMathew (talk) 07:59, 2 October 2014 (UTC)

I quite agree overloading lead sentence with naming info is a bad habit on Misplaced Pages, and the Hebron example you cite is a particularly horrible example that needs to be changed. I'm not too certain though whether a sidebox is the best place for it (although I guess it could be optionally integrated in the infobox templates, as virtually all geographical articles do have infoboxes these days.) My own favorite solution, as long as it's just a simple list of two or three names in local languages, is an extra sentence at the end of the first lead paragraph ("The city is called "X" in A, "Y" in B and "Z" in C.) Anything more complex than thathe (such as multiple transcriptions or pronunciation guides for the same name, as here with Hebrew) should go into a separate "naming" section below. One of the things that makes the present state worse is the pedantic obsession with cramming all sorts of names in for purely political/historical reasons, such as giving a symbolic nod of recognition to all language communities that live in a place by listing all their name variants, or to all historical states that once governed it, as here by listing the – otherwise completely irrelevant – Ottoman name. As a rule, the slot at the beginning of the lead sentence should be reserved exclusively to names that are or have been used in English (including possibly the one current official name in the official local language, as that might also sometimes be used in English-language maps, atlases and so on.) Fut.Perf. ☼ 08:16, 2 October 2014 (UTC)
I've taken the freedom to remove the live "ref" tags from the examples above and replace them with fake ones, just so we don't have to carry a spurious references list around here on the talkpage. Fut.Perf. ☼ 08:19, 2 October 2014 (UTC)
Assuming that every place has "one current official name" or one "official local language" seems unwarranted. For example, it appears that part of Hebron is controlled by the State of Palestine (official language Arabic) while another part is controlled by Israel (which has two official languages, Hebrew and Arabic). For another example, Switzerland has four official languages: German, French, Italian, and Romansh. Anomie⚔ 11:28, 2 October 2014 (UTC)
The important point is that we should de-emphasize this whole idea of using the inclusion or non-inclusion of names as a symbolic sign of our recognition of the role of this or that state/ethnicity/historical period etc. We are not writing our articles in order to please this or that group of locals. We are writing them in order to serve the English-speaking reader, and the only reason names need to be included in that spot is because English-speaking readers might have been led to the article after seeing the place referred to by that name in an English-speaking environment. My reference to local official names was due to the fact that some otherwise English-speaking publications, such as atlases, may have a policy of using local names (such as München) even where English prose otherwise strongly prefers an anglicized name (e.g. Munich). That's the only reason "München" would have to be there. So, we should ask ourselves: would an English atlas that uses "München" and "Athīna" also include "Ḥevron" or "al-Khalīl", or maybe both? If yes, they go in; if not, they don't. For historical names, the question is similar: would history books in (present-day) English refer to the place by name XYZ (without immediately glossing it with the modern name)? If yes, the historical name goes in; if not, it doesn't. Everything else should be treated somewhere a bit further down, where it is less obtrusive (perhaps still in the intro, but not in the lead sentence). Fut.Perf. ☼ 11:50, 2 October 2014 (UTC)
We definitely need some way to make the ledes more visually appealing and readable. A side bar might be the best solution. But what other options are there? Mosue-over pop-ups, footnotes, a double lede? Kdammers (talk) 09:15, 2 October 2014 (UTC)
I support this - overloading the lede with alternate names and pronunciations hinders readability, and I agree that we're building an encyclopedia for English readers, thus only the most common English name(s) should be in the lede, just like how we choose article titles. Frankly, this is one of the increasingly few proposals that comes along that actually quite significantly increases the readability of pages, and that should be what we're going for. I think adding an "alternate names" or "local names" or some such section to the infobox would be an elegant solution. In fact, if you look at Hebron, there is already an "other transcriptions" section right at the top of the infobox. Why not there? Ivanvector (talk) 14:46, 2 October 2014 (UTC)

Yearly donations instead of monthly donations

I would like to subscribe to Misplaced Pages and to make yearly donations. I noticed that at https://wikimediafoundation.org/Ways_to_Give there is the "Monthly gift" option, but no "Yearly gift". For example if I decide to donate 30 euros / year, it's more convenient to pay each year a single payment of 30 euros (for example each 1st of January), instead of paying 2.5 euros every month. It's simply annoying to make such small payments every month. Is it possible to implement yearly payments with PayPal? —  Ark25  (talk) 14:08, 2 October 2014 (UTC)

Media Viewer RfC Question 1

Please consider joining the feedback request service.
An editor has requested comments from other editors for this discussion. This page has been added to the following lists: When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.

We have a previous RfC consensus that Media Viewer should be default off. That RfC was never implemented due to the Superprotect controversy and a WMF Community Consultation process on Media Viewer. That community consultation process has ended and the outcome can be viewed here. I think it is time to review that outcome and determine whether we still want Media Viewer to be disabled by default. Alsee (talk) 17:33, 3 October 2014 (UTC)

(Note: There is a second question further down the page.) Alsee (talk) 17:53, 5 October 2014 (UTC)

Question One. Should we reaffirm and implement the previous RfC: WP:Media_Viewer/June_2014_RfC#Consensus.2Fdisapproval_has_been_established There is a clear consensus that the Media Viewer should be disabled by default for both logged-in (section link) and non-logged-in users (section link).

SUPPORT

  1. SUPPORT as RfC author. The WMF's Community Consultation Process on Media Viewer resolved essentially none of the objections raised in the previous RfC. I believe our original image page is better than Media Viewer. Alsee (talk) 17:41, 3 October 2014 (UTC)
  2. Support Obviously nothing has changed, the default should still be off unless specified by editors (i.e. if an editor wants the mediaviewer used for galleries, etc). Not that it matters. I have zero confidence in the WMF's respect for consensus at this point. 0x0077BE 16:01, 5 October 2014 (UTC)
  3. Support as the attribution problem has still not been sufficiently addressed. This is a show stopper. --AFBorchert (talk) 16:13, 5 October 2014 (UTC) P.S. I think that is an inherently difficult problem, take File:Carentan Église Notre Dame Vitrail Baie 07 2014 08 24.jpg as example with a very complex copyright case which cannot be represented in any simplified manner.
  4. Support. Unless the consensus has changed, we should not allow the WMF to continue to avoid the issue of enablement, and at any rate we should not leave them with the impression of acquiescence. BethNaught (talk) 16:33, 5 October 2014 (UTC)
  5. Support - I still prefer the old one and probably always will, - At the end of the day the community decided it should be off, Period. –Davey2010 • (talk) 16:52, 5 October 2014 (UTC)
  6. Per AFBorchert.--Aschmidt (talk) 17:28, 5 October 2014 (UTC)

OPPOSE

  1. Not really clear why this RFC is required at the current time. Development work is still ongoing to make Media Viewer more acceptable to communities and respond to feedback. A better time for an RFC would be when a planned deployment is put on the table, and the version of Media Viewer that is proposed for deployment is available for evaluation. At the moment, there isn't really anything more to discuss beyond what was already said last time.
    On another note, I'm not sure that RFCs of this kind are helpful. They feel somewhat antagonistic to me, and seem to bring out a vocal minority of technical Luddites within this community who don't always understand the subtleties of the issue at hand. — This, that and the other (talk) 11:35, 5 October 2014 (UTC)
  2. Not with in the framework of WP:CONEXCEPT, section 1 and/or 4. I will add that any legal objection regarding attribution is incompetent, as coming from persons without verifiable credentials or responsibility. It is also absurd to make such claims, when practically every page on Misplaced Pages (eg. Main Page) has no visible origin information for images. Alanscottwalker (talk) 16:26, 5 October 2014 (UTC)
  3. This is the wrong time. According to the outcome of the consultation process, as referenced above, We plan to complete all “must have” improvements by the end of October and deploy them incrementally, starting this week (that was on 11 September 2014). The end of October will be the time to start a thorough discussion, which may go better if editors aren't weary from a long RFC now. NebY (talk) 17:53, 5 October 2014 (UTC)

Neutral

RESERVED FOR OFFICIAL COMMENTS BY WMF EMPLOYEES

(Please do not edit here if you are not WMF)

Discuss and comment

 In progress: Sending notifications to everyone who participated in previous discussions on the same topic. Alsee (talk) 15:49, 5 October 2014 (UTC)

Media Viewer RfC Question 2

The WMF made this statement when deactivating Superprotect:

Dear German Misplaced Pages community,

We’ve been talking a lot with many of you and at the WMF about the current situation regarding Media Viewer and site-wide JavaScript changes.

Restricting edits to MediaWiki:Common.js was a difficult decision for us. We regret that we missed opportunities to do our part in avoiding a conflict that no one wanted. At the same time, we cannot fulfill our responsibilities as the site operator when users take it upon themselves to disable functionality by editing site-wide JavaScript that is executed for all users.

We learned that the use of superprotection unintendedly created the impression that we don't trust the community. This is not the case, so we have therefore removed the restriction.

In doing so, we are investing our trust and goodwill in every community member that you will work together with us before making changes to site-wide JavaScript. And we are specifically asking you to not change site-wide JavaScript to deactivate Media Viewer or to make it opt-in.

Our commitment to you is to address open technical issues with Media Viewer based on a global community consultation process beginning tomorrow. The consultation page will address the scope, intent, and timelines of the consultation will be announced on all projects and will be open-ended. We will update here with the details when the page is live and will support German language participation.

We ask you to work with us in good faith in the upcoming month and through this effort define a better, closer way of working together in support of our common goals.

Sincerely, Lila & Erik

Question Two. In light of the statement above, should Question One carry the following implementation terms:

  • Place a 7 day hold against Community action to implement this RfC.
  • Officially deliver the closing results to the WMF.
  • Express our desire to work together with the WMF before making changes to site-wide JavaScript.
  • Express our desire to work with the WMF in good faith, and our hope for a better closer way of working together in support of our common goals.
  • Formally request the WMF to implement this configuration change for English Misplaced Pages.
  • 7 days after this RfC closes our JavaScript experts and other admins are directed to take any steps necessary to implement this RfC, if such steps are still needed.

NOTE: Question two shall have NO EFFECT if question one fails. You can oppose question one and still support question two, just in case question one passes.

SUPPORT

  1. SUPPORT as RfC author. I want to make every effort of develop a more collaborative relationship between the community and the WMF. Alsee (talk) 18:01, 3 October 2014 (UTC)
  2. Support. First we should try to work with them, FWIW. Then, when that will fail, fiat justitia ruat caelum. BethNaught (talk) 16:36, 5 October 2014 (UTC)
  3. Support. The seven days give WMF sufficient time to implement this. Features that are switched on by default and problematic in regard to copyright law (two clicks to access complete copyright information) lie within the domain of the community. How can we with good conscience use images at en:wp if, by default, this feature hides essential copyright info? This is a problem of the community as many of them work with their real names and have consequently a different perspective than the WMF who sits in the safe harbour. --AFBorchert (talk) 17:58, 5 October 2014 (UTC)

OPPOSE

Neutral

RESERVED FOR OFFICIAL COMMENTS BY WMF EMPLOYEES

(Please do not edit here if you are not WMF)

Discuss and comment

I'd support this if only the first 5 bullet points were present, but I can't support it given "7 days after this RfC closes our JavaScript experts and other admins are directed to take any steps necessary to implement this RfC, if such steps are still needed." Jackmcbarn (talk) 17:50, 5 October 2014 (UTC)

Conflict infobox

The Syrian Civil War infobox has been the subject of a long-running content dispute (see Talk:Syrian Civil War#Infobox very misleading). Just about everyone involved agrees that the proper way to present this complex conflict would be to have four distinct combatant "sides" in the infobox, rather than trying to split hairs over whether the nationalist Kurds (who are explicitly not allied with either the government or the rebels, having clashed with both throughout the conflict, but have cooperated with both groups in some areas) should go in the government or rebel column. Clearly we are past the point where the Islamic State, which has been in the news a lot lately, can credulously be presented in the same column as the rebels they are at war with, much less the Kurds they are also at war with. Just about all of the Syrian war graphics we have been using (maps and the like) show four sides. The limitations of infobox coding do not allow us to present the conflict appropriately, and because of that, I believe the content dispute will continue and readers will continue to get a confusing and inaccurate picture of what is going on unless and until we are able to build an infobox with four sides. -Kudzu1 (talk) 17:43, 5 October 2014 (UTC)

Yeah, just to explain this more generally, there is a technical limit that only allows three columns in the war infobox, and we basically want to enable a fourth one. Could be useful in other articles about complex wars as well. FunkMonk (talk) 17:57, 5 October 2014 (UTC)
Categories: