Wikipedia:Petition to the WMF on handling of interface changes

The handling of interface changes is an issue that comes up again and again. Fundamentally, there is, at times, a lack of sufficient communication, and a failure to try hard enough to leverage the collective knowledge of active Wikipedians. This applies most obviously to things which do get implemented (like WP:Notifications), but also to things which don't (like cross-wiki watchlists) or to fix the typical 2-reply edit-conflicts which have been a problem for over 10 years.

This petition is not seeking the right for the community to block everything they don't like. This petition asks the WMF to try to improve communication between editors and those who design, develop and implement changes to the interface of the English Wikipedia. This needs to happen irrespective of whether the changes are by WMF employees or contractors, volunteer developers, established Wikipedians or some combination of these. There needs to be more exposure of what thinking has gone into different decisions, and (if applicable) what sort of evidence base is being used. Part of the problem is the wider editing community not having input into the process; some of it is the community simply not knowing why things are being done, which contributes to a feeling that a change is arbitrary. Some suggestions and examples of good and bad practice are included below.

Petition signatures

Rd232 ^talk 15:58, 9 May 2013 (UTC)[reply]
I didn't have any problem with the recent changes, but this is an eminently reasonable request, entirely compatible with the collaborative spirit of Wikipedia. As the petition says, it's not necessary that everyone vote on every new proposal, but WP:ASTONISH can apply to the backend as well. --BDD (talk) 17:54, 11 May 2013 (UTC)[reply]
Interface changes shouldn't be implemented without the community's being prepared for it first. AutomaticStrikeout ! C Sign AAPT 20:06, 11 May 2013 (UTC)[reply]
I'm not sure why people aren't notified in advance. Red Slash 18:24, 12 May 2013 (UTC)[reply]
I did not like many of the new changes but I also am glad the WMF is finally stepping up since we have shown we can't make any decisions. With that said, this is a much needed change to the way changes are deployed. Kumioko (talk) 20:47, 12 May 2013 (UTC)[reply]
I have no issue with the recent changes, but the community should at the very least know what changes are proposed so they can have an input into the discussions, and then they need to be notified that changes are planned so that they do not come as a surprise. Thryduulf (talk) 13:42, 13 May 2013 (UTC)[reply]
Agree We often tell (specially new users and our friends who don't edit Wikipedia) about our consensus procedure. how/why we depend on discussion-consnsus and not pole! Wikipedia should not be like other internet corporate giants where you have not other option than accepting the changes. In case you use Gmail, most probably you also disliked their new compose, but, you had no option there. Wikipedia should not follow this trend. The procure should be Inform → Discuss → Implement and not Implement → Inform. Wikipedia generally follows it, but the petition itself shows there are few editors who are fully satisfied at this moment! (in addition see my suggestion below) --Tito Dutta (contact) 22:55, 13 May 2013 (UTC)[reply]
Unfortunately, there is a lack of communication between the developers and the community that needs to be addressed. — Preceding unsigned comment added by Tazerdadog (talk • contribs)
Distant second choice, the first being the dismissal of WMF employees that repeatedly fail or completely disregard the need for community input. This has happened far too often, and even the Foundation have known there has been a problem for at least a year (I seem to remember a board report or something which identifies this issue, but cannot find it at the moment). MER-C 07:42, 16 May 2013 (UTC)[reply]
Ich hoffe, dass auch Diskussionen und Änderungsvorschläge in anderen Sprachen als Englisch stattfinden können und notwendige Übersetzungen stattfinden. – I hope to find proposes to changes also in other languages than English and that there can take place discussions where persons don’t absolutely have to take part in English. And I’m very astonished that I don’t have a notification bar anymore, so that other users may be astonished that I don’t see new messages anymore now (or not at the time they are posted, when I’m here and contributing at that time, but at any other time when I look at the little blue number on top – not red!). Please give me the bar back, I don’t like it without notification bar! --Geit ost 15:50, 16 May 2013 (UTC)[reply]
PS: And please, don’t set this feature in other Wikis as it is now and as long as this isn’t compatible with de:Wikipedia:BIENE/Technische Einschränkungen and Unobtrusive JavaScript, otherwise there will be more problems with that also there (and not just here). Please check every of these new features with this page and let it translate into English. --Geit ost 21:08, 18 May 2013 (UTC)[reply]

Next change back to where we were before: Wikipedia:Village pump (technical)#Bolding on watchlist has gone away, please give it back :-( --Geit ost 22:18, 13 June 2013 (UTC)[reply]
The communication between the Foundation and the projects ist disasterours. Even, as I can see here, the communication with en.WP doesn't fit, and other languages are obviously out of range and out of scope. That's very bad. -jkb- (talk) 16:08, 16 May 2013 (UTC)[reply]
Somewhere at WMF people are working hard on improving Wikipedia for new editors — a noble task! However during the last months I got the impression they're missing an important step: Checking back with the established community how these improvements could interfere with every days work and how this could be avoided. --Patrick87 (talk) 16:19, 16 May 2013 (UTC)[reply]
+1. This is the crux of the communication problems and community backlash. Diego (talk) 12:12, 18 July 2013 (UTC)[reply]
there should be a possibility for people who do not have english as their first language to understand the project pages. If the community should help to make a project better, the relevant information has to be more understandable. --IW 17:25, 16 May 2013 (UTC)[reply]
Heimstern Läufer (talk) 01:21, 17 May 2013 (UTC)[reply]
There were plenty of great improvements in this area during the past year; please continue: It's good that after new software rollouts, your bug wrangler looks for issues at the local discussion forums. Bugzilla is not really suitable for potential users of VisualEditor and volunteers perhaps don't want to spend their spare time with debugging and writing bug reports; Interaction with the community has been improved: We got notifications about new features, we were asked for feedback; that's great! If more efforts would be put into involving people unable to contribute in English and asking the community about what is most wanted before developing something like moodbar (or was this just an expensive April fool?), I would be happy. I am also signing for Commons. Thank you. -- Rillke (talk) 22:13, 18 May 2013 (UTC)[reply]
~~Ebe 123~~ → report 11:13, 19 May 2013 (UTC)[reply]
Ramaksoud2000 ^{(Talk to me)} 03:31, 20 May 2013 (UTC)[reply]
Jclemens (talk) 03:45, 23 May 2013 (UTC)[reply]
Almost every user-interface change caused some browsers to lockup, crawl, or garble the screen, for a day or for months. Overall net disaster. -Wikid77 15:05, 26 May 2013 (UTC)[reply]
I am still plagued with a known bug with 'my notifications' that I do not suppose will ever get resolved. I was perfectly fine with the old notification or none, actually. I am not a baby and some of these tinker toys seem to be developed for use in the playpen. I had no opportunity to experience this modification prior to having it forced upon me (ie Facebook tactics...) Fylbecatulous talk 14:49, 30 May 2013 (UTC)[reply]
Often I found out about these two days before implementation, with no oppurtunity to bug-test or anything. Things are getting more confusing, although probably overall a net positive to new users who have no experience with the old system.--Gilderien Chat|List of good deeds 15:55, 31 May 2013 (UTC)[reply]
The new notification system that was deployed with little to no regular user's input and little and/or limited testing, as could be seen by the bugs that were introduced with it, was just the latest and "most notable" screw-up. There is some other new problem that is discussed right now here at the technical village pump. As I stated over there: "I too wouldn't call for "firing of WMF personnel", although when (programming) geniuses are blowing up the barn, they need some serious supervision." I fully endorse this petition and hope something good comes out of it in regards to future software changes.TMCk (talk) 00:05, 1 June 2013 (UTC)[reply]
I'm confused. You think programmers have broken something because servers are slow? We've got tens of thousands of editors; do you not think that, were the problem at the WMF end, anyone but you might have noticed? There are legitimate issues with WMF-community communication. "There's a bug and I'm on a speedy internet connection so: blame developers!" is not. Ironholds (talk) 04:07, 1 June 2013 (UTC)[reply]
If all you can do is taking my post here and apparently from the linked page out of context for you own excuse you're part of the problem described in this petition. Solve the newly persisting problem or if you can't, please be quiet and don't post BS.TMCk (talk) 05:36, 1 June 2013 (UTC)[reply]
TMCk, I'm posting as a volunteer - but it's clear that you're not interested in an actual conversation on the subject. If you change your mind, I'll be on my talkpage as both a volunteer and a staffer and happily to discuss things with you. Ironholds (talk) 12:44, 1 June 2013 (UTC)[reply]
I've responded her at the village pump where this started.TMCk (talk) 22:31, 1 June 2013 (UTC)[reply]
I didn't have any problems, but find this request to be reasonable. We're volunteer editors and that must count for something in the 'heads-up' notice department. Malke 2010 (talk) 05:28, 1 June 2013 (UTC)[reply]
I have had some problem with the recent changes. I lost the "orange bar" functionality completely while I was working on DNS issues (now resolved), and it wasn't completely restored when I got it fixed. (I'll post on VP with appropriate detailed suggestions.) — Arthur Rubin (talk) 20:39, 1 June 2013 (UTC)[reply]
Communication between the community and the developers has been a one-way street recently, which is a recipe for disaster. WikiPuppies _bark ^dig 17:07, 2 June 2013 (UTC)[reply]
I'm was quite shocked at the recent sudden (and seemingly unannounced) changes to the UI and roll-out of new functionality. There's not enough communication. Greater access for the community to re-design discussion is needed. --RA (talk) 17:18, 2 June 2013 (UTC)[reply]
Readers and editors should be made aware of the proposed changes in an easily discovered location (like with a banner message for big changes, or at least in Village Pump for smaller ones); discussion in some wiki-backwoods not meant for a large audience is inappropriate. The wording that strikes most wise to me about this proposal is "leverage the collective knowledge of active Wikipedians". For what it's worth, I think the WMF ought to concentrate less on new features anyhow and more on the backlog of Mediawiki bugs and documenting and improving existing WMF-produced code. Jason Quinn (talk) 16:16, 3 June 2013 (UTC)[reply]
Seems reasonable. I don't think the community should get to veto things, but it should be listened to before changes are started and certainly should be warned before they are implemented. Hobit (talk) 01:59, 8 June 2013 (UTC)[reply]
Absolutely - unless there's a very strong reason for implementing a change (such as it being too confusing for newcomers), the community should have a right to veto it if a high percentage oppose it. עוד מישהו Od Mishehu 08:52, 12 June 2013 (UTC)[reply]
I sometimes get the impression that the WMF coders behave like school lunch cooks: "We have made cabbage stew, we DGAF that you want pizza, you will eat the cabbage or go hungry." The WMF needs to adjust their attitude towards volunteer Wikipedians, we are your primary customers - we don't work for the WMF, the WMF works for us. If enough of us become unhappy enough the WMF will simply go belly-up. Roger (Dodger67) (talk) 09:34, 14 June 2013 (UTC)[reply]
Tiyang (talk) 06:30, 19 June 2013 (UTC) I edited the petition. Grammar and punctuation. Respectfully,[reply]
North8000 (talk) 14:08, 20 June 2013 (UTC)[reply]
Communication is a good thing, and we're all in this together. --Tryptofish (talk) 14:11, 22 June 2013 (UTC)[reply]
At Wikipedia talk:Flow/Archive 1#"Board" versus "Talk", you can see an example of what happens when communication does not work as well as it should. --Tryptofish (talk) 00:20, 2 July 2013 (UTC)[reply]
And at Wikipedia talk:Flow/Archive 2#A note: board versus talk versus flow versus Cygnus X-1, a corresponding example of how to do it right! --Tryptofish (talk) 21:36, 10 July 2013 (UTC)[reply]
As I mentioned in a recent essay to Sj over at Meta, feature development needs to be less top-down and based upon more upon what editors' want. — Preceding unsigned comment added by ImperfectlyInformed (talk • contribs) 16:46, June 22, 2013‎
EngineerFromVega ^★ 17:43, 6 July 2013 (UTC)[reply]
Insulam Simia (^talk/_contribs) 18:25, 6 July 2013 (UTC)[reply]
Absolutely. Contrary to popular belief, Wikipedia is a democracy. The community runs this site, not the developers. Kurtis ^(talk) 18:36, 6 July 2013 (UTC)[reply]
While we're on the subject, would any of the developers mind looking at my proposal from two months back? It received unanimous support from the community, and the feature in question has long since been implemented on other Wikimedia projects. Why not here? Kurtis ^(talk) 18:49, 6 July 2013 (UTC)[reply]
Timeshifter (talk) 03:36, 7 July 2013 (UTC). Much needed.[reply]
I support improving communication between editors, designers, and developers regarding interface changes. As someone who is both a developer and a longtime community member I can see problems on both sides. For example, I think the Foundation is too reliant on off-wiki communication methods - listservs, IRC, Bugzilla, in-person meetings, etc. On the flip side, I think the community could have more influence on interface changes if they weren't so reluctant to participate in off-wiki discussions. Kaldari (talk) 08:58, 7 July 2013 (UTC)[reply]
Are we supposed to somehow smell that off-wiki communication is happening? IMHO off-wiki communication should be banned. If there is no record available on-wiki then as far as we are concerned it never happened. The minutes/notes of all relevant in-person meetings must be posted on wiki. Roger (Dodger67) (talk) 08:49, 10 July 2013 (UTC)[reply]
You think that staffers in the office should either (a) minute, and post these minutes, or (b) never have meetings? (Re IRC meetings, these are logged and posted transparently on meta). Okeyes (WMF) (talk) 13:09, 10 July 2013 (UTC)[reply]
Anything that is not on en.wikipedia is difficult to track and requires actively looking for it. I wouldn't know how to find such a logged meeting on meta except if another wikipedian linked to it from a talk page; and most editors will only follow talks which are accessible as changes at their watched project pages. Frankly, keeping track of everything that is going on at Wikipedia: space through the watchlist is difficult enough, to require users to keep looking for whatever arises at other sites, and then figuring out whether information found there is obsolete or have no watchers (a frequent experience at meta). I for one suggest below (comment #46) that WMF assigns a delegate that keeps track of up-to-date conversations and serves as an intermediary. Diego (talk) 11:35, 18 July 2013 (UTC)[reply]
After the flawed forced deployment of the buggy visualeditor it is clear that the WMF needs to be reminded that they need to listen to us regarding issues that involve such major changes to the look and feel of the encyclopedia. Even apple take the time to actually listen to their testers and delay releases as needed so there is really no excuse for the WMF to not do the same! PantherLeapord (talk) 23:56, 7 July 2013 (UTC)[reply]
Support, but does not go far enough. Yngvadottir (talk) 15:22, 8 July 2013 (UTC)[reply]
Absolutely, read my user page for my thoughts on the matter..♦ Dr. ☠ Blofeld 14:07, 9 July 2013 (UTC)[reply]
Quite a jarring change. A site notice isn't that much to ask for a major rollout. The fact that the next batch of technical changes (this time, with SUL) switching to one login page without actual notification is surprising, to say the least. Yes, it was announced on wikitech-l and posted on WP:VPT, but there's quite a number of users that don't pay attention to the mailing list or the Village Pump. I truly believe the foundation could have handled the rollout of these changes better, and I hope it's a lesson learned for Visual Editor's inevitable rollout for anonymous users. Signalizing (talk) 03:46, 12 July 2013 (UTC)[reply]
Support, as a first step. Titoxd^{(?!? - cool stuff)} 04:09, 13 July 2013 (UTC)[reply]
Support Changes should require at least a RfC. Doc James (talk · contribs · email) (if I write on your page reply on mine) 09:38, 14 July 2013 (UTC)[reply]
Thumbs up. Even when the Foundation makes significant efforts to understand the problem at hand, as is the case of new editor's experiences, their analysis only identifies a subset of the problem. Therefore, the solutions they come up with will only support a small part of all the ways the wiki platform is being used by the community. For interfaces like the Special:NewPagesFeed, which are optional and targeted to a specific group of editors, this is not a problem. But for tools like VisualEditor and WP:Flow that are meant to be the new gold standards for using Wikipedia, changes shouldn't be made with a thorough understanding of how it will affect the community. Diego (talk) 11:21, 18 July 2013 (UTC)[reply]
I'll add a request that, for all major interface changes, a Community ambassador is assigned to the project to serve a public relations role between the community and development team, explaining the team's vision and motivation and channeling the most constructive feedback from the community back to the team. Developers have demonstrated their good will to assume this task, but frankly they usually don't show aptitudes for that role nor should it be a requirement of their job. Diego (talk) 11:28, 18 July 2013 (UTC)[reply]
The trouble is that their job becomes the "phone firewall" version of customer service, as we're seeing with VE: they can't in fact do anything about the problems, but they're very sorry about them, repeat - David Gerard (talk) 12:58, 18 July 2013 (UTC)[reply]
Stifle (talk) 15:07, 20 July 2013 (UTC)[reply]
84user (talk) 23:27, 20 July 2013 (UTC)[reply]
---<)kmk(>--- (talk) 00:44, 22 July 2013 (UTC) We, the editors, are the ones who make Wikipedia the best encyclopedia ever. We know collectively better than anyone else what we need to do this job most efficiently. Not listening to us is a disservice to the projects goals.[reply]
Bigger changes in the user interface like VE or Flow should require a discussion or RFC before activation. And there should be a possibility for editors to use a simplified interface without active JavaScript - because of limited bandwidth, older machines/software, security reasons, ...--wdwd (talk) 13:31, 22 July 2013 (UTC)[reply]
--BuschBohne (talk) 14:24, 22 July 2013 (UTC)[reply]
Amazing that the group that keeps the largest community-built website does so poor a job communicating with its community.--llywrch (talk) 22:51, 23 July 2013 (UTC)[reply]
Even if interface changes make an impact on the retention of new editors, it seems likely to me that the creation and maintenance of Wikipedia's content will always follow the 80/20 rule. So why do developers seem determined to ignore the preferences, feedback, and advice of the core editors? --Cryptic C62 · Talk 01:59, 24 July 2013 (UTC)[reply]
Yeah, anything that results in a rollout of stuff like the amazingly broken Visual Editor could merit a bit of additional consideration. Sandstein 20:11, 24 July 2013 (UTC)[reply]
--AFBorchert (talk) 09:55, 29 July 2013 (UTC) Every major change of the user interface should be done with the consultation of the community using RFCs. The current style of communication appears to be chaotic at best (see, for example, the conflicting responses to the important question whether we are allowed to continue to edit traditional wikitext after the full deployment of the VisualEditor and Flow).[reply]
The WMF needs to put the community's well-being and opinions much higher up their list of priorities. The WMF's recent communication with the community regarding the Visual Editor has been dismissive and condescending, and -- as far as I can see -- focused entirely on communicating the WMF's policy decisions to the community, without any sign of paying attention to the community's clear and repeated messages that the VE is not working properly in its present state, and that the current policies are making things worse, not better. dewiki: has also just said this loudly and clearly, with exactly the same set of reasoned complaints and constructive suggestions as found here on enwiki: it will be interesting to see what, if any, response the WMF makes to dewiki regarding it. -- The Anome (talk) 12:02, 29 July 2013 (UTC)[reply]
de-wp has been configured back to the opt-in model and this will stay this way for an indefinite period. --AFBorchert (talk) 17:16, 29 July 2013 (UTC)[reply]
CtP (t • c) 19:35, 29 July 2013 (UTC)[reply]
Why is this even a question? StringTheory11 (t • c) 23:04, 29 July 2013 (UTC)[reply]
VE is RUBBISH! As per Kurtis, if Wikipedia is not a democracy, why is consensus of primary concern to policy? Was there any consensus as to whether agile programming was considered to be desirable? Has there been any evidence that VE has assisted in drawing in new contributors who have demonstrated themselves to be potentially valuable? Has anyone had to clean up after botched markup was left behind due to one-off 'contributions' which were of no value?: I know I have. Were any special units assigned to various helpdesks in order to address VE-specific problems? A good visual editor may add value to Wikipedia, but that begs the question of whether VE has been anything other than a disruptive, aesthetically detrimental nightmare. The articles look like crap screaming for anyone who's ever had an opinion about anything to contribute. I've actually surprised myself at how quickly I've gone from disliking VE to utterly loathing it. Oh, and to the WMF, don't patronise me by giving me the option of turning it off if I don't like it: I want to see how Wikipedia looks to anyone coming in. Sadly, pretending it doesn't exist isn't going to make it go away. --Iryna Harpy (talk) 01:08, 29 August 2013 (UTC)[reply]
This kind of over-the-top tone isn't helping your case. It's hardly "patronising" to give people a choice about editing Wikipedia in a way that's suitable for them, and what's suitable for new users is going to be different from what satisfies long-time users. "The articles look like crap screaming for anyone who's ever had an opinion about anything to contribute." - what does this criticism even mean? What change could be made to give a WYSIWYG editor and yet answer this criticism? MartinPoulter (talk) 20:50, 29 August 2013 (UTC)[reply]
I'm not certain as to what you're trying to achieve by making a personal attack on me, Martin. You seem to have plucked out a couple of points with which you've taken issue and presented them as being the brunt of my comment. In fact, if you care to read my comment properly, you may note that the brunt of my comment surrounds questioning agile programming as a valid method of introducing a WYSIWYG editor. In fact, I've also questioned the concept of a WYSIWYG editor being a useful or desirable method of enticing quality contributors (quantity is something I haven't noticed a shortage of). Much as I'd like to discuss this at length with you, I'm in the midst of trying to sort out an article which has been blanked and vast tracts overwritten with badly translated, biased material sourced from one of the LOTE (Languages Other Than English) wikis by a new contributor using VE: approximately 6 or 7 lengthy entries which can't be 'undone'. Interestingly, this new 'contributor' has vandalized (and I don't use the term loosely) and blanked other pages over the last couple of days using VE. Sadly, this is not the first encounter I've had with VE edits on highly controversial pages. I think that might count towards answering your question, "what does this criticism even mean?" (Sic). One might be tempted to ask who VE is enabling/empowering and who is being disempowered by its deployment. --Iryna Harpy (talk) 00:37, 30 August 2013 (UTC)[reply]
It appears I am a bit late to this party but I must agree with the intent. This petition needs a bit more exposure, I'd say. Jus da fax 02:36, 16 December 2013 (UTC)[reply]
The WMF and the community need each other, but instead of both groups utilizing each other's respective strengths to foster an atmosphere of cooperative amity and mutual respect, they are continually butting heads. To a large extent, this is attributable to (1) the Foundation's unwillingness to consult the community before making major decisions that affect the editing environment and (2) its seeming inability to communicate promptly and clearly before taking certain actions based on those decisions. The problem has been a perennial one, and while there are certain steps that the vast and unwieldy community can take to make things better (this petition being one), the onus is on the Foundation to work actively to solve it; they have the resources and the organization to do so, or at least they should. Rivertorch (talk) 22:44, 31 January 2014 (UTC)[reply]
— ΛΧΣ²¹ ^{Call me Hahc21} 01:40, 1 February 2014 (UTC)[reply]
KonveyorBelt 22:25, 1 February 2014 (UTC)[reply]
- Mr X 16:56, 27 April 2014 (UTC)[reply]
SUPPORT - user talk:Carriearchdale - Long standing never trumps change, and a better equality and a movement toward total neutrality on our beloved Wikipedia could make Wikipedia more encyclopedic. Also, I agree with WikiPuppies who said earlier up responses, "Communication between the community and the developers has been a one-way street recently, which is a recipe for disaster."
The bolding of watchlists, the Visual Editor, and recently the thing whatever it's called on Commons — you know, the thing that makes the useful information that I normally want from an image page (including its name) impossible to see? — those caught me by surprise and were soo difficult and timewasting to change for my own needs. Yes, for you guys, developers, I'm sure changing it to how you want it would be intuitive and not difficult, but you're programmers, you know, you're computer geeks, while I'm just an idiot. One way the communication needs to be better is to tell ~~people~~ the idiots, in a visible way, how to opt out of these things. Usually it turns out to be via something unlikely in my prefs, or for god's sake a little script that some helpful user creates on the fly, and that I need to find out about… and then, after us idiots have registered their frustration, imported the little scripts etc — then it finally becomes opt-in. Importing a script is no small thing for an idiot! Support! Bishonen | talk 17:14, 12 June 2014 (UTC).[reply]
The recent launch of the "MediaViewer", in all its unhelpful glory, leads me to join this list. RomanSpa (talk) 06:54, 24 June 2014 (UTC)[reply]
You'd think after the Visual Editor & Flow car crash they'd ask the wider community first, Yet again MediaViewer gets enabled for everyone and yet again the community hate it ...., I appreciate there's going to be changes all the time but It seems the WMF time and time and time again don't listen to anyone!, We just like things the way they are, And any major changes should be discussed thoroughly with the wider community before implementation. –Davey2010 • (talk) 07:21, 24 June 2014 (UTC)[reply]
For the following reasons: (1) Notifications (which I ignore thanks to Writ Keeper's script) (2) VE (which I don't use, and can't anyway on IE) (3) MediaViewer (which I disabled) (4) To be determined (given past occurrences, I would be totally unsurprised if this happened again). Waiting to see how Flow becomes... Double sharp (talk) 05:58, 13 July 2014 (UTC)[reply]
After the disaster that is Media Viewer, I have no choice but to add my name to this petition. Both the Visual Editor and the Media Viewer do nothing but make contribution harder. They do not add anything but headaches. There needs to be a dialogue between editors and those who design software, so that the software that is designed makes sense from an editing standpoint. At present, this is clearly not happening. I'm very afraid now that I've learned about the abomination that is Flow. More and more, it seems that the powers that be would like to move Wikipedia into a frilly "trendy" mess. The simplistic style of Wikipedia is part of what makes it great. We don't need frills, and we don't need commercialisation. RGloucester — ☎ 20:13, 16 July 2014 (UTC)[reply]
Products which are not yet polished should remain in beta until the majority of the large bugs are fixed, and the set of 'large bugs' needs to be agreed upon by community and WMF. Also WMF and community should be able to agree upon phased rollout, or a 'we've released a new version of beta feature XYZ fixing issues A.B & C - click [here] to enable this beta feature' banner. We need to find a solution, as leaving it in the hands of WMF product managers is not working, and does not appear to be likely to ever work with their current management team. John Vandenberg ^(chat) 08:03, 17 July 2014 (UTC)[reply]
What about the Article Feedback Tool? That was a big success, wasn't it? EEng (talk) 03:34, 18 July 2014 (UTC)[reply]
The WMF rolls out too many unwanted changes. I will be very displeased if flow is rolled out without discussion (especially if there is no opt-out). --Jakob (talk) 22:13, 20 July 2014 (UTC)[reply]
Imagine if article Talk pages worked just as well as Article Feedback Tool? Wouldn't that be wonderful? Seriously, though... I've seen flow in use on other projects and it's AWFUL. Now, let's say 70% of that is the natural human dislike of something new and familiar. OK. But the sad part is, Flow is so horrible that even the 30% of dislike that's rational is still way too much. EEng (talk) 00:39, 21 July 2014 (UTC)[reply]
The way most of the major software implementations have been done as of late is unacceptable on the WMF's side. Something needs to change. —Jeremy v^_^v ^Bori! 06:18, 6 September 2014 (UTC)[reply]
I think the WMF would get a lot more support if they tried posting RfCs on this stuff. If the RfC supports something, and someone gets upset, the WMF can point to the RfC and people will respect that. That would eliminate a LOT of complaints and hostilities. If the RfC doesn't support something, then get good feedback on what our concerns are with it. Note: They can't simply look over RfC comments for a list of stuff to change and presume it will be accepted, they'd need a second RfC asking if we want it with changes X Y and Z. And I'm not assuming English dominance - I think it's a good idea for them to RfC on (at least) the largish communities. Alsee (talk) 06:09, 7 September 2014 (UTC)[reply]
Agree with almost all of the above. Why is WMF above the consensus process? The fact that they are paid should make them more answerable to the majority, not less. Maproom (talk) 22:05, 8 October 2014 (UTC)[reply]
Agree and support. Bishonen uses the term "idiots". I've always thought of us as "ed-iots" ie "idiots that edit". Where I work is undergoing $5 million dollars worth of renovations. Did they ask the final "users" of those renovations for input and ideas before they started? No, they did not. There should always be a dialogue between user and architect. Buster Seven Talk 14:18, 22 December 2015 (UTC)[reply]
-Throast (talk) 21:44, 27 December 2016 (UTC)[reply]
Pre-design feedback, immediate prototyping for TrustedTesters groups (see comment below) on all major wikis to kick the tires, invariantly focus on iterative improvement never on stair-step mind-wrenching changes, do NOT roll out projects that are fundamentally buggy just to meet arbitrary schedule-targets, if you SCREW UP and do roll such a thing out then LISTEN WHEN GOOD FAITH EDITORS ARE TELLING YOU that such is the case, concentrate on software quality assurance and process buy-in as the main priorities, perform fairly rigorous A/B tests (of *each* iterative small improvement) with a broad spectrum of randomly-selected-via-usertalk-massmessage existing editors AND ALSO with quasi-randomly-selected-via-glam-or-similar beginners age 8 to 80 that have never edited wikipedia seriously, and then take those focus-group tests just as seriously as you take the pre-design mandates. Which Means Do Not Deploy Something Without First Getting Measureable And Measured Buy In From Real Editors AND Also From Real Beginners. Full stop, bye-bye, see you later, no cutting corners and no WMF fiat overriding the outcome of the buy-in process. Once you get a buy-in process that satisfies the vast majority of participants, then you will start to see serious benefits: good ideas float to the top, and get implemented, and are tested properly, and delight the community of editors, and enlarge it at an ever-increasing pace as more and more folks learn that editing wikipedia can be fun. As opposed to, a constant nightmare combo of 1990s technology combined with rules-oriented bureaucracy ruled with an iron fist from afar by the devs who are insufficiently enmeshed in the process of sociologically advancing and selling tech-upgrade-proposals. And I say this as somebody with the background, who understands very well that endusers will *always* resist change and they will *always* demand the impossible, but the 'solution' is not to wall the devs off from input, that is a recipe for a never-ending-story of disaster after disaster: notifications, watchlist-revamp, WP:FLOW, WP:VE, MediaViewer, and the general and well-considered view the wikipedia projects are individually failures, DESPITE the site somehow managing to carry on broadly. Changing that perception, will require altering the experiment, and going to a system where the devs and the WMF non-devs and the 10-year-editors and the 1-year-editors and the extremely vast number of 1-day-editors that have the potential to onboard, are melded into a resilient and functional community which agrees on what the shared goals are and also agrees on what the next tiny baby-step incremental improvements will help. The model utilized by the community-tech-team, where they have ~~annual wishlist competitions, is a promising sign, but needs to be exponentially ramped up: CONTINUOUS feedback, continuous iterative pre-design/prototype/betaTesting/deployment/re-design phases at multiple hierarchical levels, ALL projects/features/functionality and ALL proposals/changeOrders/bugfixes subject to the community-driven buy-in-processes, plenty of room for devs to be WP:BOLD in taking a long series of small incremental-improvment baby-steps but NOT catering to reckless blow-it-up-and-rewrite-it schemes that toss backwards compatibility and UI stability in pursuit of a shiny silver bullet. Wikipedia is a complex wiki-culture-driven system, and waterfall-megaprojects are the WRONG way to run things. Start moving ALL the dev-discussions on-wiki (even if that means they are 'slower' because they are not f2f or proprietary skype or IRC or whatnot), because making 'faster' decisions that are THE WRONG decisions is counterproductive in the long run. As Gerard says, this proposal will end up with enWiki (and other major wikis) able to "block anything they don't like"... and that is fine, that is exactly the point, because once the community buy-in process is up and running, the devs will stop BUILDING stuff that the enWiki folks do not like! That is a feature, not a bug 47.222.203.135 (talk) 20:11, 2 January 2017 (UTC)[reply]

Oppose

Whatever the intention, this will precisely become "seeking the right for the community to block everything they don't like", and I don't see how it can't - David Gerard (talk) 23:18, 2 July 2013 (UTC)[reply]
At least in cases where the view of the community is truly a valid WP:CONSENSUS, why should the community be forced to accept something that is contrary to consensus? Shouldn't the WMF want to take such a consensus into account? --Tryptofish (talk) 23:32, 2 July 2013 (UTC)[reply]

@David — Good, because that's exactly what I think it should become. I don't want Wikipedia in the clutches of an oligarchy. We get to decide, not the developers. They shouldn't be allowed to enact massive changes without getting our approval first. Kurtis ^(talk) 19:06, 7 July 2013 (UTC)[reply]
Please note that WP:CONEXCEPT says that MediaWiki software developers, including both paid Wikimedia Foundation staff and volunteers, are not subject to the consensus of the community at the English-language Wikipedia and are free to operate however they deem necessary or appropriate, such as adding, removing, or changing software features, even if their actions are not endorsed by editors here. ~~I have suggested what I think is more balanced language specifying when this does and does not apply at Wikipedia talk:Consensus#Decisions by WMF software developers.~~^{(Proposal withdrawn, no consensus for change)} --Guy Macon (talk) 00:28, 10 July 2013 (UTC)[reply]
Or may be this would give the community a chance to provide feedback so that the ideas are improved before implemented. Doc James (talk · contribs · email) (if I write on your page reply on mine) 09:40, 14 July 2013 (UTC)[reply]
I'd prefer dialogue between the WMF and the folk here rather than the hallowed "content creators" whining about every change they see as "too drastic" and citing it's broken when truth is the the main driving force is a sentiment of "this is so different I can't cope, change it all back". I've been long under the impression that a lot of old hands around here are very stuck in their ways to the point of being welded and would be prone to rejecting most if not every change if it didn't benefit them directly and they could turn it off quickly. tutterMouse (talk) 17:19, 29 July 2013 (UTC)[reply]
Your comment seems to me to highlight how important it is for all of us to get away from an us-against-them view of the issue. Not all content creators are whiners, and not all content creators are set in their ways. But all content creators, well, create content, and without content, there really would not be any reason for Wikipedia. --Tryptofish (talk) 23:23, 29 July 2013 (UTC)[reply]
Precisely so, Tryptofish. @TutterMouse: you don't see any paradox in the WMF developing VE in order to attract more & new contributors whilst not concerning themselves with those already here beavering away? You can't predict that many of those you are deriding may have already reached the end of their tether & are going to stop contributing leaving even more old, redundant content cluttering cyberspace? Both developers & contributors need to work in tandem, not despite each other, for Wikipedia to remain a going concern. --Iryna Harpy (talk) 01:27, 29 August 2013 (UTC)[reply]

Could you clarify what you're objecting to? You said you'd "prefer dialogue between the WMF and the folk here", and as far as I can see the petition asks for nothing more than "asks the WMF to try to improve communication". Either I missed something that is in the petition, or I think you read something into the petition that isn't there? Alsee (talk) 06:20, 7 September 2014 (UTC)[reply]
I think it would be better for the policy to just say they can't force new interfaces on us, like Google has just done with the new and "improved" compose interface. I don't oppose change, I just oppose change when it brings stuff that is not as good as what we had before. I am always happy to try new interfaces, but if I don't like the new ones I want to have the option to keep the old ones. Azylber (talk) 13:14, 16 September 2013 (UTC)[reply]
In practice, that would be difficult, because a single Wikimedia project, in this case the English language Wikipedia, cannot unilaterally change the authority of Wikimedia developers. --Tryptofish (talk) 21:16, 16 September 2013 (UTC)[reply]

Examples

Please feel free to expand these sections below

Good practice

Wikipedia:Notifications/New message indicator - some options for restyling the new message indicator were clearly laid out.
- unfortunately undermined by (a) rushing to a decision, so that different ideas could not be adequately iterated (b) the decision to ignore the most popular option. But the discussion structure, including mockups and followup prototypes editors could test, was good, given the limited timeframe allowed for the discussion.
Development of mw:Page Curation? Page Curation was developed from March to September 2012. In March a newsletter was announced, which before the feature was implemented, had 130 recipients. To quote from that page, "The Wikimedia Foundation has a duty to include the community as much as possible during the feature development process and to respond to their suggestions." (followed by "Historically, this has not gone well")

One thing that has made Page Curation work well is that it is proposed as a new tool that can be used in addition to the previous tool, not replacing it. The old Special:NewPages is still up and running for editors that prefer the old way. This makes the requirements for the new tool much less demanding, and it's easier to meet the community expectations. Diego (talk) 10:58, 20 July 2013 (UTC)[reply]

"If it aint broke, don't fix it" and make new features optional (opt-in) until many users become receptive, such as hiding the orange new-messages bar as an option. In general, avoid continually changing the interface, as beware moving the steering wheel or gas pedal (navigational controls) as disruptive and demoralizing to users. -Wikid77 (talk) 15:05, 26 May 2013 (UTC)[reply]
Publishing and prominently linking to a project FAQ at WP:Flow and allowing Wikipedia editors to update it, according to their understanding of the project state. Diego (talk) 11:44, 18 July 2013 (UTC)[reply]
Introduction of MathJax. This technique radically changes the way, formulas are rendered. As a result, formulas finally blend with text in a decent way. MathJax got thoroughly tested in beta. Then it was activated as an option for logged in users. Editors engaged in math, physics, chemistry or engineering got plenty of time to get themselves familiar with the tool and report bugs to the development team. Only after this step, which is more than a year now, global activation by default is considered.-----<)kmk(>--- (talk) 01:00, 22 July 2013 (UTC)[reply]

Bad practice

Wikipedia:Notifications/New message indicator after a huge backlash from the sudden disappearance of the orange bar, a new tiny orange bar was implemented without adequate discussion, that does not serve the purpose of the original bar, and disrupts the list of links at the top.
Dropping support for quick, stable browser skins, to force users into the latest user-interface experiment.
Making Visual Editor default despite considerable feedback during testing that it had major bugs and that the fact it did not accommodate important aspects of editing (references, infoboxes ...) was a problem. Failing to make it accommodate widely used browsers. Not informing editors how to revert the change in default editing mode. Dismissive responses to reports of bugs and problems.
Article feedback tool(s): not consulting with the community and turning the newer form back on without an announcement despite the result of Wikipedia:Requests for comment/Article feedback. This is present on Wikipedia:How to fix cut-and-paste moves, which is not even an article.
Unclear or contradictory answers to questions about which advanced features the new tools will support (e.g. full support of wikitext at the source editor fallback in Flow), and whether advanced features in the old tools will still be available.

Suggestions

Please feel free to expand this section

Wikipedia:Village_pump_(proposals)#Developer.27s_Noticeboard
- Developer's Noticeboard, or WMF Noticeboard, is a must-have. The best part is that we can just plain deploy it on our own! Then we ask the WMF to post there. I would hope the WMF would post RfC's there, rather than merely Royal Announcements. Maybe we should put RfC somewhere in the name of the board to guide them in the right direction. WMF RfC Noticeboard? Alsee (talk) 06:32, 7 September 2014 (UTC)[reply]
While I feel that WMF has been making a decent amount of good faith effort to improve communication, we definitely need a standard practice of where information is announced, both on a language-wiki level and on a global level. I think part of the issue is that there is such a large variety of communication mechanisms for Wikipedia - many of which are monitored by particular groups of editors but not others. I think adding a new place to announce things, while not a bad idea itself, will take a long time to get traction, since editors are set in their ways about where they look for information. Therefore, let's have make the standard policy of announcing the information to announce it on several places - on perhaps a new noticeboard, on the village pump, a notice in Signpost or the language equivalent, mailing lists, etc. Some people will likely complain about the repetition, but I think this is a price to pay until people adjust to having one particular location for announcements. Least that's my two cents. Jztinfinity (talk) 04:53, 13 May 2013 (UTC)[reply]
Trusted testers: If Wikimedia want they can create a "Trusted testers" group who can give initial feedback! Google has a trusted testers program and it works fine! Frankly, if I had been a trusted tester of Wikipedia, I would have given an immediate negative response for sudden withdrawal of OBoD! --Tito Dutta (contact) 23:00, 13 May 2013 (UTC)[reply]

Response from Okeyes (WMF) --Tito Dutta (contact) 20:57, 14 May 2013 (UTC)[reply]
- This has been discussed before and I think everyone would like this (users and devs), but it probably requires serious architectural changes in both software and infrastructure. We are a long way from being able to actually do this in terms of maturity of the system, and actually getting the system that far might be very disruptive in itself. It's not just flipping a switch or something. FB and Google's systems were designed for this, MediaWiki simply wasn't (actually it was designed to prevent fragmentation, since we were running on as little hardware as possible). —TheDJ (talk • contribs) 08:28, 31 May 2013 (UTC)[reply]

The default should be and remain that all or most of the users can have access to the new features and there ain’t no loss anymore. There should be access to basic features (like notifications) for all users also without scripts. Scripts should only be used for features that aren’t necessary for the work in Wikipedia, but not for things like notifications and things like that. It should always be checked before putting things live in Wikis, if there ain’t no loss. It is no help at all, if there is a new JS script to show a notification bar that has disappeared just because of a new system based on scripts, that doesn’t make any sense at all. Also the new translation interface isn’t useable in any way without scripts, so it’s only possible to change translations by searching the right translation message with Special:PrefixIndex. That’s quite difficult and time consuming, and you have to know it also. At Wikidata, it isn’t possible in any way to change, add or delete interwikis without scripts. There’s just no way, except the revert button. oO So you have to add interwikis in other language articles or ask another person to change interwikis. Everything new invented seems to be based on scripts, and noone seems to think about accessibility. It seems to me that the foundation is only looking for new editors with new computers and new systems, everything which isn’t compatible seems to be irrelevant. I don’t see how there can ever be an expandation in wikis in non-Western languages without thinking about people which don’t have the last computer systems. The foundation should work together with WikiProjects like Wikipedia:WikiProject Accessibility and others to avoid such things. --Geit ost 17:31, 16 May 2013 (UTC)[reply]
There is a red link at Wikipedia:WikiProject Accessibility/What is accessibility?#How can we improve accessibility? leading to Wikipedia:WikiProject Accessibility/Introduction for developers. I suggest that there should be written something useful and helpful and that there should be feedback for new features before setting them for everyone as default which can’t even be changed to the previous working feature anymore, so that accessibility for everyone will be normal again in the future, ’cause now it isn’t anymore; every bigger new feature (like notifications, Wikidata, translation interface) isn’t accessible anymore for everyone. That’s not good and should be reverted in the future. --Geit ost 11:08, 19 May 2013 (UTC)[reply]
- Ah yes, I started that, if I have a couple weekends of free time, I really should start working on that again. —TheDJ (talk • contribs) 08:29, 31 May 2013 (UTC)[reply]
Don’t look at Facebook so much, not everyone here likes and uses Facebook, and perhaps you are driving users away from here that don’t like and use Facebook and now see the same (not even working) things here, too. Please find a better way of doing things than they do there. Facebook isn’t a non-profit organization, it’s earning money with it and it doesn’t care a lot about privacy. So, if you want to be more like Facebook, then you are driving people away who wanted to take part in a non-profit and accessible kind of wiki thing. Otherwise, you are wiping away all the differences between a non-profit and a normal business company like Facebook. Then you can also activate advertising, if that’s the way it shall be in the future. --Geit ost 11:08, 19 May 2013 (UTC)[reply]
- This argument is the Godwin's law of our software development feedback. Talk about actual problems please. —TheDJ (talk • contribs) 08:24, 31 May 2013 (UTC)[reply]
  - Nice point, that's a keeper! — Scott • talk 11:19, 31 May 2013 (UTC)[reply]
- There's a lot of logical fallacies in that one paragraph, there: Slippery slope, Non sequitur (logic), False premise (that non-profit organisations don't have usable websites)... Newcomers to Facebook find it easy to use without training. People (including potentially very valuable contributors) to Wikipedia find it hard to use, even with training and documentation. There's no technological reason why it should be as hard to use as it is. Looking at sites that make a success of user involvement is a obvious thing to do. I agree with TheDJ that these arguments should be shot on sight. MartinPoulter (talk) 15:27, 1 June 2013 (UTC)[reply]
  - There's a seed of truth in there, though. The WMF has made a major goal in and of itself to retain new editors and improve the user base. This is not a bad thing on itself, but the way it's being approached has an element of disrespect for existing users, as if the ultimate goal of building an encyclopedia has taken second place to the short-term goal of improving new editors experiences. A for-profit company could be expected to follow this approach, but it seems antithetical to the foundation's spirit. This is showing in the use cases supported by the new tools, that are insufficient to meet the community requirements, and for which no fallback is being provided. Diego (talk) 11:59, 18 July 2013 (UTC)[reply]
As an experienced computer scientist, I have noted how weekly user-interface changes are disruptive to editors, think "user-interfere" as a caution. The user-interface changes have virtually ruined editing of Wikipedia (over 2 years) for users with older browsers, such as the lockups and garbled scrolling format with IE6, IE7 (MS Vista), IE8 (Windows 7), and perhaps others, until IE8 format (world's top browser) was fixed by early 2013. Most user-interface changes will be a net negative, as basically: if the steering wheel or brake pedal are moved, then expect major problems. In general, navigational controls should be kept stable. Perhaps the worst impact, of rampant changes, is when users fear how more "improvements" will be similarly disruptive. Plus, reminders about disruptive changes are disruptive. One of the dangers associated with Communism was a lack of personal ownership in the system, viewed as demoralizing, and when users feel railroaded by changes then expect poor reception. It is not surprising that some people have implied the managers should be fired for the manner in which the WP software has been changed. However, Google tried similar weekly/monthly changes to their interfaces, even having the Google Search menu fade-in for 4 seconds one week, which gave the impression of S-L-O-W or low-power searching, while monthly rearrangements of Google Translate buttons became a bit of a joke until the interface was stabilized. Well, live and learn, and understand methods of failure. -Wikid77 (talk) 15:05, 26 May 2013 (UTC)[reply]

Clearer user feedback channels and participatory design techniques are needed. I was disappointed by the Wikipedia Usability Initiative and notice that it has been shut down ([1]). My impressions of it — and I may be wrong — is that it took a ivory tower approach to usability. Given the nature of Wikipedia more involving user-centered design techniques (such as participatory design) would seem to be both more appropriate and possible.
For example, an approach to development may be to use something like Google's "canary" approach: have a version of the site that that contains features expected to be rolled out. Any one can use it as an alternative to the "stable" version of the site (some users may prefer to use it all the time). The site can be used to get feedback on feature ahead of a full roll out — and if a feature doesn't work, or get's a back reaction, pull it (brutally and swiftly), then iterate on changes until a particular feature is well-like from whereupon it gets released to the "stable site" site.
This won't work with all possible features, but is suitable for many (particularly UI changes). --RA (talk) 17:29, 2 June 2013 (UTC)[reply]

+1 to participatory design from the start and using samples for all kind of editors (including experienced editors from different wikiprojects), instead of limited tests centered only on new editors. Diego (talk) 12:05, 18 July 2013 (UTC)[reply]

Provide clear user feedback channels to developers. Also, I'm a software developer, I'm an administrator, I've been contributing to Wikipedia for almost a decade, but how/where to contribute to the software development side of the project (apart from one or two comments on Bugzilla) is a mystery to me. Maybe this petition will motivate me to look deeper into it — but it should be clearer. Open collaboration over the software (not just of MediaWiki but of the specific EN Wikipedia build) is as important as collaboration over policies and guidelines of the wiki. I don't feel it is at present. --RA (talk) 17:37, 2 June 2013 (UTC)[reply]
(Copied from my support comment above) I'll add a request that, for all major interface changes, a Community ambassador is assigned to the project to serve a public relations role between the community and development team, explaining the team's vision and motivation and channeling the most constructive feedback from the community back to the team. Developers have demonstrated their good will to assume this task, but frankly they usually don't show aptitudes for that role nor should it be a requirement of their job.
meta:Research:VisualEditor's effect on newly registered editors/Results makes for absolutely jaw-dropping reading. --Tryptofish (talk) 17:44, 23 July 2013 (UTC)[reply]
My 10 cents for improvements: --Pgallert (talk) 20:29, 28 August 2014 (UTC)[reply]
- Software release life cycle: Never roll out alpha software. Have beta software tested, by paid personnel if necessary. Come as close to a release candidate as possible.
- Customer relationship management: You have two sets of customers, readers who donate money to run your business, and writers who make sure there is something to read. Try to keep both groups happy.
- Post-disaster communication 1: A standard good practice from the business world is, if there is a serious complaint coming in, resist the urge to immediately deny and dismiss it. Let it sit in your inbox for a day. Sleep over it, think about it, consult colleagues. Only then formulate a response.
- Post-disaster communication 2: Try to think of the possibility that whoever turns up with a complaint might not be a troll, and, until proven otherwise, don't treat them as if they were. The community has identified and blocked many trolls, there are hardly any left.
- WP:ASTONISH 1: Don't change the interface for active users. There is always a reason to keep functionality as it is--if not for you then at least for the editors. In most cases it is neither necessary nor advisable to completely discontinue a certain feature, and in all those cases there is no reason to force an editor to change. While we are stubborn, we are also exceptionally computer literate; Should it one day not work any longer we will find the proper checkbox in the preferences. And on that day we could not blame the Foundation, just ourselves.
- WP:ASTONISH 2: Accept that editors are as stubborn as they are, and preserve their archaic settings for them. If on one fine day I decide to turn up at Bavarian Wikiversity for my very first time, be so kind to copy my preferred settings from my main Wikimedia project.
The WMF would get a lot more support if they posted RfCs on stuff. If the RfC supports something, and someone gets upset, the WMF can point to the RfC and people will respect that. That would eliminate a LOT of complaints and hostilities. If the RfC doesn't support something, then they get good feedback on what our concerns are with it. Note: The WMF can't simply look over RfC comments for a list of stuff to change and presume it will be accepted. They would need a second RfC asking if we want it with changes X Y and Z. And I'm not assuming English dominance - I think it's a good idea for them to RfC on (at least) the largish communities. Alsee (talk) 06:25, 7 September 2014 (UTC)[reply]