Talk:Community Tech/Page Curation and New Pages Feed improvements

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search

This talk page is for discussing the work being done by the Community Tech team as part of the Page Curation and New Pages Feed improvements project voted number one during the Community Wishlist Survey 2019.

Curation panel size (task T207439)[edit]

Hi @Kudpung, ONUnicorn, Nick Moyes, and Insertcleverphrasehere: Pinging you all as you were involved in the discussion for this feature request. I have read the phabricator ticket and the discussion there and I had a few questions for you all.

  • Kudpung, you mentioned in the discussion about having to scroll down to see the Add this comment button. Where exactly is that button in the toolbar? I see Add details, Mark as reviewed and Add x selected tags (message to creator) buttons but not that one. Also on my screen, I do not need to scroll down to see the Add details button for adding PROD info. I'm on a 15" screen so that might have something to do with it. Can you share more detail/screenshot about what you are seeing so I can understand better what the need is? Thanks.
  • As Insertcleverphrasehere pointed out, you can already drag the textboxes to be bigger. One change we can do is that the textboxes automatically grow in size as you add a message so you don't need to manually expand them and you can always see the complete text that was added. Is that an acceptable solution? This is what it would look like:

Thank you. -- NKohli (WMF) (talk) 20:03, 17 March 2019 (UTC)

@NKohli (WMF), Thanks for tackling this. I do like the proposed change, but I think that the idea here was to put a resizing corner on the whole window (to make more stuff available in the window for people with bigger screens), not just text box expansion (more info here). The resizing feature was specifically requested by User:DGG during discussions for the community wishlist proposal, and was included because it looked easy to implement (see here) I think I'd be keen to let him tell you what specific changes were in mind and whether the proposed change is what he was after, or something more akin to what I mentioned above. — Insertcleverphrasehere (or here) 22:09, 17 March 2019 (UTC)
I'd like both. I do use a large screen, and want to see as much at one time as I can; I also like to see the whole of the box in which I am writing. DGG (talk) 06:34, 18 March 2019 (UTC)
Thanks Insertcleverphrasehere and DGG. Do we want to make the panel bigger by default, and if so by how much? Or we just want it to be resize-able? In the latter case, note that the panel will revert to the default size if the page is refreshed or if you go to a different page. Doing both of those things is also an option. -- NKohli (WMF) (talk) 19:23, 18 March 2019 (UTC)
@NKohli (WMF); I think the current size works well for people with small to medium screens (me on a laptop it is perfect), so I don't think we want it bigger by default. Having it be resizable via a corner drag would be a step in the right direction. Having text boxes auto-resize as you type would be great as well. — Insertcleverphrasehere (or here) 23:15, 18 March 2019 (UTC)
Thanks Insertcleverphrasehere. I have updated the ticket (task T207439) to reflect the exact changes we want here. Please take a look and let me know if anything is inaccurate. Thank you. -- NKohli (WMF) (talk) 18:38, 19 March 2019 (UTC)
Looks good. — Insertcleverphrasehere (or here) 19:56, 19 March 2019 (UTC)

Send message to creator with need to un-review/re-review (task T207442)[edit]

Hello. I have looked at the request ticket for this feature (task T207442) and the request on wiki. It seems to me that there are a couple of different ways we could address this problem -

1. Make the "Send message to Creator" and "Mark as reviewed" as two separate steps in the "Mark as reviewed" flyout. Sending message to creator does not set the reviewed flag on the article. To do that the users have to click the second button. This could possibly look like this:

Separating the send message and mark as reviewed steps. Note that this is only a mockup and we will refine the design later, as needed

2. We could also remove the "Send message to creator" from the "Mark as reviewed" flyout and make a new tab in the toolbar to send message to creator. This will make it clearer from the user perspective that these are two separate independent actions. On the other hand, this can be a bit disruptive for users who are already failiar with the current layout of the toolbar.

PamD, Usernamekiran, Kudpung, Insertcleverphrasehere (pinging people who were in the original discussion) - I'd love to hear your thoughts on the above. If you can think of other ways we can tackle this, I would love to hear those too. Thanks. -- NKohli (WMF) (talk) 22:00, 27 March 2019 (UTC)

Either one of these seem like an intuitive simple implementatation that nicely solves the issue at hand. Number 1 has the downside that current users might write in the box and then just click the 'mark as reviewed' button expecting it to send the message as well (current behaviour), which might be a bit confusing. Cheers, — Insertcleverphrasehere (or here) 00:21, 28 March 2019 (UTC)
@Insertcleverphrasehere: Good point, I tried to simplify the design a bit further to make it clearer that they are separate workflows. Take a look at the below. Thanks. -- NKohli (WMF) (talk) 16:54, 28 March 2019 (UTC)
Separating review and message to creator workflows - option 2.png
Yeah that looks good. — Insertcleverphrasehere (or here) 22:33, 28 March 2019 (UTC)

┌─────────────────────────────────┘
@Insertcleverphrasehere: Hey! Currently, when marking as reviewed and leaving a message, it uses en:Template:Reviewednote-NPF, and adds the section heading "A page you started has been reviewed". If you wanted to only leave a message, this template and heading won't work, since they indicate the page was reviewed when it may not have been. The other problem is that with the proposed redesign, you can't review and send a message at the same time, meaning there's no situation where you could safely use en:Template:Reviewednote-NPF at all. I see a few options:

  • Rewrite en:Template:Reviewednote-NPF and the section heading to be agnostic to whether or not the page was reviewed. I suggest instead of saying "I just reviewed the page", it would say "While reviewing the page". I don't know what the section heading should be, however.
  • Change the UI so that "Mark the page as reviewed" is a checkbox. If it is selected, en:Template:Reviewednote-NPF is used as the template. If leaving only a message, it will use a separate template and section heading. Again I don't know what to suggest for a section heading.
  • Make the comment-only functionality completely free-form, without the use of any template. This can be done, but we still need to decide what the section heading should be, or provide an input for it in the UI.

Let me know what you think! Best, MusikAnimal (WMF) (talk) 17:12, 1 May 2019 (UTC)

I like the second option. — Insertcleverphrasehere (or here) 19:44, 6 May 2019 (UTC)
@Insertcleverphrasehere and MusikAnimal (WMF):, Unfortuately I don't have as much time to dedicate to these issues as I used to. However, the high number of times I would have wanted to leave a message for the creator without either tagging or patrolling the article convinces me that a solution is desirable. In an ideal situation, new pages would be reviewed within in minutes of them being created and there is then the opportunity to catch the creator while they are still logged in. The downside is that many pages are still created by SPA who never return to see what happened to their article. My main concern is that too many reviewers still do not make sufficient use of the message feature and that all tags should be accompanied by an automated message to the creator on the lines of:'Thank you for creating xxx. This article has been tagged by a reviewer as needing immediate attention.' This is specially important in cases where the article has major flaws but does not require being listed for some form of deletion. Otherwise, many articles which pass the inclusion criteria risk simply becoming permatagged. Kudpung (talk) 01:35, 7 May 2019 (UTC)
@MusikAnimal, Insertcleverphrasehere, and Kudpung: It seems to me that there is consensus in this discussion to not post a message to the user talk page and instead post it on the article talk page with an option to ping the creator. With that in mind, I think we can reduce the scope of this task to just do what the ticket specifies currently without modifying the template because we are going to change that in the follow up task anyway. There will be a brief period where the message will be misleading so we can modify the template in the meanwhile to be review-status agnostic. What do you think? -- NKohli (WMF) (talk) 20:18, 7 May 2019 (UTC)
That sounds like a reasonable approach. — Insertcleverphrasehere (or here) 22:05, 7 May 2019 (UTC)
I don't see a discussion of any depth that constitutes a consensus for anything. FWIW, I'll reiterate what I posted abve: many pages are still created by SPA who never return to see what happened to their article. Many of them don't even know what an article talk page is. Kudpung (talk) 05:14, 8 May 2019 (UTC)
@Kudpung: I am not sure I understand what you're suggesting. I believe what was being recommended in the other discussion is also what you are proposing: To send a ping/notification to the creator when the reviewer has a review message for them. Notifications are as easy way for new users to know that there is feedback they should look at or reply to. Do you think this is the wrong way to approach this problem? -- NKohli (WMF) (talk) 18:31, 8 May 2019 (UTC)
This is all very confusing. See [1] (No.49 ad 52). I do not see any discussion that could be construed as being closed without consensus or a consensus not to message the creator. I am not talking about notifications, I'm talking about leaving messages on the creator's tp. Or is there something I've missed? Kudpung (talk) 20:22, 8 May 2019 (UTC)
@Kudpung: I think you are confusing this task (being able to notify creator without automatically marking page as reviewed) with the other one (sending feedback to the article talk page instead of or in addition to the user's talk page). Please comment on that other discussion if that is your concern. Is there anythng about this specific task that you don't agree with? -- NKohli (WMF) (talk) 14:11, 9 May 2019 (UTC)
@Insertcleverphrasehere and Kudpung: I'd like us to move forward on this. Can someone make the template review-status agnostic (option 1 as MusikAnimal proposed) while we implement this option in the code? Thank you. -- NKohli (WMF) (talk) 20:20, 13 May 2019 (UTC)
@NKohli (WMF): Yes check.svg Done. — Insertcleverphrasehere (or here) 00:50, 14 May 2019 (UTC)

Implement addition of un-redirected pages to Special:NewPages and Special:NewPagesFeed (task T92621)[edit]

As we were discussing this in our team meeting today, MusikAnimal mentioned that this has previously been implemented and the edit filter has been turned off. @Swpb, Insertcleverphrasehere, and DGG: do you folks know if this used to work in the past and has stopped working since? -- NKohli (WMF) (talk) 23:49, 30 April 2019 (UTC)

I'm not aware of it ever having worked in the past. Swpb (talk) 23:20, 1 May 2019 (UTC)
I misread, sorry! Redirects that became articles do show up in the feed, and I thought that's all we were talking about. Please disregard :) MusikAnimal (WMF) (talk) 23:42, 1 May 2019 (UTC)

@Swpb, Insertcleverphrasehere, and DGG: We are trying to understand better what this ticket is about. Here is a summary of what we think is required, please take a look and let us know if this is correct:

  • Redirects that have been converted into articles and then reverted back to redirects should not appear in the feed for patrol.
  • Articles converted into redirects and then reverted back to original articles should not appear in the feed for patrol.

If this sounds about right, let me know. Barkeep49 mentioned in the ticket that consensus on the second option seems to have changed. If so, we will not be implementing that. -- NKohli (WMF) (talk) 00:04, 8 June 2019 (UTC)

As I understand it:
  1. Redirect that was never an article, now turned into article: show in feed
  2. Anything that is currently a redirect: don't show in feed
  3. Article turned into redirect, then back into article: I've never considered this or seen a consensus on it. Seems like it would depend on whether the "new" article is just a revert to what was there before, and possibly how long it was a redirect. Swpb (talk) 17:36, 8 June 2019 (UTC)
@Swpb: The first and second in your list are already implemented in the feed. Redirects turned into articles show up in the feed. Redirects do not show up in the feed until they are filtered for in the options. I am wondering if anything still needs to be done here. Insertcleverphrasehere can you confirm that the functionality requested in this ticket is already present? Thank you. -- NKohli (WMF) (talk) 22:51, 11 June 2019 (UTC)
Yes, it seems like nothing more needs to be done. Thanks to all involved. Swpb (talk) 15:12, 12 June 2019 (UTC)

Tagging Feedback in Page Curation Tools should also be sent to talk page (task T207443)[edit]

@Mduvekot, Hydronium Hydroxide, Nick Moyes, Insertcleverphrasehere, and Vexations: Hello! Pinging you all as you participated in the discussion about this feature request. I read through the discussion and I think there are a few different ideas there. I'm going to list them below and would like to hear your thoughts on what is most preferable:

  1. Post on the article talk page and ping the creator instead of posting to the creator's talk page. The big change here is social - users will have to be aware that their feedback is going to the article talk page and not the user's talk page.
  2. Post the feedback on both the article talk page and the user's talk page. This is what the ticket currently proposes (task T207443). The concern I have about this solution is that it will fragment the conversation. The creator might respond on their talk page about it but other reviewers can miss it when they check the article talk page as the response is not there.
  3. Let reviewers choose where the feedback is posted. This can be achieved by adding two checkboxes below the feedback form (Post to article talk page and Post to creator's talk page).

Looking forward to hearing your thoughts about this! Thanks. -- NKohli (WMF) (talk) 00:13, 1 May 2019 (UTC)

My preferred solution would be to send a notification to the creator that a suggestions for improvement have been posted on the talk page of the article. Note that I have resigned my NPR rights, so you probably shouldn't pay any attention to anything I say. Vexations (talk) 00:40, 1 May 2019 (UTC)
Currently, we have the issue where feedback is only sent to the author, and therefore anyone else that comes to the article is unaware of the feedback that the Reviewer gave. My preferred solution is #2, with a link from both pages to the other page. New users, unfortunately, find it difficult to figure out talk page rules and how to use/access talk pages, and so it is better I think to let them choose where to have the conversation (with other more experienced users knowing where to go to look based on the links). So long as there is a link to the author's talk page on the article talk page section, Reviewers should be able to easily access any comments made on the user's talk page, so any fragmentation will be a minor issue. The message could, however, advise them to reply on the article talk page and I am altogether not too opposed to #1 (though I don't think it would work, as new users would just end up replying on their own talk page half the time anyway, and then there wouldn't even be a link from the article talk page to the author talk page to indicate that another discussion might be happening). I am strongly opposed to #3, as we definitely want the feedback on the article talk page either way, and the user needs to be notified. This also needs to tie into the reviewer notes system, which is one of the other tasks, and these comments should flag a notification in the info section of the page curation toolbar. — Insertcleverphrasehere (or here) 03:35, 1 May 2019 (UTC)
Thanks NKohli (WMF). I'd say what's needed is Option 4: Always post on the article talk page; ping or notify creator by default but allow an alternative target (preferred) or allow no target so that manual ping/notification is required (dispreferred). The problem with contacting the creator by default is that often enough they will create a redirect (or a poor article that is redirected), and then another editor will turn that redirect into a true article. Feedback thus needs to go on the article talk page, and not necessarily contact the nominal "creator" where it's inappropriate. Hydronium Hydroxide (talk) 16:14, 1 May 2019 (UTC)
That is a good point; the creator is not necessarily the same person as the author or major contributor. Something similar to how the wikilove section allows you to select one of the page contributors would be valuable. — Insertcleverphrasehere (or here) 23:52, 1 May 2019 (UTC)
@Hydronium Hydroxide and Insertcleverphrasehere: Thanks for the feedback. It makes sense to me to always post the feedback on the article talk page. As far as pinging the creator goes, we can pre-fill the textarea with the creator's name and then the reviewer can change or remove it if they like. This could look like:
NPP mock.png
What do you think? -- NKohli (WMF) (talk) 15:31, 6 May 2019 (UTC)
Either that or re-use the code from the wikilove section which pulls up a list of users that have edited the page. — Insertcleverphrasehere (or here) 19:46, 6 May 2019 (UTC)
  • New page reviewers review new pages, hence the most important thing is to notify the creator if anything is amiss. I still maintain therefore that any maintenance tags applied to a new article should be accompanied by a automated message to the creator. I am strongly opposed to #3 because reviewers have enough to do already, and many of them don't carry out all the checks anyway. I origially posted this, which I'm sure you all read, but the WMF told me it was in the wrong section: the high number of times I would have wanted to leave a message for the creator without either tagging or patrolling the article convinces me that a solution is desirable. In an ideal situation, new pages would be reviewed within in minutes of them being created and there is then the opportunity to catch the creator while they are still logged in. The downside is that many pages are still created by SPA who never return to see what happened to their article. My main concern is that too many reviewers still do not make sufficient use of the message feature and that all tags should be accompanied by an automated message to the creator on the lines of:'Thank you for creating xxx. This article has been tagged by a reviewer as needing immediate attention.' This is specially important in cases where the article has major flaws but does not require being listed for some form of deletion. Otherwise, many articles which pass the inclusion criteria risk simply becoming permatagged.
Perhaps a compromise would to also leave a template message oi the article talk page to the effect of: 'The creator has been notified that that this article is tagged as needing attention'. Simply pinging a new, new article creator will have o effect at all.Kudpung (talk) 00:25, 15 May 2019 (UTC)
The only real chance of any notice being seen is one the user's talk page. But tagging or messages on the article page also help--in particular, they help subsequent reviewers. I really don't see any reason why everything shouldn't go on both. DGG (talk) 02:21, 16 May 2019 (UTC)
I agree that the needs of a page creator and the needs of NPP and other slightly different editors are slightly here and so putting this in both places should be a positive. Barkeep49 (talk) 17:13, 16 May 2019 (UTC)
@Kudpung, DGG, Barkeep49, Insertcleverphrasehere, and Hydronium Hydroxide: Thanks for the feedback. It sounds like the consensus is to post the feedback on both the user's talk page and the article talk page. Do we want to keep a pre-filled ping template in the input box per above discussion and mock? Thanks. -- NKohli (WMF) (talk) 22:10, 30 May 2019 (UTC)
I don't think I have any particular thoughts about the topic and so would defer to whatever you, other WMF staffers, or other editors feel best. Hopefully the silence from the others is also assent to do what you think best? Barkeep49 (talk) 15:09, 31 May 2019 (UTC)

Loading Curation toolbar on all pages (task T207485)[edit]

This ticket is being discussed on the NPP/Reviewers page. Please chime in there with your comments! -- NKohli (WMF) (talk) 19:15, 19 June 2019 (UTC)

Priority[edit]

I see that a bunch of tickets were marked as not in short to medium term plan. I think there was an understanding (or at least I understood) that everything we asked for might not be in scope. However, I did expect that the community would be consulted about our top priorities given feedback from WMF about how easy or difficult these would be to implement. For instance, I personally would have prioritized T167475: Allow filtering by date range in Special:NewPagesFeed over some of the other work and am disappointed to see this deprioritized without any discussion. IFried (WMF) are you able to help provide context or explanation here? Best, Barkeep49 (talk) 01:28, 18 July 2019 (UTC)

Barkeep49, I think you’re referring to the updates submitted by the Growth team, as found on T207757, T167475, and T207237. The Community Tech team hasn’t issued any such updates (and, when we do have priority updates, we’ll share them with the community). From my understanding, Growth typically manages Page Curation (while CommTech has taken on a short-term project to improve Page Curation). For this reason, Growth is updating these tickets to clarify their priority around this work, irrespective of CommTech work. If you have questions, I recommend you reach out to Growth directly. Thanks! IFried (WMF) (talk) 22:58, 18 July 2019 (UTC)
Thanks for the clarification. I got my WMF teams mixed up and it's good to know that Community Tech is still thinking about stuff. Best, Barkeep49 (talk) 03:11, 20 July 2019 (UTC)
@IFried (WMF) and Barkeep49: generally not knowing how Wikipedia works on the factory floor, the WMF does not understand just how confusing all these different WMF departments are for the volunteers, especially as some of the department functions overlap while some 'managers' are employed simultaneously in several. This is a result of the Foundation's persistent reluctance for years to publish a proper organigramme (and keep it updated) so that at least our editors know who is who and the chain(s) of responsibiity. This is also further exacerbated by the frequent reshuffles of staff, lack of institutional memory withn the WMF (while many of our active editors have been with Wikipedia for a decade or more), unnecessary renaming of the departments, and the lack of such indication at Phab - which is a total mystery to most of us. Kudpung (talk) 05:58, 5 August 2019 (UTC)

Introduction (New PM) & Question[edit]

@Barkeep49, Kudpung, ONUnicorn, Nick Moyes, Insertcleverphrasehere, PamD, Usernamekiran, Swpb, DGGMduvekot, Hydronium Hydroxide, and Vexations:

Hello, everyone! My name is Ilana, and I’m the new product manager for the Community Tech team. I’ll be managing the Page Curation & New Pages Feed Improvements project from now on, though I’ll be regularly consulting with Niharika.

In addition to introducing myself, I have a question for the community concerning T157048: Redirects converted into articles should appear in the New Pages Feed indexed by the date of creation and creator of the article, not of the redirect. On July 12th, MusikAnimal wrote:

“We discussed this in the engineering meeting, and we're not really sure what defines the 'page author'. Consider these scenarios:

  • Old redirect -> article -- use the article-from-redirect revision, which is what this task is about.
  • Redirect -> article -> redirect -- use the revision of the original redirect?
  • Article A -> redirect -> article B -- use the revision for article A, or article B? Note the content and author for article A and B could be different.
  • New article -> redirect -- use the initial revision to the page, or the redirect?

My interpretation is to use the following logic:

  • For articles, use the latest revision that made the redirect into an article, or the initial revision if it was never a redirect.
  • For redirects, use the latest revision that made the article into a redirect, or the initial revision if it was never an article.”

Everyone, what do you all think? Do you agree? I know that Barkeep49 chimed in on the ticket, and I would love to hear more opinions. Thanks! IFried (talk) 23:28, 18 July 2019 (UTC)

Thanks for asking, IFried (WMF). I much appreciate you reaching out. I'm not currently active in NPP, but if I remember correctly, the problem that we were trying to solve is that when a reviewer leaves a note for the creator of the article, the creator sometimes responds by saying they didn't create the article, they just created a redirect, or did something else, like a move. Ideally, we'd like to reach someone we can talk to about the article. Your interpretation above is the closest approximation of I can imagine to be that editor. Perhaps Joe Roe can clarify, since he submitted the ticket? Vexations (talk) 02:18, 19 July 2019 (UTC)
Yes, that looks fine ... except for one scenario, where an article created by A has been turned into a redirect by B (who might be a vandal or an inexperienced editor), and then C reverts this change to restore A's article. Difficult to identify in this case, but A is the original creator still. Could the creator-identification system identify and ignore edit-and-revert pairs of edits which leave the article unchanged? Similarly a redirect could be created, over-written to create a rubbish article, reverted to the redirect by someone other than the creator. Possibly just a rare case which we can't expect the software to handle, but I point it out just in case. As stated above, the need is not so much indexing in lists of creation, but in directing the message about any discussion to the most appropriate editor. PamD (talk) 06:32, 19 July 2019 (UTC)
@PamD: Indeed, if we go with my proposal, editor C who restored editor A's article will get attribution, when it should be editor A. Unfortunately we can't efficiently do any sort of revert detection, so this might have to be a trade-off. In theory we could detect that the content matches an earlier version, similar to our plans for phab:T92621, and use that as a basis to find out the original author. However that task is about the previously reviewed version, so it wouldn't work here unless editor A's article was reviewed. Additionally it wouldn't account for partial reverts -- the edit editor C made would have to be the exact same content as editor A's version (even whitespace matters). I just want to make sure this isn't a deal-breaker. If it is, let us know and we'll rethink things. MusikAnimal talk 22:33, 22 July 2019 (UTC)
Maybe this is out of scope, but have we ever considered having a unique visual identifier for these "new" pages that actually have a history? It's clearly important to patrol these pages as if they were brand new, but it seems equally important for the reviewer to be aware of how they came to be (particularly with regard to messaging). Maybe a pair of icons and/or filter(s) for NPP entries that are "redirect created from article" or "article created from redirect"? And I agree with PamD that the software should recognize and ignore edit-revert pairs; maybe this can be based on the time between edits (redirect->article->redirect within five minutes is probably ignorable; the same sequence over a month is worth looking at). Swpb (talk) 13:56, 19 July 2019 (UTC)
Redirects from articles are most often created as a result from AfD, or incorrect PRODs. 'Redirect' is an official policy as an alternative to deletion. Unfortunately, many of our New Page Patrollers won't read the tutorial and are not aware of it, while the basic page patrolling system can still be done using Twinkle by newbies and inexperienced users for whom maintenance tasks are a magnet (this is what we nneed to look at in the next stage of improvement to New Page Review)..
Redirects from pages are not usually contentious.
Pages converted back to mainspace from redirects must appear in the Feed, and should be treated with utmost suspicion.
Notifying the original page creator or the editor who moved it to draft, or the editor who moved it back to mainspace is not so critical. In the worst case scenario, it will just encourage the malefactor to persist in creating their spam by usurping yet another redirect to circumvent salted titles etc.
BTW, related: what was the outcome of this? Kudpung (talk) 02:18, 20 July 2019 (UTC)
@Kudpung: From my understanding, the conversation you're asking about focused on the approach for task T207442. You can find the requirements that came out of this conversations, as well as other details, in the Phabricator ticket for T207442. Thanks! IFried (WMF) (talk) 23:43, 30 July 2019 (UTC)

Everyone, thank you for your feedback regarding T157048: Redirects converted into articles should appear in the New Pages Feed indexed by the date of creation and creator of the article, not of the redirect. We have decided to continue with the plan proposed by MusikAnimal. We also have responses to some of the additional requests (see below):

  • Regarding the request to identify and ignore edit-and-revert pairs of edits which leave the article unchanged: We’ll discuss this with the team to see if it is possible. It would need to be separate work in a separate ticket.
  • Regarding the creation of a unique visual identifier for "new" pages that actually have a history: We’ll discuss this with the team to see if it is possible. It would need to be separate work in a separate ticket.

Thanks! IFried (WMF) (talk) 21:59, 29 July 2019 (UTC)

Requesting Feedback on "Potential COI" Alert Request[edit]

@Barkeep49, Kudpung, ONUnicorn, Nick Moyes, Insertcleverphrasehere, PamD, Usernamekiran, Swpb, DGGMduvekot, Hydronium Hydroxide, and Vexations:

Hello, everyone. We've discussed T207757: Adding a "Potential COI" alert to the feed as a team. We can most likely take on this work, if there are some adjustments to the scope.

Here is what we propose:

  • We indicate if there is a match between the username and article title.
  • We don’t indicate if there is a match between the username and external links in the article. This is due to technical complexities, which would make it difficult to consistently and accurately provide useful data. We came to this conclusion after discussing username + link matching in greater depth. If you would like more technical details, we can certainly share them.
  • Since this work will specifically check one form of potential abuse, we think this feature should be renamed. Rather than calling it “Potential CIO” alert, we can call it “Username in Article Title."

With this in mind, we have two questions for you:

  • If we go with this proposal, will this be satisfactory? Or do you feel that it’s not useful in its current scope?
  • If we go with this proposal, do you prefer that we only check new users (i.e. the current behavior of AbuseFilter 148) or all non-autopatrolled users? If we choose the latter, this may give the “Username in Article Title” some additional functionality that is not found in the current AbuseFilters.

Thanks! IFried (WMF) (talk) 21:57, 4 August 2019 (UTC)

IFried (WMF), please see the recent discussion here. Further: A common indication of paid advertisements masquerading as articles, possibly written as works for hire by public relations experts, or sometimes by sophisticated insiders, are: Articles That Look Too Good To Be True: Well written, perfectly formatted articles with lots of neat references submitted by users with low edit counts. Such articles are often patrolled as okay by inexperienced patrollers, but they are classic examples of the need to thoroughly research an article and its user when patrolling it. See: WP:COI, WP:Paid, and the detailed description of what to look for at Long Term Abuse.

Other hallmarks of COI editing include:

  • Multiple references, very clean Reflist (no naked URLs)
  • Multiple references to company, B2B, or financial listings, staff lists, interviews, press releases
  • Articles with text that seems 'too perfect to be true'
  • Articles with inline external links
  • Articles whose style of text appears to come from a news article, press release, blog, or a book
  • Articles whose style of referencing includes many references to the subject's own publications (biographies)
  • Article posted in one or a very few edits, denoting meticulous offline preparation.
  • Author has posted several single edit new articles that are related
  • Author has posted lkinnks to the article in other Wikipeda pages.
  • Author has a corporate sounding user name
  • Text with first person pronouns and possessives (I, we, my, our)

Kudpung (talk) 05:42, 5 August 2019 (UTC)

The proposed scope would do a great deal of good, and I'd love to see it implemented ASAP. It would be great to see some of the the other COI hallmarks listed by Kudpung used as the basis for a powerful, general purpose "potential COI" filter, but I don't think that should delay implementation of what we have here. Swpb (talk) 13:11, 5 August 2019 (UTC)

On the one hand this change is better than nothing. On the other hand, we're going to reach a point of visual clutter where more information is getting in the way. I'm not sure we're there yet but I think we're starting to get close. COI is obviously important enough to be up alongside Spam, and Copyright as potential issues. Username match though? Well that falls much lower on my userful information ladder. Best, Barkeep49 (talk) 21:09, 5 August 2019 (UTC)