Talk:Community Wishlist/Focus areas/Task prioritization

This page is for discussions related to the Community Wishlist/Focus areas/Task prioritization page.   Please remember to: Sign posts using the four tildes (~~~~) Remain civil and polite during discussions. Place new text under old text (start a new post).

Discussion

Unsure why Community Wishlist/Wishes/Add preference option for green and yellow wikilinks to denote Good and Featured Articles is included in this focus area ? (cc @JWheeler-WMF could you explain the rationale here) (please ping on reply) Sohom (talk) 08:22, 8 August 2024 (UTC)

Should we rename the focus area?

Hey @Johnson524, @Janhrach @Keith D @Prototyperspective @Hakimi97 - I've been looking at this focus area and am wondering if the term "task prioritization" is too clinical or limiting. Would re-framing the focus area as "Minimizing the feeling of overwhelmed" be a more appropriate articulation / summation of the problems we intend to solve?

Since you voted on it, I wanted to get your perspective.. JWheeler-WMF (talk) 16:23, 23 August 2024 (UTC)

I have no real preference, but if you think renaming better suits the focus area then I wouldn’t be opposed. Cheers! Johnson524 (talk) 16:52, 23 August 2024 (UTC)

"Minimizing the feeling of overwhelmed" sounds a bit too generalized, as it might also include the focus area of "Repetitive tasks". Unless there are plans to merge these two focus areas into one (since, in my opinion, they both could share common ground involving the topic of "task management"), with "minimizing task repetition" and "prioritizing tasks efficiently" as the two main objectives, I prefer keeping something similar to the current wording to distinguish the focus area of Task Prioritization from that of Repetitive Tasks. Hakimi97 (talk) 03:34, 24 August 2024 (UTC)

The difference between this focus area and "repetitive tasks":

There are manual, repetitive tasks which we think could be better automated, such as applying a citation needed template or having to mark an article for speedy deletion.

Then, there are use cases where editors may know generally what they want to work on, but have trouble finding it. For example, organizing their watchlist. The idea of "feeling overwhelmed" stemmed from the idea that RecentChanges and Watchlists can be overbearing, even with their filtering capabilities. JWheeler-WMF (talk) 01:10, 29 August 2024 (UTC)

I also think it's too limiting. However, I oppose changing it to "Minimizing the feeling of overwhelmed". It is not about "feeling" overwhelmed but rational task organization and efficiency. One wants to work on actual tasks not e.g. go through tons of minor changes that don't need to be reviewed without contributing anything. So enabling people to work on their actual tasks would help a lot.

As noted in my vote, it's also (mainly) better task organization including removals of repetitive tasks that don't need to be done or tags/notes for watchlisted items. For example, prioritization would imply that some tasks are just considered less important while the wishes are more about 1. enabling good identification of tasks to be done 2. eliminating time spent on activities that are not "unimportant" to the user but something they never want/will do or which isn't really a reasonable task to anyone

I would suggest that it's renamed to "Task efficiency" or "Task organization" or "Task consolidation" or something else that is yet to be suggested. I'm not sure if all the wishlist items relevant to this subject / focus area are included here however. Prototyperspective (talk) 23:56, 28 August 2024 (UTC)

I like the idea of task efficiency or organization. And it's possible some of the wishes may better align to the focus area than others, and that's ok! JWheeler-WMF (talk) 01:10, 29 August 2024 (UTC)

Review

Community Wishlist/Wishes/To-do list - waste of time, everyone can create a page in their userspace or use their personal sandbox. Building some kanban board is probably the best way to make editing wiki feel like work.

Community Wishlist/Wishes/Help editors plan their work more easily - Takes a large amount of dev time, produces no benefit to anyone. Do not try to replicate Asana/Trello/Jira, we already have those tools and hate them.

Community Wishlist/Wishes/Wishlist - identify Structured Data changes/en - better to just consider WikiData a failed experiment and move on?

Community Wishlist/Wishes/Watch list review timeout issue - only benefits a tiny group of people.

Community Wishlist/Wishes/Add preference option for green and yellow wikilinks to denote Good and Featured Articles - Only benefits a tiny group of people. The benefit, if any, is immeasurably tiny.

Community Wishlist/Wishes/Single good way of listing revisions on mobile web - Should've been done a decade ago, will cost mountains of dev time. Even if you make a perfect mobile interface, people just don't do the same thing on mobile as on a desktop. People consume on mobile and create on desktop. You cannot change that.

Community Wishlist/Wishes/A way to filter edits by Citation bot, InternetArchiveBot and OAbot from diffs - there is already a userscript to filter out AWB edits, better to have a volunteer improve that script instead of wasting dev time. Easy to make a userscript that is limited to 10 revisions, very complicated to do properly in the backend. w:List of WWE personnel has over 58.000 revisions, and it would have to get all of them to determine which areas were edited by bots.

Community Wishlist/Wishes/Watchlist - hide structured data edits/en - better to just consider WikiData a failed experiment and move on?

Community Wishlist/Wishes/Flytta bevakningslistor i Globala bevakningslistan/en - Very little benefit for a tiny group.

Community Wishlist/Wishes/Watchlist highlighting - Solution (colorcoding) doesn't even solve the problem (forgetting why you watchlisted something). Marginal benefit for tiny group. Polygnotus (talk) 23:25, 28 August 2024 (UTC)

there is already a userscript to filter out AWB edits, better to have a volunteer improve that script instead of wasting dev time.

1. This is not only about AWB and not even mainly about AWB

2. This is about showing diffs containing many edits excluding bot changes while the userscript you linked seems to be about hiding AWB edits on the History page which is something very different

- Based on this I don't think this is a good review and there could be similar issues with some of your other feedback there. Prototyperspective (talk) 23:43, 28 August 2024 (UTC)

@Prototyperspective: That's pretty bold and impolite. This is not only about AWB and not even mainly about AWB I am aware of that. This is about showing diffs containing many edits excluding bot changes while the userscript you linked seems to be about hiding AWB edits on the History page which is something very different I am also aware of that. I have read and understood the proposal. It is just not a good way to spend precious dev time in my opinion. You can disagree with me, but please do so without being insulting. Thank you, Polygnotus (talk) 23:46, 28 August 2024 (UTC)

I was not insulting and don't know why you think so. So you're saying people should just ignore your rationale there is already a userscript to filter out AWB edits except for "instead of wasting dev time" which would not have any rationale left? Why? As said that script is only about hiding these edits from the History page so not at all similar to what that proposal is about. Prototyperspective (talk) 00:00, 29 August 2024 (UTC)

@Prototyperspective: Well, that is how it came across. We all fall into the trap of thinking people who disagree with us are somehow enemies, especially online. But we have the same goals, we just have a minor disagreement on how to reach those goals. I tried to give concise feedback but I can give more details of course. Gimme a sec. Polygnotus (talk) 00:04, 29 August 2024 (UTC)

Excluding AWB/bot diffs from the watchlist is very easy. But excluding what they've actually edited when viewing a large range of diffs is not.

Let's say I take w:List of WWE personnel, a page with 58.000 revisions, and I want to check the diff from page creation till the current version. The system would have to get all these edits, determine if they were made by a bot, and determine which areas of the content were affected. Making 58175 API calls takes a long long time (been there, done that). There are ways to speed this up, but none of the ways I can think of would turn this into a quick and easy job. It is also not very difficult to write a hacky userscript for (if you limit it to lets say 10 revisions, which should be enough for pretty much anyone) but is very complicated to do "properly" in the backend (while ensuring that bad actors can't exploit it). Hope that helps, please let me know if you need any further clarification.

Polygnotus (talk) 00:12, 29 August 2024 (UTC)

That is an explanation but there can be ways to solve this problem like better reading of the bot bit that is set on diffs done by a bot. The easiest of which is to limit this to <500 revisions and I think that problem is solved with that. (If people want to check more revisions than 0.5/1/…k they have to deal with it including bot edits or wait until the API calls required for this are reduced.) Prototyperspective (talk) 00:28, 29 August 2024 (UTC)

This would be the most expensive operation on Wikipedia by far. An attacker could easily employ a botnet or proxy service to make a giant amount of requests in a very short time, clogging everything up with pointless requests. And when you further limit the amount of revisions to something more reasonable like 10 then you might as well write a simple bit of Javascript. The best weapon you can give an attacker is a damage multiplier that turns a single request into 500 requests. And why would a good-faith user ever need to see the diff of 500 edits? That is a REALLY long holiday... Polygnotus (talk) 00:33, 29 August 2024 (UTC)

This is not a problem to begin with: the page revision history is limited to 1000 edits. You're talking about random things now that could relate to any proposal that does API requests or the page revision history altogether where a "botnet" could request diffs every millisecond of x articles. Your claims are not reasonable. Prototyperspective (talk) 00:42, 29 August 2024 (UTC)

Obligatory XKCD 1425. Polygnotus (talk) 00:44, 29 August 2024 (UTC)

The page revision history limit is not 1000; I have used the various APIs quite a bit. Not all proposals contain the damage multiplier in this one. Polygnotus (talk) 00:48, 29 August 2024 (UTC)

Limit bot exclusion from diffs to 1000 revisions. Problem solved. ...and further improvements possible while wasted time of contributors saved by this is probably many years. And I would welcome this or the main part of it to be programmed in Javascript. Prototyperspective (talk) 11:48, 29 August 2024 (UTC)

@Prototyperspective: I wrote: The best weapon you can give an attacker is a damage multiplier that turns a single request into 500 requests. and you think you "solved" that problem by doubling the proposed damage multiplier of any potential attacker? That does not make sense. Also you haven't answered this question: why would a good-faith user ever need to see the diff of 500 edits? Polygnotus (talk) 13:41, 29 August 2024 (UTC)

The diff would be built the normal way, one simply does not include edits with the isBot boolean or whatever the variable is set. If some small change is required on the WMF side to make it possible in a way that does not require more server load than creation of any other multi-edit diff, then this is even more reason to work on this. These wishlist proposals aren't only for WMF employees to begin with as you seem to assume but it would be great if not just some volunteer wrote some script but it was supported by the site itself which likely implies some WMF involvement. I'm often looking at a diff of several hundred changes or intend to do so because articles like Climate change get lots of edits and I want to see what has changed since I last edited or looked at it. I don't see why it would turn 1 request into 500 – it would turn 1 request into 1 or 2 or if it's already 500 requests for building such a diff turn them into 500 or 501. Prototyperspective (talk) 19:08, 29 August 2024 (UTC)

@Prototyperspective: w:Wikipedia:User_scripts/Requests you could add for example AnomieBOT. 500 edits ago on Climate change was October 2023‎. Polygnotus (talk) 00:59, 30 August 2024 (UTC)

Thanks, this seems like a good next place to take this and maybe some other proposals in the wishlist & ideas I had. AnomieBot indeed is probably another bot that would be good to include (the list of bots wasn't complete). Oct 2023 already? I thought and hoped it was earlier. Prototyperspective (talk) 10:32, 30 August 2024 (UTC)

@Polygnotus thanks for sharing this review. It seems that you may not find these wishes to be a valuable use of WMF or technical contributor time. What else would you consider is a better use of time and resources? JWheeler-WMF (talk) 01:12, 29 August 2024 (UTC)

It's also OK if you don't think these are a good investment of time, I'm genuinely curious how we could best utilize our limited resources JWheeler-WMF (talk) 01:13, 29 August 2024 (UTC)

@JWheeler-WMF: I will work for you for free. Give me a plan and I will list all the downsides. I can warn you in advance for many of the mistakes made by the WMF. Grumpy people like me are no fun at parties (or in general), but extremely valuable in an organization like the WMF.

Currently what we really need is the WMF to work on old Phabricator tickets, some of which are a decade old. For example, the API has obvious omissions. XTools solves many of the gaps in the Action API, but is not an "official" API.

Developers, including myself, like to work on shiny new tools. I much prefer building something cool on top of the old MediaWiki codebase. But that is not what we, as a community, need. We need boring incremental improvements. No one will cheer if you close those tickets. Barely anyone will notice. But they are 1000 times more important.

Become one of our community members. Hang around at w:WP:VPT. I can show you how life is for us volunteers.

If you want a list of important phab tickets, give me a week and I will ask experienced and smart people what they think is most important, make a list, and get back to you. I respect them too much to speak for them. Polygnotus (talk) 01:18, 29 August 2024 (UTC)

Based on my understanding, the concept of "focus area" for the new Community Wishlist is to identify the common problems highlighted by different wishes, rather than to address each individual wish. While it is undeniable that every single wish listed has major flaws, the common perspective shared by all of them should not be ignored, especially regarding task management across Wikimedia projects. It might be helpful to list previous efforts and discussions by various local wiki and technical communities related to these core issues. This could help determine whether the focus area is relevant and should be implemented across Wikimedia projects, rather than concentrating on a single large community while overshadowing smaller local communities. Hakimi97 (talk) 05:47, 29 August 2024 (UTC)

Thanks @Hakimi97 yes that is the intention. JWheeler-WMF (talk) 13:52, 29 August 2024 (UTC)

@JWheeler-WMF: In software development it is nearly impossible to work in a vague direction. Clearly defined plans with MoSCoW prioritization will ensure that meaningful progress is made. The idea of focus areas should be abandoned. It is like politics, why vote for the party of lesser evil when you can make a dream team (OK this comparison doesn't really work in America but I assure you it does in some other countries). Polygnotus (talk) 13:56, 29 August 2024 (UTC)

I don't think the Community Wishlist is currently discussing the implementation of wishes from a technical perspective. Defining both the problems (from a user experience perspective) and solutions (from a technical perspective) all at once is just too time-consuming. This is why the "focus area" was created—to consolidate similar core problems highlighted by various Wikimedia editors based on their own user experiences (not just those involved in technical development). However, I hope that when WMF reaches the implementation phase, it will be beneficial to review past Phabricator tasks and seek advice from existing local technical communities. Hakimi97 (talk) 00:41, 4 September 2024 (UTC)

Let me explain in detail what I think about how the focus areas will be less "time-consuming." In the past, suggestions were provided individually, with as many details as possible, ranging from "what is/are the problem(s) the user faced" to "what are the technical suggestions to solve this problem." At the same time, many users raised the same user experience problem but offered different technical solutions. These solutions were often "shot down" primarily due to technical feasibility issues, limited development resources, benefits to a "minority" (although it was unclear how the "minority" was measured), "already have this tool/another alternative called XXX" (even if the tool/alternative was not internally supported), and personal sentiments towards technical implementation.

While all these opinions were important in determining the final decisions, these critiques might have been biased towards technical implementation without adequately showing how many people supported the common underlying problem highlighted by many users, albeit suggested in different ways. Therefore, the proposed "focus area" will conclude the common problem shared by different user experiences and will first assess whether the highlighted focus area gains sufficient support. If the focus area receives enough support from various users, regardless of their contributions or technical capabilities, it indicates that solving this specific focus area has gained importance and will become a primary concern for WMF. The process of concluding the "focus area" will be less "time-consuming" because the common issue highlighted by many users has been identified without debating technical feasibility aspects. Additionally, the repetitive process of highlighting the common issue and having it refuted by technical users over the past few years (which has been both exhausting and time-consuming for everyone involved) could be minimized.

Regarding the technical feasibility phase, I do agree that WMF staff should seek ideas and valuable perspectives from Phabricator (which is a hub for technical ideas, suggestions, and discussions) and compile these as many as possible. Following this, there should be a voting mechanism for technical users to debate, discuss, and determine the best technical solution after considering various aspects. Hakimi97 (talk) 23:50, 4 September 2024 (UTC)