I'm an active volunteer and administrator at English Wikipedia, occasionally venturing into other Wikimedia projects. To learn more, please visit my English Wikipedia profile. I also have a profile on Meta.
User Details
- User Since
- Jan 14 2019, 7:12 AM (293 w, 2 d)
- Availability
- Available
- IRC Nick
- Sdkb
- LDAP User
- Unknown
- MediaWiki User
- Sdkb [ Global Accounts ]
Sun, Aug 18
This looks like a duplicate of T75299 that should be merged with it. It's absolutely a valid issue.
Jul 28 2024
Jul 18 2024
Re-opening on the basis that the decline was done in violation of the documented standards for when a task should be declined.
@Jdlrobson, those seem like exceptionally poor reasons for declining a task. There are a million tasks on Phabricator that would be extremely valuable, but are designated low priority because there are no developers available to work on them, and which have been sitting for many years. Likewise, not all the work that is valuable is going to fit into the buckets that your team has planned — that's why the Community Wishlist is overflowing. I've re-created the task as you requested with hopefully additional details, but I should not have to do that busywork in order to get it taken up (or at the very least maintain its place in the backlog) — it's a pretty straightforward request that should be easily understandable to anyone who has ever come across <abbr> on mobile. I hope that your team will use better reasoning when declining tasks in the future.
Jun 1 2024
We need to separate "people" out into readers and editors. For readers, the protection level has minor salience for information literacy purposes, as it can indicate e.g. how wary they should be of information on the page. For editors, the "can I edit?" question is primary, but the overall protection level still has some value for understanding the overall situation with the page (and can be accessed through the notice in the edit window or through the page information page).
May 31 2024
May 30 2024
@tstarling I don't understand the gerritbot comment above. Would you be able to give an update on where this task is at?
May 29 2024
Concurred. Broader discussion raised here.
@JJMC89, per the text you quoted, I would fall into the "experienced community members" bucket, not the "reporter filing the bug report" or "outside observers" buckets that you bolded. Next time, please ensure that boilerplate is applicable to the situation before quoting it.
I am likewise unable to use the tool, with the task stuck on pending (lmk how to retrieve further info if you need it).
Mar 22 2024
This task is causing an issue; see here. Please roll back deployment until you have addressed stuff like this.
Mar 17 2024
This proposal has gotten strong support at the en-WP village pump discussion linked above.
Mar 16 2024
Mar 12 2024
Mar 8 2024
Mar 7 2024
My initial thought here is that generating permalinks is more something that experienced editors do than newcomers, so it's not the end of the world if the feature isn't all that discoverable. It's the sort of thing that, if someone sticks around, they'll eventually figure it out by the time they need to use it.
Mar 6 2024
Can you think of a case where the "logged for further review" process you're alluding to already happens?
What I'd envision is some sort of software tag, which community-developed tools could then use to create a feed to check. I'm not involved with copyright patrol enough to know what precedents exist currently, but WikiProject Copyright Cleanup would.
Mar 5 2024
Having the editor automatically check whether text being added already appears elsewhere on the internet (i.e. like Earwig's detector does) and warn editors about copyright if so would be an excellent feature. We'd also want instances where the editor declines to change the edit after being warned to be logged for further review. Sometimes there may be no issues (e.g. the text is from a freely licensed source, or is being properly quoted), but often there will be.
Feb 28 2024
Feb 23 2024
In your example, the fact you attached the prompt to your upload helped the community identify that the image was a derivative work (and thereby a copyright violation), and the community decided to delete it over your objection. Sorry, but that looks like a good thing.
The general sense I got from reading this very long discussion (in which you were an active participant) is that many editors do feel there is an issue. I don't see the connection between an image having a prompt recorded and it being more likely to be nominated for deletion.
Feb 22 2024
Thanks for creating this task! Regarding "should be available to users the possibility," I think that's too weak of a nudge. AI-generated images with prompts are much more useful than those without, so it's a piece of info we'd really like to have. And yeah, there may be some small subset of AI-generated images that were made in a way that didn't involve a prompt, or some small portion of users who won't complete the upload if forced to give the prompt, but on the whole, it's something that I think users will provide if we ask for it.
Feb 1 2024
@Trizek-WMF, oops, apologies, it seems I misread the task. It appears this one is about adjusting the entire table. That'd maybe be nice to have eventually, but I share your concern that we don't want to encourage bad usability practices.
Jan 30 2024
Making timestamps gray seems reasonable to me. The time a comment was posted is info secondary to the actual contents of that comment.
Jan 16 2024
I appreciate the link, @GoingBatty, but see my comment here.
Jan 15 2024
Why is this task marked as resolved when AWB has not yet been updated?
(@Reedy not being around to make an update is unfortunate, but the solution to the underlying problem is not for Reedy to reappear and release a new version — it's for us to move away from a non-web-based implementation of AWB that has only major releases and that has a bus problem.)
Jan 13 2024
Jan 6 2024
Initial discussion: https://www.mediawiki.org/w/index.php?title=Topic:Xwmr90hjrcq8doen
Jan 4 2024
See https://www.mediawiki.org/wiki/Topic:Xwmr90hjrcq8doen for one reason people may be choosing to disable the talk page archiving notification.
Dec 24 2023
Dec 11 2023
Dec 5 2023
Hi @OwenRB; thanks for coding a patch for this! Just wanted to circle back, is there anything I can do to help get it reviewed?
Nov 7 2023
I think that the choice to not have a default license for own work is a really bad decision. See discussion here.
Oct 4 2023
This looks good overall! I was about to make a similar comment to @Tacsipacsi's, though, about "thanks" being a weird option in the topic-level menu. If it is retained there, changing the text to something like "thank topic creator" might clarify a bit.
For comments that have been archived, it may be helpful to look to the find-archived-section gadget from @SD0001 as inspiration. Many experienced editors have this turned on, and it tends to work well.
Welp, that is both a very helpful thing to know, and also points to a severe UI failure of AWB that I've been using it for 18,000 edits and only now just discovered that feature. (I was previously only aware of the double-left-clicking to remove changes to a particular paragraph.)
Can you please say a bit more about where/why the support you have for such a system comes from? Asked in another way: what positive impact(s) do you think a more standardized system has potential to deliver?
Sep 20 2023
This is an interesting, potentially tricky task. The creation of RSP in the first place was controversial, although it's grown more accepted over time. The refrain of opponents is "it's always contextual, and trying to codify it is flattening". Personally, I support a more standardized system, which is what you're going for here, but just be aware that it's a consensus you'll likely have to fight for, and the less expressive the system you propose is, the harder that fight will be.
Aug 20 2023
Aug 15 2023
@Whatamidoing-WMF, I'd be interested to see those discussions if you can find them. But that doesn't seem like a very coherent objection. We already have the ability to reuse references normally, and that's the standard best practice when wanting to use the same reference twice, creating the same 1-2-1 display. Anyone who dislikes that configuration is out of step with consensus (we could run a poll if anyone doubts this and wants it confirmed) and violating DRY. All this ticket is doing is seeking to patch a hole in what is already established software behavior.
Aug 12 2023
Aug 10 2023
It's a bug, and is interfering with my ability to communicate e.g. here.
Aug 9 2023
See https://www.mediawiki.org/w/index.php?title=Topic:Xnih5bh8hqbseivl, where I've requested a special page that lists a user's subscriptions.
This appears to have been effectively resolved through T263821. If someone really wants both current and future topics, they can just subscribe to future ones and then manually subscribe to all the current ones. I think we can close this as declined/fulfilled elsewhere.
Aug 3 2023
Why is it a significant issue? There is a clearly documented workaround
Aug 2 2023
Have there been any updates on this? 2FA usage has risen substantially since this ticket was opened, so this is a quite significant issue.
Aug 1 2023
Jul 24 2023
Jul 22 2023
Thanks for the update! Looking at the listed drawbacks, the first two seem valid, although given that we're already planning to allow the editor to choose the decline reason, having it be editable in the summary isn't really giving them control over anything they weren't already able to control themselves. Regarding the edit summary limit, that could be seen as a feature rather than a bug. We don't want super long edit summaries in anyone's watchlist, and the automatically added decline reason would count toward the optimal limit just as other info would.
Jul 21 2023
I'd be interested to see what sort of edits fall into the third category, but I'd hazard a guess that many of them are not actually going to be [[WP:BLUESKY]] things. The follow-up action might be a dialogue that raises [[WP:BURDEN]]. Basically, to the new editor, "it's easy enough to Google this" might seem reasonable, but to a vandalism patroller going through hundreds of edits, they don't have time to Google each one — they're just going to revert with the default uncited summary. The person adding an edit is always the one best positioned to add the reference, since they already have it on hand, so pushing them a bit to add it may reduce the burden on others/result in more new content getting preserved.
Jul 20 2023
Jul 19 2023
This ticket was prompted by this discussion on how IABot is unable to process articles above a certain (relatively low) size limit. Per Harej, it is not possible to increase the size limit without making this transition.
Jul 12 2023
The edit summary would seem to be the logical place for this to me, since this is ultimately information about the edit they're making, and the edit summary is where we store meta-information about edits.
Jul 8 2023
@Novem_Linguae, thanks for taking a look at this. For your first question, I care a lot more about what happens in the published version for the reader than what happens in VisualEditor. If they display as two different independent citations in VE, and then only get merged in the display output once the edit is published, that's fine.
Jun 7 2023
May 24 2023
May 19 2023
@SD0001, just circling back to check in on this, as we were previously discussing notices for draftspace. Is what's currently needed someone to review the patch?
May 15 2023
Apr 4 2023
Our goal should be to get people the best information on the content. It's not surprising that some are going to be confused by a suggestion to switch to a language they don't speak, since most don't understand that different language versions are not just translations of the same content. But that doesn't mean we should give up and just have them read the inferior version. It means that the interface needs to do a better job of teaching them that the different language versions will differ in quality, and that a particular language is being suggested because it appears to be higher-quality.
Apr 3 2023
When will we show the links (e.g. only after you've switched languages once, etc.)?
Which links will we show? (this might already be handled by the existing compact language links logic?)
Mar 30 2023
Approach #2, embedding within timestamps, seems reasonable to me.
Mar 7 2023
As some initial community input, I'm glad to see this being taken up, as I've been wanting T51087 to be addressed for a while.
Mar 3 2023
This task relates to T248330, in that when a mentee potentially worthy of praise is surfaced to me, this feature would help me to be able to review the edits for which they were thanked when determined whether/how to praise them.
Very good point, @Xaosflux. The draft and user namespaces are very often where newcomers write articles, and we'll absolutely want the edit checks to come up when that's happening. Userspace may present a challenge, since sometimes it's just used to create one's userpage or to keep track of tasks, which are not scenarios where we want to prompt people to add references.
Mar 2 2023
Feb 27 2023
@Aklapper , sorry if there was any miscategorization. My understanding was that @Esanders' script represents the prototype version of a feature that will be rolled out as part of the talk pages project, which is why I categorized it here. Ed, feel free to forward/adjust the task so that it reaches wherever it needs to.
Feb 25 2023
Feb 22 2023
Do you think a page like Edit check/Ideas mediawiki.org would work?
Yes, that would be great! Really, the potential domain for this is everything that goes against best practice but isn't so universally guaranteed bad that we block it with an edit filter or fix it with a bot. That's a huge domain that encompasses a good portion of how experienced editors spend our time, and while not everything in it is potentially machine-readable, a sizeable portion of it is.
Ah, that makes sense!
Feb 21 2023
Feb 6 2023
Feb 2 2023
What rules ought to determine whether a change someone is making warrants the reference check being triggered?
I think the ideal situation here is one where there's a medium-importance issue — one not so dire that it warrants an abuse filter, but also not one so minor it can easily just be fixed up later. There are also some issues that are easier to fix when they're introduced rather than later on — citations is the big one here, since it's so much easier for someone to just add the source they used than for someone later to try to find it.
Thinking ahead, what other kinds of checks can you imagine being useful/valuable?
Oh, so many! I'd look through the editnotices to find a bunch of examples, as well as the abuse filters, maintenance tags, and guidance pages. Here are some (some for more specific situations than others):
- Adds a redlinked entry to a dynamic list
- Adds an image lacking alt text to an article related to accessibility, e.g. Blindness
- Links to a projectspace page from the mainspace body of an article
- Links to a disambiguation page from an article body (already implemented)
- Uses a word from a variety of English different from the one the article is tagged as having
- Uses a word that is likely a typo
- Adds a section titled "criticism" or "controversy"
- Adds a link to an article that is already linked in that section (very likely a WP:DUPLINK violation)
- Adds a reference with the same URL as an existing reference (likely a duplicate)
- Uses a relative time word like "recently" in an article body
- Use a word or phrase indicating a likely personal attack on a talk page
- Adds a reference containing only a bare URL
- Adds an external link in an article body
- Adds many entries to an external links section (likely a violation of WP:ELNO)
- Uses a phrase indicative of likely promotional language (e.g. "mission statement", "award-winning")
- Expands a section titled "Plot" beyond, say, 1400 words (recommend max length is 700)
- Uses a word or phrase listed at MOS:Words to Watch
- Adds a link to a word that is likely an overlink (e.g. a year, or a major country/language/ethnicity/etc.)
- Adds an image gallery to an article on an ethnicity (likely a violation of MOS:PEOPLEGALLERY)
- Adds a short description longer than 40 characters (see WP:SDSHORT)
- Adds a very long quote (likely a summary style violation, if not also a copyright one)
- Adds an article to a category when the article is already in a subcategory
You'd find many more examples talking to other editors. The potential extent of the applications is staggering, which is one reason I hope that once this feature is more fully developed it'll be possible for the community to create our own ones without developer assistance, just as we currently do for e.g. edit filters.
Jan 28 2023
- What patterns have you noticed in the newcomers/edits you feel compelled to assist with (e.g. write a personalized message on their talk page, add a reference to a content addition that lacked one)?
- What patterns have you noticed in the newcomers/edits you do not feel compelled to assist with (e.g. revert the edits they made, post a templated warning message on their talk page)
What additional information/context might you find helpful in assessing the quality of an edit and the intentions of the person making it so that you can decide how best to respond to it/them?
- What edits that involve people adding net new content do NOT require an accompanying reference?
Bad edits.
Jan 19 2023
@Jdlrobson I'm not quite sure what you mean. Is it this? I continue to think that this is the best design option we have with the current en-WP homepage:
Personally, that does not look at all good to me. It creates a blank space, pushing the actual content of the main page down.
Jan 9 2023
Jan 1 2023
@MarkTraceur, you are listed as the contact person for the UploadWizard. Could you look into addressing this?