Wikimedia Meta-Wiki

Community Wishlist Survey 2022/Larger suggestions

< Community Wishlist Survey 2022
Community Wishlist Survey 2022
Larger suggestions
55 proposals, 466 contributors, 1167 support votes
The survey has closed. Thanks for your participation :)



1%

Light bulb iconB This proposal is a Larger suggestion. There is no guarantee this proposal will be implemented. Supporting the idea helps communicate its urgency.

  • Problem: The WMF's funding is larger than ever, reaching obscene amounts, and none of that seems to make its way into community support / addressing technical requests. This proposal is simple. Allocate at least 1% of the WMF warchest/yearly budget to the Community Tech team. In 2019–2020, the WMF raised $130M, 1% of that is $1.3M. This is small potatoes for the WMF, but would ACTUALLY FOR ONCE yield tangible impacts on the features the community actually want, rather than on... whatever it is the WMF is spending that money on.
  • Proposed solution: Allocate at least 1% of the WMF yearly budget to the Community Tech team. Hire people. Buy new servers for toolserver. Whatever else needs to be done.
  • Who would benefit: All the community and volunteers, who would finally get the technical support they've been craving for years.
  • More comments:
  • Phabricator tickets:
  • Proposer: Headbomb (talk) 00:30, 11 January 2022 (UTC)[reply]

Discussion

  • Hello Headbomb, what is Community Tech team? Thanks, PeterEasthope (talk) 01:02, 11 January 2022 (UTC)[reply]
    @PeterEasthope, Community Tech is the team solely responsible for the entire Community Wishlist Survey. SGrabarczuk (WMF) (talk) 02:01, 11 January 2022 (UTC)[reply]
    So the proposal is to allocate 1.3 M$ for this survey. What is the current expenditure? How is the number 1% arrived at? Assuming 1.3 M$ is more than currently spent on the survey, what will be added with the larger investment. Thx, PeterEasthope (talk) 02:16, 11 January 2022 (UTC)[reply]
    I don't know what the current budget is exactly, but the Community Tech team is apparently 12 people, whom I doubt are assigned full time on this. If we ballpark an average salary of $30/hour, that's roughly $62,500 per full time coder per year, or ballpark $750,000. $1.3M would get us roughly 20 full time coders at that rate. So maybe the proposal should be increase the Community Tech team to 20 full time coders that are specifically assign to deal with community requests. The 1% is symbolic. Headbomb (talk) 02:50, 11 January 2022 (UTC)[reply]
    Obviously it’s not as simple as $1.3m equating to 20 F/T employees, there’s other overheads & expenses involved aside from salary. It’d definitely be good to see exactly how much is attributed to the CMTT though to weigh it up. Jcshy (talk) 08:46, 11 January 2022 (UTC)[reply]
    Yes, there's overhead, but it's a ballpark figure. Point if you have $130M annual income, more should be spent on things that aren't PR and feel good initiatives. Headbomb (talk) 10:26, 11 January 2022 (UTC)[reply]
  • Do we know what the current percentage of the WMF budget given to the team is? {{u|Sdkb}} talk 01:06, 11 January 2022 (UTC)[reply]
  • I was actually considering making a proposal like this myself (I did not think about 1% specifically though, and I don't know if it is an adequate number. The point is that the team has to be bigger in several kinds of resources, perhaps at cost of teams that are not working towards direct community requests). --Base (talk) 10:03, 11 January 2022 (UTC)[reply]
  • Could this be formulated more diplomatically? I think it's the most important proposal out here, but starting with the word cancer is not the best strategy to get overwhelming support. 1% is quite modest, if you compare this with the back-of-the-envolope estimate of current spending. Would you consider adding an additional medium-to-long term goal of say 2.5%? Femke (talk) 10:44, 11 January 2022 (UTC)[reply]
    • +1. Remove the aggressive "cancer", and instead state what the current budgets numbers are for that team, and name their responsabilities or give a link towards those details. How much less than 1% is it? This proposal is basically a signal from the online community to WMF, that transparency/oversight is wanted over what happens to our donations. --Enyavar (talk) 12:13, 11 January 2022 (UTC)[reply]
    • +1 on the phrasing change, I can handle being tactful if it makes it more likely to get those who disagree onboard, and +1 on bumping the numbers - let's ask for 2%. Two helpful numbers to include would be the amount spent on knowledge equity and the per/year salary of the new CEO (which, for clarity's sake, I don't think is unreasonable, just a good mark of how small the community tech budget is) Nosebagbear (talk) 12:33, 11 January 2022 (UTC)[reply]
    • Maybe it could be changed to something like "from what has been described as cancer-like". I'd also like to note that just increasing spending by itself never helped anything:
the money also has to be actually useful and it should be spent well and efficiently. All of this could tie in with my proposal below to add a banner at the top of all software-development Wikipedia articles to engage developers which would link to a page/system to organize, streamline and facilitate the development such as via selected tutorials&tasks, making it easier to set the development environment up, badges and rankinglists.
-1 on the proposed phrasing changes so far, that term is well-known and I immediately knew the page it was linked to.
I think we should strive to facilitate maximum volunteer development (some of that could for example turn into payed development over time) and maximum usefulness of both payed and volunteer development (such as focusing mainly on high-priority tasks of community wishlist proposals and phabricator tasks that e.g. decrease running costs, are relatively quick to implement, got much support or would save much editors' time).
--Prototyperspective (talk) 12:56, 11 January 2022 (UTC)[reply]
  • An excellent suggestion. We may want to work on the detail but I'd support any of the wordings so far. An organisation as rich as the WMF should not have a resource bottleneck on the thing it was actually created to do. Certes (talk) 14:38, 11 January 2022 (UTC)[reply]
  • $30/hour is significantly lower than it should be given the higher than US-average number of staff in the Bay area. It also doesn't factor in the additional costs. I know we are going "you can give more than the 1%", but I reckon they're probably already spending about 0.9% on the Team. Nosebagbear (talk) 15:20, 12 January 2022 (UTC)[reply]
  • I don't think there is a shot in hell of the Wishlist Survey determining WMF staffing or budgets. Not that it's a bad idea for more full-time help. Just saying. -- GreenC (talk) 19:23, 12 January 2022 (UTC)[reply]
    Not determining perhaps, I would see it more like a petition that can go far to mend the relationship between the community and the WMF. Femke (talk) 20:01, 12 January 2022 (UTC)[reply]
  • FWIW, the budget allocated for "Platform Evolution" (defined as "to provide technical systems to support equitable, global growth such as through the addition of a caching center that serves Africa and the Middle East, as well as investing in the technical future of our projects") was increased from US$2.4 million to US$7.9 million in the 2021-2022 WMF Annual Plan. RamzyM (talk) 02:15, 14 January 2022 (UTC)[reply]
  • (1) This is out of scope for the Community Tech Team so this is not the right forum. (2) It's also not in the right ballpark. Even at the middle of San Francisco market rates, the annual total cash comp of this team with taxes and benefits would already be well over $1.3M. czar 19:07, 14 January 2022 (UTC)[reply]
  • We will not get it, but we should keep asking, to make it clear to the WMF what the community thinks their priorities should be. The amunt specified should be increased, as Czar and others have pointed out--Using Nosebagbear's estimate, and realizing it will take time to increase capacity, we should ask for a doubling of between $2 and $3 million this year, increasing as possible in the future. The bottleneck is managerial priorities, not financial unavailability. DGG (talk) 21:22, 15 January 2022 (UTC) .[reply]
    I've made an alternative proposal on talk, asking for a doubling, and in more diplomatic terms. The goal of this is to convince the WMF, and I think this type of wording will give us a larger chance of success. Femke (talk) 11:47, 16 January 2022 (UTC)[reply]
  • Agree in principle. I'll echo what some others have said: the framing of the linked essay is antagonistic to the point of being self-defeating. That's not to say it doesn't have a point in there, but if the goal is to be taken seriously, link somewhere else. There's no shortage of "WMF has a ton of money" links. But yeah, I asked about how to get funding increased at a Community Tech Q&A somewhat recently, and don't recall that I got a clear answer (apologies to those who responded if I'm misremembering). I think perhaps this is something we'll need the Movement Charter folks to throw their weight behind (however much that weight is). It's a clear step the foundation could take which would address the widespread belief that not enough of the budget goes to directly support the community. — Rhododendrites talk \\ 15:14, 16 January 2022 (UTC)[reply]
  • We absolutely do need much more funding directed at the technical side of the project. Currently the developers are clearly overworked; a lot of the early decisions have proven to be ineffective or simply bad (see our "amazing" parser, for example). Now we are also facing an increasing number of security threats that, again, cannot be eliminated simply because of how the project was built. This is a major tech issue and it is my wish to get more tech workpower so I believe that this submission should stay in the Community Wishlist. Le Loy 04:07, 18 January 2022 (UTC)[reply]
    I agree too! This will be very good for WMF! Esaïe Prickett (talk) 00:53, 20 January 2022 (UTC)[reply]


The money are not everything. We have the money and job offers. But what are the problems? The error in Wikimedia Mowement and WMF. I think:

  • The normal user don't know about the news in Wikimedia Movement.
  • The normal user don't know about something more about the news on him local wiki, universities, about metawiki, WMF and about the jobs of WMF.
  • Wikimedia Movement and WMF only to wait, wait and wait.
    • I do not read anything about events in the Slovak media in Wikimedia movement. Nothing about job offers.
    • None The day of developers.
    • No promotion in SWAN and him entities.
  • It is the year 2022, none the year 2030. We don't have the Global Council.
  • Nobody is looking for / addressing talents.
  • Money-results: where is the report for the past year? If a person sees that it is useful, he makes an interesting contribution, wants to help or join.
  • IT people are not much.
  • Job offers:
    • None global content search.
    • If I am interested in projects and not programming languages?
    • What is the labor price?
    • None special contact / e-mail.
  • WMF presentation of works is totally like just an institution.
  • Why should I work for WMF? WMF is one of the other organizations why I should work.
  • Nobody investing in talent people.
    • Who needs a detailed knowledge of Wikidata or other languages? In him normal life doesn't need know very detailed. He doesn't generate any complex analyses.
  • Is working for WMF very special? Or can I use knowledge elsewhere?
  • International work can be discouraging.
  • Tech/News – it's Tech news (People can create some small context), or the report with the technical news (Very formal, narrow shot)?

✍️ Dušan Kreheľ (talk) 17:47, 10 February 2022 (UTC)[reply]

Voting

50 wishes

Light bulb iconB This proposal is a Larger suggestion. There is no guarantee this proposal will be implemented. Supporting the idea helps communicate its urgency.

  • Problem: The wishlist system creates scarcity, making volunteers compete for solution to bugs that should be working without volunteer's need to ask for. Each year, only the 10 most voted are evaluated and, some of them, are declined despite the popular vote. This creates more frustration. Even those that are not declined after the vote, may be forgotten or even not done: 2021 1/10 done, 2020 2/5 done, 2019 4/10 done. In the last three years, 25 proposals were made, and only 7 of those are done. Most of the projects proposed here, discussed and voted by volunteers, investing [hundreds of] hours of volunteer time, are declined, postponed or never done. Only a minority (less than a third) of the projects may be done, and some of them are even proposed to be voted... the next year. This creates even more frustration. Why should we be here proposing or discussing something that we know won't be ever done?

    On the other side, we find that the Wikimedia Foundation has funds and budget. The WMF is in good financial shape, but delivers a really scarce part of their budget to solve serious infrastructure issues that can put all our other efforts at risk.

    Finally, most of the things that are asked here are not even wishes... but only asking for things to work, even things that were working but broke due to some change made by the WMF. Solving basic infrastructure issues shouldn't be something we ask for in [a scarce handful of] wishes, this should be solved by default, without users and volunteers noting that things are broken.

  • Proposed solution: Just implement the first 50 wishes [each year]. That would make thinks work.
  • Who would benefit: All the community and volunteers. All the readers, who are reading us in obsolete ways. All the free software environment, because we create more free resources.
  • More comments:
  • Phabricator tickets:
  • Proposer: Theklan (talk) 20:12, 10 January 2022 (UTC)[reply]

Discussion

  • Wait... I thought all suggestions would be voted on "Support" or "Reject", and the Support's would be then be tried to tackle. Only 10 get selected per year?? --Enyavar (talk) 12:17, 11 January 2022 (UTC)[reply]
    Sort of, generally about 5-7 actually get actually completed. —TheDJ (talk • contribs) 13:34, 11 January 2022 (UTC)[reply]
    The real data is 7 done from the last 25 voted proposals. Theklan (talk) 16:07, 11 January 2022 (UTC)[reply]
  • I mean sure.. but realistically this is like asking the genie, as one of your 3 wishes, to give you 50 wishes. Sounds a bit unrealistic. I'd prefer more concrete proposals, like the 'x%' one on this page. —TheDJ (talk • contribs) 13:37, 11 January 2022 (UTC)[reply]
    Both can work together. Furthermore, the 1% is short. Theklan (talk) 16:08, 11 January 2022 (UTC)[reply]
  • I fully support the description of frustration and desperation this process produced. I was one of the most motivated promoter for Wiktionary community and our proposals increased year after year (in quantity and votes) to finally have one proposal that reached #5 in 2020 (the year dedicated to undersupported projects) but it was finally not done neither. So, I will just copy-past this proposal and not do any publicity for the process anymore. This is just a loss of time for any wikimedian from a small community. I know the Community Tech Team is really well informed of this issue and willing to improve the situation. Thanks a lot for all the job you do, really. I am not judging any decision you made about your priorities, you did what you can do, but it is not what is needed. I think this discussion about funding more people to challenge more issues is fundamental now, but it is also a choice of organization and I think more teams are needed to have product managers closer to the communities, and teams dedicated to each project rather than only team for transversal issues that do not adapt properly the new features to small communities. Noé (talk) 11:10, 12 January 2022 (UTC)[reply]
  • The wishlist process to date has been treated as a way of 'satisfying a few popular community needs', something nice to have on the fringes of development, rather than 'listening to the most active users and community developers to help prioritize where to tune / generalize / fix systems and pay down technical debt'. The top proposals may be a better source for the latter than the former. [The historical list of most-popular wishes covers a range of things, and is not just "most popular quality of life improvements" :) ]
Energy spent ensuring that wishes can be resolved effectively at the scale of a few dozen a year would likely be more impactful than many other current initiatives. Some of the wish-granting effort seems to go into overhead that might scale nicely if this were part of a thorough plan for refactoring codebases and related architecture, and the wishes simply helped determine which areas were tackled first. –SJ talk  23:30, 23 January 2022 (UTC)[reply]

Voting

Dark mode

Light bulb iconB This proposal is a Larger suggestion. There is no guarantee this proposal will be implemented. Supporting the idea helps communicate its urgency.

  • Problem: Wikipedia's bright themes/skins are difficult on reader's eyes.
  • Proposed solution: Add a light-on-dark color scheme; toggleable by either the user interface or by the user's browser preference.
  • Who would benefit: The average reader
  • More comments: This was ranked the #2 wish on 2019's Wishlist Survey. While there were internal planning conflicts, hopefully those have resolved in the last two years so that New Vector can get dark mode. The most popular websites, web browsers, and operating systems, offer built-in support for a dark/night mode without hacks or workarounds. This also contributes to site accessibility and user energy savings (on OLED screens).
  • Phabricator tickets: task T26070
  • Proposer: czar 23:32, 10 January 2022 (UTC)[reply]

Discussion

  • Community Wishlist Survey/FAQ#Avoid proposals that were declined in the past has Dark Mode as the first example. Procedurally, this proposal should be archived, but I have a hunch too that things have changed in the past two years. People seem to really enjoy mw:Extension:DarkMode and w:Wikipedia:Dark mode (gadget), so the work is nearly done and the popularity among users more or less proven. It just needs some final refinements and being seen through WMF deployment. So instead of archiving, I'm going to move this to our "Larger suggestions" pile, which is a place to for the community to express their desires for the visibility of other product teams and the broader Foundation. Please continue the discussion there and place your votes when the voting phase starts. I do apologize that Community Tech will have to decline this though, as much as we don't want to! MusikAnimal (WMF) (talk) 23:47, 10 January 2022 (UTC)[reply]
    @MusikAnimal (WMF), is there any indication that this still conflicts with mw:Desktop Improvements, or that any other team would take up the work? If not, and if it remains a top request two years later, why wouldn't it run in the Reading section for Community Tech consideration with other Reading proposals? If the team overlap conflict from two years ago still exists, so be it and the team can deny it, but isn't this worth checking as long as there is large, long-standing interest and no issue of technical infeasibility? Relegating this to "Larger suggestions" does not seem appropriate here. czar 03:27, 15 January 2022 (UTC)[reply]
    @Czar As I understand it, the solution of using the CSS invert filter wasn't approved. Additionally, our Varnish caching meant we couldn't offer the feature to logged out users. Then a different solution was presumably going to be part of Desktop Improvements, or at least things were going to change enough that we wouldn't want to attempt any other solutions because of potential conflicts. Obviously dark mode still isn't here, and I do not know for certain if it is still on the road map for Desktop Improvements (it doesn't appear to be). But either way, Community Tech's attempt at this was rejected. I personally don't really see a workable solution without using the CSS invert filter, in the absence of some other major changes that somehow would allow us to control parser output on desktop without stomping on any community-maintained designs, which would put it much too out of scope for our team, so even then it would still belong here under Larger suggestions. Sorry! I do believe this category will get a lot of attention during voting, if that means anything. The goal here is to give the WMF and broader movement an unfiltered window into the technical desires of the community. I hope this proposal gets the attention it deserves, because believe me when I say if we could have at any point deployed mw:Extension:DarkMode, we would have ;) MusikAnimal (WMF) (talk) 21:37, 15 January 2022 (UTC)[reply]
  • My historical concern with "dark mode" proposals was that it's tricky to style on-wiki content for a dark mode. If an official dark mode existed it could add one or more official CSS classes for use with TemplateStyles, making it easy to provide downstream support for a dark mode in templates and such, which sometimes make assumptions that backgrounds are light and text is dark. Having the support be official, rather than relying on ad-hoc gadgets and such, would make a big difference by providing infrastructure for us to build better content-side support for the feature. {{Nihiltres |talk |edits}} 00:27, 11 January 2022 (UTC)[reply]
    I agree. Wikipedians seems to be extremely against (if you look a the bug tracker) it which is a bit ridiculous. Lets just fix it. Almost every average user would enjoy it. Mrconter1 (talk) 06:29, 11 January 2022 (UTC)[reply]
    I don't think that's a fair assumption @Mrconter1: - it didn't accidentally end up at the top of a previous wishlist because Wikipedians didn't like it, after all! And the usage numbers of the various dark mode CSS etc also suggest we'd like it. Lots of the bug trackers just indicates that making a dark mode that doesn't occasionally either cause significant problems or blind the editors wandering around the less travelled paths onsite is...difficult. Nosebagbear (talk) 14:04, 11 January 2022 (UTC)[reply]
    I did not mean every Wikipedian. I am talking about Wikipedians that are responsible/driving the development of the site. Mrconter1 (talk) 14:29, 11 January 2022 (UTC)[reply]
    Im with @Mrconter1. Adding on, it would make it easier for everyone that wants to give their eyes a break like me. Rzzor (talk) 21:27, 11 January 2022 (UTC)[reply]
    Don't confuse 'against' with 'this is more complicated than ppl make it out to be'. Developers on Phabricator generally discuss the work that needs to be done, not the desire of the feature. —TheDJ (talk • contribs) 10:31, 12 January 2022 (UTC)[reply]
  • There is already some infrastructure for the mobile apps that provides dark, black, or even sepia modes. While it struggles with some custom inline css in the content, for the most part it works pretty well. Obviously, it is based on Minerva. So the real and more specific proposal/need here is Dark Mode for (improved) Vector and Minerva in the web browser. --Geraki TL 13:07, 11 January 2022 (UTC)[reply]
  • As a frequent reader, but occasional editor, I really want dark mode and don't care if it doesn't work in edit mode. The majority of "content" sites/apps on the net are adopting dark mode for nighttime reading, wikipedia now stands out as an exception. I've installed the extension which mostly works, and am a little mystified why it wouldn't be a priority for wikipedia. Its by far the most obvious problem with WP as a reader.—The preceding unsigned comment was added by Aaron Lawrence (talk) 03:29, 13 January 2022 (UTC)[reply]
    Yes, dark mode is important and Wikimedia is left behind. Leaving all of the technical limitations, we should have dark mode for dark reading at night. Thingofme (talk) 14:41, 6 February 2022 (UTC)[reply]
  • concider:some Smartphone userer using night mode, so wiki have to kow, wich mode the user is curentlyusing--JanEhlebrecht (talk) 12:37, 16 January 2022 (UTC)[reply]
  • +1, this would definitely make the list of "most popular QoL improvements". It would reduce the amount of energy currently being wasted on developing + trying to maintain other gadgets and extensions, and as Nihil notes help others build better content-side support. –SJ talk  23:35, 23 January 2022 (UTC)[reply]
    • It would also reduce the amount of electrical energy consumed by displays! Rich Farmbrough 21:26 29 January 2022 (UTC)


Where is the problem? Where is the problem to have the native dart mode? Dark mode is not extra new thing in world. WMF (owner of MediaWiki) have the money. Tools? We have the Less or another's, create some preprocessor. Missed people? WMF, You find the people found on the project or buy a solution from another company. Or, can create the comunity create the dark theme? Does the idea / solution open the door in the main stream? If yes, community, make a collection. The ways exist, so, do we want to have that? If yes, so, stop me compliance and moan. ✍️ Dušan Kreheľ (talk) 19:09, 10 February 2022 (UTC)[reply]

I'm shocked this was ever turned down for "technical reasons." This is an accessibility issues. I already need sunglasses just to look at a computer monitor without getting a migraine, and this hack-designer propensity for turning websites into white slabs glowing with the glare of the sun just because Apple and Google rolled the style out everyone is insanity. Some of us need dark mode to see. Having to research it like a technical problem to find a work around is horrible blight to force on someone who your website is already giving eyestrain. Were you a government website in my country, I'd file a complain with the Human Rights Commission, because Wikipedia is a similarly important website which I am funding. And to be sure, I'd be much more likely to donate again if I need I could put it towards dark mode specifically. I read before that there were implementation details - I don't care. Better is not the enemy of perfect. The barest bones most general and generic CSS toggle would make a world of difference. I am unfortunately used to the possibility that my disability will confer a second-class experience, but I would kill for a second-class experience over inaccessibility. --Seocwen (talk) 16:54, 31 December 2023 (UTC)[reply]

Just to continue this rant, let me explain the horrible process a disabled user might be facing as they go looking for dark mode.
- You've already had a terrible headache several days straight but still have research to do for work.
- You go looking for dark mode on the front page - this is Wikipedia, how could they not have an accessibility feature as simple and basic as dark mode?
- I have to go Googling about how to get Darkmode working.
- I find out that for God-knows what reason Wikipedia has no dark mode, and that a bunch of technical work arounds will be necessary.
- So, I have to go recover a years old account just so I can sign in to implement the "easiest" workaround,
- The easiest workaround requires me to navigate through a huge bloated settings interface.
- There's so many things on the page i'm looking for I need to control-f and search for dark mode.
- I click the box for dark mode and nothing happens.
- I save my setting and nothing happens. I go looking around some more.
- Finally, I find the word dark mode on User-related UI, which is unfamiliar since using an account is new.
- It works - thank god -
- But it only works on Wikipedia... Here on Meta.wikimedia.org, it's back to burning my eyes.
- All of this, I have to read an navigate while my eyes are on fire because I have no dark mode.
Conclusion: Quit pining for some-gold played Military procurement solution and at least for the time being roll out a total piece of shit dark mode that's at least better than being skull-fucked by your website's brightness. It might not be a priority for normal-sighted people, but for disabled people, it most certainly is. Seocwen (talk) 17:11, 31 December 2023 (UTC)[reply]

I found an existing dark‐mode project https://www.mediawiki.org/wiki/Skin:Timeless-DarkCSS/timeless-dark.css based on the Timeless skin and I used it as a base of my own: https://meta.wikimedia.org/wiki/User:Ratajs/global.css You can use it for inspiration… Ratajs (talk)

Voting

Make SecurePoll accessible through local wikis

Light bulb iconB This proposal is a Larger suggestion. There is no guarantee this proposal will be implemented. Supporting the idea helps communicate its urgency.

  • Problem: To vote in a SecurePoll election, you need to be redirected to votewiki (vote.wikimedia.org). This leads to potential vulnerabilities (see phab:T298849) and it also requires the interface language of votewiki to be changed based on the language of the local wikis who are running an election there at each given time.
  • Proposed solution: Refactor the code of SecurePoll to properly use CentralAuth and SUL, so that users don't have to leave their local wiki at all to vote.
  • Who would benefit: Wikis that hold elections using SecurePoll (currently enwiki and fawiki, soon to include zhwiki and more).
  • More comments:
  • Phabricator tickets: phab:T298849 (it is private for security reasons)
  • Proposer: Huji (talk) 01:03, 11 January 2022 (UTC)[reply]

Discussion

May be "Refactor the code"? I wonder if it is possible to simply make voters to login into votewiki through CentralAuth. --Steven Sun (talk) 03:46, 11 January 2022 (UTC)[reply]
No, more likely the privacy/security aspects of it. That's gonna make this a really big task. Also steers it outside of the expertise of the community tech team a bit I think as they would have to consult lots of other teams. —TheDJ (talk • contribs) 13:42, 11 January 2022 (UTC)[reply]
By the way, what is the purpose of local Special:SecurePoll page? You still need to go to an external wiki to vote anyway. Hope one day it could be uesd as a standalone local voting portal. —— Eric Liu（Talk） 16:41, 11 January 2022 (UTC)[reply]
It seems to be a fix for earlier days without SUL, but now, as we have it, it seems better to host elections locally (unless there's CU concern). 1233 （T / C） 16:29, 19 January 2022 (UTC)[reply]

Voting

Light bulb iconB This proposal is a Larger suggestion. There is no guarantee this proposal will be implemented. Supporting the idea helps communicate its urgency.

  • Problem: We're having these surveys every year but only a very small fraction gets implemented.
There's also a large backlog of code issues on phabricator, and many even very basic features haven't been implemented so far.
This is despite of the code issues not including many existing and potential proposals.
Often code issues, if implemented at all, take over 5 years from creation to implementation. There could be much more development.
  • Proposed solution: Add a banner asking developers to help with MediaWiki development.
The banner is only displayed at the top of all software-related articles (at least all software development related ones). Alternatively it could also be displayed on all pages.
  • Who would benefit: Wikipedia as a whole and all existing and potential sites using MediaWiki software.
  • More comments: It could be further improved by setting up e.g. a competition-like leaderboard of volunteer developers who helped the most on the page the banner links to. Maybe there could also be functionality to donate to teams/people who implement Wishlist proposals to fund their implementation. However, I think it would be best if the first time such a campaign is run, only volunteer development gets facilitated, especially because it may be difficult to design this in a way that's fair and well-functioning if that's possible at all (I think it could be fairly simple).

    Engineering would be required to put the banner only on software development related pages. This could be done by using categories. It would also be required for things like rankinglists and badges. The badges could be rewarded for certain tasks like closing a difficult issue or a number of issues and would get certified. Users could then use these badges on their userpages and even outside of Wikipedia. Moreover, engineering could help ensure that people can get started with the development well and quickly and that efforts are streamlined in a way that ensures contributions are constructive. Further details and additional ways could be worked out later or get added to this proposal (via edits and comments).

This proposal also got substantial support on reddit on multiple subreddits.
It seems like at the talk page Ayack Otourly Stryn and Sänger expressed discontempt with how Wishlists have been implemented so far.

Wikipedia runs on MediaWiki software as its core and most proposals here are about this software. It is this page or a similar page, that the page of the banner should link to or whose information the page should contain.

Note that many proposals are not yet code issues. For example, I have many proposals I never published so far because I'm still waiting for more important issues to get solved first (like a button on the Watchlist to see all changes since last visit per page which could save a lot of editors' time).

I also think that more of the WMF's financial resources should be dedicated to software development of the Wishlist proposals and phabricator tasks (this also got substantial support on reddit). However, this proposal here is "only" about the banner (and everything directly related to it on the landing page etc). I think that regardless of what's decided related to the use of funds and funding-mechanisms, we should strive to maximize volunteer MediaWiki-related development.

Note that visibility, feedback and being part of a campaign (roughly described), rather than an unfacilitated strive to help out by interested individuals, can substantially increase motivation. This could also be the idea behind #1lib1ref.

I don't think that such a campaign would draw substantial human resources (or time, expertise, effort) away from other important software development. In particular, away from open source software development/maintenance of important packages.

Discussion

A category for example. --Prototyperspective (talk) 20:31, 10 January 2022 (UTC)[reply]
How many experienced developers would be reading the Wikipedia articles for those languages in question? Wouldn't just having a global banner be much more appropriate with a wider reach? Ed6767 (talk) 22:33, 10 January 2022 (UTC)[reply]
  • Proposals should require engineering work; this one doesn't really do so. The only somehow engineering-related part of the proposal is to identify "software-related Wikipedia articles", so the proposal could be reduced to "create software that automatically identifies software-related Wikipedia articles and provides a list of them for displaying banners"… I don't really see how this is an improvement to be made by the Tech Team. Mostly, the page you're looking for seems to be CentralNotice/Request. ToBeFree (talk) 19:09, 10 January 2022 (UTC)[reply]
Yes, it's that simple that it doesn't really require any engineering work of significance, so it's really just the decision(-making / willingness) of the WMF that causes this to not get implemented. However, it still requires a minor effort of engineering, which Xaosflux asked about above: how to identify said pages. Moreover, if a rankinglist and things like that are added these would also require engineering work. --Prototyperspective (talk) 20:31, 10 January 2022 (UTC)[reply]
  • You've listed this as something for "admins and patrollers" - is this something you'd only see showing for such groups - or is this something you want to target general readers of projects? — xaosflux Talk 19:10, 10 January 2022 (UTC)[reply]
General readers. It was the best fit of the available categories of the Wishlist Survey. --Prototyperspective (talk) 20:31, 10 January 2022 (UTC)[reply]
Please unarchive it: see the answer above, it does require engineering work. It's also a wishlist proposal. --Prototyperspective (talk) 20:31, 10 January 2022 (UTC)[reply]
  • @Prototyperspective, this has been archived but I was originally writing a comment regarding this proposal.
    I think your proposal and Reddit post is pretty inaccurate and outdated, and ignores so many points - you mention "intransparency" in the WMF despite literally everything being logged and your only citation being an opinion on a talk page? You mention the WMF is "unwilling to facilitate volunteer developers to help with the thousands of already-existing code issues", despite the fact the WMF provides Wikitech, Wikimedia Cloud Services, technology grants, hackathons, and so much more. You also said "basically nothing could be done about it", which is a very pessimistic view. I could go on, especially with your irrelevant raising of log4j and heartbleed. You have to remember too that there is a big difference as many MediaWiki features are implemented through extensions and gadgets - these are the things that often go unmaintained and become neglected - adding a feature to MediaWiki itself isn't necessarily as simple as you'd think.
    You also seemed to ignore that moving from Gerrit to GitLab is already planned and timelined?
    I just don't feel you've done the adequate amount of research required for a proposal like this. You do raise some good and well known issues however, and there are many more valid criticisms regarding the current developer situation that could be made, but you completely missed the point here with weak rationale. It is true that development is lacking and not many people know they can and/or want to contribute to MediaWiki development and how current resources and developer support isn't advertised or promoted as much as it should be. My advice is you should go back and rework your proposal and come up with a plan for how developers from outside the Wikimedia community would feel more welcomed and have more resources available to them, then submit it through the appropriate venues, rather than the community wishlist. Ed6767 (talk) 20:10, 10 January 2022 (UTC)[reply]
    See also mediawikiwiki:Bug management/Development prioritization Ed6767 (talk) 20:16, 10 January 2022 (UTC)[reply]
Provide proof of your claims (which are wrong). I removed the largely irrelevant mention of log4j etc. With this unwillingness I was referring to the blockade to add such a banner. I already knew and discussed the GitLab switch before making the post. Your points basically all misunderstood my points and aren't about the proposal. The Wishlist is a perfectly suitable place to propose this. I already read that page. I reworked the proposal to remove the log4j side note. --Prototyperspective (talk) 20:57, 10 January 2022 (UTC)[reply]
@Prototyperspective, I'm not a fan of your dismissive attitude, but sure:
> With this unwillingness I was referring to the blockade to add such a banner
This was not clear, but if you have a solid proposal all you need is consensus through the appropriate venue, the community wishlist is for engineering proposals, the infrastructure for global notices is already in place. I was also responding to some of the points made in your Reddit post.
I'm not saying I'm opposed to this, onboarding more developers from the wider public would be a great thing - however, I'm saying you need better planning and better rationale. Onboarding too many developers at once may create a massive influx that would need planning in place, not to mention the responsibilities that would be in place for security, reviewing and setting up each proposal and documenting it. Simply throwing as many developers as we can at the wall and seeing who sticks isn't the best strategy and would, in my opinion, make things even more disorganised. Ed6767 (talk) 22:13, 10 January 2022 (UTC)[reply]
I wanted to keep it short on purpose. (Other than that, it's not like I've never discussed related things before.)
The annual plan is what I linked to because it does not show exactly where the money goes. I mean I could be wrong but so far I can only find very large composite expenses for whole areas of expenses like Programmatic (and some other users have expressed similar concerns). Basically, the only main reason for why I didn't link to it directly but a Talk page is because it obviously gives the reader another impression.
The technology-related efforts are great and all and I wasn't saying there was nothing going on there at all, I mean one would reasonably expect there to be efforts. I was referring to the banner only and related facilitation of volunteer development like larger, more visible hackathons, rankinglists, badges, outreach, and so on. I just don't think the banner is an "only" – it would be the starting point of larger things, basically a requirement to get the development capacities and do whatever else you'd like to do to improve the Wikipedia software (including facilitating more development).
> but if you have a solid proposal all you need is consensus through the appropriate venue, the community wishlist is for engineering proposals, the infrastructure for global notices is already in place
This proposal is appropriate here in three ways: it fits the description "community wish/proposal" and "platform improvement", it's about Community Wishlists in a meta way, and engineering is required to make it work. The infrastructure for global notices already being in place makes it even easier to implement, making it more strange that it hasn't been done before. But that's not all the engineering that would go into this, especially depending on how well it's implemented (the better the more engineering would go into it...even though the survey isn't called "Community's Engineering Wishlist").
The linked reddit post was not meant to be a major point, it was just to show that externally there is considerable support for doing so – reddit is not the Wikipedia/Wikimedia community so it has not a significance as large as you may have thought I'm suggesting it to be.
> Onboarding too many developers at once may create a massive influx that would need planning in place, not to mention the responsibilities that would be in place for security, reviewing and setting up each proposal and documenting it.
See? These things would require engineering. However, it would be about implementing proposals, not about creating more proposals. Maybe I should also add more details about that (including streamlining and onboarding) beyond badges which would also require engineering.
Having such a large wall of text under "Discussion" is a problem though so maybe it should be wrapped in a collapsed template one can expand.
--Prototyperspective (talk) 00:20, 11 January 2022 (UTC)[reply]
It seems that as I've critiqued your idea you've clarified and developed your idea, but in a contradictory way - and what I said is more than engineering, but would require policy, funding and planning. These are some great ideas to increase onboarding, and I think having a much larger hackathon event that is publicly advertised to an audience wider than the general community is a brilliant idea that should be developed, but there needs to be much more in depth planning as for a project as large as MediaWiki, it's not trivial. Not to mention some of your comments disregarding the WMFs software engineering team [1][2][3] and arguing with people on Phabricator seem, in my opinion, quite disrespectful towards their continued hard work, especially as a developer I have worked on and benefitted from their work and support, along with many others.
Ignoring that we're swerving vastly off topic, I still don't think this is appropriate for the wishlist:
  • Overlaps with another team: see mediawikiwiki:Developer Advocacy (you may want to open a phab ticket with a more developed suggestion there for their consideration)
  • You still haven't proven that this needs engineering work (i.e. development of a new tool/tech/etc.) - the tech exists, policy page and program development is different and would require further discussion at a more appropriate venue
  • This isn't just one problem that needs solving, but rather something that should be developed into deeper proposals in a different venue - this is not what the community wishlist is for
Of course, it goes without saying that the quickest way to get what you want in FOSS is to aim to fix things yourself so that you can also contribute and help the community, and it may also help with giving your perspective for developing future proposals. Ed6767 (talk) 02:04, 11 January 2022 (UTC)[reply]
You said it didn't require engineering work. I certainly don't oppose related efforts of "policy, funding" (and planning) which you think are required for this.
I'm very grateful for the developers. I was saying there should be more development. And not even once were my concerns addressed in my arguments there even though I repeated them about 10 times, trying to make them ever clearer than before. I always remained respectful, not sure why you're suggesting I wasn't. Other than that, I think there ought to be certain humility when using donated money.
I don't think that "we're swerving vastly off topic" – you've done that by causing a large a wall of text beneath this proposal that's largely not about the proposal at all.
It's not about FOSS but about Wikipedia/Wikimedia and it's a very due platform improvement proposal which does require engineering (lots of it if you do it very well). --Prototyperspective (talk) 11:24, 11 January 2022 (UTC)[reply]

Voting

Less embellishment

Light bulb iconB This proposal is a Larger suggestion. There is no guarantee this proposal will be implemented. Supporting the idea helps communicate its urgency.

  • Problem: Embellishmentosis
  • Proposed solution: Less embellishment.
  • Who would benefit: Everyone reading a Wikimedia page with a Web browser.
  • More comments: Example: "edit source" suffices; remove "edit".
  • Phabricator tickets:
  • Proposer: PeterEasthope (talk) 01:21, 11 January 2022 (UTC)[reply]

Discussion

  • Hello PeterEasthope, thanks for adding a proposal. Could you provide more examples of the Embellishmentosis? We need to know the specifics of what you mean by the label you use. Perhaps this piece of documentation could be useful. Thanks! SGrabarczuk (WMF) (talk) 01:58, 11 January 2022 (UTC)[reply]
    In accord to the documentation.
    > Pick one specific problem and describe it in detail
    Here are two. No charge for the 2nd. =8~)
    (1) Two links are presented to edit a page or section thereof. "edit source" allows editing the markup text which is translated to create the HTML of the page. "edit" allows visual editing.
    "edit" is slow to load and restricts capabilities. "edit source" loads quickly and allows all editing. Visual editing is relatively recent. Before it was added there was only source editing.
    (2) Multiple "skins" are offered. Consider this principle of the Web: the server presents content with minimal imposition of presentation; the client has as much freedom in presentation as feasible. Imposition of skins is unnecessary. Focus on content.
    > Don't worry about finding the solution
    Here are my proposed solutions. Again, no charge. =8~)
    (1) Drop visual editing. Keep source editing.
    (2) Drop the skins. Impose as little style as feasible. If you want to help readers with presentation, offer style sheets which a reader can use according to taste. Ref. https://support.mozilla.org/en-US/questions/1271227 =8~)
    Regards, ... PeterEasthope (talk) 02:57, 11 January 2022 (UTC)[reply]
    "Two links are presented to edit a page or section thereof. "edit source" allows editing the markup text which is translated to create the HTML of the page. "edit" allows visual editing." is a result of your preference/configuration. You can change that in your personal preference according to my understanding. C933103 (talk) 08:23, 17 January 2022 (UTC)[reply]
    In Preferences I found the switch and shut off visual editing. The wording suggests it's temporary for beta. I'd rather it be permanent. Thx, ... PeterEasthope (talk) 05:17, 21 January 2022 (UTC)[reply]
Inescapable question: the work on the visual editor was by volunteers or by paid Wikimedia staff or by paid contractors? Thanks, ... PeterEasthope (talk) 17:04, 21 January 2022 (UTC)[reply]
Accidentally clicking the "edit" link for the visual editor results in a delay while editing is set up. =8~( If the visual editor is permanent, then the configuration switch to turn off the edit link should also be permanent.
Dismissing legitimate concerns as curmudgeonly will only discourage some capable and well meaning people from contributing. Look at what's happened with the Web. Many pages aiming to present simple information are severely burdened with JavaScript. Consequently a bus schedule which might be presented efficiently as a table in HTML5, is bogged with JavaScript. No problem for a contemporary iPhone or Android phone containing a JavaScript ASIC. Yes problem for reading the schedule with an old computer and Dillo. Try Dillo on a desktop machine. If possible an older generic machine. Immediately you'll notice how quickly Dillo opens compared to Firefox. Not a criticism of Firefox. Rather an illustration of the pervasive imposition of JavaScript. The endless push to more complex and resource consuming systems is a grave problem for the biosphere.
Climate change
Environmental degradation
We don't have to play into the hands of mega-corporations. Of all people, Wikimedians should exercise principled autonomy and initiative. Regards, ... PeterEasthope (talk) 16:33, 27 January 2022 (UTC)[reply]
I mean isn't it already possible to disable the visual editing at Special:GlobalPreferences#mw-prefsection-betafeatures?
Currently, yes, in Wikibooks I disabled visual. I hope the personal configuration option isn't dropped. Regards, ... PeterEasthope (talk) 17:53, 27 January 2022 (UTC)[reply]
I recall having to make some special config to get multiple edit buttons? C933103 (talk) 17:27, 27 January 2022 (UTC)[reply]
In Wikibooks, my default was "edit" and "edit source". In Preferences, I switched off "edit". Here I have only "edit" (= edit source). Apparently visual editing isn't available here.
This discussion is itself an example of why I advocate for simplicity. This morning I've spent at least an hour here which could have been spent on editing and writing. Exactly my concern. When a technology becomes established, focus shifts to embellishment with unnecessary complexity. Consequently some of the original value is lost. Illustrated by the Web as noted above. At some point people should recognize success and stop. Regards, ... PeterEasthope (talk) 18:26, 27 January 2022 (UTC)[reply]
Thanks for elaborating, Peter. Of course we should focus on simplicity, a minimum of JS bloat, and the like. It was your final comment about the "inescapable question" that struck me as unhelpful. The visual editor has increased the # of people I've successfully gotten to edit many times over, and was the most-requested feature by non-editors in the years leading up to it. –SJ talk  03:24, 28 January 2022 (UTC)[reply]
'... most-requested feature by non-editors ...'
Fair enough but please leave a permanent option for visual vs. source editing preference. As mentioned, inadvertently choosing visual wastes time. Might be only 20 seconds but a distraction nevertheless and seconds add up. The principle of "user centered interface", familiar to Mac users, is significant. A user should be presented with only pertinent and significant information. If a user uses only one of the two edit interfaces, there is no need for two edit links. It's a matter of psychology. Less can be more.
'...comment about the "inescapable question"...'
Accountability may be embarrassing but is necessary where a cooperative effort is aimed to a result. Without accountability efforts go astray. A harsh reality.
Regards, ... PeterEasthope (talk) 15:34, 28 January 2022 (UTC)[reply]

┌─────────────────────────────────┘
After writing the preceding sentence I happened to the read the "Wikipedia has Cancer" essay by Guy Macon. Disturbingly congruent to my concerns. Any donor should be seriously concerned about the noted refusals for financial accounting. The scenario of bankrupcy and acquisition by a mega-corporation is gravely disturbing. Exactly the fate of Mountain Equipment Coop, started in Vancouver by a group of outdoor enthusiasts. For several decades a wonderful success. Then it began to grow like a mushroom, opening stores across the country. Opposition to the growth was met with stonewalling. =8~| No problem for a few years. Then the economy shifted. MEC became bankrupt and was forced to sell assets to a private interest. I really don't want Wikimedia to fall to the same fate but, without accountability, that might be inevitable. =8~( Regards, ... PeterEasthope (talk) 15:42, 29 January 2022 (UTC)[reply]

Valerio Bozzolan> Comment "Please invest more than 1 minute in writing a good proposal."
Before I attempt to rewrite the proposal please make one specific criticism or ask one specific question. The meaning of "less embellishment" is clear. I gave two examples. An alternative statement in one word: simplify. Sorry to resort to a flippant cliche but what part of simplify is not understood?
> "The world is watching this conversation."
Encouraging although authorization of a change and implementation are controlled by a few people. If the authority doesn't support a proposal, it won't progress. Hypothetically, the board of directors has ultimate authority. The board can advance an interest or delegate to paid staff, few of which will support a proposal limiting employment. In any case there is risk of benefit to interests of a relatively small group of people on a relatively small time span. As noted above, the analogy to MEC is frightful. =8~(
Incidentally, the absence of an answer to my "inescapable question" suggests exactly one explanation: the answer is too embarrassing to state.
Regards, ... PeterEasthope (talk) 15:50, 13 February 2022 (UTC)[reply]
A third simplification, additional to the two above.
(3) For some links to articles, hovering the mouse pointer on the link gives a small preview of the article. I question the worth of the preview. In a page containing a high density of links, just moving the pointer across the screen can produce several unwanted activations. Every unwanted activation is a distraction and delay. Rather than use computational resources for preview, simply open the full article with a click. In absence of a click, do nothing. If previewing must remain, make it optional; provide a option to shut it off. Wirth's dictum again: resouces needn't be consumed merely because consumption is possible. PeterEasthope (talk) 16:57, 13 February 2022 (UTC)[reply]
@PeterEasthope: I'm on your side, but if the proposal is poorly written, the proposal readers (lot of people) invest too much time to understand how to help and sustain you, resulting in no one being able to support you. If you think that «Embellishmentosis - Example: "edit source" suffices; remove "edit".» is a good proposal, I thank the six people who put +1 understanding what you wanted. I didn't get it. Valerio Bozzolan (talk) 09:45, 14 February 2022 (UTC)[reply]
Another question which might help: what fraction of readers in Wikipedia adjust their Preferences? Thanks, ... PeterEasthope (talk) 15:33, 15 February 2022 (UTC)[reply]

Voting

Identity protection for functionaries

Light bulb iconB This proposal is a Larger suggestion. There is no guarantee this proposal will be implemented. Supporting the idea helps communicate its urgency.

  • Problem: Functionaries get doxxed on and off Wikimedia projects, and receive threats of harm and have had things happen to them in real life. Many countries, including the United States, do not have proper legal protections regarding publication of private information, and county and state records including birth certificate and property deed information wind up on data sharing sites.
  • Proposed solution: For functionaries, provide an identity protection service like DeleteMe and/or general identity theft protection (plenty of companies do this in the US). Provide equivalent services in other countries. Also write up a guide as to basic identity protection practices (there are plenty out there for high-risk journalists, for example).
  • Who would benefit: Functionaries, and users served by those functionaries.
  • More comments: It might be possible to convince companies to provide this service as a gesture of goodwill and charity.
  • Phabricator tickets:
  • Proposer: Rschen7754 02:07, 14 January 2022 (UTC)[reply]

Discussion

Voting

What we could do to improve the situation is probably to find what prevents people from contributing to projects like Wikipedia in these situations and fix it. For instance before writing this reply, I wasn't aware of the policies, and I assumed that it was not possible to create additional accounts to avoid political persecution. Though I do edit Wikipedia through Tor and for that I had to request an exemption. Though sometimes even if I'm logged, I've to use a new route to edit as I'm somehow blocked even with the exemption, but after very few retries it usually works. Without the exemption I don't think I could do any editions at all from Tor. Another area of work would be to have guides to help persecuted people contribute to projects like Wikipedia and still stay safe. Using the tor-browser (with or without bridges depending on the country and the political situation), avoiding being identified through Stylometry, etc could probably help too. The issue here would be to find people persecuted people that are willing to explain why they don't contribute. The Tor and the Tails projects already interviewed people anonymously to understand better the needs of their users, so they also have experience with that. In addition they have to distribute bridges in countries where you could get in trouble for that, so some people involved probably have some experience with helping people facing persecution in ways that don't backfire. GNUtoo (talk) 21:25, 1 February 2022 (UTC)[reply]

Wikipedia kids app

Light bulb iconB This proposal is a Larger suggestion. There is no guarantee this proposal will be implemented. Supporting the idea helps communicate its urgency.

  • Problem: Children cannot easily consume Wikimedia content.
  • Proposed solution: Create a Wikipedia mobile app for kids with features like:
    • Articles derived from Simple Wikipedia.
    • By default the app has no censorship, however, parents can set censorship filters if wanted.
    • Daily fun facts
    • Kid-friendly topic portals
    • Image-based informational storybooks/slideshows (Wikistories)
    • Games
    • Maybe early-education Wikiversity courses?
  • Who would benefit: Children
  • More comments:
    • Maybe this could turn into a completely new Wikimedia project with a website? Who knows?!
    • Please comment below other features you think this could have!
    • See the Basque Wikipedia's kids portal: eu:Txikipedia:Azala
  • Phabricator tickets:
  • Proposer: Sea Cow (talk) 06:25, 13 January 2022 (UTC)[reply]

Discussion

  • Building an entire new app AND what is essentially a new 'wiki', seems a bit outside of the scope of the wishlist. I mean i'd love to see it too, but.... Anyway, I think this could be easily prototyped by someone as a website, which pulls from different parts of our wiki eco system. Projects like these need people who are personally invested into making them succeed I think. Better one dedicated volunteer with a vision and some tech skills, then a group of random developers. —TheDJ (talk • contribs) 10:09, 13 January 2022 (UTC)[reply]
    Oh, and I think that what you proposed in term of engagement etc. is actually better than lots of the 'wikikids'-wiki proposals I've seen out there. Also makes sense to do that on mobile, the kids I know seem to only use iPads/phones, I've only seen them use Chromebooks for school when they become 12yo or something. —TheDJ (talk • contribs) 10:12, 13 January 2022 (UTC)[reply]
  • Apparently out of TechCom's scope. Creating another app is something to be decided by WMF and its Board of Directors. Right? George Ho (talk) 08:28, 14 January 2022 (UTC)[reply]
  • I think what is needed is to cut down the scope of this proposal heavily in order to fit into community tech wish list. I see the proposal can be cut down to only "Adding children mode into the existing wikipedia app" with main features needed including "sensitive content filter", "access time limitation", "article reading history report", as well as "random DYK articles". But even just these aspects are already quite complicated by community tech standard. C933103 (talk) 22:36, 15 January 2022 (UTC)[reply]
  • OOS per George Ho, can someone please move this to Community Wishlist Survey 2022/Archive? --Liuxinyu970226 (talk) 01:42, 17 January 2022 (UTC)[reply]
  • Hello and thanks for taking the time to write this proposal. Echoing what folks said here, this is definitely out of scope for our team but an idea that's valid nonetheless. I am therefore moving it to the Larger Suggestions Category. Thanks again! Regards, NRodriguez (WMF) (talk) 17:49, 17 January 2022 (UTC)[reply]
  • Simple English Wikipedia is constantly short of editors; for this reason, things like "Portals" don't really exist. The "Fun facts" take at least a month to compile; of course Wikipedia isn't censored, so the "access restrictions" will be difficult to implement there. As long as there are not more editors on SEWP, this is not realistic.-Eptalon (talk) 22:34, 17 January 2022 (UTC)[reply]
    @Eptalon Ya I see this too. The creation of this app might encourage editors to contribute. Though, I don't think we should build something when the content isn't even there to support it yet. We're going to have to find a better way to encourage contributions to Simple or come up with some other way to deliver simplified content. Lectrician1 (talk) 11:16, 19 January 2022 (UTC)[reply]
  • FYI, Txikipedia exists in Basque, this is something you can do without asking the WMF to. There's also an app for Txikipedia (links in the main page). -Theklan (talk) 08:10, 24 January 2022 (UTC)[reply]

Voting

Identifying Lobby Teams

Light bulb iconB This proposal is a Larger suggestion. There is no guarantee this proposal will be implemented. Supporting the idea helps communicate its urgency.

  • Problem: The problem is how to prevent corporate (not individual) sock-puppets - where teams of employed (or conflict of interest) editors collude to steer a narrative. While Wikipedia has a strong ability to moderate and manage those efforts by individuals to distort, rewrite, or promote a particular viewpoint, it is not at all as strong when dealing with large corporate interests, especially when pushing a narrative that, at face value, may appear to be robust and peer-reviewed, but is actually politically or financially motivated. As one of the most visited websites in the world, where people come to find out 'the truth', there is an increasing responsibility to prevent political/financially motivated agendas.
  • Proposed solution: This behaviour could be identified using modern graph analysis tools based on edit and comment behaviours. Current sock-puppet approaches use tools such as stylometric conformance analysis, but I believe that additional tools could be implemented that look at cross-user behaviours, especially where comments and edits are often shared, following patterns of behaviour that indicate focus on specialised content. This is particularly noticeable where there are a group of editors who are aggressively defensive in their given subject area.

    For example, of a potential positive hit, it is not unusual, given any area of expertise, for editors to agree most of the time - however, when they agree all of the time, then their relationship becomes suspect.

  • Who would benefit: Everyone who matters benefits from increased vigilance.
  • More comments:
  • Phabricator tickets:
  • Proposer: 20040302 (talk) 20:37, 10 January 2022

Discussion

  • I don't know if I'm at liberty to discuss it here, but this already exists. I'm going to archive this proposal. Thanks for participating in the survey! ​ MusikAnimal (WMF) (talk) 20:44, 10 January 2022 (UTC)[reply]
    See mw:User:Ladsgroup/masz * Pppery * it has begun 23:59, 10 January 2022 (UTC)[reply]
    The example you showed only indicates sockpuppet identification through stylometric conformance. What I am suggesting is different, and involves co-ordinated efforts being made by separate editors who are working for the same lobbying organisation. 20040302 (talk) 11:19, 11 January 2022 (UTC)[reply]
    @20040302 Thanks for clarifying, and for Pppery for mentioning Masz which I wasn't sure was public knowledge :) Anyway, I worry this project might be too big for Community Tech, but now knowing that Masz isn't what you're looking for, I will unarchive this proposal for the time being. Later when Community Tech reviews the proposals we may or may not deem this one too large, but if it is, we'll be sure to move it to our Larger suggestions category so it doesn't get lost here in the archives. Best, MusikAnimal (WMF) (talk) 16:44, 11 January 2022 (UTC)[reply]
    Upon further investigation I think it's clear this is out of scope for our team, but it's otherwise a fine proposal so I'm going to move it to the Larger suggestions category. Regards, MusikAnimal (WMF) (talk) 23:27, 17 January 2022 (UTC)[reply]
  • Yeah, I don't think this is in the pile of things the team has time for, and it would need significant fleshing out. --Izno (talk) 00:19, 17 January 2022 (UTC)[reply]
  • A big task, perhaps better suited for its own persistent team. But I would say this is one problem we will eventually have to solve (or shut down). The # of editors who primarily edit because they are paid by syndicates or as editing consultants has been rising even as total editors slowly declines. In some smaller wikis and some topic areas these may already be dominant forces. –SJ talk  23:45, 23 January 2022 (UTC)[reply]
  • I'm no expert but I wouldn't have expected detection to be the main COI/PAID/SOCK issue, but enforcement. We need WMF Legal to start sending scary letters to the corporations and individuals blatantly in violation of our Terms of Service, as proud declarations on their websites of their "services" to clients make abundantly clear. — Bilorv (talk) 20:31, 28 January 2022 (UTC)[reply]

Voting