Wikipedia

Wikipedia:Wikipedia Signpost/2019-04-30/Discussion report

< Wikipedia:Wikipedia Signpost | 2019-04-30
The Signpost
← Back to Contents
View Latest Issue


Discussion report

English Wikipedia community's conclusions on talk pages

Contribute   —  
Share this
By Pythoncoder

Talk Pages Consultation 2019: A summary of the English Wikipedia and sister projects' ideas

With nobody else stepping up to close the English Wikipedia's discussion regarding the future of talk pages, it was up to Alsee to post the results. Here are some of the key takeaways:

  • Almost nobody wants Flow or a similar talk page replacement to return.
  • That doesn't mean people don't want change, though—in the same straw poll that asked about support for Flow, 95% of users supported some kind of "incremental" change to talk pages.
  • There were many complaints regarding posting to talk pages using the mobile site, due to the widespread stance that the mobile site is more focused on readers than editors. As such, several users mentioned using the desktop site when editing on mobile devices.
  • Several users cited difficulty regarding how to thread discussions, including where to reply and how to indent.
  • Many users asserted that user engagement problems are more due to Wikipedian cultural problems, as opposed to issues with the way talk pages work.
  • Almost everyone wants to keep wikitext and regular page histories/diffs.
  • Infinite scrolling is very unpopular.
  • Many users want autosigned comments.
  • Some users want VisualEditor enabled in talk and other namespaces.
  • Other issues discussed include low-visibility talk pages, making it possible to add individual sections of a page (for example, on WP:ANI) to watchlists, and edit conflicts.
  • Alsee concluded by saying: "It's worth noting that a member of the Wikimedia Foundation Board of Trustees participated in the consultation, and they were part of the near-unanimous support for keeping and improving the existing wikipages for Talk."

Sister projects

Some sister projects, however, came to different conclusions. Here's a summary of all the sister projects' summaries:

  • Catalan Wikipedia, which uses Flow, liked Flow for small discussions because it removed the requirements to ping users and sign posts. For longer discussions, there are problems with Flow's inability to manually move off-topic messages. Flow's infinite scrolling was also criticized.
  • Chinese Wikipedia, which has Flow enabled on a minority of talk pages, complained about Flow's handling of their wiki's automatic Simplified-to-Traditional Chinese script conversion system. They also criticized Flow's incomplete wiki markup support, infinite scrolling and poor table-of-contents capabilities. Some users suggested enabling VisualEditor on most talk pages.
  • The discussion on Dutch Wikipedia centered mainly around behavioral issues. Users cited newcomers' issues with talk page syntax, as well as incivility by more experienced users.
  • English Wikisource users wanted it to be more clear to new users how to centralize discussions.
  • French Wikipedia preferred wikitext talk pages, even though they saw them as complicated, especially for new users, for many of the reasons English Wikipedia contributors mentioned. Users also complained about the requirement of signing posts and it being difficult to notify other users. Flow was seen as more newcomer-friendly, but was more unpopular due to its infinite scrolling (you may be sensing a theme here) which makes it hard to search for section, excessive notifications, unreadable topic names, poor wikitext and history support, and disengagement from the community. That last one will hopefully be resolved with this consultation taking place.
  • French Wiktionary discussed centralization, the complexity of wikitext, and making discussions on multilingual projects like Commons more open to other languages. They also dislike Flow.
  • German Wikipedia apparently had a rather large discussion, but it has not yet been summarized. This is a pity since they are one of the largest Wikimedia projects. The Arabic and Hindi Wikipedias have also not posted their conclusions.
  • Hungarian Wikipedia, which was going to switch to Flow before this was blocked by this consultation, supported creating something more social media-like to appeal to younger users. They also supported creating an autosign feature, and making indentation less confusing.
  • Iberocoop are more frequent users of offsite services. Like many projects, they would like to see an autosign feature added and see indentation become less confusing. Additional requests to provide incremental talk page improvements include automatic archiving and tools to deal with bad-faith comments. Others supported Flow or something more forumlike.
  • Japanese Wikipedia wants, you guessed it, autosign, as well as making talk pages more newcomer-friendly. Many participants were mobile users and they found it hard to use talk pages with their mobile devices.
  • Polish Wikipedia wants a reply button, better tools to quote other users, section watching. They also expressed concerns about accessibility to newcomers as well as being able to opt out of any new changes.
  • The closer at Russian Wikipedia took the WMF to task for taking inspiration from social media sites when that's not what talk pages are used for. Major issues listed with Flow include infinite scrolling and the amount of whitespace. Some users did not oppose a "tree view", but wanted a way to switch between that and a more traditional wikitext mode. Miscellaneous requests: edit conflicts being automatically resolved and, once again, autosign.
  • Thai Wikipedia wanted autosign, auto-reply, and more civility (a behavioral issue).
  • Some Wikidata users requested section watchlisting. Flow is a divisive issue on Wikidata; issues with Flow (coming from both Flow supporters and opponents) include its bugginess, no diff support, notification volume, and... if you've read through the rest of this, you know what I'm going to say here. Hint: it starts with "infinite" and ends with "scrolling".

Following the HuffPost article about disclosed paid editing on Wikipedia, a full ban on paid editing (excluding Wikipedian in Residence and Reward board) has been proposed at the administrators' noticeboard. Aquillion, who posted a message in support of a paid editing ban, argued that it's impossible for paid editors to contribute without violating Wikipedia guidelines like Neutral Point of View and Tendentious Editing (which, like WP:SNOW, is not a guideline but it might as well be since people treat it as such these days). A common argument in this discussion against a ban is that the paid editing would continue, but it would be harder to regulate because it would be forced into the shadows.

In brief

  • There has been some drama about administrators deleting pages under community sanctions. Wikipedians are debating whether to add text to WP:General sanctions prohibiting deletions of pages under general sanctions (such as blockchain-related pages) outside of normal deletion procedures like WP:CSD or WP:AFD.
  • In addition to the ongoing portal deletion discussions, users are discussing whether there should be stricter rules regarding portal creation. Several proposals have been made regarding whether portals should have WikiProject sponsorship or should go through a new Portals for Creation process.
  • The controversy regarding a close of a recent RfA has led to discussion about whether RfA should be a straight vote or not. Consensus seems to be in favor of the status quo (not a vote, or maybe a bit of both).

Follow-ups

← Previous "Discussion report"
+ Add a comment

Discuss this story

These comments are automatically transcluded from this article's talk page. To follow comments, add the page to your watchlist. If your comment has not appeared here, you can try purging the cache.
  • The Fatal Flaw:
From the Talk pages consultation page:
"Wikimedia Foundation product teams have worked on communication tools before... By the end of this consultation, we'll have an overall product direction for a set of communication features that a product team will be able to work on in the coming fiscal year".
Before reading further, do you see the fatal flaw?
We are giving the same people who failed at a task before the job of doing it right this time. I realize that this will anger some people, but why should it? The WMF is great at running an encyclopedia. Nobody else, anywhere on earth, even comes close. However, running an encyclopedia does not magically confer the ability to create high-quality software, and the WMF has a pretty dismal track record in this area. Olympic-level athletes don't get angry when you tell them that their athletic ability does not magically confer the ability to repair automobiles or do astronomy.
One possible solution: Set aside a certain amount of money, and put out a call for third parties to solve this problem. Have the WMF pick some small number of proposals and let the community pick some small number of proposals, and pay the third parties to create prototypes of their solutions for all to try. Reduce the number by paying off and thanking the candidates that are of lower quality and giving the remaining teams more money to develop their ideas further. Finally, narrow it down to the one best solution (or decide that all the solutions suck and go back to square one with new requirements).
I have made this sort of proposal before. Inevitably someone claims that the WMF is already doing a a great job in every aspect of software development and that nothing needs to be changed. For those people I have a question:
On February 3 2006, it was reported to the WMF that our CAPTCHA system discriminates against blind people. See [ https://phabricator.wikimedia.org/T6845 ]. This appears to be a direct violation of the Americans with Disabilities Act of 1990 and leaves Wikipedia open to discrimination lawsuits.
So why, after 13 years of inaction, do we not have a set of software requirements (including a testable definition of "done"), a schedule with milestones and updates, and budget and staffing information for solving this? And if the WMF is not capable of solving it, why have we not put out a call for proposals in order to find someone who can? --Guy Macon (talk) 15:14, 4 May 2019 (UTC)[reply]
Depiction of Wikimedia Foundation destroying Wikipedia with Visual Editor, Flow, and Mobile App instead of making obvious but boring improvements to what we have. —pythoncoder (talk | contribs) 12:33, 6 May 2019 (UTC)[reply]
Guy Macon: ...running an encyclopedia does not magically confer the ability to create high-quality software, and the WMF has a pretty dismal track record in this area. Olympic-level athletes don't get angry when you tell them that their athletic ability does not magically confer the ability to repair automobiles or do astronomy - thank you for this. I have been saying words to this effect for years. However, I do believe that that ACTRIAL/ACPERM was a milestone and finally brought home the message that the devs are not always right and need to listen to the community rather than impose their own management decisions without experience in crucial areas. The other issue of course is that as registered charities (and NGOs , for example) are not answerable to any shareholders, they are notorious for squandering money - easy come, easy go - as long as the paid staff get their salaries. Kudpung กุดผึ้ง (talk) 02:55, 9 May 2019 (UTC)[reply]
ACTRIAL/ACPERM was really good. It surprised me how well it ended up. But it should not have been so hard. It should be easy to work together with the WMF from the start.
This brings to mind a related problem: Guy Macon and Kudpung could get together and discuss making some improvement to the software that runs Wikipedia. We could talk things over on a talk page, email each other, or even meet at a Starbucks and talk face to face. Likewise, WMF developer A and WMF developer B can get get together and discuss making some improvement to the software that runs Wikipedia, using any of the above forms of communication. In both cases the conversation can be completely open, with anyone throwing out possibly bad ideas for the other to tear apart.
But if a WMF developer ever dares to get together with Guy Macon or Kudpung to openly discuss making some improvement to the software that runs Wikipedia, he will be instantly fired and won't get a good reference. Developers are only allowed to communicate with the people who actually use the software on a day to day basis through the most formal -- and controllable by management -- methods. Thus we see things like the "2019 Talk pages consultation" above. And why I will never, ever, have an open conversation with any WMF developer about our 13 years of discriminating against a minority that is legally protected in the US. We will never see a set of software requirements that includes a testable definition of "done". We will never see a schedule with milestones and updates, and budget and staffing information for solving this. And we will never discuss even the possibility of putting out a call for proposals to solve this.
The sad part is that the actual people writing the code are in no way at fault for any of this. They are doing their best under the constraints they work under, and most of them -- maybe all -- are perfectly capable of creating and deploying high-quality software. The problem is the system they are embedded in. The problem is management, and it goes right to the top. --Guy Macon (talk) 07:48, 9 May 2019 (UTC)[reply]
Some readers take exception at criticisms of the WMF - who themselves claim their Executive Officer, though ...based in San Francisco, though it may be more accurate to say she lives in a metal tube in the sky, and accused The Signpost of misogyny. Such detractors would do well to read this excellent Meta-wiki essay on the dynamics of the relationship between the Wikimedia Foundation and the rest of the movement by The Land - the community has a right to be informed and whether or not their work and interests are correctly represented by those whose salaries are generated by the unpaid toil of thousands. Kudpung กุดผึ้ง (talk) 03:59, 10 May 2019 (UTC)[reply]
I'm glad people still read that essay :) Though do bear in mind that it's aimed at community members, as well as the WMF.... By the way @Guy Macon: you may have spotted that Diversity is one of the key features of the current work on the movement strategy, which means "are our projects actually accessible to blind people and if not what can we do about it" is the kind of question that is now getting serious thought. I am sure the Diversity working group would welcome you highlighting this issue. The Land (talk) 09:07, 10 May 2019 (UTC)[reply]
Done.[1] I would appreciate some of you who have commented here weighing in there.
...and it received that exact same response I got the last dozen times somebody claimed "You just aren't asking in the right place, Guy". :( --Guy Macon (talk) 16:12, 28 May 2019 (UTC)[reply]
As I have been bringing this up over the last five years or so, I have received multiple good-faith comments of the form "why don't you bring this up at X?" or "This is the wrong place for this, ask at Y". Every time I bring it up where they suggest. By my count, this is the 17th time I have done this. As Rocky once said, "That trick never works!" --Guy Macon (talk) 12:43, 10 May 2019 (UTC)[reply]
Are you talking about communication tools or the whole encyclopedia software? scope_creepTalk 22:42, 10 May 2019 (UTC)[reply]
I think this week we should start a scoping exercise to determine what software features were a looking for in new software, get a slack group going, a Github project going and start casting around for developers. The thing that worries me is that I feel that by 2029 we will be still using the same software if things stay the same and I really think the WMF should be no longer be mentioned in the same breath as software. I am absolutely sure we can build an Open source software encyclopedia using a DevOps model approach, using volunteers software engineers thatincrementally building features using a consensus based approach to feature approval. The software isn't that complex. I think it would take less than three years. What do you think?. scope_creepTalk 23:05, 10 May 2019 (UTC)[reply]
There are two aspects; one technical and one (for lack of a better word), "economic". It isn't really economic, but it does involve competition for limited resources.
The technical aspect is feasible. Start with a pilot run of one improvement, carefully chosen to be noncontroversial and easy to implement. Use it to put together all the details of how the team works together, what happens when team members disagree, etc. Once we have one improvement to the existing software that runs Wikipedia, we submit it to the WMF. If they accept it and add it to the software, we keep submitting new fixes until they reject one and no modification of the fix results in them accepting it. Once we get that first rejection of a good fix (which may be the first fix we submit, or may be the 1,000th) we then need to address the "economic" aspect.
The "economic" aspect is this: anyone can set up a new encyclopedia. Many have. They can copy the existing Wikipedia software, copy it and modify it, or create brand new software. They can even reuse all existing Wikipedia content. What they cannot do is make copies of the 48,193,052 registered users, 118,780 active editors and 846 administrators who, together, have made 1,249,714,485 edits, created 61,752,231 pages of all kinds and created 6,903,922 articles. A new encyclopedia is a non-starter. So, can we create an alternate front end which accepts user input and makes edits to Wikipedia? And which blocks a user when Wikipedia does, reverts vandalism when Wikipedia does, somehow adapts without breaking when Wikipedia get new features, and looks to Wikipedia exactly like a normal user -- including his IP address, browser cookies, etc. -- logging on and editing?
Feel free to create a detailed plan that addresses these issues. --Guy Macon (talk) 02:24, 11 May 2019 (UTC)[reply]
Yip. OK. We start with the current software, who guessed it. I'll start working on a plan. The scope is the UX and we need to deal with WMF. Has there been any work done on a plan, or a issues list, or potential problems list, scoping, of that ilk that you can send me, something that defines the size of the problem. Has there been any work done on it. Has there been work done on looking to partner with an external organisation that is capable of doing web-scale development and is will work with us. We need to look at the delivery models and see how they apply here. Is there impetus for actually starting the process now too get change happening now, say if I started talking to folk, put some feelers out. It not still a talking shop? Some momentum needs to be generated at the beginning to get it moving, possibly a strike to show the WMF that we are serious. It needs to be a group effort. The stability over disruption model is not something that can sustained over the long term. I was talking to a mate last night who works for Sony research and we talking about software and how it is driven by fashion and politics but mostly fashion. Its the look of new software that excites people, that newness, that makes them want to use it. Its a truism. When I look at it now I see something which is equivalent of flash. The last time I saw equivalent updates was when the menu system was reworked to look like facebook. That is astounding lack of vision. That vision that we create for a new UX, something beautiful and useful that will be updatable that will drive it. Guy Macon I see your on the WMF engineering team. Tell me what about the WMF, what is stopping them doing it themselves and have they done migration planning or have they looked at large scale feature planning/roll-out. Any research available on it? scope_creepTalk 10:25, 11 May 2019 (UTC)[reply]
The first thing we really need is a standalone NGO called something like Wikipedia Software Foundation. With a proper legal basis that is a economic counterweight to the WMF, we can start raising funds and tie into industrial fund givers. The WMF are excellent at running Wikipedia as a product, but they are not good at delivering feature scale software as the users need on an on-demand basis. The political will is not there and unless there is some kind of change in the culture, it wont happen. The best we can hope for is to get an agreement which states they will implement the feature if editors want it and consensus for it. scope_creepTalk 11:06, 11 May 2019 (UTC)[reply]
Re: "The best we can hope for is to get an agreement which states they will implement the feature if editors want it and consensus for it", there is zero hope of that ever happening. See User:Guy Macon/Wikimedia referrer policy, where the WMF rejected the clear consensus of the community. Your plan must include a workable method for cramming basic things like "stop discriminating against blind people" and "stop assisting marketers and spammers who want to gather data on Wikipedia users" down the throat of an unwilling and hostile WMF. --Guy Macon (talk) 16:12, 28 May 2019 (UTC)[reply]
What do you think of The Signpost? Share your feedback.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Wikipedia_Signpost/2019-04-30/Discussion_report&oldid=1193878474"