Jump to content

Wikipedia:Village pump (WMF)/Archive 2

Add links
From Wikipedia, the free encyclopedia
Village pump (WMF) archive  

This page contains discussions that have been archived from Village pump (WMF). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: 1, 2, 3, 4, 5, 6, 7, 8

Individual Assignments: Software Proposal

My new proposal, a bot account which you can request assignments from. You should be able to input certain keywords or categories like stubs, or it could just be an algorithmic software that doesnt need a users input, but makes suggestions based on the pages in the contributions log of the account. I don't know, just leave something as a reply. I'll answer in a few hours. Gjjixzho (talk) 22:18, 26 August 2020 (UTC)

@Gjjixzho: Sounds like SuggestBot! – Joe (talk) 06:57, 27 August 2020 (UTC)

Gjjixzho (talk) 11:47, 27 August 2020 (UTC)

See also Wikipedia:Task Center and Wikipedia:Maintenance. Certes (talk) 22:40, 27 August 2020 (UTC)

Editing news 2020 #4

Read this in another language • Subscription list for this newsletter

Reply tool

The number of comments posted with the Reply Tool from March through June 2020. People used the Reply Tool to post over 7,400 comments with the tool.

The Reply tool has been available as a Beta Feature at the Arabic, Dutch, French and Hungarian Wikipedias since 31 March 2020. The first analysis showed positive results.

  • More than 300 editors used the Reply tool at these four Wikipedias. They posted more than 7,400 replies during the study period.
  • Of the people who posted a comment with the Reply tool, about 70% of them used the tool multiple times. About 60% of them used it on multiple days.
  • Comments from Wikipedia editors are positive. One said, أعتقد أن الأداة تقدم فائدة ملحوظة؛ فهي تختصر الوقت لتقديم رد بدلًا من التنقل بالفأرة إلى وصلة تعديل القسم أو الصفحة، التي تكون بعيدة عن التعليق الأخير في الغالب، ويصل المساهم لصندوق التعديل بسرعة باستخدام الأداة. ("I think the tool has a significant impact; it saves time to reply while the classic way is to move with a mouse to the Edit link to edit the section or the page which is generally far away from the comment. And the user reaches to the edit box so quickly to use the Reply tool.")[1]

The Editing team released the Reply tool as a Beta Feature at eight other Wikipedias in early August. Those Wikipedias are in the Chinese, Czech, Georgian, Serbian, Sorani Kurdish, Swedish, Catalan, and Korean languages. If you would like to use the Reply tool at your wiki, please tell User talk:Whatamidoing (WMF).

The Reply tool is still in active development. Per request from the Dutch Wikipedia and other editors, you will be able to customize the edit summary. (The default edit summary is "Reply".) A "ping" feature is available in the Reply tool's visual editing mode. This feature searches for usernames. Per request from the Arabic Wikipedia, each wiki will be able to set its own preferred symbol for pinging editors. Per request from editors at the Japanese and Hungarian Wikipedias, each wiki can define a preferred signature prefix in the page MediaWiki:Discussiontools-signature-prefix. For example, some languages omit spaces before signatures. Other communities want to add a dash or a non-breaking space.

New requirements for user signatures

  • The new requirements for custom user signatures began on 6 July 2020. If you try to create a custom signature that does not meet the requirements, you will get an error message.
  • Existing custom signatures that do not meet the new requirements will be unaffected temporarily. Eventually, all custom signatures will need to meet the new requirements. You can check your signature and see lists of active editors whose custom signatures need to be corrected. Volunteers have been contacting editors who need to change their custom signatures. If you need to change your custom signature, then please read the help page.

Next: New discussion tool

Next, the team will be working on a tool for quickly and easily starting a new discussion section to a talk page. To follow the development of this new tool, please put the New Discussion Tool project page on your watchlist.

Whatamidoing (WMF) (talk) 18:47, 31 August 2020 (UTC)

Wikimedia Alternative to fandom

Currently on Wikipedia articles on fictional topics are constantly under threat of deletion or merging due to overly strict notability rules and full time deletionist editors. This forces fictional articles to be exiled to Fandom where there is adverts and privacy violations. This is antithetical to the Wikimedia Philosophy. I don't think just because something is fictional your privacy should be violated. I think it is time for an inclusionist Wikimedia fiction project should be created and rescue the cc licenced content so people can read about fictional content with dignity. 2A01:4C8:57:1178:ABC7:9B7:572F:DF52 (talk) 09:04, 31 July 2020 (UTC)

  • I agree with this. I liked the concept of Fandom but the profiteering from Wikia is digusting. That website is completely unusable on mobile even with Firefox and uBlock Origin installed. Wikimedia should do a service to the People that donate money to it and create a nonprofit Fandom/Wikia alternative. But Jimmy Wales, a founder of and investor in Fandom, is also the Chair emeritus of the Wikimedia Foundation; so I don't think it'll work out for obvious reasons. TryKid [dubious – discuss] 12:15, 31 July 2020 (UTC)
  • I like the idea that even our most ardent deletionists could be considered "full time deletionists". I'd also dispute that the consequences are particularly antithetical to "Wikimedia Philosophy" either. That isn't to say that either of those, alone, is sufficient to sink the idea of a spin-off project that allowed "in-universe" sourcing for fictional content. However, this is in no way the right location for it. If you had some rough ideas, the "ideas" village pump page might help finding some support before going through the formal project setup. Projects in Wikimedia require huge levels of effort (Wikimedia Abstract, recently formed, was the first one in seven years). THe ideas stage would need a rough framework, and the submission stage would require significant support. Nosebagbear (talk) 12:56, 31 July 2020 (UTC)
    Agreed that this is not the appropriate forum. Meta would be better. {{u|Sdkb}} talk 10:04, 1 August 2020 (UTC)
  • This has been proposed before: meta:Wikifiction_(In-universe_encyclopedia). – Joe (talk) 13:03, 31 July 2020 (UTC)
  • It's not officially linked to the Wikimedia Foundation, but Miraheze (https://miraheze.org/) is a nonprofit that runs a advertising-free MediaWiki-based wikifarm similar to Fandom. If you have a specific wiki in mind, you might want to check it out. Vahurzpu (talk) 02:58, 1 August 2020 (UTC)
    • There's also http://editthis.info, which makes it even easier to create wikis (just create an account and click a few buttons), but 1) there's no HTTPS (so don't use it on public networks or reuse your passwords), 2) it's using a version of MediaWiki that doesn't even have Vector (which makes it *checks mediawiki.org* 11 years old) 3) it's veeeeeeeeeeeerrrrrrrryyyyyyyyy slooooooooooooowwwwwwww. That said, it's a good tool for creating wikis if you want to create small wikis about topics that Wikia or Miraheze wouldn't accept, or if you just want to try out MediaWiki but have no clue how to use web servers. —pythoncoder (talk | contribs) 22:21, 1 August 2020 (UTC)
  • I support but first we would need to get rid of Jimmy Wales as chair of the WMF as he is also related to Fandom and Wikia and also would take a long time to be created as WMF would need to get the project approved and then set up guidelines for the Wikis and set up how the domain names would work and stuff like that 🌸 1.Ayana 🌸 (talk) 20:47, 9 August 2020 (UTC)
    • He hasn't been Chair of the WMF since 2006, so not much point trying to "get rid of him as chair". He is "Chair Emeritus" but I'm not sure if there is any formal authority that comes with that title. He is also a board member of the WMF, and that is a real position within the movement. But it is possible to be a board member and have a conflict of interest. The key test is whether he has recused on WMF votes where he has a conflict of interest. If you are serious in your concern about Jimmy and conflicts of interest between Wikia and the WMF then have a look through the votes he has taken part in as a board member - having a conflict of interest is not the issue, what matters is how you behave when you have a conflict of interest. ϢereSpielChequers 17:02, 17 August 2020 (UTC)
  • I'm opposed to this. Not only am I a deletionist, I don't see any inherent problem with running ads on crufty wikis like Fandom as the contributors there just want to bask in legitimacy they haven't earned. Chris Troutman (talk) 17:26, 17 August 2020 (UTC)
  • We don't discriminate against fictional characters. They are held to the exact same standards as real events or people: Either it is notable enough that independent 3rd parties are covering it in a significant way....or they aren't. As for Fandom, that isn't our concern, it isn't Wikipedia/media. Anyone can fork the fictional content here anytime they want, all the text and images are free to use. Dennis Brown - 2¢ 18:41, 18 August 2020 (UTC)
  • Opposed to special treatment for fanboys and their pet projects. -Indy beetle (talk) 22:35, 7 September 2020 (UTC)
  • FWIW, Fandom is a massive project with hundreds of thousands of wikis, and a user and content base comparable in size to that of Wikimedia projects. (While its numbers are not entirely reliable, s23 wikistats might give you some idea.) Running something of that size comes with its own technical and social challenges, and they have a product and community team of the appropriate size. Having a wiki for fictional characters is one thing; having something at the scale of Fandom would be a sizable chunk of the Wikimedia budget. Given that the topics they cover are peripherial to the Wikimedia mission, I doubt there is any chance of that happening. --Tgr (talk) 22:52, 13 September 2020 (UTC)

A Universal Code of Conduct draft for review

Hello folks,

The UCoC Drafting Committee has created a draft for review. They would like to learn which parts of the draft would present challenges for you or your work. What is missing from this draft? What do you like, and what could be improved? The discussion will be open until October 6, 2020. The Drafting Committee will be reviewing comments weekly, and making improvements over the next month. To learn more about the UCoC project, see the Universal Code of Conduct page, and the FAQ, on Meta. Please help share the news as you see appropriate. The draft is available at Universal Code of Conduct/Draft review. Patrick Earley (WMF) (talk) 21:28, 7 September 2020 (UTC)

Where is the draft UCoC? I don't see a link.Nigel Ish (talk) 20:19, 7 September 2020 (UTC)
@Nigel Ish: It's at meta:Universal Code of Conduct/Draft review. --Yair rand (talk) 20:26, 7 September 2020 (UTC)
Thanks both, added it above as well. Patrick Earley (WMF) (talk) 21:28, 7 September 2020 (UTC)
  • Question regarding 3.3 - Content vandalism and abuse of the projects This provision prohibits "Unwarranted, unjustified addition of symbols, images, or content with the intent to intimidate or harm others." How shall WMF determine "intent" in this manner? I imagine if I posted a Nazi flag on my userpage identifying myself as a proud Nazi it would be deleted under the code, but there are other symbols which fall into grey areas. Specifically, I remember coming across a userpage some time ago (I think the user had been blocked or retired, can't remember) and they had posted a custom userbox which displayed the Confederate Battle Flag with a comment about being a proud Southerner. Many Americans now regard that flag as a symbol of white supremacy, while some of its proponents argue its just good ol' regional pride. Would the WMF try and heavily account for context and the poster's own words, or are there some symbols that will basically be outright banned? -Indy beetle (talk) 22:31, 7 September 2020 (UTC)
    A comment no doubt better left at the meta talk page. --Izno (talk) 23:55, 7 September 2020 (UTC)

Request for accessibility specifications

I am engaged in a project to develop Wikimedia content with a university. I would like to register all the Wikipedia activities I organize as part of this project. For this particular project, there is a requirement that collaborators describe the accessibility of their activity output. I am writing to request that the Wikimedia Foundation produce these specifications. The reason why I think the WMF should produce this is because I think this is of broad interest to partners, but not of typical interest to readers or Wikipedia editors, and because I expect that the WMF will have to give these kinds of self-evaluations as it seeks government and foundation funding.

Some of the things I think the specifications would say include

  • extent of compliance with any standards, such as Web Content Accessibility Guidelines (WCAG) 2.0 from the W3C
  • other special Wikimedia features, like the extensive language translation options or Wikidata tags for images
  • compliance with any government guidelines, perhaps with the European Union or any other regulatory agency

Here is what I found -

The format that I would like is a wiki landing page which gives an overview then links to any subpages that anyone cares to make. I am imagining that a link to such an overview would help me in my university collaboration, and also assist anyone else who has similar instructions to provide evidence that their Wikipedia engagement meets good practice in accessibility.

Thanks for whatever anyone can do. This is a standing request and I expect the issue will repeatedly arise until addressed. Blue Rasberry (talk) 20:36, 8 September 2020 (UTC)

Bluerasberry, you might be interested in WT:Did you know#Adding an accessibility requirement?. -- RoySmith (talk) 15:12, 10 September 2020 (UTC)

Strategy prioritization events

I mentioned earlier at this noticeboard that we had a Strategy transition group, which was developing the design of on-line events to implement the strategy recommendations, and which I was part of. Now we have got the call for the first series of events, prioritization events. I do not expect much of a reaction here, and I do not expect that the events organized by the affiliates will discuss much what the consequences of the strategy would be for online editing communities. However, if someone has interest and energy to organize such an event for the English Wikipedia, or for the English-speaking wikiverse, this would be very good. The whole purpose of such an event would be to go through the strategy recommendations and to see what would be possible consequences for us, which recommendations we want to implement asap, which we do not care about, and which we have to be very careful with the implementation. I do not have capacity and free time of organizing this, on- or off-line, but I could help a bit if people are interested.--Ymblanter (talk) 11:32, 24 September 2020 (UTC)

Appeals open: Interim Trust & Safety Case Review Committee

Hi everyone, I'm Brian. You may know me in my volunteer capacity as Airplaneman. I'm posting here in my role as Interim Case Review Committee Facilitator with the Wikimedia Foundation to follow up on Maggie Dennis's post in July regarding the Interim Trust & Safety Case Review Committee (now in Archive 1 of this page). The new appeals process for Foundation office actions through this committee is now open. Below is an announcement that I'll also be sharing on forums such as Wikimedia-l and the Wikipedia Weekly Facebook group. Suggestions for other forums to share are welcome (you are also encouraged to share)!

This announcement is to increase awareness of a new addition to the Wikimedia Foundation's office actions appeals process through the Interim Trust & Safety Case Review Committee (CRC). It includes a new way for some editors who have sought sanction and some editors who have been sanctioned by the Wikimedia Foundation to appeal.

Historically, some office actions have been appealable through the Trust & Safety team. The Interim Trust & Safety Case Review Committee (CRC) was created to provide community oversight of the appeals process. The CRC has 10 volunteer Wikimedia community members and will function until the Universal Code of Conduct becomes effective in approximately mid-2021, when we hope to have a more permanent process in place. As mentioned in the CRC’s charter, the committee will be able to review office actions which were closed by the Foundation with action or inaction, except statutory, regulatory, employment, and legal cases as defined by Foundation attorneys.

The office actions policy is a set of guidelines and procedures regarding official changes to or removals of content on the Wikimedia projects, or actions against specific individuals, performed by Foundation staff members and under the authority of the Wikimedia Foundation, upon receipt of one or multiple complaints from the community or the public, or as required by law. Complaints that may lead to enforcement of office actions may include, but are not limited to, privacy violations, child protection, copyright infringement or systematic harassment. All office actions are performed pursuant to the Terms of Use.

Appeals of office actions may be submitted to the CRC by anyone involved in the office action via email at appeals@wikimedia.org. Detailed instructions on how to appeal may be found on the CRC’s meta page. Some office cases are not eligible for review. A Foundation attorney will check each case where appeal is requested to determine its eligibility before turning over the case files to the committee. For transparency, the committee chair will be able to review those requests and will therefore have insight into how many cases are eligible or not.

Please refer to the CRC’s page on meta.wikimedia.org for further information. You are encouraged to inform your community about this new appeals process. If you have questions for or about the committee, please put them on the CRC talk page on Meta or email me at bchoo-ctr@wikimedia.org. The Meta talk page also contains questions that have already been asked and answered. I will find answers to your questions and post responses on the Meta talk page.

On behalf of the committee, BChoo (WMF) (talk) 23:32, 28 September 2020 (UTC)

Brian, according to the [handbook] there will be monthly reports to the community. When can we expect to see that first monthly report? Best, Barkeep49 (talk) 00:34, 29 September 2020 (UTC)
Barkeep49, I should have the first monthly report in the next 7 days. BChoo (WMF) (talk) 21:13, 5 October 2020 (UTC)

Thanks but no thank.

"When submitting an appeal, please:
Include an explanation as to why you believe the case should have been handled differently.
Be concise with your request. Lengthy emails with unnecessary information will make it harder for the committee to process the case in a timely manner.
Include the name of the account(s) subject to office action.
The committee's role is to review the appropriateness of an office action; therefore, new evidence will not be considered in appeals. However, certain appeal outcomes—for example, if the committee sends the case back to Trust & Safety for further investigation—could then be open to new evidence."

Considering that, when you get an office action thrown at you, you don't even know what the supposed evidence against you is, it is quite rich to then get an appeals process where new evidence (in the case of a defendant, this means any evidence) is not allowed. Basically, taking my own case, all I could have said is "please review, I don't think this is warranted", without any means to actually address any issues at all. Would T&S have reported the case truthfully? Would they have disclosed all possible serious conflicts of interest they had? Would they have played the same "there may be off-wiki evidence involved" when they knew from the start that no such evidence existed, but kept this deliberately vague so as to poison the well a bit further? I don't know, and neither won't anyone else who gets sanctioned.

This is a nice method to avoid the unappealability of T&S actions, without actually giving the sanctioned a fair chance, and wuold in my case probably have resulted in upholding my ban as I wouldn't have been able to defend myself, nor would an independent body have made a full case review based on hearing both sides, like ArbCom did (to the best of their possibilities, the cooperation from T&S was sorely lacking).

T&S should just stay the hell out of all cases which aren't strictly within their original remit, like child protection. This is a step in the wrong direction, cementing the role of T&S into areas where they have no business and have a very poor track record. Fram (talk) 13:21, 29 September 2020 (UTC)

I trust that my colleagues would abide by this anyway, but just FYI, EN.WP has prohibited current members of its arbitration committee from concurrently serving in this role. Beeblebrox (talk) 18:35, 29 September 2020 (UTC)

Desktop redesign

mw:Reading/Web/Desktop Improvements/Features.--Moxy 🍁 11:28, 25 September 2020 (UTC)

the W?F has come up with yet another really, really bad idea: "Sticky site and article headers will allow users to access important functionality (logging in/out, edit, talk pages, etc.) without requiring people to scroll to the top of the page." Just what we need: a part of the screen that never scrolls and makes the readable area smaller. And of course the W?F will start small and then slowly grow the nonscrollable area by adding more and more clutter. --Guy Macon (talk) 12:47, 25 September 2020 (UTC)
I made a similar point in July. However, I fear that it's now too late for anyone to listen. If another skin lets me keep the screen height I've paid for, I'll probably use it, otherwise it'll be time to remove Wikipedia from my ad blocker's whitelist so I can get rid of the space wasting elements. Either way, I am reluctant to stop seeing Wikipedia pages as readers see them, which will reduce my effectiveness as an editor. Certes (talk) 13:17, 25 September 2020 (UTC)
64% of readers are on mobile, so if you are interested in what they see, I am sure you will switch to the Minerva skin (which is what is on the mobile website) with a significantly reduced browser viewport width ;). This is only half-facetious; the other half is that we need to be reading/editing with these elements in mind already, yet we have an active desktop editor-ship that either doesn't know or doesn't care about it. I switched to Timeless (Minerva hamstrings editing TBH) so I see a bit more of the impact of changes like the ones that the WMF are implementing as they rework Vector; the implementation of an always-present leader bar in Timeless is quite nice actually. (You should try it.) --Izno (talk) 14:02, 25 September 2020 (UTC)
Izno, I certainly agree that every pixel is precious on mobile. That being said, one of the things I find really frustrating on mobile is having to scroll-scroll-scroll all the way back up to the top to get to the header links. -- RoySmith (talk) 14:29, 25 September 2020 (UTC)
The answer -- something the rest of the world has known for over 20 years but the W?F somehow cannot grasp -- is to give users a choice. Does RoySmith want his header links to stay on his screen? Make that an option in the preferences. Does Guy Macon want the header links to scroll up like the rest of the page? Make that an option in the preferences. Want to make the sidebar go away? Option. Preferences. Alas, instead of giving us more choices, the W?F thinks they know better than we do what we do and don't want on our screens.   :(   --Guy Macon (talk) 15:09, 25 September 2020 (UTC)
You have the ultimate customization in a CSS sheet or a Javascript script for yourself which you or Roy can remove or add to at your leisure. As for what the rest of the world has done, have you looked at any other websites? WMF is making these changes because it's what the rest of the world has recognized will be a good UI (for reading at least; wikis are rare in that we must write and maintain as well). Lastly, every (optional) feature has a cost, and since I know you know how much the WMF spends, spending money maintaining features like that, indeed with access to a rich stylesheet/Javascript system already that you can customize yourself, makes 0 sense in the budget tradeoff that occurs when they figure out what they want to spend money on. --Izno (talk) 15:35, 25 September 2020 (UTC)
Please explain in detail exactly what combination of CSS and Javascript will give me the following IU changes:
  • The sidebar on the left goes away, leaving the entire width for content.
  • The items on the sidebar are still available if I need them (a menu, a hide/show button on the sidebar... I don't care how.)
  • RoySmith gets what he wants (a floating header that stays on the screen while he scrolls) without imposing that "feature" on me, a person who hates it.
Finally, considering finances, you are using the classic "Admiral's Yacht" argument, presumably in responses to my essay at WP:CANCER.
The Admiral's Yacht argument goes like this: if anybody argues that the US is spending too much on the military (See note below) someone proposes that we stop buying bullets for the army or that we stop buying food for the navy. Nobody ever proposes getting rid of the general's private jet or the sdmiral's yacht.
Note: In 2019 the US spent 732 billion dollars (up from 649 billion in 2018) dollars on the military. The combined military budget of the next ten countries (China, France, Germany, India, Japan, Russia, Saudi Arabia, South Korea, Brazil and the UK) was 726 billion dollars, and the combined military budget of the rest of the world (139 countries) was $460 billion dollars.[2]
--Guy Macon (talk) 18:07, 25 September 2020 (UTC)
@Izno: WMF is making these changes because it's what the rest of the world has recognized will be a good UI
That's...actually not really true. There's a sizable group of people who strongly dislike these sorts of changes, and almost everyone agrees that things like the most recent Twitter redesign are objectively worse for desktop users than the previous version. The vast majority of the time, changes like the ones the WMF is proposing here and you're referring to in general are done purely in order to unify codebases so there's only one version of the site/app that has to be maintained. And, since mobile users comprise the vast majority of content consumption (but, importantly, not content creation) on the Internet these days, most of these "unified" site designs are designed for mobile users first and intentionally treat desktop users as second-class citizens.
Not a single interface expert in the world would argue that a hamburger menu is a good design choice for an interface designed to be run on a big 27" desktop monitor, because the hamburger menu was literally invented as a way to move navigation, settings, and tools into a collapsible menu to get them out of the way for mobile users with much less screen real estate. And yet many, many apps intended for desktop users include hamburger menus now. In fact, this very proposal includes six of them (the collapsible sidebar, collapsible language list, user menu, sticky table of contents, and the article tools menu). Which is even more hilarious here, since this is supposed to be a redesign of Vector, the desktop skin, and Minerva isn't even being affected. There's no screen real estate reason on desktop to hide this many tools away in menus. And any reason related to "unifying interfaces" doesn't make any sense here, either: this is wiki software. The entire point is that I should be able to dump correctly formatted wiki markup into it and in return it generates a (mostly) consistent output no matter what device or skin is being used to view the page.
On top of that, this redesign doesn't even accomplish the most basic things it claims to accomplish. Just look at mw:File:Header Logo reconfiguration - commons pt - GIF.gif, and pay attention to the Mona Lisa's hands. The "compact" header redesign literally uses objectively more screen space than the "big" header! And there's a ton of unused whitespace added as well, if I had ten minutes to fiddle with the CSS, I could easily fix it so it's actually smaller than the original header, and it would look way better. I mean, I don't actually understand why the branding needs to scroll with you; if they just had the strip of user links set to sticky instead of an enormous header and all of the attached whitespace, I'd actually be pretty excited because that's a far more useful thing to have access to.
Finally, I also want to point out that, starting with last year's move to iPads having a separate version of iOS, Apple set the default behavior on iPadOS Safari to be to request desktop versions of websites, not the mobile ones. Considering Apple has been aggressively pushing iPads as content creator devices these past few years, this is pretty much an admission from the company that basically designed the modern mobile web that the mobile web is inadequate for the tasks that content creators want to perform. That pretty much says it all, far better than I could. Nathan2055talk - contribs 00:19, 28 September 2020 (UTC)
Right, I'm willing to agree that these changes are focused on the reader rather than the contributor. (Vector had some of those changes too, like moving the top-page portlets to a [sometimes disappearing] dropdown.) And I agree that some of them are pointed a slightly-wrong way for what are the right reasons. I do think if you have specific criticisms of the current design you should voice them somewhere (here? doubtful. maybe mediawikiwiki:Talk:Reading/Web/Desktop Improvements. phab: otherwise perhaps).

However, I do not agree or think that desktop users are being treated as second-class citizens by WMF, especially given the perpetual angst over increasing our contributor-base. (Twitter had another redesign? :) That it's been 10 years since a redesign is something of a miracle; I'm sure we can find some images of the top X websites and see a significant difference elsewhere, whereas we're making these tiny steps that do seem to agree with those bolder than our lovable WMF (the fixed width particularly, mobile-design first approach to reading). (Maybe some day the WMF won't need to maintain Minerva to the same degree or work so hard on e.g. "advanced mobile contributions" that they sank time into last year. That might be nice. So yes, making one codebase for mobile and desktop makes a lot of sense.)

I do think there's probably a future, as with Timeless, that we start taking the blank space left by the fixed width and filling it. Timeless went the more passive direction with another editing sidebar on the right, but I've seen discussion that would put images and infoboxes and the table of contents in those places. --Izno (talk) 16:06, 28 September 2020 (UTC)

Yeah, the hamburger menu is stupid, but introducing a maximum page width is definitely a good thing readability-wise. On the laptop I normally use to edit the text is longer than the optimal number but it’s not too bad. On my phone the text is tiny (which is to be expected when you’re using Vector on a small screen) but it’s a good length. Trying to read an article on a desktop screen, however, is a mess. —pythoncoder (talk | contribs) 20:10, 28 September 2020 (UTC)
Guy Macon, There's several problems with making things extensively configurable. They make the software more complicated, so it's harder to build and more likely to have bugs. If there's N configuration options (assuming they're binary options), there's N^2 combinations, and you have to make sure none of them have weird interactions.
From the user perspective, adding more options makes the software more complicated to use. Every configuration option is just another chance for somebody to mis-configure things. We've already got 9 tabs of options under Special:Preferences. Most of them I don't even know what they do, and many interact in non-obvious ways. -- RoySmith (talk) 23:22, 25 September 2020 (UTC)
  • I feel bad for the WMF team implementing this; UI changes always take some getting used to and thus generate initial resistance, and when you combine that with Wikipedia's consensus model, well, that's how we've gotten stuck with the status quo for a decade and become miles behind all the other major sites on the internet (who, contrary to the assertion above, typically have no qualms about the "get used to it" mode of rolling out UI updates).
My advice for the WMF is just to continue actively soliciting feedback and to take on board the feedback that's useful, so that people have as little to complain about as possible.
And my advice to Wikipedians who want to leave constructive feedback is to do so at MW, where the temperature is cooler and it's possible to segment the discussion by feature (and which the desktop improvements team is presumably monitoring more closely than this board). {{u|Sdkb}} talk 16:53, 25 September 2020 (UTC)
Concur. The current design and interface is way behind what it should be in 2020. Time for Wikipedia to catch up. ProcrastinatingReader (talk) 12:47, 29 September 2020 (UTC)
  • An alternative implementation of these changes that simply added a new skin, Vector2020 or something, would leave current users the option to keep what they have or actively switch to the updated version. My guess is that a greater number would stick with, or even switch to, a VectorClassic theme than use cologneblue - less than 3k total users, according to this 2016 phabricator comment. I also think it would be cool to have a new skin contest every few years to generate new ideas, not replace the default, with the winner added to the user preferences options. Dialectric (talk) 00:25, 26 September 2020 (UTC)
    The problem is of course is that most (if not all) custom gadgets are ski-dependent, which makes switching between skins really painful for active users (who are most likely to use the gadgets).--Ymblanter (talk) 06:14, 26 September 2020 (UTC)
    Do we have stats on gadget usage? I don't doubt that power users make use of them, and am interested in seeing which are the most popular. I don't think I have ever used any gadgets, but given that they are made up of css and javascript, modifying the most popular gadgets to work with the 2-3 most popular skins doesn't seem like too much of a barrier to new skins. The idea I floated, of a Vector2020 vs VectorClassic, would have a lot of overlapping css code.Dialectric (talk) 21:20, 27 September 2020 (UTC)
    Special:GadgetUsage, but that includes all users rather than active users, and obviously excludes non-gadget scripts and styling. I am pretty sure we have a database report that hits the same points with active user count included somewhere. You have most assuredly used things qualified as gadgets based on the fact we have a number of default gadgets (which is good that you didn't realize they were gadgets :). --Izno (talk) 15:44, 28 September 2020 (UTC)
    @Ymblanter: I'm not 100%, but I'm pretty sure that, assuming "Vector2020" was forked off of Vector and used similarly designed elements, most gadgets would still work fine with both skins. We hit this same issue with the Monobook to Vector transition, which IIRC was easily handled by simply making the backends of the two as similar as possible. Even now, almost all gadgets that advertise support for just Monobook or just Vector usually work fine in the other skin. It's just the "weird" skins like CologneBlue that wind up breaking gadgets because they change so many of the UI elements/code. And, just looking at what was proposed here, I don't really see any changes that would massively break gadgets. Everything in general is grouped the same as it's always been, it's just been moved to different places. Assuming the WMF hasn't done some tremendously unorthodox refactoring work behind the scenes to make these changes possible, I imagine that 95% of gadgets would work fine in either Vector or Vector2020 (after all, if they weren't, then the WMF would be shipping a massively breaking change to most people's workflows, and then we'd have a way, way bigger problem than just some minor interface changes). Nathan2055talk - contribs 00:28, 28 September 2020 (UTC)
    WMF has already made a few gadget-breaking changes to the HTML for which we were dutifully warned. That said, most gadget authors have figured out they should design for more than 1 skin and where they haven't, editors like me have complained for nicer integration with their favored skin (Timeless). :) (Now if only the Twinkle interface could come into the 21st century; maybe the deployment of Vue.js will get us there.) --Izno (talk) 15:48, 28 September 2020 (UTC)
    The decision-making process for the current implementation of Vector20 was at phab:T234907. I've discussed offline and the decision has caused some spaghetti in the skin, so I'm sure WMF will eventually come around to having an actual new skin....

    I would guess most people who hadn't made an alternative skin selection would have been dropped into Vector 20 versus "I want Vector". There is a lack of an active "I want the 'default'" skin selection (whatever that might be at the time); that's ancient phab:T22553. --Izno (talk) 15:37, 28 September 2020 (UTC)

    They said they are keeping old Vector as a preference option for logged-in users, but it's to be renamed "Legacy Vector". So you do get choice, Guy Macon and Dialectric, though it’s all-or-nothing: can’t turn on collapsible sidebar and disable max-width at the same time. The new Vector2 (my preferred term) or Vector2020 (per Dialectric and Nathan2055) is to be called ... wait for it ... "Vector". I suggested this is a problem for communication, documentation, etc. but you can guess Olga's response. Blah blah we think our way is best. (Speaking as someone who's had to try explaining to end-users that the Edge blue e is different from the IE blue e, and that Chromium-based "Edge" is completely different from EdgeHTML-based Edge which is now "Legacy Edge", this is not as minor an issue as you might think. One solution is to call the new one "Edgium", but sadly that didn’t catch on.) Pelagic ( messages ) – (05:34 Fri 16, AEST) 19:34, 15 October 2020 (UTC)

Feedback requested on proposed changes to the WMF bylaws

The board of trustees is proposing changes to the WMF bylaws. You can view the call for feedback for more information. — Wug·a·po·des​ 03:44, 16 October 2020 (UTC)

Quick link to the list of proposed changes
  • Substantive changes include:
  1. Change in number of trustees, to a non-required target of 16
  2. Community and affiliate positions merged
  3. 8 Community roles, but the majority of the Board is not required to be community-based (in case of resignations etc)
  4. These positions to be filled by a not fully stated “community nomination process” determined by the Board, rather than the current ratification of community vote and the affiliate process. Nosebagbear (talk) 19:19, 19 October 2020 (UTC)

Wikitree

Is Wikitree a part of Wikipedia? — Preceding unsigned comment added by 2001:8003:2422:C900:2194:A827:975E:F3F6 (talk) 11:45, 20 October 2020 (UTC)

No. --Izno (talk) 13:36, 20 October 2020 (UTC)
See WikiTree. — GhostInTheMachine talk to me 14:34, 20 October 2020 (UTC)

Update: Scheduled shutdown of Wikidata descriptions on EnWiki

Background: Some time ago some Foundation staff thought Wikidata item-descriptions could be used as convenient short-descriptions for Wikipedia articles. They began displaying them in several locations on our articles or as descriptor/links to the articles. Several concerns arose when the community noticed and examined the practice, resulting in consensus against using Wikidata on/for our articles in this fashion. (Link to one of several discussions.) Several editors and I discussed collaborative resolution with staff. The Foundation created a new feature allowing us to create and manage these descriptions locally (see WikiProject Short descriptions). The Foundation wanted to avoid suddenly blanking all descriptions, so Wikidata descriptions continued to appear when no local description is present. The Foundation agreed to shut complete the shutoff of Wikidata descriptions once we had created approximately 2 million local descriptions.[3]

I am happy to announce there are now 2,250,000 mainspace pages with short descriptions - approximately 1,939,000 articles, approximately 312,000 disambiguation pages, plus thousands of other assorted pages in and out of mainspace (portals, help pages, drafts, redirects, project pages etc).

Almost two months ago I created Phabricator task T248457 for the WMF to implement the agreed shut-off. The task appears to have slipped through the cracks unnoticed/forgotten. Ping DannyH (WMF) who gave the original shutoff commitment (or any Liaison or other staff) to get the ball rolling on this. I am eager to celebrate successful collaboration and resolution on this issue. Thanx. Alsee (talk) 13:39, 15 May 2020 (UTC)

In case it is unclear from the above, the WMF committed to disabling short description Wikidata fallbacks: the WMF plan is to switch from a Wikidata-fallback to full enwiki control when there are 2 million non-blank short descriptions on enwiki (quoting DannyH (WMF) from the discussion linked above). They have not done so yet, even though en.WP has exceeded that criterion by over 10%. – Jonesey95 (talk) 16:53, 15 May 2020 (UTC)
Alsee, Thank you for the update. —¿philoserf? (talk) 17:12, 15 May 2020 (UTC)
It's worth reminding DannyH (WMF) of his statement at the time: "the WMF plan is to switch from a Wikidata-fallback to full enwiki control when there are 2 million non-blank short descriptions on enwiki". Nevertheless, we are going to have to wait for somebody to triage phab:T248457 and then get it assigned and finally get it implemented. There's no timescale for that, nor is there any likelihood that anyone other than DannyH will feel under any obligation to do the job. I can only suggest that everyone who thinks that it's important for staff to respect their promises to the community, should post on that phabricator thread to urge some progress on implementation. --RexxS (talk) 00:05, 16 May 2020 (UTC)
  • It would be good to see enwp control. We have a large number of editors working and we can do this. Wikidata is a super fine project, there is no doubt on it. However several things continue to disturb me: example, one Wikipedia article has an IMDb or Twitter external link or some other article value being called from Wikidata. Now you go to Wikidata, and find they are linking back (imported from/Reference) to English Wikipedia. This is confusing and make things circular (note: this particular topic is not in scope in this discussion, and we may discuss somewhere else if you want). Coming back to short descriptions, if we really need short descriptions, we should do it following our own guidelines and thoughts, and not from another project, specially where generic item descriptions are mass-created using QuickStatements and other tools. Regards. --Titodutta (talk) 00:49, 16 May 2020 (UTC)
    @Titodutta: one of the first features I implemented in Module:WikidataIB was to filter out values that were unsourced or referenced only to Wikipedia, That facility has been available for four years now, so there's no excuse for having the feedback loops you describe. If you let me know whenever you find those sort of problems, I'll fix them. --RexxS (talk) 01:20, 16 May 2020 (UTC)
    • I did not prepare a list. I'll create one on the go now. Anyway, a couple of (not the best) examples I can find now: Jan_Schmid external links "FIS Nordic combined skier ID" is on Wikidata, Wikidata says it is imported from English Wikipedia. Similarly "EL" section Official website at WePay. It might be a good idea to directly link, than going to Wikidata and learn it was imported from Wikipedia. --Titodutta (talk) 02:04, 16 May 2020 (UTC)
      Okay - that shows up because Zyxw used #property which doesn't filter. I can fix it by using a Wikidata call, but are you sure you need references for an identifier? An identifier will link to the entry in the relevant database, so following it will verify the id almost always. I don't usually worry about sources for images and their captions for the same reason. Anyway, I'll have a look at any list you want me to. --RexxS (talk) 02:35, 16 May 2020 (UTC)
      First, this is unrelated to the WMF so perhaps discussion should move elsewhere. The last Wikidata RFC was a long time ago, a lot of issues are unresolved, and I would welcome some clarity. If anyone gets the ball rolling on that, please ping me with the location. RexxS: On a personal note I've noticed some of your comments elsewhere to the Foundation, particularly in relation to Wikidata descriptions, and I wanted to express my appreciation. Back to the immediate topic, it sounds like you're considering a "fix" of filtering out values that are sourced from Wikipedia. In this case, I don't think that was the concern. If you recheck Titodutta's comment they didn't want the value gone. They were suggesting that the info should be "directly link"ed from Wikipedia, rather than coming through Wikidata. See my diff. I want to know whether or not the community wants edits like that applied broadly. I think it's an improvement, I believe(?) that is what Titodutta was suggesting, but we're in consensus-limbo on it. Alsee (talk) 11:11, 17 May 2020 (UTC)
  • It's truly a pity to have wasted so much efforts adding clutter to articles. Nemo 14:21, 17 May 2020 (UTC)
    • If you mean the short descriptions are clutter then I very strongly disagree - they're extremely useful and the big shame is that they're going to disappear from the majority of articles if wikidata fallback is turned off (if it must be turned off, waiting until local coverage is close to 100% would achieve the goal without the any unnecessary accessibility issues). If you mean that the local (vs soured from WikiData) descriptions are clutter, then I'm not sure I agree - they're certainly unnecessary duplication of effort but a single line in the page source isn't really what I'd call "clutter". Thryduulf (talk) 14:27, 17 May 2020 (UTC)
      I wouldn't mind relying on local short descriptions. A few days ago, someone changed wikidata descriptions to label iCarly seasons as "child pornography" and "isis propoganda", but I only noticed because they bragged on Twitter. Changes to local short descriptions will show up in people's watchlists. Schazjmd (talk) 22:52, 20 May 2020 (UTC)
      Can't we just make wikidata changes show up on watchlists on an opt-in basis? Enterprisey (talk!) 04:07, 11 June 2020 (UTC)
      Can't wikidata get some form of ClueBot running to revert vandalism like that? It's such a big problem. {{u|Sdkb}} talk 04:41, 11 June 2020 (UTC)
  • I wasn't involved in the prior discussions about Short Descriptions, so I don't have a well-formed opinion about them, but since this is the WMF page, I think the scope of the discussion here ought to be limited to encouraging the WMF to abide by the agreed-upon community consensus, not challenging that consensus, which inappropriately muddles things. As a new page, we need to set down some strong norms about what is okay to post here. That said, there does seem to be a fair amount of sentiment questioning where we are at with short descriptions, so I think it might be appropriate to open up a conversation at a more appropriate venue to take stock of where we are at with short descriptions and to potentially reassess whether we ought to go ahead with using 2 million as the point to cut off Wikidata imports. One piece of data that I can't resist sharing (despite what I just said above) since it might help frame the discussion is this: of the 43,000 Level 5 Vital Articles (example of the kinds of pages in that group here), currently 19,000 (44%) have no short description. {{u|Sdkb}} talk 19:43, 20 May 2020 (UTC)
    Sdkb we're all figuring on the scope of this page together. For what it's worth: My concept when I created this page, and according to the notes at the top, this is the correct page for discussing and forming consensus on the relevant topics. Therefore this would be the correct place to consider a new/different consensus. That said, I was also a central participant in the previous discussions. The consensus was actually to eliminate the Wikidata descriptions immediately, effectively blanking everything while we rebuilt local descriptions. Waiting for 2 million descriptions before shutoff was a compromise with the WMF, insofar as it wasn't particularly unreasonable and no one pressed the issue any further. At that time not shutting off wikidata, or waiting for "close to 100%" local descriptions, were pretty well WP:SNOWy territory. I expect that remains true today. Alsee (talk) 22:27, 20 May 2020 (UTC)
    Alsee, that makes sense. I'm concerned a little, though, that having too many conversations directly on this page (given how sprawly they can often get) might make it harder for WMF folks (who are understandably very busy) to follow along with it all. For some issues, it may be better to discuss them elsewhere as a sort of staging area, and then to come here once they're decided enough that we can present a more straightforward "this is what the community thinks" message. (We'd of course link to the full discussion; the idea isn't to hide anything, but just to keep this page more readable.) {{u|Sdkb}} talk 08:03, 24 May 2020 (UTC)

Ping Whatamidoing (WMF). The Foundation agreed that this would be done once we hit two million descriptions. There has been no effective response on phabricator T248457 since March 25, and DannyH (WMF) hasn't responded to the ping three weeks ago. Can you help get a response on this? Thanx. Alsee (talk) 23:13, 4 June 2020 (UTC)

We don't appear to be having much luck with this do we. Any ideas for next steps?©Geni (talk) 16:38, 10 June 2020 (UTC)
Given that Danny is active, and his line manager is probably Katherine Maher, probably suck it up. And stop adding short descriptions. Unless someone can get her attention on Twitter. I do not think she is paying any attention to what is happening on Wikiprojects. I am not going to resign an admin bit over it.--Ymblanter (talk) 18:12, 10 June 2020 (UTC)
And do not forget to take it with the candidates on the Board elections which are going to happen next year. Some of you (not me) may even try to check with the candidates from affiliates.--Ymblanter (talk) 18:15, 10 June 2020 (UTC)
One option is to effectively shut off Wikidata descriptions from our end. Right now there is a filter in place to prevent us from setting a description that is blank or only punctuation. We could modify {{short description}} to check if the value is blank, and then fill in some non-blank value of our choosing. (Perhaps "No description yet.") Then we can do a bot run to make sure {{short description}} is present on every article.
Another option (and we can proceed with both options simultaneously) is to draft a message to Executive Director Katherine Maher and submit it as a formal consensus message from the EnWiki community. My concept would be to start by expressing serious community concern at the poor relationship, poor alignment, and poor level of partnership between the Foundation and the community. I'd suggest phrasing it like 'perhaps you are unaware of these systemic problems', as I suspect staff aren't reporting these issues up to the Director. Then we briefly lay out the Short Description case, that Wikidata descriptions were deployed without consulting the community, that there was a commitment to shut off Wikidata descriptions once we created 2 million descriptions, and then lay out how long the Phab task has been ignored, how long the manager who made the agreement has been non-responsive, and how long the liaison has been non-responsive. (Note: The liaison was only pinged 6 days ago, which is not good but also not badly excessive yet. However those figure will presumably be higher if/when we deliver the message.) Then I would close by requesting her help improving Foundation-engagement, and that we have other specific concerns we hope to be able to bring to her attention. I tend to procrastinate, but I'd be willing to draft it and open the proposal if there's support for this route. (Ping me for quickest action.) I have other specific issues that I want raise for consensus-discussion, but I think we should start with this one simple item. Asking the Director to follow through on an existing Foundation-commitment should be comparatively easy, and it will hopefully establish the path for trying to resolve other issues. Alsee (talk) 20:45, 10 June 2020 (UTC)
I pinged DannyH on 16 May in this very thread as he's the one responsible for keeping the promise he made, so he has no excuse for not having enough time. I can't help but wonder whether we could take the unusual step of discussing the issue on Jimbo's talk page first and asking for his help and advice. That would at least make sure that we try all of the avenues available to us before starting a formal complaint to the CEO. It would also perhaps raise the profile of the problems we've encountered because of the number of talk page watchers there. I almost made that very post there today, but I thought it would be reasonable to leave it a few days yet, just in case we do get a reply from WAID as she was only pinged a few days ago. --RexxS (talk) 23:45, 10 June 2020 (UTC)
The end of the fiscal year is always a busy time of year for him. He and I are usually in a meeting together on Mondays; I'll try to ask him about this the next time I see him. That may be more effective right now than asynchronous communication. Whatamidoing (WMF) (talk) 17:39, 11 June 2020 (UTC)
thanks WAID.--Ymblanter (talk) 17:57, 11 June 2020 (UTC)
@Whatamidoing (WMF): It's now been more than a week. * Pppery * it has begun... 15:23, 21 June 2020 (UTC)

Hi everyone, I'd like to let you know that we are currently working on plans to make the switch to entirely using local short descriptions on English Wikipedia, without the Wikidata fallback. We really appreciate that people have put in so much time and work populating the local descriptions.

I don't have an estimate yet for when we expect the work to happen, because there are a few use cases that we need to figure out. Right now, the Wikipedia apps allow people to write and edit short descriptions on their phone, and that's a popular feature that helps readers who may not typically be Wikipedia editors to contribute new descriptions, and to keep existing descriptions accurate. We want that feature to only use the local descriptions now, so we're going to work on that. We also want to make sure that the descriptions work properly when they're dynamically generated from an infobox, as Template:Infobox settlement currently does.

Engineers are talking about this now, and you'll see activity on the Phabricator ticket. I can let you know when we have a stronger idea of how and when the changes are going to be made.

One thing that I'd like to ask about is the point that Sdkb brought up above: how do we get from ~2 million descriptions to ~6 million (minus disambiguations and lists)? When we make this switch, descriptions are going to "disappear" on a lot of articles, and as Sdkb points out, that will include some important articles. I know that some people have been using automated tools to import descriptions from Wikidata, and I'd like to know if folks plan to continue doing that, and if we can help. I'm interested to know your thoughts. — DannyH (WMF) (talk) 21:46, 22 June 2020 (UTC)

@DannyH (WMF): thanks for your announcement, it is very welcome. I'm sure we will all be happy to hear your estimate for when the work will happen as soon as you have that information.
I'd like to suggest that the solutions to the issues you raise could lie in a change of mindset. When you consider the short description text that accompanies searches on mobile and acts as a subtitle on the app, it may be helpful to forget about Wikidata and to think about short description text as being sourced authoritatively from the enwiki short descriptions; then to refocus your efforts into finding ways of making the enwiki short descriptions as comprehensive as possible. These are some examples that come to mind:
  • Support a proposal to import missing enwiki short descriptions from Wikidata on a one-off bot run. This won't be easy to generate support for, but it would represent a way of closing the old chapter and starting a new one.
  • Redirect mobile apps that allow editing of short descriptions to creating enwiki short descriptions. Worry about getting those descriptions into Wikidata as a secondary issue.
  • Support moves to allow bots to update the Wikidata description field periodically to import enwiki short descriptions as the authoritative text. There will be resistance from Wikidatans but it should be possible to offer a good case for doing it.
I know you'll think "that's what I'm already proposing", but I wanted you to consider principally the focus of where the short descriptions come from. While you think about the issue as an uneasy hybrid between enwiki and Wikidata, you can't hit the targets you want. If you embrace the concept that the authoritative text resides on enwiki, you'll mobilise the large workforce on enwiki (who have already done so much amazing work) to continue to improve and expand the coverage of enwiki short descriptions. Having that sense of ownership of our content is fundamental to keeping work going on it. --RexxS (talk) 22:35, 22 June 2020 (UTC)
RexxS: Well, that is still what I'm already proposing. :) We are now thinking about enwiki as the authoritative text for English short descriptions, and with that as the focus, we want to help to get descriptions on those x-million more enwiki articles. I think we're on the same page. — DannyH (WMF) (talk) 05:58, 23 June 2020 (UTC)
that's a popular feature that helps readers who may not typically be Wikipedia editors to contribute new descriptions, and to keep existing descriptions accurate Well, it is also a feature that turns existing descriptions into inaccurate ones and allows people to create new inaccurate ones where no description existed. This seems to be common for Indian caste articles, where glorification and denigration is the name of the game, and it is difficult to track. - Sitush (talk) 09:27, 29 June 2020 (UTC)
-
@DannyH (WMF) How do we get from 2M descriptions to 6M? Make them visible on the article page in desktop web and mobile web. People won’t edit what they can’t see. Once they get used to seeing the shortdesc on good articles, they’ll want to add them to others.
Perhaps, as Alsee suggested, display "No description yet". But now that we have way more than a critical mass of articles with local descriptions, that mightn’t be necessary.
I know the en-wp community tends to be resistant to changes that are opt-out rather than opt-in. But if we can get consensus on this, will the Foundation support us?
Aside: another team at W?F is looking at simple structured tasks to engage new users, short descriptions could be a good fit for that.
Pelagic ( messages ) Z – (12:19 Sat 04, AEST) 02:19, 4 July 2020 (UTC)
Instead of backsliding, and playing for time, if WMF actually did what they said they would and shut down the displays of Wikidata descriptions, now that we have basically paid up on the extortion, it might encourage Wikipedians to add more short descriptions. · · · Peter Southwood (talk): 13:04, 8 July 2020 (UTC)
@Pelagic: The worst part is that some non-W?F editors literally implemented all of the features that W?F keeps saying they'll "get around to adding on desktop" in the short description helper gadget. It displays short descriptions at the top of the page under the title; tells whether they're defined locally, being pulled from Wikidata, or were generated automatically by an infobox or similar template (or if they don't exist in any of those places, which is pretty rare at this point); and it gives options to easily and quickly edit them and import/export them from Wikidata. Literally all the W?F needs to do is flip on that gadget by default and pretty much everyone's problems would be solved. Actually, the community could just flip on that gadget by default: setting a gadget as default doesn't require Foundation action and could just be done by an interface admin after getting consensus. Nathan2055talk - contribs 22:38, 8 July 2020 (UTC)
Nathan2055, I don't think the gadget actually does all of those things, though it is a great gadget. · · · Peter Southwood (talk): 12:55, 9 July 2020 (UTC)
@DannyH (WMF):: I actually don't think these problems are quite as difficult to solve as they sound. Our own short description helper gadget already handles displaying and editing locally defined, pulled from Wikidata, and infobox-generated descriptions fine, and allows for one-click importing and exporting between Wikidata and enwiki. That gadget could be flipped on by default for logged-in editors, with a MediaWiki extension-based solution eventually adding a version of it for logged out users as well. As for handling descriptions "disappearing" from articles that only have one defined on Wikidata, I think the easiest solution to that is adding an optional imported=yes parameter to {{short description}}, having that parameter stick the pages in a Category:Pages with descriptions automatically imported from Wikidata category or something similar, and then having a single-run bot go through and import in the Wikidata descriptions for every article which doesn't have one defined locally. Then we can just work through that category and verify that all the descriptions look acceptable. I certainly think that's a better choice than just leaving automatic Wikidata population on, because we've already seen just how ridiculously prone to abuse that system is. It was a good idea in theory, but I think we have enough evidence at this point to say that no project should be displaying data stored on another project that hasn't been checked manually by a human first. It's just too dangerous. Nathan2055talk - contribs 22:54, 8 July 2020 (UTC)
@Nathan2055:, If I remember correctly this is one of the proposals that was specifically turned down previously. Not to say you cannot propose it again, but I fear it would still face opposition on the basis that the descriptions in Wikidata should be checked by a Wikipedia editor before inporting them, and that the person who imports a description from Wikidata is personally responsible for ensuring that it is, if not necessarily very good, at least not very bad. A semi-automated tool to run through a list of pages lacking a short description, using the helper would be OK, as an editor would be checking before importing, at least in theory, and can be held accountable for any harm done due to lack of diligence. I might use such a tool myself. · · · Peter Southwood (talk): 11:23, 16 July 2020 (UTC)
  • Perhaps the Shortdesc helper should become a default feature for all users (or at least all registered users); I've noticed that my adding short descriptions to articles has skyrocketed since then, and I believe that the acceleration of adding short descriptions to articles will far outweigh the possible increase in vandalism. – John M Wolfson (talk • contribs) 03:00, 16 July 2020 (UTC)
    I agree that higher visibility could greatly accelerate the addition of short descriptions. Making the helper a default feature would make short descriptions more visible, so it could help accelerate addition, if it does not start another flare-up of the squabble over whether they should exist in the first place. Unfortunately, the history of how they were basically forced onto Wikipedia will be dredged up and revisited, both by the people who opposed it in the first place, and probably also by a whole batch of people who have managed to remain unaware of the details of that dispute, and possibly even unaware of the existence of short descriptions. Could be worth a try. This would call for an centralised RfC as it would affect everybody, and as I was heavily involved in the original dispute, I would prefer not to draft it myself. My own feeling is that it is time for WMF to display a little good faith and do what they promised. If and when that happens I am willing to support such a proposal. If it does not happen, that failure do deliver on a promise will be used as a weapon to resist making the gadget a default, which could delay or prevent long term predominance of articles having a short description, which to my mind would be a lose-lose result.· · · Peter Southwood (talk): 10:57, 16 July 2020 (UTC)
    Given that installing the gadget increased my own short description adding probably around fivefold, I think it should be the default for registered users, which would accelerate the process of making short descriptions near universal. I can draft an RfC to that effect if you'd like, seeing as it might be inevitable. I wonder what the hold up with the Wikidata-description deprecation is given that more than 2 million mainspace articles (albeit including disambiguation pages) that have them, which was the benchmark as I recall. – John M Wolfson (talk • contribs) 08:42, 17 July 2020 (UTC)
As far as WMF Product is concerned, we'd be happy for the short descriptions to have more visibility on desktop or mobile, either opt-in or not. I agree that being able to see them would help to motivate people to add and update them. People were so adamant in previous discussions about not displaying them, that we didn't know if having them 100% hosted on enwiki would make a difference. It's good to know that's on the table, and I'd be happy to talk more about how to get to consensus, and how we can help.
To respond to the questions above about whether we are doing what we've promised, work on the change has begun — if you're into Phabricator, you can see the progress that's being made on this ticket. — DannyH (WMF) (talk) 18:50, 21 July 2020 (UTC)
While we wait for the squabbling at phabricator about avoiding doing something they are ethically obliged to do to finish, perhaps we should do a bot run to add a short description to all articles where a local short description does not already exist, putting them into a maintenance category and with content stating that they have no short description yet, but anyone can help by adding a suitable short description. This would use existing code to discontinue the use of Wikidata content and make the missing descriptions more visible and findable. Then it would no longer matter how long the issue is avoided by those who want to push Wikidata content into English Wikipedia against community consensus and against the word of WMF that it would be stopped. Cheers, · · · Peter Southwood (talk): 11:04, 30 July 2020 (UTC)
That sounds like a great idea in theory, but what short description would be displayed in practice? I believe that WMF has technical measures in place to prevent us from overriding an inappropriate or vandalised Wikidata description with a blank one. Certes (talk) 11:43, 30 July 2020 (UTC)
Something like:"This article needs a short description - Click here if you think you can help" The link should take the editor to an explanation of what is needed in a short description, and after reading it they could click a button indicating they understand and will comply with the requirements, which would skip this stage in future and open the short description gadget on the page they clicked from, which should display the usual options, including copying the SD from Wikidata if it is good enough. This cannot reasonably be described as an inappropriate or vandalised short description, nor a blank one. It would serve the purposes of Wikipedia and incidentally also WMF in a way that maximises usefulness to all, and does no harm to Wikidata, so if WMF were to override it it would be strong evidence of unethical and counterproductive behaviour on their part. Or have I missed something? Logged out users would unfortunately have to go through the instructions every time, or maybe a cookie could help here. · · · Peter Southwood (talk): 12:43, 30 July 2020 (UTC)

Those editors who have encouraged the adding of missing short descriptions by bot and user-assisted scripts might like to have a look at the miniproject which is currently being planned at Wikipedia talk:WikiProject Short descriptions#Bot proposal to create short descriptions from scratch, for articles requiring one. Given the sensitivities of some editors to the importation of Wikidata descriptions, we will create new SDs for articles that need them from local information only, without pulling anything from Wikidata. Contributors are welcome. MichaelMaggs (talk) 16:56, 14 August 2020 (UTC)

Phab:T248457 has now been triaged and classified as "Later". Will Wikidata descriptions still be removed as promised, or has the WMF's half of the bargain been postponed indefinitely? Certes (talk) 15:17, 2 September 2020 (UTC)

Clarification from the WMF folks would be appreciated - are you going to do this on your end, or do we need to set up a bot to do this ourselves? Tazerdadog (talk) 23:18, 2 September 2020 (UTC)

Summary

So, in summary:

  • The WMF implemented, years ago, the addition of Wikidata descriptions to enwiki articles without informing enwiki of this, without providing any way to monitor or overrule this, ...
  • After an RfC which overwhelmingly opposed this, they promised to turn this off, but did this only for some uses and not for all
  • When this was found out, the opposition was reaffirmed, but the WMF then, instead of finally keeping their original promise, haggled for a compromise based on rather fanciful data, and got us to agree to add 2 million descriptions, and only then they would turn it off.
  • In March, this goal was achieved, and the WMF asked to keep their side of the bargain. It then turned out that while many people on enwiki had worked hard to keep our side of the bargain, not a single thing had been done at the WMF side to keep theirs.
  • Some six months later (and three months after it was promised that we would see "work being done" at the phabricator ticket), there is zero progress, and the task is in fact scheduled for "later" and not assigned to anyone at the WMF.

Is this somewhat correct? And if so, why is this in any way acceptable? Fram (talk) 08:38, 4 September 2020 (UTC)

Pinging DannyH (WMF). What steps can the volunteer community here at en.WP take to ensure that WMF staff are able to keep the commitment that you made? – Jonesey95 (talk) 16:08, 4 September 2020 (UTC)
Hi, thanks for the ping — this is a misunderstanding based on ticket numbers. :) The ticket that Certes posted about a couple days ago is Phab:T248457 — that ticket was submitted by Alsee, and that's not the one that the developers are using. I mentioned above that the correct ticket is Phab:T256817, which is currently being worked on — you can click on some of the subtasks to see that discussion and work are happening on them today. I posted a link to the correct ticket number above on July 21st, but I didn't stress enough that it was a different ticket; I just linked the phrase "this ticket". Sorry that I didn't make that clear enough. I agree that we have promised to make this change happen, and we are working on making it happen. Let me know if you have more questions. Sorry about the mixup. — DannyH (WMF) (talk) 20:19, 4 September 2020 (UTC)
Thank you for the explanation, Danny. It's comforting to know that this is still a priority for the WMF. Certes (talk) 20:27, 4 September 2020 (UTC)
Off topic

DannyH (WMF) sorry to change the subject, but while you're here I wanted to give you an important update on the Talk Page project. A quick recap for you and everyone else: Back when the Flow prototype was being built, editors told the project manager that correct wikitext support was fundamental and necessary, and that the project could never be deployed without it. The project manager said he had no intention of fixing it, and cut off communication saying further discussion was a waste of time, and proceeded to build a system with needless wikitext corruption issues. Eventually I had to organize an effective Global Community Consensus across three wikis before the Foundation finally acknowledged there was a problem. You stepped in and did an excellent job running the Talk Page Consultation, genuinely listening to what we wanted. You cancelled the last phase of the consultation, and handed the project over to a new manager. That manager has essentially cloned Flow's back-end design problem. Instead of simply inserting the new comment into the page, he decided to needlessly translate everything through Parsoid before inserting the new comment, then retranslate the combined content back through Parsoid for saving. Again, like with Flow, this round-trip double-translation causes wikitext corruption to the page. Again, the manager has declared that he has no intention of fixing it. Again, the Foundation has terminated communication. I honestly can't understand why the Foundation becomes actively-hostile whenever we say "don't screw up wikitext". It's such a simple and basic requirement.
I thought you might want to look into this. I'm hoping you can avert an RFC against the new Talk Page Project. Alsee (talk) 23:28, 4 September 2020 (UTC)
@Alsee: I think you are exaggerating a bit here. The developers of DiscussionTools seem to care about edits using their tool not corrupting unrelated parts of the page. * Pppery * it has begun... 21:56, 5 September 2020 (UTC)
Hi Alsee: I'm working closely with Peter on this project, and I'm aware of your concerns about wikitext corruption. From what I recall from a few months ago, Peter asked you for examples of wikitext that you said were corrupted by the tool, and looked into the problems. Other active contributors appear to be satisfied with the team's progress on the tool; some folks on Meta are discussing it on Meta:Babel, with a lot of support. — DannyH (WMF) (talk) 20:40, 9 September 2020 (UTC)
So, instead of a ticket that is unassigned and "later", we have one that is unassigned and "blocked/waiting"... Still doesn't explain why nothing had been done on the WMF side in the years since their promise and while we were active keeping our side of the (WMF-forced) bargain. Looking at the underlying tickets, it seems that some initial activity in early August was the last that actually happened. Fram (talk) 07:05, 7 September 2020 (UTC)
Is there anything we can do to help unblock it or end its wait? Is the Android app board the best place for the ticket (or is it also in other work flows – I'm unfamiliar with Phab "boards")? Certes (talk) 09:14, 7 September 2020 (UTC)
One thing we as a community could do is to never again modify our behavior based upon any promise from the W?F, citing this example of them not keeping their promises. A would be interested in hearing about any other examples of unkept promises by the W?F. If any come to mind please drop me a note on my talk page. --Guy Macon (talk) 17:51, 7 September 2020 (UTC)
Guy Macon, I'm sure it is challenging to be a Wikimedia developer, but there are multiple examples of this phenomenon. Take ISBN magic links (please!). We sure have worked quite a bit, and continue to work, to transform ISBN magic links into ISBN templates after T145604 (follow links there for discussion) and a related en.WP RFC about magic links. Four years later, we're still waiting on WMF developers for the ability to turn off magic links here at en.WP. – Jonesey95 (talk) 04:07, 8 September 2020 (UTC)
I'm starting to see an underlying theme here. I'm sure we're all grateful to the WMF for providing a stable computing and comms platform and for being the legal body which a project with BLPs and other controversial content needs. The problems seem to start when the WMF imposes technical changes: ISBN must be a magic word; short descriptions must be imported; you will change to this text editor or that talk page format. If they are appropriate for and welcomed at some projects then by all means make them an option, possibly even the default with due notice. However, it should be a requirement of any breaking change that it either have community consensus or be easily turned off by local sysops where it is not wanted. We may have differences on other issues, such as the WMF's proposal to share Wikipedia's title and the UCoC, but making unwanted technical change optional would go a long way towards restoring the WMF's former status as a welcome partner. Certes (talk) 10:30, 8 September 2020 (UTC)
The problem is that that would mean that every technical change would result in two version going forwards which becomes a maintenance headache.©Geni (talk) 00:08, 10 September 2020 (UTC)
Certes, as problematic as the foundation can be. I don't think you have a clue how hard it is to develop this platform. Things you are saying are fun if there were 4000 developers working on all this. —TheDJ (talk • contribs) 07:39, 10 September 2020 (UTC)
According to phab:T257486 it's blocked because there isn't an API to allow editing local descriptions from the mobile app (they don't want users being able to edit descriptions but not able to see those descriptions) yet, but building that API seems to be currently being worked on. – Majavah talk · edits 05:59, 9 September 2020 (UTC)
What happens when the mobile app edits the description of a page which has a local short description? Do they edit the {{short description}} in the WP article, or the Wikidata description? If the latter then the problem they are trying to avoid already exists for two million articles, so it may be wise to disable app description editing anyway, which would unblock the fix. Certes (talk) 10:18, 9 September 2020 (UTC)

Hey all, I want to let you know that work is still continuing on this. I know that seeing something called "Blocked/waiting" seems disheartening, but in this case, that just means another team needs to do something before the first team can pick it back up. I've been assured that the platform team is working on their part this week, and then the Android team will be unblocked. This is taking a while, because we want to make sure that it's actually done correctly — that every place where someone can edit a short description, we're getting the old description from the correct place (English WP page) and the new description is added/edited in the right place (again, English WP page). I know that it's exciting to accuse the WMF of lying and betraying everyone, and I would be the last person to try to deny folks that particular form of entertainment. In this case, we made a promise that we are currently in the process of keeping. — DannyH (WMF) (talk) 17:39, 10 September 2020 (UTC)

Any reason why the work on this didn't start at the time of the promise? Apparently this isn't easy (considering that we are now 6 months since our part of the deal was done), so shouldn't have some planning, analysis, work ahead have been done? It almost looks as if everyone at the WMF was surprised that this needed to be done, and had to start working on this years too late. Surely that can't be true? And I guess Certes would like a reply to his post of 10:18 9 september directly above, which seems rather on point. I notice that Task 257488 only got someone assigned two days ago (well, it was assigned in July, then almost immediately declared "blocked/waiting", and just now assigned to someone else). This sudden revival is of course unrelated to this thread.
It's just that some of us are rather sick of still getting vandalized Wikidata descriptions in various enwiki displays. E.g. a few dating from at least 4 days ago and still active at the time of writing, some simply rather unprofessional (2020 New South Wales Rugby League gets the description "202p new South Wales"), some weird (Verghese Kurien, 600 pageviews per day, is "Indian founder of dairy-cooperative Amul. Atali buttely delicious amul", 2020 Saskatchewan general election gets "Photo of Current Premier of Saskatchewan -Scott Moe".
Or if you want really high-profile pages, take e.g. Karl Marx, with a vandalized description now since more than a day[4] (visible e.g. at the Commons infobox, not just an enwiki problem). Nalanda, world heritage site, vandalized description since almost 24 hours. BLP violations, like for Jacek Kurski, where the description of this politician/journalist was changed 22 hours ago to Polish politician and government propagandist.
To be fair, anti-vandalism at Wikidata sometimes does work. Sodapoppin, a BLP, had his alias "little genitalia man" removed a few days ago[5], after it had been added in December 2018... On the other hand, Baby Phat is still named AMIT KUMAR on Wikidata, since May 2020[6]: this has been copied to other languages through smart bots... It's a good thing that despite the exaggerated claims of having so many editors and views, very few people actually ever look at Wikidata. The only way most people come into contact with it is when it is being pushed into Commons or enwiki.
So perhaps the pressure we put on this is not just a desire to accuse the WMF of bringing on the end of the world, but also a genuine concern that this (descriptions, and more generally vandalism on Wikidata perpetuated to other, more visible sites) is still not being taken serious by the WMF, and that only pressure from groups like enwiki eventually gets some result, perhaps, someday. Fram (talk) 07:32, 11 September 2020 (UTC)
Just an FYI that work is currently being done to unblock the switch to only use local descriptions: [7][8]. Ryan Kaldari (WMF) (talk) 00:34, 18 September 2020 (UTC)

Current work

Hi all, there was some confusion in the conversation above about which Phabricator tickets you should look at if you want to follow along with the work being done. We've cleaned up the tickets so it's easier to follow now, and the easiest place to look is "T256817: Replace Wikidata descriptions on enwiki with local descriptions". If you click through the subtasks in that tree, you'll see that there are patches currently being worked on and reviewed right now. I hope that helps folks who are monitoring the progress. Please ping me if you've got questions, or something that you want to talk about. — DannyH (WMF) (talk) 19:44, 22 September 2020 (UTC)

It’s hard to see what's progressing with all the sub tasks in Phab, but I observe the following now. Joseph Henry Maiden (Q2583058) has "Anglo-Australian botanist (1859-1925)", "botaniste anglais", "australischer Botaniker". At w:en:Joseph Maiden I see "Missing article description (Add)" on desktop shortdesc helper, no desc on Timeless or mobile/Minerva search drop-down, nor in Related Articles from Margaret Flockton. Desc shows in iOS app at the head of the article, but not in search drop-down. For comparison, w:fr:Joseph Henry Maiden has "botaniste anglais" both below the title and in the search drop-down on mobile. Seems to be mostly turned off now for en. Would that reflect your understanding, DannyH? —Pelagic ( messages ) – (22:20 Thu 15, AEST) 12:20, 15 October 2020 (UTC)

Too late now, but ...

Wikidata descriptions generally aren't bad, maybe because few vandals discovered how much "fun" could be had there. The problem seems to be that lack of visibility meant problem descriptions didn’t get fixed as quickly as desired. With the luxury of hindsight, all this could have been avoided if:

  1. Changes to Wikidata descriptions were logged as revisions to the linked articles in the same language (perhaps a null edit with summary like "Description on Wikidata (Q93462772) changed from "..." to "..."). Then they would show in watchlists, recent changes, etc.
  2. Descriptions were displayed on articles for web platforms, not just search results and related-articles lists. Sure, search results are where they have great value as disambiguators, but being rendered at the top of every page would help readers notice problems.

The horse has bolted for w:en, but please, Danny (and for #1 maybe Lydia), for the sake of the larger non-English Wikipedias, could you consider those as potential improvements? —Pelagic ( messages ) – (21:04 Thu 15, AEST) 11:04, 15 October 2020 (UTC)

Hi Pelagic, Thanks for the ping! I am the right person for the first one. It is in fact already on my list of next things to ask my team to tackle. The ticket for it is at phab:T191831. --Lydia Pintscher (WMDE) (talk) 12:01, 15 October 2020 (UTC)
Thanks, Lydia Pintscher (WMDE), that's great to know. I found Phab:T257588 "Improve the integration of description and label fields with other Wikimedia projects" but that seems more general. Pelagic ( messages ) – (19:47 Fri 16, AEST) 09:47, 16 October 2020 (UTC)
Pelagic extensive previous discussions have made it clear that the points you list would not be sufficient to address the problems or wikidata-item-descriptions acceptable. It never made sense in the first place to try to store language-local content remotely on wikidata. Alsee (talk) 10:08, 16 October 2020 (UTC)

Current status

Hi all: I believe that now we're only showing enwiki-hosted descriptions on English WP, and not pulling from Wikidata at all. This works for me on the app article pages and search results, on the mobile search results, and in the Visual Editor link modal. One thing that's pending is that adding new descriptions on the iOS app saves to Wikidata and not to English WP right now, so you don't see the description that you just tried to add — this should be fixed in the next app update. Other than that, I believe that the change is now working everywhere. Does anyone see something that I've missed? (ping Pelagic, who was looking at it a couple weeks ago.) — DannyH (WMF) (talk) 23:38, 2 November 2020 (UTC)

Yes, Danny, I see that the iOS app now shows the w:en description. (E.g. for koala c.f. koala (Q36101), the app says "An arboreal herbivorous ...".) – without updating the app, still on 6.6.2 (1745).
"+ Add article description" only shows if there is neither a shortdesc magic word / template nor a wikidata description. Perhaps it should create both? (Wikidata might have their own ideas about the great unwashed body of app users creating descriptions having initial capitals, but *shrug* ...)
Good to know this is almost finished. Now that English Wikipedia has sovereignty over the descriptions, I'd like to see them displayed on Desktop Web (without requiring users opt in to the gadget or some custom script/CSS). Is there any plan for a per-wiki config that can do this, if a community agreed they want to turn it on?
— Pelagic ( messages ) – (20:00 Thu 05, AEST) 10:00, 5 November 2020 (UTC)

Wikimedia Login Wiki

What is the interwiki link for Wikimedia Login Wiki? --Ituafmq (talk) 20:05, 31 October 2020 (UTC)

Looking at Special:Interwiki, I don't believe there is one. BethNaught (talk) 21:03, 31 October 2020 (UTC)
@BethNaught: But aren't there supposed to be interwiki links for all WMF projects? Or is my belief incorrect? --Ituafmq (talk) 01:00, 1 November 2020 (UTC)
There are several private/hidden/fishbowl/etc. wikis that the WMF maintains. They're not for general or external use, and my understanding is that most/all of them don't have interwiki links as no links to those wikis should ever be posted. ~ Amory (u • t • c) 12:38, 2 November 2020 (UTC)
@Amorymeltzer: Ok, thank you very much for your reply! --Ituafmq (talk) 16:01, 2 November 2020 (UTC)
Amorymeltzer, What is a "fishbowl wiki"? -- RoySmith (talk) 16:05, 2 November 2020 (UTC)
Well, meatball:FishBowl, but less confusingly: open to read, (largely) not open to write. It also gets tossed around for anything that "looks" like a little fishbowl, like some office/cubicle designs or some silly icebreaker games. In this case, anyone can "look in" from the outside, but only the "fish" are inside and participating. Truthfully, fishbowl wikis can make use of interwiki links, I just lumped them in above with the other "weird/nonstandard" options. ~ Amory (u • t • c) 16:20, 2 November 2020 (UTC)

Community Wishlist

The Community Wishlist goes live in a few days. There have been some changes again this year with the Community Tech team being more explicit about their ability to pick which projects they work on and with there being a seperate "leaderboard" for large and small projects.

I tried to be neutral in the above paragraph with the description. However, I am not a fan. When I worked with this team for changes around WP:NPP, I found them great collaborators and on the whole a pleasure to work with. However, the community has now gone from having one way to actually get some developer time for things it thinks important to zero ways. In order for a community desired change to happen it needs to pass an initial screen to be allowed onto the community wishlist. It needs to attract some level of support (but don't worry if it's not the most since it's neither a vote nor a discussion). It then needs to be selected, by whatever method the team feels like using, for research. Then the research needs to be positive. Then the development needs to be completed successfully That is, by my count, 5 different places where, no matter how much the global community desires a change, that the it could simply not happen. The fact that the team is small is not an indictment of them but of the leadership who allocates funds, including the board. But the rest of this are changes I'm dispirited to see. Best, Barkeep49 (talk) 21:55, 9 November 2020 (UTC)

@Barkeep49: For the global watchlist that was not done by the community tech team, I got a grant to create an extension to do it - once that is done if there are any other wishes that I think I could do, but the community tech team has declined (at any of those 5 stages) I can look into it DannyS712 (talk) 22:05, 9 November 2020 (UTC)
That's a wonderful offer DannyS712 and I am grateful for the work you and other volunteer devs do. However, it doesn't let the foundation off the hook. Volunteers by their very nature are less reliable than a permanent group of devs at the foundation. To use a different example, I am grateful that Enterprisey developed reply-link and my life was made better by it. However, I still the foundation's work on the discussion tool was necessary and useful. Best, Barkeep49 (talk) 22:10, 9 November 2020 (UTC)
@Barkeep49: Hello! We have discussed the feedback provided by you and other volunteers (thanks for sharing it). We have shared a response, which provides some clarification and adjustments, on the talk page. Thanks! --IFried (WMF) (talk) 01:34, 10 November 2020 (UTC)
To summarise two key points of that update, which is substantive enough to warrant a read: all non-declined backlog items will be added to the task list and when they're researching which wishlist items to do, they'll do so in order of most votes received. Nosebagbear (talk) 09:41, 10 November 2020 (UTC)

RFC on Discussion Tools content corruption

There insufficient support (actually more opposition) to block the the deployment of Discussion Tools to the English Wikipedia until (all) round-trip-translation content corruption is avoided. — JJMC89 (T·C) 00:12, 28 November 2020 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

As a result of the Talk pages consultation 2019, the Foundation ended their strategy to eliminate&replace Talk pages with Flow. It also resulted in a decision to keep existing Talk pages, to keep existing Talk page editing, and to build new tools on top of the existing Talk system. The current project is called Discussion Tools. Discussion Tools is, in general, a promising product. It aims to add a Reply link after comments, and help automatically insert the comment into the page wikitext at the right spot with appropriate indentation. I hope to see it ultimately improved and deployed. However the RFC below describes a design problem with the product, and the project manager doesn't want to fix it. The proposal below seeks consensus that the product not be deployed until the design flaw is fixed. Alsee (talk) 18:43, 28 October 2020 (UTC)

One of the reasons Flow failed was broken wikitext support, including a wide range of content corruption issues. Discussion Tools does not look like Flow, but the backend code basically clones Flow's design flaw. When Discussion Tools is used, it can and does cause corruption to existing Talk page content. I will try to keep the technical details to a minimum. Here is how Discussion Tools should work:

  1. You click Reply and enter your comment.
  2. Discussion Tools should insert your comment-text (with indents added) into the page-text, and save the page.

Simple, right? Any programmer knows that should never result in content corruption. Instead Discussion Tools is designed like this:

  1. You click Reply and enter your comment.
  2. Discussion Tools uses VisualEditor's Parsoid engine to translate the wikitext page content into something that isn't wikitext. (I believe it is called HTMLRDFa). It does this even if you explicitly avoid VisualEditor.
  3. It inserts your comment into the non-wikitext translation of the page.
  4. It (tries to) translate that back into wikitext, and the result of the round-trip-translation is saved.

In theory double-translation is supposed to return back to the original page content, and much of the time the theory works well enough that you never notice it. However the roundtrip translation is insanely complex with many hidden bugs. Below I document multiple different cases where the Discussion Tools round-trip double-translation causes content corruption to the existing page. The problem wouldn't exist if they didn't use round-trip-translation. Note an important point: The examples below are proof that that there is a systemic design flaw. There are likely hundreds, if not thousands of different examples that trigger content corruption. Arguments over the specific examples, or advocating fixing the specific examples, fail to address the systemic problem. The Flow team was never able to fix these problems, and even if the new team could magically fix each individual case there will still be new cases of corruption popping up with no foreseeable end.

Collapsed examples demonstrating Discussion Tools content corruption

Inserting a reply in the middle of a line here on EnWiki, mangling a relisting at RFD.

Deleting a template out of the middle of a previous comment, here on EnWiki. (The template should have had a tl| but DiscussionTools shouldn't be creating confusion or damage with mystery deletions.)

Mangling an existing 5 line comment onto a single line on FrWiki.

BLANKING AN ENTIRE COMMENT in a different section, on KoWiki. - Appears unrelated to DiscussionTools.

Moves hidden comments such as the <!--Autosigned by SineBot--> applied by Sinebot, off of an existing comment and incorrectly puts it on the ends of the new comment.

Here is a diff reported from FrWiki. The </div> markup was deleted, and the 'Message envoyé' line was moved. Note that Discussion Tools deleted and moved content in an entirely different section from the section where the reply was.

This is one staff member making a test reply to another staff member. Quiddity's edit should be be a one line diff, with Quiddity replying "test". Note that it made a various changes to six different lines of Whatamidoing's comment, and then proceeded to wrap both Quiddity's comment comment inside Whatamidoing's table markup. This is a related example, it should be a simple one line diff "Reply to reply 1". Instead it is a multi-page diff, grossly mangling multiple sections in a variety of ways.

This test was another one-line-reply made with Discussion tools - "Reply 2." Note that Reply 2 deleted the </span> markup from the previous comment. That causes causing all current and future text to turn red, down to the end of the section.

Note that the examples above document at least three completely unrelated cases that trigger corruption. They are surely just the tip of the iceberg of things that will trigger corruption.

Proposed: Discussion Tools not be deployed until it is fixed to avoid round-trip-translation content corruption, including both known and as-yet-unknown cases in this class. (This almost certainly means altering the design to avoid round-trip-translation.) Alsee (talk) 18:43, 28 October 2020 (UTC)

Update: I'm finding and adding new examples (in the collapse box), which have now escalated to DiscussionTools blanking entire comments from an entirely different section. And to reiterate, I don't want DiscussionTools eliminated (as some responses seem to believe) - I'm desperately trying to get it fixed. Alsee (talk) 07:52, 30 October 2020 (UTC)

Discussion Tools RFC responses

  • Support as nom. They should simply insert the new comment without a needless Rube Goldberg round-trip-translation. It is inexcusable that the Foundation has such gross disregard for fixable wikitext corruption. Alsee (talk) 18:43, 28 October 2020 (UTC)
  • Support the need to fix this fundamental flaw before deploying this tool. Barring that, local WP instances should have the option to disable it until it is fixed. Developers might complain that these are edge cases, examples of GIGO, but garbage exists, and the Wikimedia software does not prevent it from existing. The reply tool should simply post an indented (LISTGAP-compliant, presumably) reply, regardless of the text around it. If it can't do a simple reply for some reason, it should emit an error message asking the editor to reply using regular editing. I would love to trust the developers to deploy a mostly working tool and then diligently fix bugs, but as we have seen with the still-in-beta Visual Editor, well-described bugs that damage wikitext and cause headaches for gnomes are not being addressed (e.g. three-year-old T162291; there are plenty more of those). Developers have moved on to the next shiny thing. – Jonesey95 (talk) 21:24, 28 October 2020 (UTC)
  • Oppose, as the benefits of Discussion Tools clearly outweigh the issues. The upside is large: editors not familiar with markup will be better able to participate in talk page discussions, a critical part of editing. The bugs are, as the discussion below documents, rare. I have been using the 2017 wikitext editor, which also uses Parsoid, for a couple years now, in mainspace and on discussion pages, and have never run into a Parsoid parsing bug. "Just go back and re-architecture the entire project when it's already nearly complete to prevent some occasional bugs" isn't a reasonable demand to make. Vahurzpu (talk) 00:08, 29 October 2020 (UTC)
    (edit conflict) The 2017 wikitext editor does not use Parsoid in the way that DiscussionTools does. Making an edit to an un-Parsoid-parsable page using the 2017 wikitext editor does not make any changes to the wikitext other than those you typed in, whereas replying to a comment on such a page does. * Pppery * it has begun... 02:00, 29 October 2020 (UTC)
  • Support Alsee's proposal: alter the design to avoid round-trip-translation. "Something must be done. This is something. Therefore this must be done." --Guy Macon (talk) 01:41, 29 October 2020 (UTC)
  • Question: Is there some way I can cut and paste the Wikitext from some random page, send it through the dual conversion, and see the result? I would ask that the result show up in some sort of sandbox with no ability to save, not in the edit window where a single click might publish the undead thing. --Guy Macon (talk) 01:41, 29 October 2020 (UTC)
    @Guy Macon, mw:Parsoid/Round-trip testing has information on how to do that. In this particular context, you could also just use the Reply tool for a while (e.g., in a Sandbox page) and see what happens, or look at https://dtcheck.toolforge.org/dtstats.html and see what's actually happened during the last ~16,500 real-world uses. Whatamidoing (WMF) (talk) 06:47, 29 October 2020 (UTC)
    Guy Macon, User:Enterprisey/parsoid-round-trip, hot off the press. Enterprisey (talk!) 07:16, 29 October 2020 (UTC)
  • Oppose. I'm not thrilled with Parsoid, and I'm particularly not thrilled with HTML/RDFa. As a practical matter, however, both are here to stay. They are part of the core wikimedia architecture that exists today. Likewise, the model of "convert wikitext to HTML/RDFa, manipulate it in that domain, then convert back to wikitext" is not going away; it's part and parcel of the whole Parsoid architecture. To demand that tools be designed to avoid the round-trip translation is tilting at windmills.
Wikitext is a disaster. I'm not sure if it has a formal grammar, but if it does, it's absurd, allowing constructs which make no sense to anybody who has ever tried to write a parser. So we've got multiple parsers, each of which is broken in a different way. And, with wikitext being hand-generated, it's bound to be written badly. There's tons of unparsable wikitext in the wild right now. If it gets mutated during a round-trip, well, garbarge-in, garbage-out. The more we get away from hand-written wikitext, the better off we are. If there's some bumps in the road, that's the price we have to pay. Parsoid is a line in the sand. It may have bugs, but there's one place they need to get fixed. And HTML/RDFa, despite its problems (I'll be happy to rant about that in another forum), is at least a fixed target with a real grammar against which to write tools. — Preceding unsigned comment added by RoySmith (talk • contribs) 01:55, 29 October 2020 (UTC)
  • @RoySmith: Actually, Parsoid has a PEG tokenizer based on several thousand parsing IO tests (I want to say on the order of 10-20k). See mw:Parsoid/Internals#Architecture. --Izno (talk) 03:24, 29 October 2020 (UTC)
    Izno, That may be true. But surely any grammar that allows:
    This is italic and also bold and now just bold.
    is just farshtunken. -- RoySmith (talk) 21:46, 29 October 2020 (UTC)
    I didn't claim that the grammar was sane. :) --Izno (talk) 23:34, 29 October 2020 (UTC)
  • (edit conflict) I would prefer using the edit filter to block edits made using DiscussionTools which corrupt the wikitext, but the edit filter isn't currently given enough information to tell whether an edit is made using DiscussionTools, and this proposal does present a serious problem, so I have to support the current suggestion as an interim measure. * Pppery * it has begun... 02:00, 29 October 2020 (UTC)
    @Pppery, I hope you'll try out the Reply tool yourself. In the meantime, here are all of the dirty diffs at enwiki from the last seven days: [9] and [10]. They remove a single stray space from the end of a line (spaces that do not show when you are reading the page, because the old PHP parser drops them). There have been some serious bugs in the past (e.g., this bug, which was fixed months ago), but I would classify removing a stray space as a minor problem. Whatamidoing (WMF) (talk) 06:32, 29 October 2020 (UTC)
  • Oppose The benefit of Discussion Tools is that more casual editors will be able to engage in talk page discussions by breaking down technical barriers for new participants. The harm is that bad wikitext continues to be bad wikitext. If you want a different parser, write a different parser, but I'm not going to support keeping our talk pages inaccessible just because Special:LintErrors exists. — Wug·a·po·des​ 02:26, 29 October 2020 (UTC)
    information Developer note FYI there are far more barriers that just writing a different parser - buy in from the WMF for one, but more importantly any existing quirk in wikitext would either need to be kept, which hinders how "different" the other parser would be, or removed, which would require consensus (devs, community, or both?) and effort to both decide, clean up existing uses that would be broken, etc. A different parser would only compound the issues of the differences between the current parser used to render everything and the parser Parsoid uses. DannyS712 (talk) 02:38, 29 October 2020 (UTC)
    I was suspicious that a new parser would be a miracle solution, so thanks for clarifying the design considerations. As an aside, this is my first time using the reply button (thanks for the link @Whatamidoing (WMF)), and seeing it with my own eyes just convinces me more that this would be a boon for editor recruitment and engagement. — Wug·a·po·des​ 02:53, 29 October 2020 (UTC)
    @Wugapodes, thanks for the ping. The three Wikipedias that tested it and then asked for it to be turned on by default (and the Editing team actually agreed to so far; there are a couple of requests pending but not approved yet) are all working with the Growth team on newcomer retention. However, the initial analytics results aren't back yet, and this probably requires an A/B test (planned for November or December), so I can't tell you whether it's actually having the effect you (and I) expect. Whatamidoing (WMF) (talk) 06:04, 29 October 2020 (UTC)
  • Oppose this feels like nitpicking over edge cases. I'm using the tool right now (per instructions of Whatamidoing below in js file), I think it's quite neat. I haven't ran into any issues so far, and it feels like a good tool. This whole "enwiki doesn't subscribe to anything new developed" is a bit meh. And if there are bugs, it'll be like any other software with bugs, and I'm sure they'll fix it. Also + Roy above and Izno below. ProcrastinatingReader (talk) 10:22, 29 October 2020 (UTC)
    • Having used this for almost a week now, I'm even more strongly opposed to this. I think this is a well built tool that will facilitate better talk page discussions. This should go live as planned. Reply-link is great, but it wasn't enabled by default and every now and then there's errors on trying to reply; this tool I haven't had such an error with yet. I have not seen any problematic replies in my usage. Very rare, exceptional GIGO cases are totally not a good reason to hold this. This seems stable for production usage, and it seems like it's been thoroughly tested for edge cases, which is reassuring to me as well. Large benefits here which outweigh any small 'errors', and we've got few common usage (ie not-(stress)test) examples of errors here. ProcrastinatingReader (talk) 19:09, 4 November 2020 (UTC)
  • Oppose per the data below provided by PPelberg (WMF). A 1% error rate that is still being examined is, I have to say even looking at this page, a lower error rate than is generated by editors in normal editing. I'm guessing as I continue to use the tool I will find more issues but knowing that the "bad code" problems highlighted here are being tracked, and are at such a low rate, is enough to reassure me. Best, Barkeep49 (talk) 01:09, 30 October 2020 (UTC)
  • Support per Jonesey95 above and below. Post-release it’s too easy to focus on the next project and not fix the issues here. Cavalryman (talk) 19:58, 1 November 2020 (UTC).
  • Oppose: Properly participating in Wikipedia discussions currently requires learning a strange syntax; the new tool improves accessibility for those deterred by this first hurdle. This especially includes users who already constructively participate using VisualEditor, which is unavailable on talk pages. Making it easier for users to discuss conflicts will probably reduce the amount of unnecessary edit wars and the amount of "discussions" occurring in edit summaries of reverts instead of talk pages. No software will ever be free of bugs, and rejecting the tool for the rare occurrence of fixable bugs would be a mistake. ~ ToBeFree (talk) 21:31, 1 November 2020 (UTC)
  • Oppose - While the new discussion tools aren't perfect, they seem to be a substantial improvement in the user experience, even for seasoned editors. The few parsing inconsistencies that exist would be rare edge cases for talk page discussions. Kaldari (talk) 17:09, 4 November 2020 (UTC)

RfC Discussion

  • @Alsee:, do you have a diff where developers have indicated they're not going to fix this issue? Like you I'm in favor of the goals of this project. I would love for the enwiki community to be able to work collaboratively with the foundation rather than in an us vs them manner. That might not be possible but I worry that the outcome of RfC being successful will be that the foundation writes of enwiki in terms of how it develops this and so we miss out on the value altogether. Frwiki is hardly a small wiki; has there been community discussion about the relative benefits to current drawbacks of the implementation there? Best, Barkeep49 (talk) 21:56, 28 October 2020 (UTC)
    @Barkeep49, I think the answer to your question would depend upon what you call "this issue". I'm not so sure about these claims.
    • In Alsee's first diff, Parsoid automagically resolved a stripped tag error on a talk page about six weeks ago. Resolving Special:LintErrors is generally considered a good thing to do. Moving the blank line around the hidden HTML comment is less desirable, and I believe there's a bug report for this (it might be in the list that will get resolved this WP:THURSDAY).
    • In the second diff, my teammate and I were testing a bug report from Alsee at the mw:Beta Cluster testing site back in February. This was early-stage testing, months before the tool was offered as a Beta Feature to any community. This page was corrupted when a wikitext table had all of its formatting syntax with ::: inserted in front of it. (Wikitext tables require the table formatting codes, such as |-, to be the first characters on the line.) Broken wikitext is expected to produce broken pages, especially when we're talking about super-early stages of software. To make it harder to create this problem accidentally, the Reply tool hasn't let editors insert tables or templates for months now, unless you put the wikitext in yourself. A longer-term solution requires a significant technical change to wikitext, which may be discussed in the coming months.
    • In the third diff, Alsee ran a test with this content: {#if:x|<span style="color:red;|<span style="}} font-weight: bold">This should be red 2.</span>. I have seen Alsee post this string as a deliberate 'stress test' several times on at least three wikis now, but I've never seen an editor type anything like that in a real comment. There's a bug report for this in Phab, and I understand that it's priority is set to reflect its rarity.
    These diffs are not representative of the everyday experience of using the Reply tool. If you'd like to see real-world diffs, you can check RecentChanges here at enwiki.
    You can also look at this table of diffs by wiki, if you want a quick way to find diffs that are more likely to be broken in some way. The problem rate is low and falling. Most days, about one out of 150 Reply comments have a whitespace change, and another 1 in 150 have a non-whitespace change. (Fun fact: Parsoid isn't the only software that causes 'dirty diffs' on talk pages. WP:WikEd does, too.)
    If you're interested in why both the Reply tool and User:Enterprisey/reply-link.js are using Parsoid to place comments, then I can tell you more about that, but I think you might be better off trying out the Reply tool for yourself. Unless someone deliberately corrupts this page, then you can try it out right here. Click on https://wiki.riteme.site/w/index.php?title=Wikipedia:Village_pump_(WMF)&dtenable=1 and look for the little [reply] links at the end of each signature. I recommend clicking over to the "Visual" section and using the toolbar to ping me or to add a link to your reply. Imagine a world in which you never have to remember how to spell or correctly capitalize editors' usernames. :-D Whatamidoing (WMF) (talk) 22:17, 28 October 2020 (UTC)
    Although I'll give you a hint now: @Izno replied while I was typing, and I didn't have to deal with the edit conflict that would have triggered in any of the regular wikitext editors. Whatamidoing (WMF) (talk) 22:19, 28 October 2020 (UTC)
    Whatamidoing (WMF), I'm not sure how much of your reply is really meant for me and how much is a "I'm going to reply to this comment so I can say everything I want to." Going off the idea that it's at least actually partially directed at me, I have tried the tool. I found it impressive at the early stage I tried it and I found the foundation responsive to the concerns I did raise - more responsive than I'd have actually expected. This is partly why I asked Alsee the questions that I did; I wanted to make sure I wasn't missing something/ Best, Barkeep49 (talk) 22:40, 28 October 2020 (UTC)
    @Barkeep49, if you copy the first happy lines from m:User:Whatamidoing_(WMF)/global.js (this diff), then you can use it all the time. I haven't tried out Enterprisey's reply-links myself, but it's obviously popular, especially with the improvements he made a few months ago. Maybe someday you can tell me how the two compare. Whatamidoing (WMF) (talk) 22:51, 28 October 2020 (UTC)
    Whatamidoing (WMF), thanks for the links to these diagnostic tools. Do similar tools exist for VE while it is still (I hope) being debugged? Here is an example of a broken edit from this tool. I don't know the rules on fr.WP, so I don't know if this was technically a GIGO edit, but it looks like an editor unwittingly altered the formatting of another editor's comment in a significant way, which is usually unacceptable. Given the small scale on which this tool is currently deployed, and based on my experience with stale VE bugs, I worry that multiplying the frequency of this sort of edit by 100 or 1,000 will lead to a lot of problems that developers will dump on gnomes to fix after they have moved on to something more fun than fixing tricky bugs. – Jonesey95 (talk) 02:53, 29 October 2020 (UTC)
    @Jonesey95, what do you mean by "significant way"? It stripped out a line containing only colons between two comments by the same editor. That editor wrote a comment with four colons, then added a blank line with three colons, and then wrote another comment with four colons immediately afterwards. Under our rules about WP:LISTGAPs, any editor would have been justified in removing those stray colons manually.
    The Editing team is working with the Parsing team to reduce the "dirty diffs". The current rate is low and falling. I encourage you to try it out and see what you think about it yourself. Whatamidoing (WMF) (talk) 06:16, 29 October 2020 (UTC)
    @Whatamidoing (WMF): I was not going to bother mentioning this experience, but having seen the conversation here I did want to weigh in as someone who actually has used Discussion Tools before on Meta recently.
    First, I find the extension very convenient to use and rather nifty, too. However, I did have some weird bugs that occurred during the global RFC I had drafted (m:Special:Diff/20666993 & m:Special:Diff/20688139). I see why the first diff happened given my initial error with <h2> vs </h3> (though I don't think it gave the intended result there). It is not clear why the second one happened. I get that my RFC used some advanced formatting and stuff, but it made me feel bad to see I accidentally broke the tool (and/or the tool broke my RFC).
    Finally, I get that what Alsee had written was likely just a stress test, but I regularly use the {{gender}} magic word and would hope its usage is properly in the tool. –MJL ‐Talk‐☖ 05:18, 27 November 2020 (UTC)
    The second change happened because you had a copy of Template:Div col end without any Template:Div col begin to balance it.
    Right now, you can't insert templates in the visual mode, but there's no fundamental reason why template such as Template:Gender couldn't work. Whatamidoing (WMF) (talk) 21:39, 27 November 2020 (UTC)
    Barkeep49, you asked if there's a diff where developers have indicated they're not going to fix this issue. I think this link will do: Phab post by the project manager. Context: The manager is discussing just one of the symptom cases (the tables example). He states they aren't even going to try to fix that case. Their "fix" to avoid corrupting the page (for that particular problem case) is to detect that case and then fully break the REPLY button. The REPLY button won't corrupt the page if the button refuses to let the user post any reply at all. I reported this issue directly to the manager seven months ago. That post from him is exactly one month ago. If they're not fixing that specific case, they clearly don't intend to fix the underlying cause. Alsee (talk) 23:10, 29 October 2020 (UTC)
  • As I've said at least once, this proposal is DOA. The technology stack powering DiscussionTools is coming whether you want it or not. I would invite other editors to read through that thread and the other forked thread that Alsee disruptively started twice to try to kill the implementation, as well as the responses from just about everyone else (to wit, the developers have worked issues identified where it is the tool that is at fault and asked for further specific details; Alsee failed then to provide them, so I guess I'm happy there are 3 observed questionable problems above).
    Further, in almost all cases I've seen where round-tripping has caused an actual corruption rather than a suboptimal edit, it has been the fault of frankly bad wikitext. --Izno (talk) 22:06, 28 October 2020 (UTC)
  • This seems out of our scope. Software back-end is the domain of the MediaWiki.org community, and WMF-wide configuration policies are set on Meta. The most we can do is decided whether to enable or not enable Discussion Tools on EnWiki. — Wug·a·po·des​ 02:14, 29 October 2020 (UTC)
    If you all decide that you'd like to test this as an opt-in-only Beta Feature, then I can make the request for you. I do not know what the response would be. Whatamidoing (WMF) (talk) 06:42, 29 October 2020 (UTC)
    I think it would be useful. For an opt-in beta feature, I do not think we need a formal RfC or anything similar.--Ymblanter (talk) 07:32, 29 October 2020 (UTC)
    I for one would prefer going ahead with the current rollout scheme across all wikis unless there is consensus to do something different. It seems enwiki is excluded in phase 3 in T266303; what phab task is tracking the deploy to enwiki? Is it roughly known when will it be deployed, and will it be a beta feature at that point or is it enabled-for-all, under the current plans? Unrelated, it seems sometimes the "Reply" button sends me to the top of the page rather than to the comment I've just posted (I have to scroll back down manually). ProcrastinatingReader (talk) 12:12, 29 October 2020 (UTC)
  • I've only tried in one niche discussion, but is this tool able to distinguish between * and :? eg in Special:Diff/986048398 it added a : when most of the replies were bullets (it also added a space). This was when I was responding to the main comment, btw. Side feature request: to add a reply to this section I have to edit source. Not sure if it's easily possible, but in the long run maybe some kind of "Add reply" functionality when replying to a section/main discussion rather than an individual user? It may be more difficult to achieve, if at all, I know. ProcrastinatingReader (talk) 14:02, 29 October 2020 (UTC)
    It does know about list types, but it uses that only for when you're replying to something that's already in a list. I.e. it'll sensibly reply to an * comment with * and a : comment with :. When you're just replying to a top-level section (which isn't in any sort of list), it'll default to :. I took a look at the replies where you were, and they're already super-mixed -- in the HTML output there's 5 dl and 4 ul lists, so it's a bit of a mess, and one could argue that even if it was trying to guess based on overall usage it'd have landed on : for that reply.
    The reply links trigger off of finding a block of text with a signature, which is why replying to this section-as-a-whole isn't present. I do agree it'd be helpful if it better supported non-described sections, even if they're less common... DLynch (WMF) (talk) 17:19, 29 October 2020 (UTC)
    Oops, sorry, I gave outdated information. We matched the list type up until about a month ago, when we started replying to everything with :. We decided that we’re still evaluating how best to choose which indentation type should be used for replies... so having a half-done selective approach in place was probably worse than a consistent one while we’re thinking about it.DLynch (WMF) (talk) 19:20, 29 October 2020 (UTC)
    @DLynch (WMF) thanks for this. That's fine, was just curious. BTW, the preview on "Source" actually shows bullets. Every new line is an additional bullet. I actually kinda liked that, but that's not how it saves, so it feels a bit misleading to show it in preview. But otherwise, great work on this reply stuff to all devs/others involved! It's quite cool! Hopefully it encourages talk page participation even more. ProcrastinatingReader (talk) 19:03, 4 November 2020 (UTC)
    Oh hey, thanks for pointing that out! We hadn't noticed the preview issue -- it's a side-effect of forgetting to remove the list-type inference there when we did everything else. A fix for that has been committed and will work its way out in the next deploy cycle. DLynch (WMF) (talk) 16:34, 5 November 2020 (UTC)
  • As you all consider this, I thought it would be helpful to do two things:
    1. Share how the Editing Team is thinking about and addressing the risk that edits made with the DiscussionTools make changes to talk pages other than adding content.
    2. Address the statements and diffs in the original post.
What follows isn't exactly "bite-sized." Tho, I thought thoroughness would be worthwhile in this context. If anything here prompts new thoughts or questions, please let us know...
  • 1. The potential for DiscussionTools to impact other parts of the page.
    • The core of this proposal is the need for edits made with DiscussionTools to not affect talk pages beyond adding the content people are posting with it. We relate to this proposal in so far as we, too, see it as a requirement that edits made with DiscussionTools should not impact other parts of talk pages, especially in ways that make them more difficult to edit and understand.
    • As Whatamidoing (WMF) mentioned above, to help us all ensure the tool is working in ways we expect, we've created a way to detect when edits made with DiscussionTools do anything beyond adding new content to talk pages. You can play around with it here: https://dtcheck.toolforge.org/dtstats.html.
    • To date, the tool has analyzed over 16,500 comments.
    • In the past 5 days, an average of ~1.30% of comments do something other than add new content to talk pages. In the past 30 days, an average of ~1.20% of edits made with the Reply Tool have changed other parts of the talk page in some way.
    • Note: The most common change we see is space characters being removed at the beginning or end of comments. We're working to eliminate these as well.
    • Since we started tracking this kind of edits on 3-September, we've seen the 5-day average "dirty diff rate" fall 83%, from ~6% → ~1%.
    2. Statements made in proposal
    Discussion Tools round-trip double-translation causes content corruption to the existing page
    In principle, this statement is true: edits made with the Reply Tool have changed other parts of the page. Although, evidence suggests (see: https://dtcheck.toolforge.org/), the incident rate of these "changes" is falling, and we now have a mechanism to proactively detect when these changes occur.
    The problem wouldn't exist if they didn't use round-trip-translation
    Some context as to why we have been using Parsoid to save comments made with Discussion Tools: "[Parsoid] makes it possible for the software to work out the structure of the page and thus more reliably insert replies in the correct position on the page. Secondarily, by sending talk page content through Parsoid, it enables the reply tool to work on transcluded pages." More context here: https://w.wiki/jGS.
    ...examples demonstrating Discussion Tools content corruption
    Example 1 (fr.wiki)
    • This is an issue we're tracking and talking about a fix for. You can track the progress on this work on Phabricator here: T262448.
    • Note: Matma Rex shared some helpful context about the impact and cause of this category of issues in T262448#6499606, "Many of the diffs we're seeing look really bad because they remove closing tags that actually seem to be matched to an opening tag at a glance, and are only unmatched because of incorrect nesting resulting in the relevant node being implicitly closed earlier."
    Example 2.1 & Example 2.2
    • The above seem to be cases where an edit is made with the Reply Tool on a page that contains broken/incomplete table syntax. As of April 2020, the tool is disabled on most affected pages (T246481). We think this protection might not have worked as expected in this case because of the speed with which these edits were made. See: T263709#6502328.
    • As shown in the second example, it’s still possible to intentionally avoid that workaround, e.g. by opening the reply tool in one browser tab, and then adding the broken syntax to the page in another; or posting multiple comments very quickly. Fixing this is possible, but would cause posting replies using the tool to be slower in the common case where the page isn’t affected by this bug. We investigated this issue back in September and decided it would be safe to not fix this considering, what we see as, the low likelihood of this occurring in "real" usage (T263709#6503764).
    • Long-term, the solution to this problem requires extending wikitext, so that corrupted syntax can be isolated from the rest of the page. We are planning a technical RFC to do this. You can track the progress on this work in Phabricator here: T230683.
    Example 3
    • This seems to be similar to the issue we talked about earlier this year.Topic:Vcwvt3bq03o5gv8h
    • As a result of that interaction, the Editing Team decided not to address this issue considering:
    • There are Parsoid-compatible ways of achieving the same intended effect.
    • We are not currently aware of any instances where the syntax you are using here has been used on live talk pages.
    • Technically, this is the same issue as T262448 (unmatched closing tag), and may get resolved along with that.
    There are likely hundreds, if not thousands of different examples that trigger content corruption.
    • As noted above, to date, the tool has analyzed over 16,500 comments. Over the past 30 days, ~1.20% of edits made with the Reply Tool have changed other parts of the talk page in some way.
    • We'd value you having a look at the kinds of changes contained in this "~1.20%" metric by inspecting the diffs we're tracking. If you see diffs that you think involve serious problems, please let us know here, in Phabricator or by commenting on the tool's talk page at mw.org: Talk:Talk pages project/replying. Here is a link to the tool you can use to review all edits made with the Reply Tool: https://dtcheck.toolforge.org/dtstats.html. PPelberg (WMF) (talk) 00:53, 30 October 2020 (UTC)
    Thanks @PPelberg (WMF), this is helpful context. I'll just note that one kind of "reply" I can't do yet (as I've installed the tool per @Whatamidoing (WMF)'s invitation above) is I cannot participate in the response part of the RfC. Is that in scope for this project? Best, Barkeep49 (talk) 01:07, 30 October 2020 (UTC)
    I'll just note that one kind of "reply" I can't do yet...
    To make sure, we're on the same page, in stating the above are you referring to being able to use the Reply Tool, or something like it, to submit a vote (e.g. Support or Oppose) in the ===Discussion Tools RFC responses=== section?
    If yes, then this is a use case we've started to think about (see: phab:T259865); I've also added the use case I think you are highlighting here to the task's description (see: phab:T259865#6590520).
    {Is that in scope for this project?
    I think the safest answer would be to say "no" in so far we do not yet have specific date in mind for when we will work on supporting this use case. This is not to say we do not think it's important or we won't end up getting to it.
    Rather, we think getting the "communication primitives" (e.g. responding on discussion-style conversations and adding new topics) to a place where people who are newer to the wikis can communicate with others instinctively and ways that comply with community conventions should take precedent. You can see a bit about how we're thinking about the project in this update: Talk_pages_project/Updates#4_Sep_2020.
    ...this is helpful context
    Oh good. If any other questions come up, please do let me or anyone else know. We're striving to make the work around this project as legible as possible. PPelberg (WMF) (talk) 02:00, 30 October 2020 (UTC)
    PPelberg (WMF) I remain mystified at your apparently intense desire to not fix it. If you inserted the new comment into the original page content, all of these problems would be solved in a single stroke. Instead you're expending work chasing after a variety of symptoms, in some cases you're "fixing" it by fully breaking the reply button so the user can't reply at all,[11] you are going to have to chase after all of the new cases that crop up, and then you're leaving us screwed after your immediate project wraps up. Even if you manage to fix today's list of examples, tomorrow's corruption cases are never going to be fixed. We're supposed to file phab tasks on them, and these kind of tasks just vanish into the infinite-backlog on phab after the immediate project closes. Alsee (talk) 06:13, 30 October 2020 (UTC)
    PPelberg (WMF) I just found that DiscussionTools blanked an entire comment in a completely different section![12] How is that not a screaming showstopper?!?!? Alsee (talk) 07:46, 30 October 2020 (UTC)
    I just found that DiscussionTools blanked an entire comment in a completely different section.
    This diff was unsettling to us as well – thank you for linking to it, @Alsee. We investigated this diff when we noticed it ~2 months ago.
    The result of that investigation: the bug that caused this concerning edit was not caused by DiscussionTools, but rather by MediaWiki failing to handle edit conflicts when the replica databases were out of sync. This blanking would've happened regardless of what editing interface/tool someone used.
    So folks are aware: we fixed the underlying issue that caused this problematic diff in T261715.
    Note: you'll see the problematic diff happened on 6-September-2020 and the patch to resolve it was committed on 1-September-2020. The reason that patch did not prevent this particular issue is because the patch landed on ko.wiki (a Group 2 wiki) on Thursday, 10-September, four days after the edit happened. PPelberg (WMF) (talk) 15:33, 30 October 2020 (UTC)
    @PPelberg (WMF) that is the context I was talking about. Thanks and best, Barkeep49 (talk) 14:47, 30 October 2020 (UTC)
    Roger that, okay. Thank you for confirming, @Barkeep49. PPelberg (WMF) (talk) 15:35, 30 October 2020 (UTC)
    PPelberg (WMF) I have stuck that one from the example list. With that one out of the way, could I get a response to my comment (06:13 , 30 October)? There's now something like a dozen known independent cases where DiscussionTools will randomly corrupt the existing page (not all included in my example list). Those cases will randomly be serious or "minor". New ones are found week after week, month after month, and will continue year after year. Alsee (talk) 19:30, 30 October 2020 (UTC)
    ...could I get a response to my comment (06:13 , 30 October)?
    For sure. Although, can you please point me to the specific point within the comment you posted that you'd value a response to? I'd been thinking I'd responded to that post, tho, you may be seeing something I'm not. PPelberg (WMF) (talk) 01:03, 31 October 2020 (UTC)
    PPelberg (WMF) sorry for the delayed response. I'm disappointed that I find not a single word from you responding to anything in my earlier comment,[13] and I'm confused that you think you did respond. My later comment about the blanked-comment turned out to be completely unrelated to DiscussionTools, and your response on that was also completely unrelated to Discussion Tools. If we strike that pair of off-topic comments, there's no response my earlier comment.
    Moving on, the RFC response is currently barely over half basically saying that DiscussionTools is better than nothing, regardless of the problem. Nearly half object and want the problem fixed. Before you built the product, seven months ago, I alerted you that there was a problem and people would object. You knowingly and needlessly built a defective design. I, and others, are mystified at your apparently intense desire to not fix the problem. We want you to stop wasting precious dev hours fixing bugs that shouldn't be fixed. One of your "bugfixes" amounts to stopping an airliner from crashing into into the runway by deliberately self-destructing the plane in the air.[14] Why oh why would you make the product even more broken instead of fixing it? We want you to fix the underlying design flaw. If you inserted the new comment into the original page content, all of these problems would be solved in a single stroke. I believe it would beneficial to the Foundation-Community relationship if you agree to fix it, and I believe it will be another perpetual irritant in the wound if you don't. Alsee (talk) 13:52, 22 November 2020 (UTC)
  • @PPelberg (WMF):, I realise that you don't just set a "if we reach x% of edits having a bug, we ship", but you've impressively dropped the bug rate thus far (80% or so, I believe you said). Notwithstanding any substantial changes to the timeline, how much more time is intended in pre-(broader)-release for squashing the blighters? I'm sort of ambivalent at the moment, mainly because of the increased possibility of the tool to have errors outside of the reply itself, which are both harder to detect, more problematic, and if not detected immediately, more fiddly to fix manually. But the progress made seems positive (I am not qualified to weigh in on the pros and cons of not directly using source as the proposal advises), so I'm more on the general tool. Nosebagbear (talk) 10:26, 3 November 2020 (UTC)
    hi @Nosebagbear – thank you for this question. A couple of comments in response below...
    ...how much more time is intended in pre-(broader)-release for squashing the blighters?
    Assuming you are referring to how much more time do I anticipate us needing before we'd consider offering the Reply Tool as an opt-in Beta Feature at en.wiki, I can share some of what we have planned before doing this:
    • Listening for what consensus emerges in this RfC.
    • Making the Reply Tool available as a Beta Feature at an additional ~250 wikis to ensure it continues to work in ways people expect at a broad range of wikis. See phab:T266303.
    • Monitoring how the latest round of backend improvements (see: Phab:T262408) impact the rate at which edits made with DiscussionTools do anything other than add new content to pages.
    • Talking with people who have used the Reply Tool at en.wiki using the script @Whatamidoing (WMF) shared in this comment to understand the extent to which the tool is working as expected.
    ...I appreciate you likely asked the above seeking an estimated date or number of weeks/months before the tool is offered here. Tho, considering the unknowns involved with them, it's hard to offer that at this time. Of course, when we have a better sense of time, we will make sure it is widely known.
    ...the increased possibility of the tool to have errors outside of the reply itself, which are both harder to detect, more problematic...
    Had you and I been having this conversation in August, I would've agreed with you about it being harder for us to detect, at scale, when edits made with the Reply Tool do anything other than adding new content to pages. Although, we now have a tool that enables us (you, everyone in this conversation, the Editing Team, etc.) to detect this category of errors. If you are interested in exploring this for yourself, you might check the tool's "dirty diff detection" results for yesterday, 3-Nov-2020: https://dtcheck.toolforge.org/dtcheck-2020-11-03.html.
    Please let me know if anything here prompts new thoughts or questions. PPelberg (WMF) (talk) 17:08, 4 November 2020 (UTC)
  • I think this is a bug. It's adding a new line between what it's replying to. I believe this fails enwiki's MOS:LISTGAP. ProcrastinatingReader (talk) 02:05, 5 November 2020 (UTC)
    Nope, a new line there is fine since it is not a list being replied to. --Izno (talk) 04:02, 5 November 2020 (UTC)
  • WMF devs, another thing: I was replying to a discussion and it was closed between the time I started typing and clicked submit. After doing this, the page refreshed and my entire reply was lost (it was not added as an edit). I think this behaviour is undesirable; an error should be shown or the opportunity to save ones reply. ProcrastinatingReader (talk) 20:40, 16 November 2020 (UTC)
    A comment you have drafted being "lost" without warning does sound undesirable; thank you for saying something about this, ProcrastinatingReader. A clarifying question for you: can share in more detail what a discussion being "closed" in this context means? One thought that comes to mind: the conversation was archived. In the meantime, here is a ticket where we can define the issue at hand: phab:T268069. PPelberg (WMF) (talk) 19:52, 17 November 2020 (UTC)
    @ProcrastinatingReader an update for you: it looks like @Matma Rex was able to reproduce, and subsequently fix1, the issue you experienced.
    ---
    1. phab:T268069#6631447 PPelberg (WMF) (talk) 18:41, 20 November 2020 (UTC)
    @PPelberg (WMF) ah, sorry, I had this on my list to reproduce again and get some useful data/steps for you, but it totally slipped my mind! When I say "closed" I mean someone comes along and "closes" the discussion using eg Template:Archive top. I saw that Gerrit change and it says "This is probably because it was added inside a transclusion's HTML?" -- technically, when a discussion is closed, it "wraps around" the discussion rather than transcluding all the content, so HTML wise it'd be added inside the HTML, so that comment sounds about right.
    I've reproduced this with @GeneralNotability's help. Basically, see User_talk:ProcrastinatingReader#Category:Pages_using_Infobox_GB_station_with_unknown_parameters. I clicked "reply" on the latest comment, wrote up a message, then asked someone else to "Close" the discussion. The close caused Special:Diff/989736218. After they close, I click "reply". Effect: The page refreshes, and my reply is lost.
    I'm happy to test this again once that Gerrit commit is live on here and see if that fixes it? Just let me know when it's live. ProcrastinatingReader (talk) 19:02, 20 November 2020 (UTC)
    Also note, in case it helps, in this case my reply was to the very last comment (which would've been right above the {{abot}}), but when I initially expeerienced this bug iirc it was not the last reply, so I think this happens regardless of where the reply is in the closed discussion. Though note my memory may be faltering... ProcrastinatingReader (talk) 19:04, 20 November 2020 (UTC)
    @ProcrastinatingReader this additional context and reproduction steps are a big help - thank you for writing them up. I've added this information to the task where work on this issue is being done. See: phab:T268069#6647101.
    I'm happy to test this again once that Gerrit commit is live on here and see if that fixes it? Just let me know when it's live.
    You testing this again once the patch arrives at en.wiki would be great; I will ping you here when that happens. PPelberg (WMF) (talk) 00:13, 25 November 2020 (UTC)

Some musing about software engineering

Every piece of software has bugs. Deciding when a piece of software is ready to release is a matter of weighing the value of getting it shipped vs the severity of the known bugs (plus the risk exposure of the bugs you haven't found yet). At some point, you decide that it's good enough, and ship it. Then you have a big release party, celebrate your accomplishments, and hold your breath until the first wave of bug reports come in, hoping that none are too serious.

There's no such thing as perfect. If your release criteria is that you've eliminated every bug, "both known and as-yet-unknown cases", you'll never ship. And then the value of the software is zero.

Where that balance falls depends on what you're writing. If your program's job is to detect that a 737 is about to stall, the consequence of getting it wrong is that hundreds of people die. If your program's job is to insert a comment in a talk page, the consequence is that somebody has to revert the edit. So, clearly, the release criteria are different. To insist that it not be shipped because there are known bugs is absurd. -- RoySmith (talk) 21:40, 30 October 2020 (UTC)

That's a great philosophy, but it implies that developers will be willing to fix bugs that are reported post-release. The WMF developers have a spotty track record on doing so (e.g. the three-year-old T162291 Visual Editor bug; there are plenty more of those, and pleny that are much older). Once bitten, twice shy. – Jonesey95 (talk) 22:07, 30 October 2020 (UTC)
Jonesey95, Just like it's absurd to think software will only get released when there's zero bugs, it's absurd to think every reported bug will get fixed. There's a finite amount of developer time. Every day somebody spends working on one thing means there's something else that didn't get worked on.
I'm not privy to how WMF does things internally, but typically each bug gets scored based on how bad the problem is, how much value there will be in fixing it, and an estimate of how much effort will be required to fix it. Not unlike our importance/quality scoring system for articles. Or our plethora of "article needs improvement" templates. Surely adding a {{Citation needed}} template to an article is tantamount to filing a bug against it. We've currently got 412,324 of those. We should stop writing new articles until we get all of those fixed, right?
I see that T162291 was triaged as low priority. I gather from your comments on the phab ticket that you disagree. Such is life, people don't always agree on how bugs get prioritized, just like editors don't always agree on what edits should be made to an article. -- RoySmith (talk) 01:47, 31 October 2020 (UTC)
I'll just add to what Roy wrote that, assuming the data offered by PPelberg is correct (and I have zero reason to distrust it), the current error rate is for this tool is in the ballpark, if not less, than our manual error rate. Like I know I did a whole bunch of reply indenting wrong before (using :::: when I should have been using *::: for instance) and if this tool can get that correct then our fellow editors (in this case primarily those who need screen readers) benefits. Best, Barkeep49 (talk) 01:57, 31 October 2020 (UTC)
@Barkeep49: One reason I have some concern is that the current set-up is generating bugs that cause issues outside of the posted reply. This has a couple of effects on your's and Roy's comments above. Issues (other than ones that completely bork the whole page) are much more likely to be missed, so the error rate can be both more substantive than the manual rate but also be harder to fix. If the tool damages a post elsewhere (say the one it's replying to, which is most likely), and the poster doesn't notice, it's quite possible several posts will come in before someone notices. As with pending changes, fixing it in that circumstance becomes way more fiddly. So it's not quite an "apples to apples" consideration Nosebagbear (talk) 10:20, 3 November 2020 (UTC)
What kind of error impacts how I feel about it happening. Erasing other's comments is a big concern if it's happening 1% of the time. Some of the other errors shown don't really bother me if it's at a 1% rate. But correctly writing syntax that would otherwise have had errors if be made by a human edit is the dog that doesn't bark and it's why I mention it. And some of those human made errors, as in my example of using :::: when it should have been *::: are likely never fixed. So I am just as concerned about the errors this tool fixes as the errors it introduces. Best, Barkeep49 (talk) 16:48, 3 November 2020 (UTC)
Indeed, by the end of the work, I and others will not need to fix WP:LISTGAP issues on talk pages. --Izno (talk) 17:10, 3 November 2020 (UTC)
RoySmith I don't think your comment resembles the current issue. I am not asking them to fix multiple bugs. In fact I want them to stop wasting time and resources fixing these bugs. Insert the new comment into the page source and the number of translation-corruption bugs becomes zero. Fix the design and the time spent hunting and fixing this class of bugs becomes zero. Alsee (talk) 07:42, 31 October 2020 (UTC)
@Alsee and RoySmith: This right here is the correct solution, and would solve almost every issue I currently have with this system. IIRC, this is what reply-link (which I'm writing this comment with) already does, and it works fine in 99% of cases. In that remaining 1%, it instead errors out and fails to post instead of corrupting the rest of the talk page. Someone will probably say "but making new editors have to go into wikitext mode if there's a problem is Bad™" but that's simply the only option available. Community consensus after Flow imploded was that any further attempts to build new discussion features must be done exclusively as an extension to wikitext talk pages and integrate seamlessly. Unless the WMF somehow gets consensus to throw out wikitext entirely (yeah, that's not happening), new discussion features must not break things for editors using plain wikitext exclusively. Internally to the WMF, this should be looked at the same way Linus Torvalds looks at the "kernel updates must never break userspace software" policy, i.e. an immutable rule that can never be broken under any circumstances (with the sole possible exception of extremely critical security fixes).
Luckily, the WMF's developers have an extremely simple solution to this issue: don't commit back any of the wikitext that was pulled from the page. Visual Editor doesn't really have a choice here, but Discussion Tools does. Pull the wikitext and run it through the parser for previews if you want to, but only actually convert back and commit the added wikitext from the new reply. Congratulations, you've just fixed every single potential issue with this system in one fell swoop. In any event, per WP:TPO this should really be the only acceptable course of action. Automated tools should never be allowed to touch existing comments (beyond archiving, of course, but even then that's moving full sections to a different page without modifying the wikitext contained within) without strong consensus that it's a good and necessary decision that won't break anything. Nathan2055talk - contribs 04:13, 5 November 2020 (UTC)
Nathan2055 it's of course fine if you decided to not !vote, but was that possibly an oversight? Given your comment I was a bit surprised when I didn't find you in that section. Alsee (talk) 11:53, 22 November 2020 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Strategy event organized by Wikimedia UK and WMF

There will be an online event [15] next week Tuesday organized specifically by Wikimedia UK and the Wikimedia Foundation for the English Wikipedia in relation to the strategy. More details are provided at the link. I have no relation to its organization, though I am planning to attend, but I would like to remark that this could be a chance to have some conversation and to break the usual circle WMF proposes something - Community does not care - WMF comes with a specific proposal - a shitstorm - WMF bacls down - nothing is done, problem not solved. We are now at the stage of "Community does not care", but the process is certainly going to affect us - and I hope this is a chance to think how it will affect us and what we can do about it.--Ymblanter (talk) 20:01, 10 November 2020 (UTC)

Movement initiatives within recommendations

We should learn that either the recommendations are now subdivided into priorities initiatives or we can discuss priorities initiatives related to the recommendations. Either way, we can now vote "Support", "Oppose", or "Comment" on whatever priority initiative you would like to discuss. Link: m:Strategy/Wikimedia movement/2018-20/Transition/Discuss. --George Ho (talk) 00:15, 23 November 2020 (UTC)

Just in case, here is the list (i.e. simplified versio) of initiatives: m:Strategy/Wikimedia movement/2018-20/Transition/List of Initiatives. --George Ho (talk) 03:30, 23 November 2020 (UTC)

Did you sign the rebranding open letter? If so, please read [In fact, read anyway!]

After the rebranding process was delayed by the Board, they decided to create an ad-hoc committee to advise (method as yet unknown) the ad-hoc Board Committee on Branding, with reps drawn from several routes. Most of these are smaller groups that could be specifically contacted, so this is more spreading the word to the c.1000 who signed the community open letter (of which roughly 150 were, at time of signing, active on en-wiki). Current deadline for self-nominations is the 12th December has now been changed to the 31st January

Stated purpose

"Seeking to improve the Brand Project process, we are looking for community advisors to give input from various Wikimedia movement perspectives. The goal is to re-launch the brand discussions with a clear and transparent process in March 2021, and to conclude the conversations with a decision by the end of the fiscal year (July 2021). Though we will be approaching specific groups directly asking for advisors, I am updating the general Brand page with details, so there is clarity & transparency regarding the process."

Role activity

"The Brand Committee is looking for a small set of advisors who are able to engage thoughtfully on the importance of branding to the Wikimedia Movement’s 2030 goals. Advisors will be asked to reflect on more than processes: they will be asked to think about the strategic goals of the brand names and logos within the movement, and how to equitably structure decisions around them. Ideal advisors therefore have experience representing the movement to the public, as well as understand the internal needs of the movement’s work as something multidimensional and open. The number of advisors will be between 7 - 9 people, in an effort to support active participation within the committee, and to keep the process on track, to “un-pause” in March. By then we strive for a clear sense of a process with which the broader community will be able to engage. We have identified 3 main groups we would like advisors from:"

They estimate it will be between 6-9 hours/month.

The full details on submitting and so on are at on the open letter's talk page. In theory there should be some degree of consensus on who the two reps are - I'm not sure how that's being handled for this particular rep "source", but would encourage anyone to take a look at the talk page over the next week or so. Nosebagbear (talk) 15:04, 3 December 2020 (UTC)

Is there a magical way to make an auto-updating total? --Guy Macon (talk) 17:41, 3 December 2020 (UTC)
You've seen what they are planning to do with the logo in the default desktop skin? These people know nothing about branding. — Alexis Jazz (talk or ping me) 18:05, 3 December 2020 (UTC)
Can't we vote on putting the rebranding project in the freezer? Also, shameless plug for the userbox: {{User:Alexis Jazz/W?F}}. — Alexis Jazz (talk or ping me) 18:26, 3 December 2020 (UTC)

Community Resilience and Sustainability/2020 December Foundation commitment of support for LGBT+ volunteers

The WMF has issued a public statement in support of underrepresented communities in the movement, among which LGBTIQ+ here https://meta.wikimedia.org/wiki/Community_Resilience_and_Sustainability/2020_December_Foundation_commitment_of_support_for_LGBT%2B_volunteers --Nattes à chat (talk) 14:07, 9 December 2020 (UTC)

It's long been overdue in my opinion. Thank you, Moonriddengirl! –MJL ‐Talk‐☖ 18:29, 9 December 2020 (UTC)

Licensing

A non-starter with a tendency to become a time-sink--Ymblanter (talk) 21:38, 13 December 2020 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

All Wikimedia projects should be CC0, not copyleft licenses. The knowledge shall be public domain and used for any purpose, and without the restriction/need to attribute license, Wikipedia and contributors. The only true free knowledge are under public domain. talk@TRANSviada 14:58, 13 December 2020 (UTC)

TRANSviada, that is not going to happen. Quite aside from anything else, it would mean having to blank all 62,115,331 pages on Wikipedia and starting again from scratch (and perhaps 60 million of the 67 million images currently on Commons); unless material is already in the public domain or the authors choose to release it Wikipedia articles remain copyright to their authors, and very few people would be willing to release their contributions into the public domain (and bear in mind that most pages are the product of multiple authors, and it would only take one to object). ‑ Iridescent 15:11, 13 December 2020 (UTC)
@Iridescent: It doesn't mean that; it just one solution. Another solution would be to make past contributors re-license to CC0. People are wiling to what's the default, so put CC0 as the default. Period. Why there isn't an option to release contributions on Wikipedia under CC0? See, Wikipedia aren't allowing it to happen. To start, Wikipedia should default all new contributions to CC0. talk@TRANSviada 15:19, 13 December 2020 (UTC)
To repeat since I don't think you heard me, that is not going to happen. There is no way on Earth that most contributors are going to release their copyrights into the public domain—particularly with images, there are a lot of people who literally rely on Wikipedia credit for their livelihoods—and to repeat, it only takes one objector in the history of a page to block the release of that page. Even if everyone were happy, the logistics involved would bankrupt Wikipedia since you'd need to get the formal consent of all 48,453,517 editors in Wikipedia's entire history before it could proceed. (I'm not sure you appreciate the scale of Wikipedia. For this page alone—which is a very low-traffic page which has only existed since May—releasing it into the PD would require the explict consent of 161 different people.) The Wikimedia Foundation is the custodian of the copyrighted material it hosts on its sites, not the owner; what you're proposing is functionally equivalent to proposing to a bank that they empty their customers' accounts and spend the money themselves. Your second proposal, of making CC0 the default, would kill Wikipedia within days, since few if any of the c. 3000 regular editors who are responsible for Wikipedia's content would be willing to continue donating their time to Wikipedia if they weren't being credited, so all you'd be left with is a very poor-quality social network. ‑ Iridescent 15:36, 13 December 2020 (UTC)
I sure did not heard you, but I did read your words with my eyes. Wikipedia should PD the text—this is the content I'm mainly proposing—since the beginning, and then default CC0 with the license release. People already spend their time on Wikidata which releases the data as CC0. The same can happen to Wikipedia. Just default it to CC0. Wait 'til AI suppress humans on researching and writing; they won't care about licensing. BTW you're supposing stuff about those 3000 editors. talk@TRANSviada 15:48, 13 December 2020 (UTC)
You are entitled to your opinion, of course, but I have to agree with Iridescent: not only is it not going to happen – but it should not happen. I'm sure you are aware how the ShareAlike part of our Creative Commons Attribution-ShareAlike license actually helps keep our content free for everyone and for any purpose, which would not be possible under CC0. Without ShareAlike, anyone can make a derivative work and just run with it giving no one any rights to the derivative portion. For instance, translating an English-language public domain encyclopedia article into Spanish and reserving all rights for the translation does not sound "true free knowledge" to me at all. – Finnusertop (talk ⋅ contribs) 16:20, 13 December 2020 (UTC)
Y'all trying to bait me with personal attacks, but I have higher standards. Just because Stallman public domained his code and then got butt-hurt they wouldn't share their improvements back doesn't means Wikipedians should be butt-hurt. This already happens. The true free data is the one which anyone can use for any purpose, inclusive to make it proprietary. talk@TRANSviada 16:30, 13 December 2020 (UTC)
There are no personal attacks here, and this has nothing to do with Stallman or anyone else being butt-hurt, but it is simply a matter of finding the best nethod to create free content that anyone can use but not copyright for themselves. Let's close this thread per the comment below as a clear nonstarter. Anyone who wants their contributions to be public domain can do so, as this is a more free (I was going to write freeer but the triple "e" seemed wrong) alternative than our standard. Phil Bridger (talk) 20:41, 13 December 2020 (UTC)
  • I'm tempted to close this as a clear nonstarter that has no community will behind it, let alone enough consensus for us to need to get the WMF involved. I'll leave that to the next editor just to make it clear, but please curtail this before it spirals too long. {{u|Sdkb}} talk 19:55, 13 December 2020 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Fundraising feedback from Lemon Gras

Moved from Wikipedia:Village pump (miscellaneous)
 – Sdkb, 19:38, 11 December 2020 (UTC)

A Swiss Medium author named Lemon Gras wrote How this Message for Donations from Wikipedia is Accidentally Threatening with suggestions on how to improve. Could we make sure people at WMF see that article and consider it? A1415 (talk) 12:32, 7 December 2020 (UTC)

The Lemon Gras's comments look really interesting. If only they could make their version of a message shorter than the original.... --CiaPan (talk) 14:30, 7 December 2020 (UTC)
They did say their version needs revising. I guess it's supposed to be a starting point for a discussion, rather than a final answer A1415 (talk) 15:46, 7 December 2020 (UTC)
Except I have to dispute some fairly key components. The social proof area is a fairly common issue but they all fall down in that they fail to note that WMF fundraising may have a range of issues, but it is effective. Social proof is absolutely right when it comes to imposing restrictions, but people actually like being special when it comes to being kind or doing something moral, like donating. And then, "if you can’t give but you believe in what Wikipedia is all about, we are always looking for new contributors to help.” made me furious, as it directly proposes that fiscal donations would be more important to Wikipedia than editing donations. Nosebagbear (talk) 10:30, 8 December 2020 (UTC)
I can see where you're coming from there, but if it was rephrased I'd actually really like the pairing of a call for contributions with the fundraising banner. Adding a link to our tutorial could be give us a huge influx of new editors. {{u|Sdkb}} talk 15:28, 8 December 2020 (UTC)
Definitely an interesting read. The social proof part was something I noticed but I didn't want to second guess the marketing folks, but it's interesting someone who seems to know what they're talking about had the same thought.
Also, is it alright if we move this to the WMF pump? {{u|Sdkb}} talk 15:28, 8 December 2020 (UTC)

The author has since deleted this article. Pity: I would have liked to read it. -- llywrch (talk) 21:12, 15 December 2020 (UTC)

Llywrch, hmm, not sure why they deleted it and it looks like the Internet Archive missed it, but I was able to retrieve the text portion from Google cache, which is just missing the screenshots. I'm not sure how long Google will hold it for, but here's the link: http://webcache.googleusercontent.com/search?q=cache:o6wDNPZJuO4J:https://lemongras.medium.com/how-this-message-for-donations-from-wikipedia-is-accidentally-threatening-ef3b1d543b08&hl=en&gl=us&strip=1&vwsrc=0 {{u|Sdkb}} talk 21:32, 15 December 2020 (UTC)
Having read the cached version, I'm not sure why either. In terms of criticism, the piece is obvously thoughtful & pretty tame: more of a critique about how to better present their message than (the usual) criticism about the "give us $$$ or Wikipedia will die" tone or that the Foundation is raising too much money. -- llywrch (talk) 16:22, 16 December 2020 (UTC)
I read it too. It seems like fair comment and reasonable advice. · · · Peter Southwood (talk): 05:15, 17 December 2020 (UTC)
It seems the author deleted not only that article, but their entire Medium account and all its content. I don't know why that happened, but I doubt it's to do with that specific article. A1415 (talk) 17:53, 31 December 2020 (UTC)

Query about official publisher of Wikimedia websites

Please answer my following query

Who is the designated person in Wikimedia foundation who is designated as publisher and/or legally responible for content publshed on wikimedia foundation owned websites and domains ?

(Previously it was somebody called Lila Tretikov) — Preceding unsigned comment added by 2405:201:4004:705A:9961:93A2:5896:349D (talk) 08:23, 20 December 2020 (UTC)

The Wikimedia Foundation doesn't "own" Wikipedia per se. It hosts it, and owns its domain names and trademarks. Wikipedia itself is run by volunteers and individual editors retain the legal ownership of the material they contribute. I don't believe there's such a position as an individual "designated publisher". Lila Tretikov was the WMF's executive director between 2014 and 2016. The current executive director is Katherine Maher. – Joe (talk) 10:39, 20 December 2020 (UTC)
Actually, I learned that the designated person is Tony Sebro, Deputy General Counsel, of Wikimedia Foundation. — Preceding unsigned comment added by 2405:201:4004:705A:9961:93A2:5896:349D (talk) 12:32, 20 December 2020 (UTC)

Uploading non-free files locally to Wikipedia

Can users upload a non-free file locally to Wikipedia (not to the Commons) to use in discussions and then in an article. What are the restrictions and points to watch out for. — Preceding unsigned comment added by 2405:201:4004:705A:9961:93A2:5896:349D (talk) 17:14, 21 December 2020 (UTC)

Yes, you may upload non free files to Wikipedia, keeping in mind WP:NFCC. Particularly, they must be used in an article once uploaded, and may not be used in other places, such as talk pages. --Izno (talk) 17:54, 21 December 2020 (UTC)
However, note that in order to upload a file locally to Wikipedia (whether a free or a non-free file), a user needs to be registered and WP:Autoconfirmed. Nsk92 (talk) 18:51, 21 December 2020 (UTC)
If you're not autoconfirmed, you can go to Wikipedia:Files for upload to request that a file be uploaded. Vahurzpu (talk) 02:45, 22 December 2020 (UTC)

Wikipedia, but with essays!

Misplaced; the appropriate venue from suggesting new projects is meta:Proposals for new projects. (non-admin closure){{u|Sdkb}} talk 01:07, 25 December 2020 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

This idea might seem really stupid… It could have been thought of before, because, let's be honest, it's hardly original. I'm just throwing it out there for the internet to judge. Maybe this project page is dedicated to submitting more developed ideas. If so, I apologise.

Wikipedia is an encyclopedia. As such, a more verbose style is generally discouraged. An enyclopedia, needless to say, has a rigid structure, which needs to be observed. Content needs to be rigidly structured, because most people don't read the article for its own sake -- they read it (or more accurately, they read the conveniently placed Google infobox) because they want to know when Charlemagne was born, not because they want a summarised version of his entire life, legacy and domestic policy.

The exception being people who want intimately familiarise themselves with Charlemagne. The sort of people who, when they're older, want to write a book called 'The Life and Times of Charlemagne'. They're probably going to use the Wikipedia article as a starting point (unless they've been tasked with doing an unimaginative middle school presentations, in which case it's probably going to be their only source). And while Wikipedia certainly is a good starting point, maybe there is room for something... more?

A collection of essays the wiki way: one essay for each viewpoint, edited collaboratively, to form a canon of the world's knowledge. Sure it might not an authoritative or definitive version, but it would be a slightly more centralised solution to a problem that is usually solved by a wide variety of blogs, explanation videos on YouTube, and longer-than-allowed Twitter threads.

A couple of possible failure modes:

  • Horcruxes: Wikipedia is already prone to edit warring. It turns out that people have wildly varying opinions about how to best display certain information. This problem might intensify if you're not just editing an objective Wikipedia article on epistemology, but writing an essay on epistemology that is potentially deeply intertwined with your own world view, you might get a bit touchy when someone else decides to overturn your delicious phrasing with their own cheap talk full of meaningless tautological redundancy. If you have an opposing viewpoint, you can of course just fork the essay, or rather, write a competing one, but people are probably going to be even more invested when they're not working on a purely non-personal article designed to represent the most popular arguments on a subject, and I don't think it would be wise to have 15 different essays on Wittgenstein and skepticism. To put it more poetically, the author might invest part of his soul into the creation of the essay, so that he may live forever in his position on the correct pronunciation of the word 'Quetzalcoatl' (I don't encourage writing essays about the pronunciation of words -- I'm just making a point).
  • Underrepresented viewpoints: As with Wikipedia, there would, naturally, be people who would contribute more than the average contributor. It would be safe to assume that essays reflecting on the viewpoints of these people might be better maintained, and perhaps better written, assuming that people with an extremely good grasp of the English (or any other) language are more likely to be more active on such a project.
  • Wildly varying quality: Again, a problem which isn't unique to this kind of project, but might be more strongly pronounced. You can start an article on Wikipedia by giving a short summary on the topic. You probably shouldn't write a five line long essay on a subject, and call it a day. It might also be more difficult for non-native speakers like me to contribute to essays, if we can't express ourselves well enough.
  • It's not an encyclopedia: There'll probably be a topic nobody cares enough to write an essay enough. Of course there'd be lots of essays on philosophy, economics, or politics. But maybe nobody's imagination is sparked by computational complexity. I don't know how this would play out in real life, so maybe it's not as bad as I make it out to be.

That would be it, essentially. Please excuse some of the more obvious (both syntactical and semantical) mistakes I've made, it's midnight here in Central Europe, and I'll go back to bed now. Merry Christmas to all, and to all a good night! Milanandreew (talk) 23:17, 24 December 2020 (UTC)

So, Google Knol? --Izno (talk) 23:55, 24 December 2020 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Discussion at Wikipedia:Village pump (proposals) § Proposal to change logo for 20th anniversary

 You are invited to join the discussion at Wikipedia:Village pump (proposals) § Proposal to change logo for 20th anniversary. — Wug·a·po·des​ 22:46, 13 January 2021 (UTC)

Problem with an image

I don't know of this is the right venue, but this link, the celebration link, leads to a page that includes [16] this image, which contains the copyrighted and trademarked 2018 FIFA World Cup logo. (CC) Tbhotch™ 04:27, 15 January 2021 (UTC)

It looks like a tiny screen shot to me. If that's not fair use, I don't know what is. – Jonesey95 (talk) 16:14, 15 January 2021 (UTC)

Editing news 2021 #1

Read this in another language • Subscription list for this newsletter

Reply tool

Graph of Reply tool and full-page wikitext edit completion rates
Completion rates for comments made with the Reply tool and full-page wikitext editing. Details and limitations are in this report.

The Reply tool is available at most other Wikipedias.

  • The Reply tool has been deployed as an opt-out preference to all editors at the Arabic, Czech, and Hungarian Wikipedias.
  • It is also available as a Beta Feature at almost all Wikipedias except for the English, Russian, and German-language Wikipedias. If it is not available at your wiki, you can request it by following these simple instructions.

Research notes:

  • As of January 2021, more than 3,500 editors have used the Reply tool to post about 70,000 comments.
  • There is preliminary data from the Arabic, Czech, and Hungarian Wikipedia on the Reply tool. Junior Contributors who use the Reply tool are more likely to publish the comments that they start writing than those who use full-page wikitext editing.[17]
  • The Editing and Parsing teams have significantly reduced the number of edits that affect other parts of the page. About 0.3% of edits did this during the last month.[18] Some of the remaining changes are automatic corrections for Special:LintErrors.
  • A large A/B test will start soon.[19] This is part of the process to offer the Reply tool to everyone. During this test, half of all editors at 24 Wikipedias (not including the English Wikipedia) will have the Reply tool automatically enabled, and half will not. Editors at those Wikipeedias can still turn it on or off for their own accounts in Special:Preferences.

New discussion tool

Screenshot of version 1.0 of the New Discussion Tool prototype.

The new tool for starting new discussions (new sections) will join the Discussion tools in Special:Preferences#mw-prefsection-betafeatures at the end of January. You can try the tool for yourself.[20] You can leave feedback in this thread or on the talk page.

Next: Notifications

During Talk pages consultation 2019, editors said that it should be easier to know about new activity in conversations they are interested in. The Notifications project is just beginning. What would help you become aware of new comments? What's working with the current system? Which pages at your wiki should the team look at? Please post your advice at mw:Talk:Talk pages project/Notifications.

–Whatamidoing (WMF) (talk) 01:02, 23 January 2021 (UTC)

About the discussion tool:
*It is buggy. E.g. when I reload the page while I have a "reply" section open, it doesn't discard that section but keeps it open, which is not wanted with a page refresh)
*Where is the preview?
*Why is VE the default? VisualEditor should never be the default.
*Why is the edit summary hidden in an "advanced" section? Edit summaries should be the default, not something tucked away.
*I made this in "Visual" mode, and I notice that using "bullet points" in my reply (not an outlandish feature on a talk page surely?) creates the dreaded VisualEditor "nowikis". Please, no...
That's from a first test using only the very simplest of things (nothing fancy). Are you really sure that this is Beta-ready and shouldn't be labeled "Alpha" and kept away from live environments? Fram (talk) 16:05, 26 January 2021 (UTC)
The reload behavior could've been chosen either way, and is a matter of preference, not a bug. The preview shows up when you pick "Source"; with "Visual", a separate preview is unnecessary. Visual is the default presumably for new editors; I figure there will be a preference to set the default if one doesn't already exist. An edit summary is usually pointless for replying to a discussion; "Reply" works well enough. Bullet points seem to turn into real bullet points if you type a space after the asterisk, although I suppose writing an asterisk on a new line probably could be interpreted as starting a list. The experience otherwise seems beta-ready to me; I don't see any bugs. Enterprisey (talk!) 02:39, 27 January 2021 (UTC)
I have been using it for over a month and would agree that it's beta ready. In terms of the edit summaries there is a default edit summary: reply. Slightly less useful than reply link's edit summary but also you can't (that I'm aware of) change reply link's edit summary but you can this discussion tool's. And once you click advanced it stays open so you can always have the edit summary a few tabs away when doing a reply (in source of course). Barkeep49 (talk) 03:20, 27 January 2021 (UTC)
Reply-link does have a preference for it, but you have to go to the documentation page to find it. I would agree this isn't optimal, and the normal interface should have some way to set it. Enterprisey (talk!) 03:35, 27 January 2021 (UTC)
I figure there will be a preference to set the default if one doesn't already exist It just remembers what you used last and uses that, afaik. Majavah (talk!) 07:12, 27 January 2021 (UTC)
For me it still seems to have issues executing when the comment before starts with a ping template. Since that is a not inconsiderable sum, it means it doesn't work for a lot of messages. Is this just me or a known bug - I had a quick look but wasn't able to find a long list of known bugs without going to phab. Nosebagbear (talk) 10:29, 27 January 2021 (UTC)

Change in Foundation bylaws

Just saw this reported on the Wikimedia general chat Telegram channel: Wikimedia Foundation Board noticeboard/January 2021 - Approval of Bylaws amendments and upcoming call for feedback about the selection of new trustees -- llywrch (talk) 17:38, 21 January 2021 (UTC)

Thanks, llywrch for posting this. You beat me to it! I look forward to talking with you all Call for feedback: Community Board seats. Best, JKoerner (WMF) (talk) 13:41, 22 January 2021 (UTC)
Thanks for posting this. Ensuring community/affiliate majority and for it not to be Board appointed was my top priority and I'm pleased to see that this has happened even if the details of how this will work going forward still need to be worked out. Best, Barkeep49 (talk) 17:57, 21 January 2021 (UTC)
Yeah, this seems like as close to an ideal outcome as one could have hoped for in my opinion. –MJL ‐Talk‐☖ 19:21, 21 January 2021 (UTC)
@Barkeep49: you are more optimistic than I, to me it still reads that the Board is intending on offering a range of different conditions that the Community will have to meet. Anything beyond a standard nomination process and direct vote by individual Community members should have been ruled out (legal notwithstanding). Nosebagbear (talk) 10:35, 22 January 2021 (UTC)
I find community-and-affiliate-selected to be satisfactory for now. It's possible I'll have concerns when the details are revealed, but this aligns my goals (community/affiliates deciding rather than the board) with the language and so I will indeed take the win. Best, Barkeep49 (talk) 16:29, 22 January 2021 (UTC)
I still don't understand the legal problems that prevent direct elections of the board across international boundaries. IEEE manages to do this, & have for decades. I'm sure there are other examples. -- llywrch (talk) 16:10, 22 January 2021 (UTC)
@Llywrch: Under Florida law (where the WMF is incorporated), identities of voting members of nonprofit organizations must be publicly disclosed. Changing Board elections to direct legal elections would prevent contributors that prefer to remain anonymous from participating. (I've suggested a workaround try to solve part of the problem with the current situation.) --Yair rand (talk) 10:18, 26 January 2021 (UTC)
Hmm. I don't remember that issue being mentioned back in the beginning; I know the choice was not offered to us volunteers at the time. Maybe anonymity was that important to the community; maybe enough us would have accepted losing it in order to maintain control over things. (Or it could have been incorporated in another state -- the only ties the Foundation currently has with Florida is that is where it is incorporated, which can be changed, if desired.) But as it was explained to me, the problem was because of the Foundation's international character. -- llywrch (talk) 00:20, 27 January 2021 (UTC)
There is new movement on this including the chance to participate in one of three virtual sessions about this next week. See more at meta. Best, Barkeep49 (talk) 15:41, 28 January 2021 (UTC)
Please see:
--Guy Macon (talk) 20:03, 28 January 2021 (UTC)

Please help me understand this W?F page

Apparently I am unable to understand the following document:

[ https://foundation.wikimedia.org/wiki/Bylaws ] Section 3. Selection and Appointment.

(For some reason I cannot create a link that goes directly to that section.)

  • How many trustees will be selected by some sort of !vote by individual volunteers?
  • How many trustees will be selected by the affiliates?
  • How many trustees will be selected by the W?F?

I am trying to figure out if the following is possible under the above rules:

  • The majority of the trustees are selected by affiliates
  • A minority of the trustees are by the W?F
  • The rest of us get zero representation.

After all. if you combine community seats and affiliate seats into one category, it could by 0% community / 100% affiliate, 100% community / 0% affiliate, or anything in between, right?

The "up to" language is also concerning. "Up to 8" could mean 1 or even 0, right?

Finally, does "sourced from candidates vetted through a Community and/or Affiliate nomination process" mean "selected by the W?F, not the affiliates or the community"?

--Guy Macon (talk) 09:32, 29 January 2021 (UTC)

wmf:Bylaws#Section 3. Selection and Appointment. — GhostInTheMachine talk to me 10:31, 29 January 2021 (UTC)
  • (IV.3.C.i) says As many as eight (8) Trustees will be sourced from candidates vetted through a Community and/or Affiliate nomination process. and that process is defined by the Board (IV.3.C.ii).
    So there could be no candidates chosen by the volunteer community or if there are, the Board's approvers (IV.3.C.ii) may reject them all (IV.3.C.iii) and (after an undefined time) appoint anybody else instead (IV.3.C.iii.c → IV.6).
    Also — Up to 8 can, in this case, be 1 but not zero (IV.2.A says 9-16 total – 9=7+JW+1 or 9=7+(no JW)+2). — GhostInTheMachine talk to me 11:34, 29 January 2021 (UTC)
  • The bylaws are vague enough that the Board can do whatever it wants. The only real limitations is that it must hold some sort of community/affiliate based selection process for 1-8 of the seats and consider the results. --RaiderAspect (talk) 13:44, 29 January 2021 (UTC)

Urgent: Vote about to close on community representation for the Foundation's Rebranding committee

Summary: The Foundation has been running a rebranding project, involving organization names and logos etc. Various documentation made it clear that the plan involved renaming Wikimedia Foundation to "Wikipedia Foundation" or something similar. An RFC at Meta received 586 votes and reached over 92% consensus that it was not acceptable for the Foundation to call itself Wikipedia.[21] The rebranding team then proceeded with a plan and community-survey where every available option was restricted to renaming the Foundation as "Wikipedia" in some form. (Wikipedia Trust or Wikipedia Network or Wikipedia Foundation.) This, and other strong community complaints, lead to a Community open letter on renaming signed by over one thousand editors and affiliates and orgs. The letter asked the Board of Trustees to pause or stop the rebranding project. The Board did pause the process and declared they would establish a committee for "developing and proposing changes to the Movement Brand Project process", after which the process would resume. The Board declared that the committee would consist of:

  • 2 seats to be filled by the Affiliate leadership.
  • 1 seat filled from the Affiliate Committee.
  • 2 seats to be filled by Affiliates, with those Affiliates specifically designated by the Board from the global south / emerging and underrepresented communities.
  • 2 seats to represent the general community, with those seats specifically designated for "people who participated in authoring the Community Open Letter on Renaming".

As far as I am aware, there are currently only two known candidates to fill the two seats to represent us. To avoid canvassing one way or the other, I will invite people to view the discussion on Meta to learn more about the candidates. I will merely mention that the vote is currently evenly split to accept both or reject both candidates.

As far as I'm aware there has been approximately zero advertisement of this vote, and the current vote is evenly split with exactly half coming from Affiliates. We are technically past the deadline for voting. If you wish to participate, I suggest you hurry.

Voting is at Meta:Talk:Community open letter on renaming#Nominations from among COLOR authors.

Alsee (talk) 16:22, 2 February 2021 (UTC)

Updated Universal Code of Conduct draft ratified by Board of Trustees (February 2021)

Hello all,

Today the Board of Trustees announced that they have ratified an updated draft of the Universal Code of Conduct (UCoC). The update makes changes to four sections, adding clarifying language and reinforcing concepts in the October 2020 draft. These changes can be seen in the change log.

With this announcement, the project moves into Phase 2. The meta:Universal Code of Conduct page has an updated timeline that includes the major engagements ongoing and over the next few months. There is also an updated Frequently Asked Questions page with information on next steps, the current status of the UCoC, and more.

Please let me know if you have any questions. Xeno (WMF) (talk) 18:00, 2 February 2021 (UTC)

https://foundation.wikimedia.org/wiki/Terms_of_Use/nl

Hi, anybody hanging around willing to take a look at the page? Imo, it might not be a bad idea to have someone like MarcoSwart take a closer look at it. Thank you for your time. Lotje (talk) 15:01, 3 February 2021 (UTC)

FYI: WMF Executive Director to step down April 15

Announcement on the mailing list. --Yair rand (talk) 03:00, 5 February 2021 (UTC)

Dang, that's a bummer. –MJL ‐Talk‐☖ 04:12, 5 February 2021 (UTC)

Well with luck it will go better than the last planned handover.©Geni (talk) 07:19, 5 February 2021 (UTC)

I do not see why, the procedure seems to be exactly the same.--Ymblanter (talk) 07:47, 5 February 2021 (UTC)
Different people. More experience.©Geni (talk) 09:45, 5 February 2021 (UTC)
Unfortunately, we had a few showcases recently which demonstrate that the collective learning curve of the WMF is, if not flat, not very steep. They continue making the same mistakes which they made 15, 10, and 5 years ago. And people making them are often different. We will see.--Ymblanter (talk) 09:54, 5 February 2021 (UTC)

WMF Board of Trustees Consultation: Community Board seats selection & form

The WMF is running a consultation on the nature of the Community trustees - both on the selection method (through a sub-committee vs through direct election), quotas, and more.

There is both a general discussion page and subpages for specific proposals.

Please participate and spread word to other suitable locations as appropriate.

Cheers, Nosebagbear (talk) 17:11, 5 February 2021 (UTC)

What's the point? The board clearly doesn't care what we say and nothing we say matters. Jimmy Wales already stabbed us in the back after insisting he wouldn't vote for taking away our vote -- which he did -- and the community has largely stood by and watched this happen. This ending of any semblance of community control of Wikipedia should have been fought with 100 times the passion of FramGate or WMF changing its name and...nothing. CoffeeCrumbs (talk) 02:41, 7 February 2021 (UTC)

Second office hours - Call for Feedback: Community Board seats

Hi all, I want to announce the second office hours for the Call for Feedback: Community Board seats.

The Call for Feedback about Community Board seats selection processes is happening between February 1 and March 14. With the help of a team of community facilitators, we are organizing conversations and gathering feedback. It is not too late to join the conversation! Talk to you all soon! Best, JKoerner (WMF) (talk) 22:52, 16 February 2021 (UTC)

[Copied across from WP:VPM]

UCOC Survey

There doesn't seem to be an UCOC survey for enwiki, but you can participate in e.g. the Wikidata one, here. Most questions are not Wikidata specific anyway, and a fair number are hardly intelligible. E.g. "In the event consensus will be reached about the establishment of an "enforcement body", either on Wikidata or within the Wikimedia community, to address harassment and threats, how much do you agree with the following statements? ... Larger communities should have the possibility to opt-in the scope of action of such "enforcement body", should there be consensus about it." Do you agree or disagree with this? No idea, I don't know how a community can "opt-in the scope of action"[sic] if the enforcement body is established locally in the first place. Fram (talk) 14:35, 12 February 2021 (UTC)

I have seen that a survey has been sent to some people on Commons though the questions are different between the two surveys seemingly reflecting that the two "facilitators" are different people. Xeno (WMF) what can you tell us about enwiki? Best, Barkeep49 (talk) 16:07, 12 February 2021 (UTC)
Thanks for the questions Fram & Barkeep49: some local consultations started earlier as they required more time due to the translation workflows or multilingual nature of those projects (and while I've been following along, the individual facilitators would be better placed to discuss).
For enwiki, the upcoming consultation planned for March (entitled "Meta-wiki consultation") which I'm designing will involve global discussions as well as discussions that are tailored to individual projects. I hope to ensure that any points where the global policy is impractical in individual community contexts are identified and clearly highlighted to the drafting committee writing the application section.
Please let me know about any other ongoing local discussions, or if you have any thoughts about the upcoming consultation. Xeno (WMF) (talk) 20:40, 18 February 2021 (UTC)
@Xeno (WMF) I feel like I have less of a grasp on what will happen than before i started reading this message. Enwiki editors will be expected to participate in meta conversations if they want a voice? Best, Barkeep49 (talk) 21:11, 18 February 2021 (UTC)
Barkeep49: The goal is seek feedback from editors of all communities, so discussions that happen locally will be considered and are linked from meta:Universal Code of Conduct/Discussions#Community discussions. Since the formal consultation will involve many different languages and project types, we're still finalizing the exact process to ensure all the feedback is properly organized and considered. Xeno (WMF) (talk) 21:49, 18 February 2021 (UTC)
Well it seems to me that the goal is to solicit feedback from everyone but especially the Arabic, Bangla, Indonesian, Italian, Korean, Malay, Nepali, Polish, and Yoruba Wikipedias plus Wikimedia Commons and Wikidata. Like the nice part of me wants to be sympathetic to the idea that there are probably some really great ideas being planned behind the scenes that just aren't finalized enough for you to reveal yet and if I'm patient there will be some comparable consultation with enwiki.
However, there's another part of me that is less charitable. That part of me is based on past experiences with foundation initiatives. Not with foundation staff, I have worked with a variety of foundation staff and on the whole have found them just absolutely delightful and competent at their jobs. However, initiatives seem to be this other thing at the foundation and so my personal affinity and respect for a number of staff doesn't translate to good results. Perhaps it's the people who I haven't worked with driving those initiatives and overruling the good staff who I do know. That part of me says that I should be alarmed that you won't commit to a discussion with enwiki. That part of me is resigned to the fact that it's only large scale anger that has a prayer of getting foundation attention and has me already beginning to think how we would go about generating that kind of attention, perhaps building on our own ability to work cross wiki without the foundation in the middle. I don't like it when I can't convince myself that the nice part of me is what should win out. Sadly, Barkeep49 (talk) 22:52, 18 February 2021 (UTC)
Barkeep49, I had the impression (I'd have to look for diffs to support that claim) that the UCoC was written to codify the existing consensus on the projects that have robust behavioural policies. It was not supposed to conflict with existing enwp policies. As far as its authors are concerned, if I understand them correctly, nothing will change for English Wikipedia. Unfortunately, they are very quiet. Not one has engaged in the discussion of their work. Vexations (talk) 23:10, 18 February 2021 (UTC)
Vexations, I mean I've heard Maggie Dennis (noping: Mdennis (WMF) ) say something similar during office hours. And I don't actually have much to quibble with in the UCoC and certainly don't see anything that brings it into conflict with enwiki policies/guidelines. I would go so far as to say I support the UCoC in principle. However, enforcement is the whole ball game and if it is decided that the UCoC is to be regularly enforced on enwiki that's going to be a problem. And that's what phase two is about: how should the UCoC be enforced. So I would expect that enwiki is consulted so they don't just hear these concerns from me, but from the community writ large. And we're here because Xeno can't or won't say that enwiki will be consulted unlike 9 specific Wikipedias plus the two largest non-wikipedia projects. Instead Xeno seems to have written a response to a nice open ended question asking about what he can tell us about enwiki with an answer that boils down to "I can tell you nothing about enwiki". The answer maybe implies enwiki will be one of the "individual project" discussions are "tailored" to. Or maybe it doesn't imply that at all. And so rather than being patient knowing that our time will come, I'm forced to be a Talmudic scholar deciphering missives from a foundation representative. Best, Barkeep49 (talk) 23:28, 18 February 2021 (UTC)
@Vexations: I too have had this impression. Frankly, I am worried that communications from WMF staff on this front have been deceptive, and that enwiki will be more deeply affected by the UCoC and the Global Council than anyone would have reasonably anticipated. KevinL (aka L235 · t · c) 23:50, 18 February 2021 (UTC)
Sorry Barkeep49 if I wasn't clear: input from enwiki will be integral to the consultation, and my goal is to ensure the input of this community (and every community) is given due attention, and that individual users are comfortable expressing their thoughts and opinions. I welcome input on how best to achieve that goal. Xeno (WMF) (talk) 00:09, 19 February 2021 (UTC)
"input from enwiki will be integral to the consultation": I sure hope so, but that would be a first in this whole UCOC thing, where the actual UCOC is already finalized and the enforcement rules will be written before the largest communities (en, fr, de) are heard for the first time. I fear this is yet another token consultation which won't change a thing, with feeble excuses like "we are already too far in the process to change that now" or "we hear you" (without actually doing anything). All of this is yet another top-down WMF effort (like the rebranding and so many other things), with the same mistakes being made in all of them. The query I linked will probably used to justify some decisions as well, even though some of the questions are incomprehensible and thus the answers worthless (and some others are very leading in the choices given). Anyway, thanks for answering here. Fram (talk) 09:09, 19 February 2021 (UTC)
@Xeno (WMF): I'm a bit confused. Should we be waiting for someone from the WMF to organise a survey or discussion on the UCOC on enwiki? Or should we start one ourselves and then link it at meta? – Joe (talk) 11:11, 19 February 2021 (UTC)
Joe Roe: It probably makes sense to hold for the structured conversations, where the discussions will be facilitated and organized into major topic groups. The first round (planned for March) will be asking broad questions about potential application of the UCoC globally and in individual community contexts. There is also a parallel consultation ("Functionary consultations") inviting input from Arbitration Committees, CheckUsers, Oversighters, Stewards, and other functionaries. The second round (planned for mid-2021) will seek community input on the proposals created by a drafting committee using the input gathered in earlier rounds. Xeno (WMF) (talk) 14:51, 19 February 2021 (UTC)
The statement I was looking for is summarized in the answer to question 13 of the Universal Code of Conduct/FAQ I'm not sure if there ever was a statement that enwp's policies do meet or exceed the UCoC expectations
Earlier statements from the board do not give the impression that the existing enwp policies are sufficient: [22] for example, and especially the Board's Statement on Healthy Community Culture, Inclusivity, and Safe Spaces, which states rather bluntly : The Board does not believe we have made enough progress toward creating welcoming, inclusive, harassment-free spaces in which people can contribute productively and debate constructively. Vexations (talk) 21:17, 20 February 2021 (UTC)
Re. "some local consultations started earlier as they required more time ... individual facilitators" and "welcome input on how best to achieve that goal". I read the Commons and 'Data conversations last week, and ran the non-English-language discussions through Google Translate (haven't checked back this week yet). I hope they get down to the nitty gritty in time. I got the impression that the questions being asked so far are very general and bland, like 'how do you feel about the Code?' and 'how do you think you should report conduct problems?'.
It's interesting to compare the general tone of the responses across language communities. Bangla seems to be like 'this is really good we need this'. Polish is 'go away why is Foundation imposing this we already have an admin noticeboard and an arbcom and we are a lot more civil than wp:en'. In Arabic several people said they would support a Code if they could have input into its formulation, not realizing that ship had already sailed. (Apologies if I am misinterpreting or misrepresenting those discussions.)
I'm glad to see that Xeno (WMF) is involved in this. But I still fear that despite having some good facilitators, management direction will result in the consultations just asking us in vague terms what we want, then doing something else anyway. (Then W?F will claim community support for whatever the hell it is the W?F wanted in the first place, because "consultations were held and they were very thorough and successful". And when we say that we didn't ask for this, W?F will say it was directed by the Board, and the Board will say it was "requested by the community" in the Strategy 2030 process, just like how Shani is saying the community requested rebranding.)
What we really need is some concrete proposals on the table that we can hash out. Probably English Wikipedia and some of the other "ornery" Wikipedias (de, ru?) will go into depth regardless of the questions asked. But will we be listened to? Pelagic ( messages ) – (11:30 Sat 20, AEDT) 00:30, 20 February 2021 (UTC)
  • @Barkeep49, Vexations, L235, and Xeno: - it clearly isn't intended to be just a formalisation for those communities with significant conduct policy already in place, because in the UCOC-formation "consultation" there were multiple comments from WMF staff, plus the ongoing surveys' questions, suggesting they want a private conduct submission process (even for just on-wiki conduct issues). That suggests the ability to know one's accuser, accused knowing all the evidence against them (in all but the most egregious cases), standard review of accuser's behaviour, etc are not going to be the case. If there is going to be a later meta discussion, there must also be an earlier en-wiki (and de-wiki, etc etc) discussion. The WMF, to me, seems to be prepping to go "some communities want this, and that outweighs what 75% of the editors want" or "we're too far into the process, we'll take your thoughts into account in the actual execution) Nosebagbear (talk) 15:44, 20 February 2021 (UTC)
    Listen I'm clearly willing to gripe at the foundation and am skeptical about their intentions. But I think it's a stretch to say they want a private conduct submission process (even for just on-wiki conduct issues). That suggests the ability to know one's accuser, accused knowing all the evidence against them (in all but the most egregious cases), standard review of accuser's behaviour, etc are not going to be the case. I think they're throwing out a lot of concepts - see the idea of "volunteers" being paid for this work mentioned in the commons survey - not knowing what will work best. I think they don't have the answers. But I also don't think they're going to have a process that will allow for comments except for answers to questions they ask and I think they're going to move at a speed incompatible with the scope of this task. Barkeep49 (talk) 16:30, 20 February 2021 (UTC)
    Since you pinged me as a volunteer, I get to reply as one: This is the way =)
    From the commons/wikidata prompts: "How do we balance privacy and safety of reporters with transparency and accountability of reports?" This is something that our community grapples with also, so it is not unexpected the Foundation is seeking advice on how to balance these needs in a manner acceptable to the communities. Enwiki already has a private conduct submission process (even for just on-wiki conduct issues), so the answer from enwiki users might be: "route it to arbcom-en". Shunting it to community members doesn't necessarily solve the problem, though as the balance still needs to be struck by someone. I've found that the private reporting system can still reduce harm without necessarily throwing transparency and accountability out the window: Private reports received at arbcom-en may result in a dialog with the reporting user to determine their level of comfort for the committee's possible responses, as even taking on-wiki action (or even privately contacting the reported user(s)) to address the reported behaviour can cause additional harm in unintended ways. A private reporting system could allow editors to seek assistance with experiences they are receiving as harassment in a non-public space and receive support from users experienced or trained in harm reduction to assist them with addressing the concern in ways the editor had not previously contemplated. –xenotalk 18:00, 20 February 2021 (UTC)
    @xeno: okay but what does Xeno (WMF) have to say about this? –MJL ‐Talk‐☖ 23:24, 20 February 2021 (UTC)

IP Address Masking Confirmed As Mandatory

Per a recent update on the IP Masking project, Legal has apparently decided that IP masking is no longer desirable but mandatory, with consultation now limited to implementation form.

Thus far Legal have not provided reasoning on that, but they are set to give a statement (detail level unknown), likely in the next week.


As this will have a significant effect on anti-vandalism efforts, please provide your ideas, concerns, and comments on the discussion page on how to mitigate any negative consequences and utilise any potential positives. Nosebagbear (talk) 10:19, 19 October 2020 (UTC)

This link will be useful here--Ymblanter (talk) 11:01, 19 October 2020 (UTC)
Looks like we need, and will have, an RFC on this. Alsee (talk) 09:38, 23 October 2020 (UTC)
I believe that our traditional workflow is as follows:
  1. The W?F proposes something on an obscure meta page. Nobody notices.
  2. The W?F posts it somewhere else, and literally everyone who replies hates it.
  3. The W?F reaffirms their commitment to listening to user feedback.
  4. The W?F announces that they are going to go ahead and do it anyway and you can all go and pound sand.
  5. An RfC is posted. Hundreds of people contribute. The result is overwhelmingly negative.
  6. The W?F goes ahead and does what they were always planning on doing.
  7. The shit hits the fan, admins resign, The Signpost does a feature. Wikipediocracy does a feature. The Register does a feature. The Guardian does a feature. The New York Times does a feature.
  8. The board of directors tells the W?F to knock it off. Nobody gets fired or demoted.
  9. Return to start.
I will make popcorn. --Guy Macon (talk) 17:19, 23 October 2020 (UTC)
Sometimes they skip step 4 and go straight to step 6, which we then follow with step 5. Extra butter, please. – Jonesey95 (talk) 17:58, 23 October 2020 (UTC)
Depiction of Wikipedia Foundation Wikimedia Foundation destroying Wikipedia with the Fram ban, IP masking, and the 2020 rebrand instead of making obvious but boring improvements to what we have. —pythoncoder (talk | contribs) 18:52, 24 October 2020 (UTC)
The W?F has thrown a lot of crap at us before, but basically saying "we want more vandals" is a new low. Popcorn tastes good. —pythoncoder (talk | contribs) 18:52, 24 October 2020 (UTC)

This might be a good next step. -- RoySmith (talk) 21:30, 1 November 2020 (UTC)

I've said this elsewhere, but didn't gain much traction. Showing IP info to logged-in users isn't a problem. Exposing it to every anon, scraper and mirror is a problem. But W?F want to hide it from all of us. Pelagic ( messages ) – (20:33 Thu 05, AEST) 10:33, 5 November 2020 (UTC)

  • There should be some freedom for project communities to decide which flag should include the technical right to see IPs. Some projects may decide to allow it to patrollers, other only for admins (W?F proposal doesn't even allow admins). Ain92 (talk) 20:07, 29 November 2020 (UTC)
What is the exact legal issue? Can wikipedia just encrypt the ip address with a different id for each edit? Wakelamp d[@-@]b (talk) 13:16, 14 December 2020 (UTC)
  • I think every edit should be randomized, so you never know who made what edit, on talk pages and articles. 100% mystery, even admin actions and Arb discussions. That would fix all our problems and make Wikipedia a great place to be an admin at. Maybe they will bump it up to that. Dennis Brown - 2¢ 23:13, 10 January 2021 (UTC)
  • I never thought I would wind up advocating that we suspend IP editing, but that now seems to be the sensible option, at least until the WMF has a solution in place and working reasonably well on a sizeable Wikipedia. ϢereSpielChequers 23:34, 10 January 2021 (UTC)
I say this advisedly. You have got to be fucking kidding?--Fuhghettaboutit (talk) 06:02, 24 February 2021 (UTC)

Latest versions of browsers break Wikimedia single sign-on

Tracked in Phabricator
Task T226797

Recent Firefox and Safari browsers now have "total cookie protection" sandbox cookie storage to prevent cross-site tracking by third party cookies. Unfortunately, this also seems to break the Wikimedia single-sign-on mechanism. See https://hacks.mozilla.org/2021/02/introducing-state-partitioning/ for a description of how it works.

This clearly either needs WMF liason with Mozilla and other browser vendors to whitelist the single sign on mechanism, or to use the Storage Access API to request it be permitted on a site-by-site basis.

TheDJ has filed a bug phab:T226797 for this behavior on Safari, and I can confirm that Firefox 86.0 now shows the same behavior. Apparently Chrome will do the same on the next release.

This is a blocker for serious cross-wiki editorial work, and needs to be fixed ASAP -- how best can we get the WMF's attention on this? -- The Anome (talk) 10:08, 25 February 2021 (UTC)

The phab ticket is indeed the right way. I've added a pointer to this discussion to the phab ticket and requested that it be given high priority. -- RoySmith (talk) 14:10, 25 February 2021 (UTC)

enwiki Board consultation?

Ok then, we'll try this over at AN. Barkeep49 (talk) 02:17, 26 February 2021 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Attending the office hours last weekend thanks to Nosebagbear's notification, the the WMF emphasized that they are willing to hold guided/moderated discussions about this topic with particular groups/communities. Is this something other editors of English Wikipedia would be interested in having? If so I think we can let the WMF know so a date/time could be found to do it. Best, Barkeep49 (talk) 22:01, 25 February 2021 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Broader concerns about difficulty of getting phab tickets resolved

  • Also, I hope that this specific issue gets handled here, but the larger point that I think this highlights is that it's incredibly difficult to get phab tickets resolved. I sympathize that there are limited developer resources, but Wikipedia has fallen really far behind most of the rest of the web in the basics, and the focus seems to be on building new (sometimes desired, sometimes not) products rather than patching up the core. Having a wishlist once a year where the community collects together hundreds of urgent problems that have already been reported (in some cases for years) and then a tiny team tackles the top 10 is nowhere near enough. Items 10-50 are essential, too. When a problem like this has been on phabricator for a year, we shouldn't have to come here to beg for it to get attention. I could point to plenty of other tickets in a similar situation. What steps could be taken to get significantly more phab tasks out of the backlog? {{u|Sdkb}} talk 18:55, 18 February 2021 (UTC)
    Sdkb, To be fair to the MWF, the focus seems to be on building new (sometimes desired, sometimes not) products rather than patching up the core has been true on every project I've ever worked on. New stuff is sexy. It's what everybody wants to work on. Most engineering organizations overtly encourage this attitude by putting their best people on new projects, and by rewarding shipping new stuff with raises and promotions, to a greater extent than doing maintenance. -- RoySmith (talk) 19:08, 18 February 2021 (UTC)
    RoySmith, for the foundation, the cause is slightly different. The original idea was that they would work 'on the big things' and that the MediaWiki community can pick up the smaller tasks. This concept really stems from around 2009. Unfortunately since then volunteer development hasn't really increased, while MediaWiki itself has become a lot bigger and more complex. I've indicated multiple times in multiple interviews with WMF that I think it is not wise to have so many smaller problems in existing code, with NO owner, and that it creates quality problems.
    Since 2015 there is a core team that thinks about such problems in core, but that team is rather invisible to most of the community (they deal mostly with database, caching, api and authentication issues, keeping things running rly). I have also stated multiple times that we should have at least a 1000 developers.... but this seems to be impossible/unwanted. —TheDJ (talk • contribs) 09:58, 19 February 2021 (UTC)
    I agree that the urge to work on shiny new features persists everywhere - maintaining things is often boring and repetitive, with little 'to show' for your work, while developing new features has an obvious impact. However, maintenance is incredibly important lest a project accumulate an unworkable amount of technical debt. I'd be happy to look at contributing a pull request for this myself if I can dust off my rather rusty PHP skills, and figure out just how you actually go about submitting a PR for MediaWiki. ƒirefly ( t · c ) 10:43, 19 February 2021 (UTC)
    Firefly, please see mediawikiwiki:New_Developers —TheDJ (talk • contribs) 10:48, 19 February 2021 (UTC)
    Aha, that looks like what I need. Thanks! ƒirefly ( t · c ) 10:51, 19 February 2021 (UTC)
    Firefly, and more specifically for MediaWiki: How to become a MediaWiki hacker —TheDJ (talk • contribs) 11:07, 19 February 2021 (UTC)
    Yeah, found that - thanks! ƒirefly ( t · c ) 11:43, 19 February 2021 (UTC)
    For me, the issue I have with contributing to MediaWiki development is: (1) I really dislike Gerrit; (2) code reviews are irritating; (3) it's irritating to get WMF sign off on various things I'd want to work on. WMF don't really respond to tickets half the time (fair enough there's a limited amount of attention to go around). Some projects (like FlaggedRevs) are totally abandoned; I wanted to work on improvements to that codebase but there's nobody that will actually code review changes to it. The idea that volunteers work on all the boring/maintenance/smaller stuff and paid devs get to work on the fun stuff is icky. ProcrastinatingReader (talk) 12:01, 19 February 2021 (UTC)
    ProcrastinatingReader, When you say, "code reviews are irritating", do you mean WMF does them in an irritating way, or are you objecting to the entire concept of code review? -- RoySmith (talk) 16:26, 19 February 2021 (UTC)
    I mean some patches just don't get reviewed quickly, or are in obscure parts of the codebase that few people want to review. There's an Echo patch I started (but someone else finished/did much of the work on) which allows for Echo notifications to be given for multi-rev reverts. Still awaiting code review. Of course code should be reviewed, just it's not exactly motivating to have to wait months for patches lying around till they get deployed. This isn't uncommon in many orgs, especially large enterprises, I acknowledge. But compare this to, say, editing here and getting consensus on issues in a week or a month max via RfC. ProcrastinatingReader (talk) 16:30, 19 February 2021 (UTC)
    Since 2015 there is a core team that thinks about such problems in core Your timeline is a little off. Up until 2015 there was a core team. In 2015 it split into several smaller teams, and then three weeks later the "core" part was disbanded by WMF executives. A new core team was re-formed in 2017. Then in 2019 or 2020 the focus slowly started shifting to "new shiny things" again. I haven't kept track since to see to what extent they still pay attention to "core" stuff, but as with the 2015–2017 period I'm sure the devs that are left still try to pay attention to core even if management is focused on shiny things. Anomie⚔ 13:54, 19 February 2021 (UTC)
    The dates when the core team was disbanded then reassembled appear to match when Lila Treitikov was head of WMF. If there is a connection, then it would confirm something about the WMF I've long suspected: no one there understands how to properly integrate the technology side with the educational mission. If a technical person is put in charge, the wants & ideas of that side are prioritized -- often to the detriment of the community of volunteers. If a non-technical person is put in charge, that person often has no grasp of how to manage the technical side & ends up being buffaloed into allowing the technical side do whatever it wants. Unless you are interested in promoting technical solutions all of the problems with Wikipedia & the other projects (e.g. "AI will solve all of our content issues"), it is difficult if not impossible to get heard, let alone allowed to enact ideas. -- llywrch (talk) 22:07, 21 February 2021 (UTC)
    I don't think technical knowledge or lack thereof in the ED makes much of a difference. Technical managers push technical solutions to be seen as "managing", and non-technical managers do other things like push through codes of conduct and rebrandings for the same reason. A friend of mine has compared the practice of management (in general, not specifically at WMF) to James A. Garfield#Treatment and death. Anomie⚔ 23:12, 21 February 2021 (UTC)
    The difference I am pointing out is that while Treitikov emphasized to her misfortune the Knowledge Machine, it was merely a different species of the same genre of approaches: emphasizing technology without concern about the people who actually make Wikipedia, et alia, successful. The Knowledge Machine at best was unnecessary; at worst it would replace the self-organizing communities of volunteers -- as many fear Wikidata might. Individuals routinely point out shortcomings in the UI that prevent volunteers from participating, such as missing features in the mobile web editing interface or (perhaps more egregious) failure to support blind users; the PTB respond that such requests are difficult & would require more manpower to solve. Yet there is ample resources to support new features the technical side wants to work on. I would hope competent management would explain clearly their priorities should be what the communities want & need -- not another shiny new feature. -- llywrch (talk) 17:23, 22 February 2021 (UTC)
    One of the things they never find time to fix (failure to support blind users) is actually illegal under the Americans with Disabilities Act of 1990 and exposes the W?F to potential lawsuits. See National Federation of the Blind v. Target Corp.. --Guy Macon (talk) 10:34, 24 February 2021 (UTC)
    IANAL, but according to our article Unruh Civil Rights Act#Disability litigation California disability access plaintiffs are allowed claim treble damages with a minimum of $4000 per access violation plus attorneys fees. As far as I can tell, it matters not where you are incorporated, only that you have a physical presence in California. An HQ in San Fransisco will do nicely. --Guy Macon (talk) 10:56, 24 February 2021 (UTC)
    I've always believed locating the Foundation's HQ in the Bay Area would prove to be an unprofitable expense. -- llywrch (talk) 06:43, 25 February 2021 (UTC)
    It's unlikely that it would directly apply in this case; the Unruh Act focused on commercial entities and is relevant here as the Ninth is one of the circuits which has found that an internet site has to have a digital nexus to be a place of public accommodation under the ADA (which is why Unruh was used). There's currently a circuit split on this question. CoffeeCrumbs (talk) 02:52, 27 February 2021 (UTC)
    Whenever the WMF next holds trustee elections, I'll be voting for trustees who commit to allocating a lot more of the $100+ million annual budget to software development for maintenance tasks like clearing phab tickets (not just new features, although those are important, too). I hope everyone else does the same. The way we fix this problem is to make sure we have trustees that are spending the money correctly. If we don't do that, we'll never get the phab backlog cleared (or replace MediaWiki with something better). Levivich harass/hound 20:16, 25 February 2021 (UTC)
    It is quite possible that the WMF never holds the next trustee elections.--Ymblanter (talk) 20:49, 25 February 2021 (UTC)
    I doubt you are the only one who suspects that will become the new normal. -- llywrch (talk) 07:35, 26 February 2021 (UTC)
    Their timeline says they'll pick the election process by April 15, and they're (for now) saying they want to complete that election process by the end of the year. I actually doubt that they'll just abandon this timeline altogether. It would look really bad if they had to pass another resolution this year temporarily re-appointing themselves, as they did last year. I think they'll be keen on voting on something concrete (meaning amending the bylaws with this new election process) before summer, so that their temporary term extensions don't have to be re-extended. The bigger question in my mind is what kind of election process they'll select on April 15, and specifically whether they're going to put all the Board seats up for grabs or reappoint themselves. That's going to be the proof of the pudding in terms of whether their intent is to actually continue with elections, or to retain their seats. Levivich harass/hound 18:31, 26 February 2021 (UTC)
    On that page, I only see selection, not election.--Ymblanter (talk) 18:50, 26 February 2021 (UTC)
  • Very good point and question! I'm quite confident that the solution to the problem of "limited developer resources" does not require a lot of time or a lot of money (the latter of which Levivich seems to suggest).

Instead, it's only a matter of will or decision-making.
Wikipedia is one of the largest websites in the world and has a daily audience of millions and probably something on the order of a twentieth of all trained developers in the world (daily).

I'm all for spending lots (i.e. most) of Wikipedia's financial resources on improving the software, but that's not what it needs at all. I also wouldn't oppose (spending more money for) financial rewards or financial hiring of developers but don't see any reason why volunteer development wouldn't remain to be a major part of this.
Implementing this only needs one administrator to spend something on the order of a weekend if at all (or a few days and devs more depending on the specifics of the implementation). Imo this should have been addressed years ago and get addressed first before any particular technical issue. --Prototyperspective (talk) 22:27, 28 February 2021 (UTC)
You might want to read WP:CANCER to see what the phrase "lots (i.e. most) of Wikipedia's financial resources" means in dollars. I'm just saying. --Guy Macon (talk) 22:36, 28 February 2021 (UTC)

Bitsquating

Key quote:

"Of course, the simplest way to prevent bitsquatting attacks is to try and grab bitflipped variations of your own domain names as much as practically possible before a threat actor does."
"On the defensive side larger companies are easily able to identify and reserve domains that are likely to be used with phishing, bitsquatting, and IDN homoglyph attacks."

It appears that it would cost the Wikimedia foundation less than $200 per year to grab all of the bitsquatting domains, and maybe another few hundred to get all of the "finger hits the next key over" typo domains. They seem to already be doing some of this. Try going to [ https://en.wikipedoa.org ] and [ https://en.wijipedia.org ]. --Guy Macon (talk) 02:20, 5 March 2021 (UTC)

Who wrote WP:CANCER again? :) ~ ToBeFree (talk) 12:12, 7 March 2021 (UTC)
That would be that annoying fellow who thinks the W?F should spend money on fixing bugs, security improvements, keeping the servers running, and building an endowment but should not spend money on giving free vacations to exotic destinations to "the in crowd", building a search engine to try to outgoogle google, or trying and failing to do Arbcom's job. This would be in the "security improvements" category. --Guy Macon (talk) 14:16, 7 March 2021 (UTC)

Update to Universal Code of Conduct Timeline

Please note that in recognition of community requests to provide adequate time for other important movement-wide conversations currently ongoing, the Board of Trustees has published Foundation:Resolution:Update to Universal Code of Conduct Timeline, extending the timeline for the current phase of the UCoC project ("outlining clear enforcement pathways") to December 2021.

A description of the project and updated timeline is available at Meta:Universal Code of Conduct. In a nutshell, the Wikimedia Foundation is consulting communities on the application of the Universal Code of Conduct.

The project is meant to be collaborative and involve community members at many levels including volunteers serving on the drafting committee. A call for applications will be posted soon. The Foundation is seeking input from as many communities as possible about how such a global policy might interface with their project. Later this month, specific details will be posted about the individual on-wiki consultations, which will start in April and run into May 2021.

For ease of reference to local policies, guidelines, and past practice, the project team would like to conduct a consultation locally on EnWiki (similar to a process used in 2019 by the Talk pages project). Parallel discussions will be occurring on other projects, including Meta.

As a facilitator for this process, please feel free to let me know if you have any thoughts. Xeno (WMF) (talk) 19:10, 15 March 2021 (UTC)

Cross-posted from Wikipedia:Village pump (policy)#Update to Universal Code of Conduct Timeline.

Various WMF office hours

Various WMF teams are going to be holding office hours:

  • Wikimedia Research office hours today at 16:00 UTC. (In a few minutes from this posting.)
  • m:Wikimedia Enterprise office hours on March 19, two sessions at 13:00 and 22:00 UTC, talking about the project to to build services for large-scale commercial reusers.
  • Campaigns team Office hours on March 25, 15:00 UTC, talking about "Evaluating ideal use of prizes or rewards for campaigns"
  • Community Resources team office hours, talking about the grants strategy relaunch: sessions for EU+CEE on 18 March 2021 17:00 UTC, and LATAM and North America on 22 March 2021 21:00 UTC. (Sessions for other regions already happened.)
  • Events team office hours, March 18, 14:00 UTC. (Edit: Added to list, 03:38, 17 March 2021 (UTC))

In case anyone's interested in any of these things. --Yair rand (talk) 15:59, 16 March 2021 (UTC)

A commercial subsidy of WMF

meta:Wikimedia Enterprise

I was just reading Wikipedia Is Finally Asking Big Tech to Pay Up in Wired by Noam Cohen and it appears that the WMF has setup a for profit subsidiary "Wikimedia Enterprise LLC" that hosts a version on AWS. A couple other things of note from the article There will also be a level of customer service typical of business arrangements but unprecedented for the volunteer-directed project: a number for its customers to call, a guarantee of certain speeds for delivering the data, a team of experts assigned to solve specific technical flaws...The Foundation says it doesn’t expect Enterprise ever to become the primary source of funding for the foundation’s roughly $100 million budget. Barkeep49 (talk) 19:12, 16 March 2021 (UTC)

Cohen believes this a smart move (For Wikipedia to reject this steady stream of money, to throw up objections based on principle, would perhaps seem as quixotic and stubborn as those homeowners who turn down a big check from a real estate developer planning a new skyscraper. The building usually goes up anyway, while the house sits in its shadows, a relic of the past. And the owner has missed out on a big payday to boot). I wouldn't go nearly that far but I certainly don't have any problems with this. I do have a problem that the Foundation seems increasingly assertive in its actions. It feels like with the Global Council we're headed towards some Constitutional structure in terms of Foundation/community relations which has some advantages but also takes us further from supporting the core function of the project - the thing that builds enough value we can create a for profit subsidiary to work on it despite giving it away, nominally, for free - and more into supporting whatever is new and shiny. I would love if the profits of this revenue stream were dedicated towards community directed development. Maybe then we wouldn't have mobile editors who we cannot communicate with. Best, Barkeep49 (talk) 19:17, 16 March 2021 (UTC)
The Wikipedia Enterprise link in the topic above is exactly about Wikimedia Enterprise LLC. and the responsible user, as far as understand, is Wittylama.--Ymblanter (talk) 19:20, 16 March 2021 (UTC)
Barkeep49 It's what was brought up multiple times in the past including in the strategy meetings. Basically.. the foundation is already spending a ton of money supporting these companies. This is often very disruptive support because it has to go in between planned projects etc. and no one keeps track of it. But its necessary because otherwise those companies use the same entryways as community and plain readers and it would become even more unpredictable and costly, so why not make that an actual professional service that can be predictable and stable. There is also hope that investing in better commercial/professional support will trickle down into services for the community like further professionalisation of toolforge services, better backups and export options, maps etc. So basically, instead of having volunteer and NGO labour pay for the commercial services (and then be thrown a grant every once in a while), flip it around and hope that the enterprises can create more value for the NGO and volunteers. The projects has been in development as an idea for quite a while already previously known as okapi. More information is on meta including on the principals, legal structure etc. —TheDJ (talk • contribs) 20:36, 16 March 2021 (UTC)
Hello, and yes, I'm the community liaison for the project (to be clear as LWyatt (WMF) (talk), not my volunteer account Wittylama). The WIRED article is a fair description, but it is by-necessity a simplification for a general audience, and it also doesn't get into the details that are most interesting from a wikimedian's perspective. It (quite naturally) focuses on the issues for big tech etc. So, for anyone wanting to read the documentation on-Wiki (as User:TheDJ so kindly pointed out), there is a new an Essay on Meta which discusses the “why?” and “how?” of this project. See also, the associated FAQ, operating principles, and also the technical documentation on mediawiki.org. There's various 'office hours' advertised on the project's main page (on Meta) if you'd like to join those. Sincerely, LWyatt (WMF) (talk) 20:46, 16 March 2021 (UTC)
As I stated above I have no problems with this for the reasons you mention. I've been at an average of 1.5 WMF meetings per month (not counting ArbCom) since October but obviously I've not been at the right ones. I'm glad to hear it's been discussed. Best, Barkeep49 (talk) 20:41, 16 March 2021 (UTC)
and to quote the FAQ: "Beyond covering for the costs of the project itself, all the funds generated from Enterprise customers will be used to support the Wikimedia mission. This includes investment in the Wikimedia projects, the community, our movement organizations, and the Wikimedia Endowment." —TheDJ (talk • contribs) 20:44, 16 March 2021 (UTC)
That's the part I don't agree with. Basically the profits will do whatever the board decides - no different than now. I would suggest, instead, this would be a fine dedicated revenue stream so that things like our inability to communicate with IPs get fixed (or whatever else the community collectively decides is a priority). Right now that feels very underfunded compared to other areas. Best, Barkeep49 (talk) 20:48, 16 March 2021 (UTC)
When they have trustee elections, I'll be asking the candidates whether they think we should provide our data to the public for free, and if big data take up all the bandwidth, rate limit them; or, whether we should provide our data to the public for free, and if big data take up all the bandwidth, charge them for it. Personally I think I'm in the former camp. Also I wonder if big data would be as interested in our data if it was licensed CC-BY-NC-SA instead of CC-BY-SA. Levivich harass/hound 04:14, 17 March 2021 (UTC)

Wikimedia Enterprise timeline

--Guy Macon (talk) 14:03, 17 March 2021 (UTC)

  • My perspective
    • No meaningful conversation in advance
    • Avoidance of requests for conversation, to avoid tough questions
    • My overall take: WMF is selling Wikimedia community trust and reputation for cheap with no public evidence of due diligence, forethought, or rationale
    • Identified team behind this is tech-oriented; no WMF team members here have training in ethics, diversity, society, humanity, values, community, etc.
    • The team itself seems prohibited by WMF higher ups from having conversation, or perhaps they simply have no opinions about what they are doing
    • The refrain and explanation from the WMF is that money will come in, but nothing else will change.
    • The major protest from the Wikimedia community is that inviting corporation will change culture and invite corporate shenanigans and interference with Wikipedia community processes; WMF denies this
    • Other online communities have been monetized to their detriment. For example, OpenStreetMap used to be a more of a volunteer community like Wikipedia, but now at their conferences the majority of attendees are corporate professionals
    • When Wikipedia ecosystem data is monetized, Wikipedia becomes a business asset which will invite investment in influencing Wikipedia to become a more favorable asset for organizations relying on the revenue stream
    • The number that I have heard as unreliable rumor that WMF expects is US$20 million a year starting within 3 years, but so far as I know, no WMF statement on the estimate
    • Wikimedia community must demand 51% of gross revenue of the Wikimedia Enterprise Money should go to grants. This is in addition to other Wikimedia community claims to the funding of the Wikimedia Movement.
    • Additionally WMF must be financially transparent as part of the Wikimedia Movement commitment to diversity. The public requires financial reports to the satisfaction of the Wikimedia community, including clear reporting (1) how much Wikimedia money is governed by the WMF versus by community (2) reporting by region: Each America, Europe, Africa, South Asia, etc (3) reporting by target minority focus (Global South, gender, etc)
    • With this massive change in income, the only resource sharing that I have heard from the WMF is more opportunities for volunteers to spend hours engaging with their paid staff doing the staff's work, and more participation certificates and unpaid recognition with the stated goal of uplifting minority communities through thanks to volunteer representatives
This all makes me anxious that the WMF is moving into crazy territory without a pilot or anyone able to articulate what they are doing. The lack of communication when so much is at stake is an indicator of major problem. Blue Rasberry (talk) 18:00, 17 March 2021 (UTC)
Agreed with many of those points. A concern is by taxing Google et al will stop using Wikipedia data (as much). Wikipedia is so popular because the data is open and free, they drive traffic to our site. And once you start imposing fees it is hard to stop, indeed the pressure is to charge more and more often. It creates not partners but competitors. All sorts of problems arise. -- GreenC 18:40, 17 March 2021 (UTC)
@Bluerasberry:
  • WMF staff appear to be engaging on the Meta talk page.
  • Pegging a percentage to grants strikes me as a bad idea. I expect the overall Wikimedia resource allocation framework to be taken out of WMF hands in any case, per the strategy, so the funds won't be any more under WMF control than other income. (This contradicts the Enterprise FAQ, which asserts that long-term decisions on spending this income will be up to the Board.)
  • Overall, bringing in a lot of funds from deals with Big Tech organizations sounds like a very risky move, and it does not look like the WMF is adequately managing this risk.
--Yair rand (talk) 18:44, 17 March 2021 (UTC)
It does indeed contradict the Enterprise FAQ. I continue to believe that designating the profits from this endeavor - which I expect to increase in the medium term - to community directed purposes, whether programming or grants, should be done. Of course the board wants to have ultimate discretion but that doesn't mean we can't push back on those ideas. Best, Barkeep49 (talk) 19:04, 17 March 2021 (UTC)
@Barkeep49 and Yair rand:: With regards to the specific point about WMF Board oversight of revenue (and how it is eventually spent): As you note, the FAQ describes the status quo - which is that the WMF board has ultimate legal discretion over movement funds raised by the Wikimedia Foundation. If, as a result of strategy-implementation discussion, the broader movement governance structure were to change in a way that alters the board's role in oversight of movement resources then Wikimedia Enterprise's governance rules would adapt correspondingly. LWyatt (WMF) (talk) 21:39, 17 March 2021 (UTC)
Thanks for making this clear @LWyatt (WMF). The FAQ is obviously correct as to what is happening now while I am arguing that the status quo should change. Best, Barkeep49 (talk) 21:42, 17 March 2021 (UTC)
@Yair rand: you are right, pegging any one thing to grants is a bad idea.
Wikimedia community must demand 51% of gross revenue of the Wikimedia Foundation
The only engagement that I want from WMF staff is their funding Wikimedia communities to organize their own conversation. WMF staff should not be using consultants or their own labor to formulate the values and ethics of a community. The Wikimedia Foundation staff and the Wikimedia community are not the same and have very different values and ethics. Increasingly the Wikimedia Foundation has a conflict of interest against the Wikimedia Movement, and moreso as it continues to invest in compromises with corporate players who are buying their way into Wikimedia policy votes.
I can support the Wikimedia Enterprise intent to negotiate with corporations, but I wholly oppose the long planning the WMF designed to exclude Wikimedia community perspective from this and the WMF paying people to argue ethics with Wikimedia community volunteers. Ethics and values do not come from corporate paid labor or strategic revenue plans. The heart of all this is revenue and at best, someone at WMF may in the future make a budget item for ethics or compassion, but that has not till now been a consideration even after making 100s of 1000s of other dollars investment in the planning.
The Wikimedia Movement needs its own funding for community ethics because the corporate colonialism of the Wikimedia Foundation is never ending and I cannot see where that organization keeps its brain or thought process. The only soul in the Wikimedia Movement is in the community. The corporate personhood of the Wikimedia Foundation is an inhuman golem or Frankenstein. I feel strongly that the success of the Wikimedia Movement is in the trust and reputation that we have good ethics, and the WMF is greatly compromising that by hiding essential information and investing in countering community discussion while not investing in promotion of discussion. Blue Rasberry (talk) 19:10, 17 March 2021 (UTC)

Every time I see one of these WMF flowcharts, it's missing the step at the beginning called "Ask the Community If It Wants to Do This". Levivich harass/hound 19:13, 17 March 2021 (UTC)

In fairness, the community appears to view most things the WMF does with skepticism (perhaps often deserved, but still). Personally, if the WMF wants to monetise big tech usage of data & is willing to reinvest the profits into making the project better (eg properly funding a development team that can work through the phab backlogs) I'd say it's a good endeavour. ProcrastinatingReader (talk) 20:38, 17 March 2021 (UTC)
The problem is that the WMF has a strong track record of spending money on perpetuating itself with wishy-washy jobs for people doing things like "outreach" that never deliver anything rather than proper jobs for people who can improve our infrastructure, such as, for example, people who can improve the abysmal experience of editing from a mobile platform. If they would concentrate on the primary job of giving us good infrastructure rather than on perpetuating the bureaucracy then I'm sure nearly everyone would support this. Phil Bridger (talk) 20:56, 17 March 2021 (UTC)
For what it's worth Levivich, I did write up a reasonably detailed description in the project FAQ to the question of "Where has this previously been discussed?" - going back more than a decade for the general idea. Most recently, there are two specific section of the Movement Strategy recommendations which talk about an Enterprise API. LWyatt (WMF) (talk) 21:14, 17 March 2021 (UTC)
Reading the FAQ is what prompted me to write that comment. The FAQ answer says, "Revisiting large-scale data services to help ensure the success of the movement, irrespective of changing discovery methods of Wikimedia content, was discussed as a possible avenue for exploration in 2015 and again on Wikimedia-l in 2016 ... The start of work on the Enterprise API project specifically was raised on Wikimedia-l in mid-2020." A board meeting in 2015, a mailing list thread in 2016 do not count as "previously been discussed". It definitely doesn't count as "asking the community if it wants to do this". I suggest revising the FAQ to a direct and honest answer: "Where has this previously been discussed? It wasn't, except in this one board meeting six years ago and once on the mailing list five years ago." Levivich harass/hound 21:23, 17 March 2021 (UTC)
Indeed that’s quite true that conversations on mailing lists several years ago about the general topic of an enterprise API do not constitute a discussion of ‘’this’' project. But the point of mentioning these older discussions is that the issue at the heart of this (an for enterprise-scale needs that brings in revenue) has been floating around the movement for a long time – this is not a “new” idea that grew after the last rain-storm. That includes the fact of User:Brion Vibber (WMF), the first ever(?) employee, being able to be hired because of/for the m:Wikimedia update feed service (now long since defunct).
What cements those previous discussions, is that Wikimedia Enterprise is based on two sets of recommendations from the movement strategy process and was based on the output of two different working groups. Those recommendations are part of a 4 year body of work that built by nearly 100 Wikimedians of all backgrounds that was based on the inputs of hundreds of volunteers. Given that this project is a direct result of the recommendations from the strategy process, the biggest questions are I feel mainly about how we ought go about this: There are really bad ways this project could be approached, and then there are ways which are aligned with our movement – and we are most definitely trying approach this project via the latter. Over the past 9 months we've also held a number of roundtable discussions and sought the input of a number of volunteers with specific expertise - to design the "principles" list, and various oversight rules described in the FAQ.
The public pages for this project (on Meta, MediaWiki, Phabricator) were started in mid-2020 with what was - naturally - relatively little detail since there wasn’t anything “built” yet. But nonetheless there were threads on mailing lists, phabricator tickets etc. at the time too. Now, at this stage of development, there is actually something to “show’ (both in terms of policy and technology) that is concrete enough for people to give useful, actionable, feedback and commentary upon. Much earlier and it’s all hypothetical, much later and it’s already ‘done’: and in both of those cases it would be rightfully very frustrating to be asked ‘what is your feedback?’ of an either non-existent, or an already-finished, project. We’ve tried to get the ‘goldilocks’ moment in the middle of those two extremes: But it’s never going to be the right moment for everyone simultaneously. LWyatt (WMF) (talk) 22:38, 17 March 2021 (UTC)
I agree. The WMF should have started a discussion onwiki (with a notice on Village Pump) specifically about this project. Ideally, there should be consensus, but at the very least they should have consulted us and considered our opinions. In this case, there was no consultation, and public news reporting is the first time that I have even heard of this project. Very disappointing, since the volunteers (not the WMF) generate the vast majority of Wikipedia's content. Tony Tan · talk 21:48, 17 March 2021 (UTC)
In the WMF's defense I think the place they should start such discussions is meta. This is not an enwiki related thing so while we can (and are) discussing it here I think the foundation is under no obligation to post something about it for us. Best, Barkeep49 (talk) 21:51, 17 March 2021 (UTC)
Meta is the right place for the centralized discussion, but WMF has an obligation to advertise such discussions on all projects. Levivich harass/hound 21:55, 17 March 2021 (UTC)
Also while I'm here, some other feedback about the FAQ:
The FAQ question, "How will the money be spent" is answered by Once we have a more clear picture of timing and profitability, the Board of Trustees can plan for how they want to invest the profits to support the mission. That is likely to be at least a year away. So we're going to roll out this new product and we don't have a plan for how to invest the profits to support the mission, and won't make a plan until after we have the money, which begs the question: where are you going to put the money in the meantime?. And the really important part of that question is: the LLC or the non-profit?
The FAQ question, "How much money will this raise" is answered by Unsurprisingly, this is one of the most important questions from a business-model perspective, and it is also impossible to answer in advance. Significant research has been undertaken to learn what the Enterprise API's potential customers need and want, which has informed the product development and, consequently, the estimates of potential revenue over time...
So we haven't pre-sold it. We're building a product for a customer base of like.. what.. less than 100 potential customers? Less than 10? Less than 5? And we haven't presold it? There is no contract in place? We're estimating revenue based on research?
Which means no customer is making an up-front payment that is paying for the development of this new product.
So let me get this straight: We're taking money—millions?—from the non-profit and putting into an LLC, and then using that money to build a product that might be interesting to about five customers, and hoping that when it's done, they'll pay for it. If they do, we don't know how much they'll pay, but when they pay, we'll figure out what to do with that money. That'll be at least a year away. We're doing this based on a mailing list discussion five years ago and a board meeting six years held by a board that has since been replaced evaluating the recommendation of a CEO that has since been replaced. Without any discussion revisiting the topic in the interim.
And this is part of the reason why I can't wait for the next trustee elections. Levivich harass/hound 21:44, 17 March 2021 (UTC)
“So we haven't pre-sold it. We're building a product for a customer base of like.. what.. less than 100 potential customers? Less than 10? Less than 5? And we haven't presold it?” U run a business where you presell software and services u don’t yet have? Goddamn, I gotta get in on that trick... —TheDJ (talk • contribs) 22:25, 17 March 2021 (UTC)
Every service I sell is pre-sold. I just finished the control electronics for a firefighting robot, and before I started the work we agreed on exactly what they would get and how much they would pay me. Of course some busineses can't do that (Pepsi, for example) but if you only have 10 potential customers pre-selling is a great way to make sure that they will buy what you make. --Guy Macon (talk) 23:46, 17 March 2021 (UTC)
Some folks apparently are unfamiliar with how custom software is sold. Levivich harass/hound 23:49, 17 March 2021 (UTC)

Letting the wolves in at the door

It's one of the oldest dictums out there - money is power. If you control the purse strings, you can control everything else. Or, to put it another way, a budget document is a values document. I believe that the WMF is creating this in good faith. After all, why pass up the potential for a lot of money from some of the world's richest companies if all it's doing is affecting the data flowing out of Wikipedia, and won't impact what content is added or deleted?

That might be true today. But the WMF is putting itself in a dangerous position. If the revenue stream is as successful as the WMF hopes, at some point, it will make up a substantial portion of the WMF's budget. And then the big companies will be in a position to lean on the WMF for changes, in big ways and small, obvious and subtle. Wikipedia is an idealistic place. It will be destroyed by the rapacious maw of capital if it is not carefully managed. The WMF and the community have kept the wolves at bay for years. But this lets them in at last. One step at a time, $$$ will change what Wikipedia is. This idea is a mistake, and a dangerous one to this project. Ganesha811 (talk) 21:28, 19 March 2021 (UTC)

This is the best nutshell description of the problem. Beautifully put. Rollo (talk) 12:56, 20 March 2021 (UTC)

NOTE: see Meta:Talk:Wikimedia Enterprise#Letting the wolves in at the door. This exact question was also asked on the Meta talkpage for the project, it was answered there, and the conversation continued there. LWyatt (WMF) (talk) 23:46, 19 March 2021 (UTC)

The foundation is building an endowment fund, eventually that endowment could produce sufficient income to fund the whole prject. If this new revenue stream were to be directed into expanding the endowment fund, then you reduce the risk of WMF budgets expanding to the point where we have to have this money, and you bring forward the day when the movement is financially independent. ϢereSpielChequers 13:49, 20 March 2021 (UTC)
As it is currently structured, the W?F can at any time take money out of the endowment and use it to maintain their ever-increasing spending despite a major drop in revenue. This is unlike many endowments, where the principle cannot be spent, and makes the W?F endowment just another bank account with extra paperwork needed to make a withdrawal. We may very well choose to trust the current W?F management, but do we also trust all possible future management teams? Having some of the same people on the W?F board and the endowment board is also troubling. --Guy Macon (talk) 14:20, 20 March 2021 (UTC)
WSC is right that they're building an endowment, effectively doing a capital campaign all without acknowledging it and all basically on the back of small donors who don't realize that's what they're contributing to. I support them building an endowment even if I don't love the way they're going about it. Barkeep49 (talk) 15:09, 20 March 2021 (UTC)

The Enterprise API: a technical analysis

Based upon my decades of managing hardware and software projects and as a consultant specializing in rescuing engineering projects that are in trouble, here is my technical analysis based upon first principles with no insider information about the Wikimedia Foundation, Google, Amazon, or Apple:

  • Assumption #1: The software that Wikipedia runs on can be run on someone else's' computer.
  • Assumption #2: The content on Wikipedia can be mirrored on someone else's' computer.

See...

Wikipedia:Mirrors and forks,
Wikipedia:FAQ/Forking,
Downloading the Wikimedia software,
Wikipedia:Republishers,
Wikimedia Installation Guide. and
How to mirror Wikipedia

...to examine the above assumptions. Also keep in mind that you can create a mirror of most things that are available on the internet by crawling the website like any ordinary user.

If the above assumptions are true, then Google, Amazon, and Apple can create and maintain complete and frequently updated copies of Wikipedia on their internal servers.

They could also check Wikipedia (we are on the web, after all) to verify that individual pages on their internal server are up to date, with the choice of what pages to update driven by them displaying that content to their users in some form.

At this point, engineers at Google, Amazon, and Apple could reverse engineer the Enterprise API and create an identical API that pulls data from their internal servers. They might even be able to poach some foundation engineers, at least some of whom would welcome a doubling of salary and a promise of better management.

This would give Google, Amazon, and Apple exactly what they would get from the Enterprise API without paying a dime for it.

Engineers at Google, Amazon, and Apple could then attempt to differentiate themselves from each other by making their internal API better in some way than the Enterprise API.

One obvious improvement would be to not update their copy when a new Wikipedia user makes a change unless the edit survives without being reverted for a day or two. This would give them a feed with less vandalism.

My conclusion is that this proposal has a fatal flaw; the potential customer can easily eliminate the middleman. --Guy Macon (talk) 14:12, 20 March 2021 (UTC)

I was curious about that too, but the reasoning is explained at mw:Wikimedia Enterprise. – Joe (talk) 15:22, 20 March 2021 (UTC)
I must be missing something. You can take that document, replace every mention of "Wikimedia Enterprise API" with "Apple's API to their internal server" and all of the listed advantages remain the same. The only way out I can see is if one of my two starting assumptions isn't true. --Guy Macon (talk) 20:06, 20 March 2021 (UTC)
The reasoning has a gap: this applies for every software product, ever. The difference is that it costs time and money to develop and maintain these systems, more than it costs to purchase API access, and presumably they’d do a worse job than the people who actually have ran the software for decades. The same reason why FAANG and other tech giants buy API subscriptions for practically every other thing, and pay for software like GitHub Enterprise rather than develop their own GitHub from scratch (and repeat for everything else they own). Simply not worth the cost or effort. ProcrastinatingReader (talk) 16:45, 20 March 2021 (UTC)
No. It does not "apply for every software product, ever." Ignoring the fact that we are talking about a service, not a software product, it only applies to open source products. You can fork Linux, but you can't fork Windows.
If, as you claim, Google, Amazon, and Apple will be willing to pay for Wikimedia Enterprise API, why then are they not willing to pay to create it? Why does the W?F have to pay the cost out of donations that were never meant to be used to fund a for-profit venture? Has any potential customer signed a contract agreeing that if the new LLC creates X the customer will pay Y for it? Has Google, Amazon, or Apple given us a definition of what they might be willing to buy in the future, or are the details of the Enterprise API based upon what some foundation engineers are guessing that those customers might want? --Guy Macon (talk) 20:06, 20 March 2021 (UTC)
I never said there are people willing to buy it. I don’t know exactly what the WMF is selling. I’m just saying it’s a demonstrable fallacy to make the general “big tech can just write it themselves rather than pay for API access” argument. Big tech frequently use external APIs and services rather than reinvent and maintain the wheel. ProcrastinatingReader (talk) 20:33, 20 March 2021 (UTC)
Looking at the mw page, briefly it appears for the most part they’re high availability APIs offering access to the same content. I suspect they’d have more interest if they made APIs that analysed the content and provided that, aka something different, rather than just raw data dumps. But I’ve done zero market research and that’s just a guess. ProcrastinatingReader (talk) 20:38, 20 March 2021 (UTC)
What makes you think that Google, Apple, and Amazon don't already have their own internal mirrors, whether exact or post-processed in some manner? The trick is in keeping these mirrors up to date as Wikipedia is edited, particularly when all three are competing on having the most complete and up-to-date data for their various assistant programs. To me it looks like this whole Enterprise API thing is basically a way to sell then a better feed so they can update their mirrors more reliably, and possibly reduce their own investment in maintaining exact mirrors, while possibly also reducing their impact on Wikipedia's existing infrastructure that isn't really designed for large-scale real-time mirroring. Plus, if you want to ascribe philanthropic motives to the big players, it's much easier for a publicly traded for-profit company to justify (to their shareholders) spending money on a service than to justify making large donations. Anomie⚔ 23:10, 20 March 2021 (UTC)
You have pretty much nailed it on the head @User:Anomie Seddon talk 01:08, 21 March 2021 (UTC)
Yep - as Anomie said. LWyatt (WMF) (talk) 03:43, 21 March 2021 (UTC)
So why haven't these potential customers made a financial commitment? Have we even bothered to ask them if they would be willing to fund this? --Guy Macon (talk) 04:05, 21 March 2021 (UTC)
As I wrote on Meta's forum where you also asked this question: It was stated on the record in an interview for WIRED that conversations between the the big tech companies and the project team "are already underway" - which is is a simple way of saying that yes, the 'enterprise' team has been in close contact with those companies: finding out what they currently do and how they do it, what they need and can't do themselves, what they'd like instead, and would they be willing to pay for it... This is not being built in a vacuum. LWyatt (WMF) (talk) 04:51, 21 March 2021 (UTC)
Thanks! Very helpful. --Guy Macon (talk) 05:36, 21 March 2021 (UTC)
The ability to replace one vendor is not a "fatal flaw", it's the whole point of being in the business of free knowledge. Business models for open-source software is a complicated topic, so naturally the press made a giant mess of the news with its sensationalist headlines. All the various for-profit proprietary software companies have a sore need to share technology, although not everyone is happy. Selling free software may not get you the 40 % margins Microsoft has, so some people get sad they can't become billionaires on the stock exchange, but we don't have that problem. Nemo 06:31, 21 March 2021 (UTC)

Consider this as an opportunity

Perhaps we should consider this as an opportunity. I call upon the W?F to publish a detailed accounting of every penny and every hour spent on this project and of every penny that comes back to the W?F if it succeeds. There is absolutely no reason to keep this information secret -- no other giant online encyclopedia snapping at our heels and trying to figure out how we do things -- and a detailed accounting would make the project a lot more palatable to the community. --Guy Macon (talk) 04:05, 21 March 2021 (UTC)

As noted in the FAQ on meta in the financial subsection, overall revenue and expenses, differentiated from those of the Wikimedia Foundation in general, will be published at least annually. More generally, for those interested in financial issues specifically, there are a couple of other related questions that have been asked and answered on the Meta talkpage, here and here. -- LWyatt (WMF) (talk) 04:43, 21 March 2021 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia:Village_pump_(WMF)/Archive_2&oldid=1045701637"