Wrong balance at Community Wishlist Survey


Under one item of our wishlist you write “Community Wishlist Survey is rather broken, in accepting only what has the most votes this year, which is never, ever going to be stuff template editors need.” That is a valid point that deserves wider attention. How would you suggest this to be fixed? One fix I can see would be to put effort and effect in proportion. A wishlist without any regard for cost will tend to favor the most expensive items, regardless of how many useful items can be had at the same price. ◅ SebastianHelm (talk) 13:45, 16 December 2020 (UTC)Reply

@SebastianHelm: Yes, there's definitely that effect.
  • That one's challenging to address, since assumptions about difficulty of implementing something are often – maybe even usually? – wrong (just ask any software engineer, especially one tasked with changing existing features or adding new ones to an existing product mostly written by other people). I'm reminded of the voter guide I get in the mail; there's a dedicated legislative analysis office that comes up with estimated costs and complications of implementing various ballot measures. WMF having someone[s] on staff doing this for CWS proposals and Phab requests in general might help, but it might be easy to be wrong and get fired/sacked. >;-)
  • The no. 1 thing to me is true prioritization. Mission-critical things, e.g., accessibility solutions, HTML (and other) standards-compliance fixes, security improvements, and other key proposals which meet with support should take precedence over all attempts to add new features or "polish the chrome" on things that already are properly functional. Secondarily, improvements to existing features people definitely use (wishlist, search, editing tools) should generally have higher priority (among accepted proposals) than requests for all-new features.
    • This, to me, is where the process (not just CWS, but WMF's MW development in general) has failed the worst. It's also deeply entwined in why I resigned as a WMF Tech Ambassador to en.WP; the short version of my statement on my user page about this is: WMF is acting like a software company with a customer base and a marketing plan (what it wants customers to go for), instead of behaving as a globally important NGO with a constituency and a mission to serve the actual needs of that constituency. Some of the standards compliance things have been open tickets for 15+ years, across multiple bug-tracker systems, and some attempts to "fix" them have simply introduced more compliance problems, cutting off our nose to spite our face. There's a competence problem of some kind happening somewhere, even if most of the devs are amazing. But whoever thought it was good idea to have : equate to <dd> and render visually as an indent, and do this in absence of a proper <dl> list structure was foolish. Of course it would get abused for purely visual indentation not d-list construction, especially if no alternative was provided to do indentation properly. But it was an even worse idea (one I just now learned about, in the mobile skin) to replace that abuse of <dd> with abuse of <blockquote>, which is strictly reserved for actual quotations. The <div> generic element exists for a reason, and is super-mega-obviously the one to use here (though on talk pages the HTML 5 element <article> might be a better choice, especially with smart id stuff for thread building; this can probably just be ripped wholesale from any good blog, forum, or other CMS that is open-source.
    • No one who is unwilling to totally absorb the HTML and CSS specs has any business working on HTML and CSS code (including code that generates that code) at a professional level. I don't mean fire/sack anyone, just move them to something they're actually competent at, and put experts on the tasks the non-experts have been screwing up. Seriously, the kind of screwups involved are things that would not have been tolerated at a regular meritocracy-driven open source project; they would have been fixed years ago, and a bad mistake, like moving from abuse of one element to abuse of another instead of use of the proper one, would likely never have happened.
    • A conceptually similar issue (which I raised with a WMF person at w:en:WP:VPTECH, I think, within the last month) is WMF's internal hostility to VPNs, and inability to distinguish them from other kinds of services, nor to recognize the value they provide for security in an increasingly mobile but increasingly vulnerable computing and communications environment. The current practice of just blacklisting almost every block of IP addresses that happen to resolve to machines that provide VPN out-node services (generally blacklisted because of other services they provide) is downright stupid. It betrays a sort of "stuck in 2004" ignorance about how the technology works. Not just the necessity of VPNs these days, but the simple fact that any given IP address is apt to resolve to multiple [virtual] servers, even by multiple entities, and any given "server" is apt to have multiple sometimes unrelated IP addresses, all due to cloud computing, and software/servers-as-a-service models. It's rather like trying to block travel from Massachusetts because you heard about a bank robber who was born in Massachusetts, and also block entry to banks while you're at it, because anyone going into one might be a robber. This is not how to address sockpuppetry and other abuse problems, anymore than just massacring the entire populations of Nigeria and India is how to address the problem of online scams often coming from or passing through Nigeria and India.
  • CWS proposals that pertain primarily to WMF projects should get pretty much all priority; stuff that's extraneous to that (e.g. features for bending MW into a blogging platform) should be left to third-party development, other than any necessary hooks for that development. And even then only if both WMF and the overall community think spending any time at all on that hook is worthwhile. Just because someone can conceive of a way to torque MW into being something it was not supposed to be doesn't make it a good idea.
  • But there also need to be more CWS categories, or subcategories, that independently rank proposals within them. The current ones are mostly too sweeping, and net together many unrelated things (plus they become so long they are difficult to get through).
    • E.g., almost all requests for template/module tools are stuffed under "Editing", which is not at all what most people are thinking about for that category (they're thinking of public-facing content, the form we used for creating it, and the tools that operate on the content in that form, like add markup with a button press, etc.).
    • It even needs to split between source-mode editing and VisualEditor. Some of the proposals this year are VE-only, but are not labeled as such, and end up being confusing.
  • Then there's the issue of the same proposals being made for 5 or 10 years in a row and always being supported but never implemented. Support assessment needs to be cumulative (within reason; some of the proposals mutate a little over time, but the entire WMF community is good at assessing shifting consensus over time, so this is not much of a challenge).
  • Not-quite-relatedly, there are often also essentially duplicate proposals (I saw at least three this year: one pair already identified as such by someone; one pair flagged as such by me, though I only did that one way; and one pair unmarked because I was exhausted by the end and couldn't be bothered). Just as en.Wikipedia's Arbitration Committee (and several other processes, have clerks), someone should be tasked with clerking this stuff and merging proposals that are too similar (just present the options as variants, and if the proposal in general passes, the exact version to implement can be another discussion for another time, if that's not already clear from the CWS comments). I think there actually is some clerking going on already, since I have seen translation and other work get done. Maybe whoever's doing it needs an assistant.
  • One other thing: this survey is so daunting it is very difficult to actually get through it all. It might be more practical to stagger it, e.g. put out the Editing section one month and the Search section another month, and so on, so one does not have to spend literally an entire waking day to wade through it all.
  • We're getting too little input from too few editors. In part this is because of the issue in the bullet above this, but in part it's due to lack of local-project awareness and engagement. One radical change in approach could be for projects to host their own wishlists, or have RfCs for items to add, and then forward this on the bigger, cross-project process. There are numerous ways this could be reshaped, and each would present its own strengths and weaknesses.
  • Some of it could also be more top-down. The devs will have ideas about what really needs to get done, what is nearing completion and pretty easy to do, what is virtually impossible, and some other matters, like what WMF's executive team and/or board are hoping for (which the community often doesn't know anything about in detail until too late) and solicit feedback more directly.
  • Frankly, WMF needs to be willing to spend more money on getting stuff done. It has a lot of money, and isn't really spending enough of it on mission-critical things. I come from a "tech nonprofit" background (EFF and CRF), so I know very well what that problem looks like. A common version is over-spending on executive salaries and perqs (also for the board), like luxury furniture and first-class travel, at the expense of sufficient program staff (the average tech, communications, and other program staffer at such organizations is in dire need of at least one assistant, often a department, and the organization will not realize this until that over-worked and under-paid person burns out and leaves, and the org finds that person has to be replaced with 2 or 4 or 8 to get the same work done).
I could probably come up with more ideas and observations (see, e.g., w:en:User:SMcCandlish/Discretionary sanctions 2013–2018 review for an example of the kind of policy analysis I can do when I devote enough time to it, and even that's two years out of date and would cover several more more things than it does if I revised it significantly).
 — SMcCandlish ¢ >ʌⱷ҅ʌ< , 02:21, 17 December 2020 (UTC)Reply
Wow, I had no idea there was so much behind it – and you're hiding it in the comment to one wish! How best to tackle all of this? Does it even make sense to try and find a solution for one problem that only addresses a small shard of the whole?
Good point about the clerical tasks. I would see those as part of project management; why aren't WMF's PMs doing that?
You're right that the sheer amount of wishes is daunting. It may be a good idea to stagger it, but ultimately the workload stays the same. Not sure how to actually reduce the workload. Maybe similar to what we wrote in the wish for preferences: Mark everything for which a wish exists with a “🎁” symbol – in the UI and the manual – which links to the wish under discussion. So users will see wishes at the right moment and the right place, and only for those functionalities that they use or are interested enough to RTFM. I think this may also address the issue of getting input from too few editors. ◅ SebastianHelm (talk) 22:58, 17 December 2020 (UTC)Reply

This thread would probably have more impact at Talk:Community Wishlist Survey, so I've copied it over there.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  04:14, 19 December 2020 (UTC)Reply

Democratic authoritarianism


Your formulation of the concept at en:Wikipedia talk:There is no justice made you one of the most respected en.Wikipedians by me. BTW I am astonished that such criticism of the regime has been possible in mainstream essays as late as in 2016. Incnis Mrsi (talk) 08:17, 29 January 2021 (UTC)Reply

@Incnis Mrsi: Thanks, and I'm glad you liked it. :-) I worked most of that material into w:en:Wikipedia:Advice for hotheads, which covers several other things, including explosive behavior, false civility, and attempts to "argue Wikipedia into capitulation". I'll take the liberty of engaging in some coffee-fueled morning rambling:

As for essays, there's long been a lot of tolerance for conflicting viewpoints between various of them. We even have pairs of directly contradictory ones (or seemingly so, until you see that they address different kind of issues/incidents/questions). But ones that just do not at all align with the community's norms tend to get userspaced (or deleted at MfD if they're so off-kilter they have a NOTHERE vibe).

On the more philosophical "democratic authoritarianism" thing (not exactly the term I would use, but I see what you mean), and how it relates to an entity like WMF and a project like Wikipedia, I'm reminded of Twitter and Facebook kicking Trump and friends off their platforms (way later than they should have). They are privately owned companies with terms of use/service and a public to answer to. Various people in Trump's camp are claiming they are being "censored". They're making legally incorrect First Amendment arguments (the 1A only applies against censorship by the state, and doesn't let someone force their expression to be carried by private-sector third parties). WMF is in a similar boat. It isn't in a position to allow PoV pushers and other disruptive parties free reign, to allow defamatory material in articles on living people, and so on. WP is more like a newspaper or magazine publisher. PeTA and Greenpeace do not have a legal or "moral" right to force The Wall Street Journal to print their advocacy material, and the Family Research Council and the Eagle Forum can't require Huffington Post to given them equal "air time".

There are some grey areas, the common carriers. The gist is that various private or somewhat privatized entities have quasi-monopoly privileges, in exchange for infrastructure rollout, and liability shields for content they did not create, in exchange for not being permitted to monitor and censor. Some are arguing that social networking sites should be like this, should operate like package delivery services and telephone companies, as passive conduits for anything people want to send through them. I think this would be disastrous, since even with such sites trying to enforce ToU/ToS against against racist rabblerousing, black-market trading, insurrection and terrorism planning, etc., etc., the effect on our society of social media's propensity for creating borderless "reality bubbles" that inculcate us-vs.-them thinking, radicalization, and the spread and belief in patent falsehoods has just about ripped society apart over the last decade, and it's not looking to get better immediately if at all. If anything, non-state actors in the online information and communication space need to be more rather than less restrictive about what they'll permit on their systems, And that goes for far-left stuff too; the trans right activists making death threats against TERFs, or supposed antifa people agitating to burn down courthouses and cops' homes, should have their accounts nuked right along with anti-abortionists doxxing clinic workers in hopes they'll be tracked down and murdered, or white-nationalist "militia" nuts planning racist hate crimes.

The fundamental difference between a common carrier and a social networking site (in the broad sense, including webboards, collaborative content projects, etc.) is the public, memetic component. You can't recruit 10,000 people to join your telephone call or share in the goods inside a package you ordered from Amazon. There is no broad threat to society from having privacy and freedom of expression in one's phone calls and postal mail (even if certain crimes can be organized that way). There's obviously a big one inherent in using technology to create "permeably-walled-garden" propaganda and indoctrination farms, abusing private-sector services that were intended to make people's lives better and happier.

I have a lot of concerns about people system-gaming WP's "assume good faith" position through crafty "civil PoV-pushing" techniques to essentially bend WP articles to propagandistic purposes. It's already happening in a lot of topics, and it's hard to do much about it. All the pushers have to do is bait neutrality-minded editors into doing something explicitly uncivil, then get them banned from the topic area so the PoV pushers can just own it. This POVRAILROAD technique is precisely what was happening in the recent Flyer22 ArbCom case. The "AGF is not a suicide pact" maxim is going to have to be taken more seriously. WP is not longer a project eagerly accepting thousands of new editors per month from SlashDot and other nerdy forums to attempt the wacky idea of building a free encyclopedia. Eventualism essentially expired in the late 2000s at the latest. WP is a free encyclopedia, one of the most-read information sources in the world by the general public, and is under constant pressure to say non-neutral things on thousands of topics. We can still assume good faith, at first and for a while, but that has to stop with regard to a particular party when we see clear evidence to the contrary in their behavior. I should stop here or this will just get longer and longer. >;-)
 — SMcCandlish ¢ >ʌⱷ҅ʌ<  14:00, 29 January 2021 (UTC)Reply

Tech News: 2023-50


MediaWiki message delivery 02:12, 12 December 2023 (UTC)Reply

Tech News: 2023-51


MediaWiki message delivery 16:18, 18 December 2023 (UTC)Reply

Tech News: 2024-02


MediaWiki message delivery 01:19, 9 January 2024 (UTC)Reply

Tech News: 2024-03


MediaWiki message delivery 00:13, 16 January 2024 (UTC)Reply

Tech News: 2024-04


MediaWiki message delivery 01:04, 23 January 2024 (UTC)Reply

Tech News: 2024-05


MediaWiki message delivery 19:31, 29 January 2024 (UTC)Reply

Tech News: 2024-06


MediaWiki message delivery 19:22, 5 February 2024 (UTC)Reply



Hi SMcCandlish, thanks for your feedback at the SE election [37]. I thought I've stated clearly where I intend to work if elected as steward, but apparently didn't manage to convey this properly?

I want to help reducing the SRG backlog which has been terribly long last year (multiple times passing way beyond 300+ open requests) and still is too long in my opinion with 100+ open requests right now. This of course means I want to process other users requests and not just „bypass the SRG step“ for myself, which is what I stated in Stewards/Elections 2024/Questions#Areas of intent and Stewards/Elections 2024/Questions#Uniqueness as well. Additionally I want to help at SRP, SRGP and SRM (pages I'm already quite active at) as mentioned in my statement.

I take this as a learning to explain my intentions in more detail when again in a similar situation to this election. Have a nice day! Johannnes89 (talk) 11:07, 10 February 2024 (UTC)Reply

Also commenting here, as I just happened to see you in RC and another voter mentioned you yesterday. I also want to apologize if my statement was partially difficult to understand. My intent is not to "collect hats" (that would rather burn me out, which I replied to you on the voting page but I will do it here too) and excuses if you have misinterpreted my statement that way.
Like Johannnes I don't want to volunteer "just for my own good" or to "bypass SRG", or to "gain more permissions", but rather to benefit the community. As mentioned, both in my statement and on our questions page, I plan to help out mostly at IRC (with locks/OS requests when quick assistance is needed) as well as the steward requests pages, especially SRG, and also at SRP and SRGP. I don't want to be "selfish", especially considering stewards serve the community.
So, I will also take your feedback into account in the future, and hopefully, be more clear next time. Cheers! EPIC (talk) 08:08, 13 February 2024 (UTC)Reply

Tech News: 2024-07


MediaWiki message delivery 05:49, 13 February 2024 (UTC)Reply

Tech News: 2024-08


MediaWiki message delivery 15:37, 19 February 2024 (UTC)Reply

Tech News: 2024-09


MediaWiki message delivery 19:23, 26 February 2024 (UTC)Reply

Tech News: 2024-10


MediaWiki message delivery 19:47, 4 March 2024 (UTC)Reply

Tech News: 2024-11


MediaWiki message delivery 23:04, 11 March 2024 (UTC)Reply

Tech News: 2024-12


MediaWiki message delivery 17:39, 18 March 2024 (UTC)Reply

Tech News: 2024-13


MediaWiki message delivery 18:56, 25 March 2024 (UTC)Reply

Tech News: 2024-14


MediaWiki message delivery 03:36, 2 April 2024 (UTC)Reply

Tech News: 2024-15


MediaWiki message delivery 23:37, 8 April 2024 (UTC)Reply

Tech News: 2024-16


MediaWiki message delivery 23:29, 15 April 2024 (UTC)Reply

Tech News: 2024-17


MediaWiki message delivery 20:28, 22 April 2024 (UTC)Reply

Tech News: 2024-18


MediaWiki message delivery 03:33, 30 April 2024 (UTC)Reply

Tech News: 2024-19


MediaWiki message delivery 16:44, 6 May 2024 (UTC)Reply

Tech News: 2024-20


MediaWiki message delivery 23:58, 13 May 2024 (UTC)Reply

Tech News: 2024-21


MediaWiki message delivery 23:04, 20 May 2024 (UTC)Reply

Tech News: 2024-22


MediaWiki message delivery 00:15, 28 May 2024 (UTC)Reply

Tech News: 2024-23


MediaWiki message delivery 22:35, 3 June 2024 (UTC)Reply

Tech News: 2024-24


MediaWiki message delivery 20:20, 10 June 2024 (UTC)Reply

Tech News: 2024-25


MediaWiki message delivery 23:49, 17 June 2024 (UTC)Reply

Tech News: 2024-26


MediaWiki message delivery 22:32, 24 June 2024 (UTC)Reply

Tech News: 2024-27


MediaWiki message delivery 23:59, 1 July 2024 (UTC)Reply

Tech News: 2024-28


MediaWiki message delivery 21:32, 8 July 2024 (UTC)Reply

Test and co-create a new feature for reusing references with different details



this is Lina and Eline from the Technical Wishes product team at Wikimedia Deutschland. We hope this message finds you well!

We are currently working on a solution to help Wikimedians easily reuse references with different details – a problem related to several Community Wishlist Survey wishes (partially) supported by you (e.g. 1, 2, 3, 4).

We want to invite you to a user testing session. During the session, you can test a prototype for Visual Editor and provide your feedback. Sessions will take 30–45 minutes, compensation is available. If you are interested, please sign up here (privacy policy).

Please note that most likely, we won’t be able to have sessions with everyone who is interested. We will try to test with a diverse group of wiki contributors. If you’re a fit, we will reach out to you to schedule an appointment.

Hope to hear from you soon, and please let us know if you have any questions!

Best, Lina Farid (WMDE) (talk) 18:17, 10 July 2024 (UTC)Reply

Tech News: 2024-29


MediaWiki message delivery 01:31, 16 July 2024 (UTC)Reply

Tech News: 2024-30


MediaWiki message delivery 00:04, 23 July 2024 (UTC)Reply