I'm part of the team that's holding the Talk pages consultation, and I'm glad to see this writeup; it's a good summary of what's been discussed. The talk page team is currently working on a full report of findings that we hope to publish within a week or two -- bringing all of the discussions together, as well as some user tests that we've done this month. That report will wrap up Phase 1, and kick off Phase 2, where we'll talk about tradeoffs, and zero in on a product direction. Folks who are interested should watchlist the consultation page on mediawiki.org to see the report; I think it'll be interesting. I'm also available if people have questions about the consultation, or talk pages in general. -- DannyH (WMF) (talk) 21:27, 30 April 2019 (UTC)[reply]
"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:
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]
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]
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]
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_creepTalk23: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,305,407 registered users, 122,731 active editors and 851 administrators who, together, have made 1,254,308,071 edits, created 61,892,793 pages of all kinds and created 6,914,744 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?
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_creepTalk10: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_creepTalk11: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]
← Back to Discussion report