The Signpost

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:

Sister projects

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

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

Follow-ups

S
In this issue
+ Add a comment

Discuss this story

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 47,422,686 registered users, 121,176 active editors and 859 administrators who, together, have made 1,219,916,013 edits, created 60,711,036 pages of all kinds and created 6,825,327 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]





       

The Signpost · written by many · served by Sinepost V0.9 · 🄯 CC-BY-SA 4.0