Misplaced Pages

:Village pump (proposals) - 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.

This is an old revision of this page, as edited by Maproom (talk | contribs) at 21:46, 5 October 2014 (→Support). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Revision as of 21:46, 5 October 2014 by Maproom (talk | contribs) (→Support)(diff) ← Previous revision | Latest revision (diff) | Newer revision → (diff)
 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)
Strong support. Lead sentence cruft is totally out of control. Let's go back to having readable articles. Kaldari (talk) 19:59, 5 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)
  7. Support, although this wasn't needed; community consensus has already been formed to disable it. Consensus-changing attempts are appropriate, but that would be the only reason for having such a discussion. Let me remind the closer that "no consensus" defaults to pre-discussion, which is unambiguously "off". Nyttend (talk) 19:29, 5 October 2014 (UTC)
  8. Support: The most frequent piece of feedback that WMF removed was "turn this to opt-in" and the WMF intentionally and purposefully ignored all such feedback . Since the consultation was a sham, I see no reason to wait for any results.—Kww(talk) 20:09, 5 October 2014 (UTC)
  9. Support. It seems to me to be common sense that WMF should care what the editing community says. --Tryptofish (talk) 20:15, 5 October 2014 (UTC)
  10. Support. It's inherently inferior to the existing file page, and the community spoke after due examination of the two. Yngvadottir (talk) 21:06, 5 October 2014 (UTC)
  11. Support. I don't know why we are having this discussion again. We already know that 1 a large majority of editors prefer the pre-existing system, and 2 WMF people ignore and misrepresent our views. Maproom (talk) 21:46, 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)
    I think this makes it clear there is no claim of WP:CONEXCEPT here. The WMF withdrew it's hasty and unconsidered application of Superprotect, and explicitly asked that we not disable Media Viewer. Alsee (talk) 21:10, 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)
  4. What TTO said. Also this really isn't an RfC, it's just a WP:VOTE. Legoktm (talk) 18:31, 5 October 2014 (UTC)
  5. Per NebY. If they're currently working the feedback they have from us into the software and will have that done soon, a random RfC now on the basis of old discussion and an old software version is pointless. Discussion about the tool's future status should happen when there's actually something new to discuss. A fluffernutter is a sandwich! (talk) 18:44, 5 October 2014 (UTC)
  6. It's long past time to deploy this improved file-page interface, especially for non-logged-in readers who likely don't care about the cruft that we editors do. Powers 19:21, 5 October 2014 (UTC)
  7. It looks like improvements are still being made and many of the problems of the initial version have already been fixed. Kaldari (talk) 19:54, 5 October 2014 (UTC)
  8. Per NebY. Wait until they get it fixed, and then if we still don't like it, turn it off. Jackmcbarn (talk) 20:20, 5 October 2014 (UTC)

Neutral

  1. I dislike Media Viewer and disabled it wherever it irritated me, but I see the point of those who say "Let's see the new improvements first." LynwoodF (talk) 18:42, 5 October 2014 (UTC)

Reserved for official comments by WMF employees

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

Discuss and comment

 Done: 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)
  4. Support. This seems a reasonable proposal. LynwoodF (talk) 18:47, 5 October 2014 (UTC)
  5. Support. I can't see why this would controversial at all. Powers 19:23, 5 October 2014 (UTC)
  6. Of course. We should try to work with them, but community consensus must be enforced as long as it's technically possible. Nyttend (talk) 19:31, 5 October 2014 (UTC)
  7. Support. I don't know about all the details, but I'm coming from a position that we, editors and WMF, are all in this together. --Tryptofish (talk) 20:17, 5 October 2014 (UTC)

OPPOSE

  1. Per my my oppose and policy (WP:CONEXCEPT section 1 and 4) above, and to repeat AFBorchet's argument (and similar) shows a misunderstanding or incompetence regarding law, and does not accord with current layout. Moreover, if you think the Foundation is doing something illegal, than the remedy is not an RfC or a WP:Vote, per WP:LAWSUIT. Alanscottwalker (talk) 18:43, 5 October 2014 (UTC)
  2. 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)
  3. The WMF is supposed to serve the projects, not the other way around. Their removing the super-protection is too little, too late, and they should not be setting conditions. Their forcing software changes on the projects that impair our ability to execute our mission here is indefensible and is yet another indication that they have forgotten what we are here for and what they are supposed to exist for. No negotiation. Throw this thing out. Yngvadottir (talk) 21:11, 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

  • Which "javascript experts" are we talking about here? The self-appointed ones? The ones who took a class once and totally know what they're doing? The ones who have admin rights, and thus must know what they're doing? The ones who heard about this piece of js from someone who totally knows what they're doing, so the code must be ok? The whole reason the js-editing debacle turned into such a disaster last time is because we don't have a designated team of "javascript experts" in the lay community; instead we have a team of admin-type people who have the technical ability to edit mediawiki pages but who may or may not have the slightest idea what they're doing. If a mediawiki dev(s) or other actually-provably-qualified-to-edit-mediawiki-code person is willing to write javascript that will a) enact the community's will and b) not be buggy, prone to breaking things it shouldn't, or otherwise degrade site performance, then yeah, let's talk about the cases where the enwp community will use that code, and how we're going to limit the ability to edit that code to that person or people. But unless you're going to limit this implementation to those qualified people only (perhaps through limiting editing of mediawiki space to those actually responsible for the mediawiki software? oh, wait...), we're just going to land back in a case where a well-meaning person throws in a hack, breaks things sitewide, and has to be reverted while everyone gets very angry and shouts rude words. A fluffernutter is a sandwich! (talk) 18:57, 5 October 2014 (UTC)
If I'm not mistaken there's significant precedent of community management of Javascript, and I trust we have competent people for the job. Nonetheless, this RFC already explicitly designed to address your concerns. You can OPPOSE question one and SUPPORT question two. Alsee (talk) 21:29, 5 October 2014 (UTC)

Conflict infobox - 4 sides needed

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 (since this proposed change will not only affect the article in question), 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)
I also think that we need make four distinct combatant "sides" in the infobox. And it would be a great solution to our problem. Hanibal911 (talk) 18:01, 5 October 2014 (UTC)
Fully support. I just edited the heading by adding "- 4 sides needed" to make the request easier to find. Legacypac (talk) 18:03, 5 October 2014 (UTC)

I argee,we need a infobox for 4 sides.Alhanuty (talk) 18:04, 5 October 2014 (UTC)

I'll rework Template:Infobox military conflict to support this. When I'm done, I'll let you know so that you can fix Template:Syrian Civil War infobox to use it. Jackmcbarn (talk) 18:13, 5 October 2014 (UTC)
Thank you very much, Jackmcbarn! -Kudzu1 (talk) 18:24, 5 October 2014 (UTC)
  • I think the better solution is just to not have any "combatant" section at all. It is quite clear that situation in Syria is too complex to be adequately summarised in the infobox. Remember, the purpose of an infobox, as laid out by the guidelines on this matter, is to summarise key points, not to become an endless mire of information. The infobox is not a substitute for prose. Adding a fourth column will only create a giant mess that will be hard to read, and will infringe upon the page's layout. Given that this situation is so complex, and given that an infobox simply cannot do it justice, the best thing to do is to let the prose stand. Eliminate the combatants section. RGloucester — ☎ 18:15, 5 October 2014 (UTC)
Most people won't read the article, so the infobox gives a quick overview. In any case, we can discuss this further at a later point, right now it couldn't hurt just to make the fourth column possible. FunkMonk (talk) 18:20, 5 October 2014 (UTC)
There is nothing "quick" or "overviewish" about the present infobox, or about the idea of adding a fourth column. It flies in the face of the guidelines on infoboxes and their innate purpose. RGloucester — ☎ 19:22, 5 October 2014 (UTC)

Oh, the combatants infobox really helps get a grasp of the situation quickly.

  • A | B | C | D or
  • A | B

line here (hard to show this!)

  • C | D

in the interest of not eating up too much width. Legacypac (talk) 18:18, 5 October 2014 (UTC)

Support creating a 4th side to a conflict. Although strictly speaking, the disputed Kurdish faction is in fact formally opposed to the Assad regime faction ("Syrian Kurds may have added appeal for the back channels they provide. Despite claiming to be opposed to Mr Assad’s regime, there are reports that they may be co-ordinating with his forces in the fight against Isis."), as well as only forming official alligences with the Syrian opposition factions since the conflict began, this is a complicated situation that could change. Nulla Taciti (talk) 18:20, 5 October 2014 (UTC)
  • I would agree with this in concept, but the consequences could turn out to be a bit unpleasant (visually, I mean), especially with the amount of references we have. Right now I've temporarily dealt with the Kurds' issue (see ) and bordered them so that the dividers in the first 2 columns don't go up and down. I believe this solves the problem for now. Thoughts? Fitzcarmalan (talk) 18:23, 5 October 2014 (UTC)
It is an innovative solution, but can the Kurdish "Commanders and leaders" section and the Kurdish "Strength" section also be bordered in an identical manner to the Kurds in the "Belligerents" section, to avoid confusion? Nulla Taciti (talk) 18:35, 5 October 2014 (UTC)
I agree that a fourth column might be the solution. Hopefully it won't look too crammed... But that's just the nature of this conflict. Jushyosaha604 (talk) 18:44, 5 October 2014 (UTC)
I like Fitzcarmalan's layout (similar to an earlier one by Kudzu). Clearly shows Kurds have been fighting, depending on the situation and location, beside both the Assad forces and the opposition against ISIS (contrary to an earlier statement that the YPG has been fighting alongside the rebels only). But I would also support a fourth column for the Kurds (if it wouldn't be too cramped). EkoGraf (talk) 20:01, 5 October 2014 (UTC)
Categories: