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

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)

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)

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)

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): Done. — Insertcleverphrasehere ^{(or here)} 00:50, 14 May 2019 (UTC)

• @NKohli (WMF), MusikAnimal, MSchottlender-WMF, and IFried (WMF): - Whilst decoupling this, you seem to have (successfully) broken the feature to send a customized message in case of un-reviewing :( Now, whenever we un-review any reviewed page, a standard boilerplate is delivered to the t/p of orig. reviewer. This seems to be a bug and ought be fixed. Whilst this will return us to normalcy, another long-standing feature request is that we shall be able to un-review pages w/o sending any message at all. Regards, Winged Blades of Godric (talk) 13:34, 14 September 2019 (UTC)

@Winged Blades of Godric: We addressed this change in the ticket (see my comment from July 30, 2019), which included the following information: This work required that we decouple two sections that were previously tied together: a) “mark as reviewed,” b) send a message to the creator process. When these two sections were tied together, they would adapt to one another. Now that we have decoupled these two functions, the process is different. The message section is now meant to notify the page creator. The message is also posted to article talk page. Meanwhile, if someone unreviews someone’s work, a general message (i.e. not customizable) will be sent to the previous reviewer’s user talk page. This message is only sent if the current reviewer is different than the previous reviewer. To be clear, the user can still manually write a customized message directly on the talk page (this will just not be possible via the messaging tool, as we’ve decoupled the processes). In short, this change occurred because we needed to decouple the two functions, and we needed to do it in a streamlined way (as we’re balancing many projects and requests). We also asked for feedback when we were doing the work on Phabricator, and we received general approval from those following the ticket. Thanks! IFried (WMF) (talk) 00:24, 18 September 2019 (UTC)

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

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)

@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:

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)

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

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

@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)

• @IFried (WMF), MusikAnimal, and Barkeep49: I'm not sure I understand where the confusion is so I'll reiterate what I think the situation is:

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)

• hello everyone. I apologise, but I will comment here in detail, and other related threads after 3 days from now. Inconvenience is regretted. We wish you a safe, and happy journey. —usernamekiran(talk) 10:32, 29 August 2019 (UTC)

Requesting Feedback on "Potential COI" Alert Request

@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 links 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)

Everyone, thanks for the feedback. We'll think this over as we consider next steps. IFried (WMF) (talk) 15:09, 21 August 2019 (UTC)

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

Update: We have created a new ticket for this potential work: T233115 Add 'Username in title' tag and filter for Page Curation. Let us know if the basic requirements sound good to you. Also, the "medium" in the title doesn't reference priority or commitment; it's the rough level of technical effort to do the work (from the perspective of the engineers). Thanks! IFried (WMF) (talk) 00:13, 18 September 2019 (UTC)

@IFried (WMF) and Barkeep49: How common in reality is the occurrence of 'Username in title'? Isn't this something that would be fairly obvious to a New Page Reviewer? If it can be addressed fairly easily using the filter, fine, but maybe if it's more complex it should not be regarded as a high priority request. I would prefer to see the 'Hallmarks' in my list above being addressed as many of them are indeed things that may well escape a reviewer's attention - especially the 'too good to be true' ones when posted by a user with a very low edit count. Kudpung (talk) 01:18, 18 September 2019 (UTC)

Kudpung, I think the username = title thing is fairly common, I see it at the help desk all the time, less often when I'm patrolling new pages. I think what happens is wannabe singer/actor/whatever Joe Roe thinks he should have a Wikipedia article to promote his work, signs up as Joe Roe and then makes a draft page like, "Joe Roe is the greatest singer in the world!" Those pages never make it out of draft, because they're not really notable and the person never gets autoconfirmed. They can't figure out how to move the draft so they visit the help desk and get shot down there, while the draft gets G11'd. In short, it happens fairly frequently but such pages don't usually end up in the new pages feed because they are killed in draft space, meaning draft space is doing its job. I think some of the criteria you list would be more important to flag than username = title, but I also think it would be difficult to train an AI to flag those things, and we need to rely on human reviewers having brains. Meanwhile, a flag like this would be helpful for those rare times when pages like that do make it out of draft. ONUnicorn (talk) 13:23, 18 September 2019 (UTC)

I'll post that list again here, but with some comments: Other hallmarks of COI editing include:

1. Multiple references, very clean Reflist (no naked URLs) - should be possible
2. Multiple references to company, B2B, or financial listings, staff lists, interviews, press releases - perhaps for a human reviewer to look out for.
3. Articles with text that seems 'too perfect to be true' - perhaps for a human reviewer to look out for.
4. Articles with inline external links - should be possible
5. Articles whose style of text appears to come from a news article, press release, blog, or a book - should be possible and is already being partly done by our COPYVIO mechanisms.
6. Articles whose style of referencing includes many references to the subject's own publications (biographies) - match words in the refs to the article name?
7. Article posted in one or a very few edits, denoting meticulous offline preparation - should be easy enough, perhaps using a filter.
8. Author has posted several single edit new articles that are related - should be easy enough, perhaps using a filter.
9. Author has posted links to the article in other Wikipeda pages - should be possible.
10. Author has a corporate sounding user name - being discussed already.
11. Text with first person pronouns and possessives (I, we, my, our) - should be easy enough.

Kudpung (talk) 05:48, 19 September 2019 (UTC)

How about running a sentiment analysis on the new article? Extreme scores either way would indicate both possible COI and attack pages? Even if it is not part of the toolbar the ability to run such a query on a batch of articles would be useful. Jbh^Talk 15:06, 19 September 2019 (UTC)

August 20th Status Update & Feedback Request

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

We've updated the project page with the status of Page Curation & New Pages Feed Improvements (as of August 20, 2019). We have also posed a question for the community, related to T207238: Special:NewPageFeed - add option to filter by pageviews in the update. Please do check it out and let us know your thoughts (regarding our alternative proposal for T207238 & the status of the work overall). Thanks! IFried (WMF) (talk) 15:08, 21 August 2019 (UTC)

• I'm disappointed to learn that the making curation available to other wikis was decided as out of scope with no discussion. When the very long list of ideas was submitted, those doing that submission understood that some might not be done. That's fine. However, what was asked for and agreed to at the time was that this prioritization would be done together. Given the challenges that were laid out it's entirely probable that we'd have still reached the same conclusion. But I would have ranked making the tool agnostic above some of the other things that were done - I felt it was part of the promise we made when we went to wishlist and is why some non-EN editors supported the proposal (though obviously even with just EN editor support this would have passed). I know we're now two project managers removed from the person who made that promise so this is all a bit of flailing at the wind but I feel it needs to be said.

As for this second issue, I appreciate that we are having this consultation. I would suggest that without some ability to either sort or filter that just listing page views is perhaps not worth the time. The idea behind the ticket was to make it easy to triage the most important articles first. If that's not possible to do in a user friendly way I personally OK giving up the engineering hours in exchange from Ilana or some other equivalent staffer taking time to do a debrief on this whole project. As it seems like the only way we could ever get future improvements is through more wishlist proposals what worked well? What could the NPP community do to make things work better? That sort of thing. Othwerise I feel a bit silly turning down any help that we have to fight so hard to get. Best, Barkeep49 (talk) 16:18, 21 August 2019 (UTC)

• Not pinged but I saw the phab update, was disappointed but will like to ask should we get a consensus on zhwp to implement something like this, will the team provide support (on a case by case basis). However, I will still support anything that make any patroller work in any wiki easier so my support still stand. --Cohaf (talk) 16:28, 21 August 2019 (UTC)

@Cohaf: Thanks for the feedback. One question: Are you referring to T50552: Make PageTriage wiki agnostic (which we have concluded is beyond scope for the team) or T207238: Special:NewPageFeed - add option to filter by pageviews (which is too large in its current scope, but we have proposed an alternative)? — The preceding unsigned comment was added by IFried (WMF) (talk) 14:31, 21 August 2019 (UTC)

IFried (WMF) he is referring to T50552: Make PageTriage wiki agnostic. — Insertcleverphrasehere ^{(or here)} 03:30, 22 August 2019 (UTC)

@IFried (WMF): Yeah, I am referring to that. Is it okay to implement it on one other wiki.--Cohaf (talk) 03:44, 22 August 2019 (UTC)

@Cohaf:Thanks for the clarification. We’ll elaborate with more details regarding T50552: Make PageTriage wiki agnostic soon (probably in the next day or two, if not sooner). In the meantime, we want to know: Have you checked out our alternative solution to T207238: Special:NewPageFeed - add option to filter by pageviews, as described in the project page (i.e.  display the number of pageviews in the article record, without allowing for sorting or filtering). Would this be a satisfactory alternative to the community? And, if so, how would you like the number of pageviews displayed (e.g. average per day, median per day, total views in the last 30 days, etc)? Thanks. IFried (WMF) (talk) 16:11, 22 August 2019 (UTC)

@IFried (WMF): Hi, thanks and hope to hear the details. As per the 2nd one, unfortunately I can't comment as I am not a patroller in enwp. Apologies. --Cohaf (talk) 16:31, 22 August 2019 (UTC)

• Agree with Barkeep about being disappointed that curation will not be made available to other wikis. Obviously the parts of it that relate to enwiki specifically can just be removed? The tags are all costomisable via on-wiki .js pages, so those should not be an issue at all, and the deletion sections can just be disabled when not used on en.wiki.

Listing by page views would be useful, and the suggestions of simplifying it makes total sense. It doesn't have to be an ultra up-to-date and accurate number; even just the average views per day being listed and updating once every 24 hours would be perfectly fine (as an example). — Insertcleverphrasehere ^{(or here)} 03:30, 22 August 2019 (UTC)

@Insertcleverphrasehere:Thanks for the feedback. We’ll elaborate with more details regarding T50552: Make PageTriage wiki agnostic soon (probably in the next day or two, if not sooner). In the meantime, we want to know: Have you checked out our alternative solution to T207238: Special:NewPageFeed - add option to filter by pageviews, as described in the project page (i.e.  display the number of pageviews in the article record, without allowing for sorting or filtering). Would this be a satisfactory alternative to the community? And, if so, how would you like the number of pageviews displayed (e.g. average per day, median per day, total views in the last 30 days, etc)? Thanks. IFried (WMF) (talk) 16:11, 22 August 2019 (UTC)

Ah, apologies, @Insertcleverphrasehere:, I see that you already responded to the second question. Thanks for letting us know!

@Insertcleverphrasehere:: I should clarify one thing. With the proposed change to T207238: Special:NewPageFeed - add option to filter by pageviews, we would not be listing or sorting the records based on pageviews. We would simply display the pageview number within the article record. Would this be sufficient, given that the original proposal is unfortunately too large for the team to take on? IFried (WMF) (talk) 20:07, 26 August 2019 (UTC)

@IFried (WMF): Apologies for a late poke-in but absent a sort, the info about page-views is sheer bloat to me. Winged Blades of Godric (talk) 13:41, 14 September 2019 (UTC)

• Hello all. I'm the Technical Lead for the Community Tech team, and I thought I'd pitch in with an explanation that may answer some of the concerns raised in this conversation, in hopes to at least clarify the process that the team went through in making the decision.
  I speak for myself and the team when I say that we share your disappointment about not being able to make PageTriage wiki-agnostic. While we had initial misgivings, due to the historical difficulties of this request, we went into the code with the genuine hope that we could prove this exercise doable. This type of work is part of the mission that drives the movement, the Foundation, and the team in specific, so we all wanted to see if we could make it happen. Unfortunately, we discovered very quickly that this is not the case.
  PageTriage was written over six years ago with the goal of working with all wikis. However, due to time and resource limitations, the extension ended up being completed with only support for English Wikipedia's processes around the curation/review of articles and edits. This means two important results. First, the technology is old and difficult to work with, and some of it is no longer supported outside of our technical stack. Second, the entire architecture was written specifically to address the unique workflow of English Wikipedia's processes (from Article for Deletion, to how to notify users about reviews and potential problems).
  The code was architected in such a way that these processes are built-in, inherently, into the deep operation of the system. We cannot easily untangle these operations while keeping the extension working. Every step of the process invokes actions that are English-wiki-process specific, and getting those out or allowing to disable them in other wikis (what we call "refactoring") ends up meaning rewriting the majority of the software. Further complexity is added in when we consider that the current technical implementation uses technology that is old and unsupported, which means it is almost impossible to add and edit features, as the code is written right now.
  Unfortunately, we are not the first to discover this problem. The technical ticket is full of discussions about how this attempt could be done, along with several attempts made and abandoned by both staff and volunteer developers, due to these considerations.
  We take great pride in producing the best solutions that help you, as the drivers of this extremely important process, to do this work with greater ease and support. When we experience technical constraints, we try to propose a feasible alternative (like the current page views alternative). However, in the case of this request, we found ourselves continuously fighting against the stream. PageTriage is not an easy environment to add features to, and we have to balance the powerful results we want to give you with the technical feasibility of our efforts.
  I hope this explanation sheds some light on this decision. Please feel free to examine the technical ticket, as it is the best place to discuss technical concerns and implications with the other technical experts in the movement and continue to strive and solve these issues.
  MSchottlender-WMF (talk) 19:27, 23 August 2019 (UTC)

MSchottlender-WMF Thanks for the explanation and response. We aren't going to blame you guys for it if the code just isn't written in a way that it can be modified for use on other wikis without a complete rewrite. Thanks for exploring it in detail at the very least and giving it a try; if it can't be done I guess it can't be done. — Insertcleverphrasehere ^{(or here)} 19:58, 23 August 2019 (UTC)

• I too appreciate the detailed explanation. I do have some new questions. Am I correct that the way the PageTriage module is written that supporting it over time will only become more difficult? If that's correct would making it modern be a viable wishlist request? Best, Barkeep49 (talk) 00:33, 25 August 2019 (UTC)

@Barkeep49: unfortunately, your assessment is mostly correct; supporting PageTriage is already difficult, and it will not get easier. I will note that the work that the Growth team has put in earlier this year, along with the work we've been doing for the past couple of months, has served to make the module slightly better to handle, but overall, it is not an easy codebase to deal with.

As for your question, that's a bit more complicated. If we really want to make PageTriage wiki agnostic, then the approach should be more than just the consideration about modernized code. We will need to make a preliminary investigation to understand the general practices of these processes in other wikis, and then come up with a good architecture that allows for at least some limited customizability (scoping is key here) while keeping the same base behavior for English Wikipedia (so we don't harm the process you have in the name of helping the others).

This is doable, but it makes the project quite much larger than a Community Wish. We'd need time for the basic user research and community consultation (even if we make it relatively limited, so we understand how to build this product well) and then implementation time, and then integration time. My estimation (optimistic and conservative) is at least 6 months of purely coding work for the team, not including the parts for research, testing, design, etc. All of this, unfortunately, makes it much too large for a wish for the wishlist. MSchottlender-WMF (talk) 00:22, 30 August 2019 (UTC)

Thanks MSchottlender-WMF again for the detailed thoughtful analysis.Looking ahead, it's possible that WMF decides to do some of the work above you describe. If that happens, well happy days. It's also possible that it doesn't fit into the plans and so no further development happens. In this case an essential piece of English Wikipedia continues to become more and more obsolete. Maybe in a year or two we bring another group of suggestions to the Wishlist and that happens, but at some point that itself no longer becomes practical - perhaps the Wishlist goes away or the code simply becomes too disconnected from modern practices to support. Then we're stuck. Not to mention this process which really has worked well for EN is never made available to other large or medium wikis that would have the need and editor time necessary to support it. So as someone who cares about this, do you have any advice for us? Best, Barkeep49 (talk) 13:21, 30 August 2019 (UTC)

That's a really good question, @Barkeep49: I had to think on this for a bit. No matter what path is taken on this project, or who picks it up — whether it is another team at the Foundation, a volunteer effort, or another wish — the first step will always be the same: conducting an analysis of the process and user needs, and devising a Product Plan with a technical architecture recommendation. This process always needs to happen, and it sets up all projects for success, whether they focus on one wish or span many years. This kind of planning is also something that the Community Tech team has direct expertise in, as we do this to various levels with almost all wishes. We examine the needs, research the options, come up with a solid product or feature (or feature set), and work on a technical architectural plan. We often even come up with an iterative plan, where we recommend a "first" product (what we call an "MVP" — Minimally Viable Product) to make sure that there's a workable solution that can get feedback and be iterated on.

This process, as described, could be a "wish" in the Wishlist. Under this scenario, the team would collaborate with people experienced in product, design, and technical architecture to conduct an investigation into the processes and users in potentially several wikis. We would then produce a "user story" driven product plan with a technical roadmap.

This plan, in itself, could open several doors for NPP efforts. The first possibility is that we may identify a tool, a feature, or a certain aspect of the general product that could be scoped down as a wish. The second possibility is that the project (already planned) could be taken on by a developer using a Wikimedia Foundation Grant. The developer would already have a solid product definition and an architectural plan, which makes it a lot easier and faster to hit the ground running and produce something viable.

I know that none of this is a foolproof way to upgrade the product. Yet, I do think this proposal provides a pretty solid plan for us to move forward, so that PageTriage (or whatever else might be even better) can be worked on and improved.

MSchottlender-WMF (talk) 21:28, 6 September 2019 (UTC)

Moriel thanks so much for taking the time to share your thoughts and expertise. It makes a lot of sense and gives me some things to think about. Best, Barkeep49 (talk) 21:36, 6 September 2019 (UTC)

• @Barkeep49, MSchottlender-WMF, ONUnicorn, Nick Moyes, Insertcleverphrasehere, PamD, IFried (WMF), Swpb, DGG, Mduvekot, Hydronium Hydroxide, Vexations, and DGG:

All those years ago when following talks with Jorm and Erik Möller I kind of agreed on behalf of the Community to accept 'Page Triage' being proposed as a consolation prize for being so rudely denied the massive consensus for ACTRIAL, I worked closely with them during its development - but from the aspect of a patroler and not as a software developer. Fast forward to 2019: we now have ACTRIAL/AQREQ, and we have a special user group of (hopefully) experienced New Page Reviewers, and we finally have a much enhanced curation system.

The importance of the process of reviewing new pages accurately has since been better understood by both the community and the WMF due to the exposure of Orange Moody and the discovery how deep rooted COI actually is among certain editors who willfully exploit our free work for financial reward. We now also have hundreds more Wikimedia projects and hundreds more staff managing it all. Back in the day, it probably was not considered that Page Triage should even be Wiki agnostic. But here we are now with hundreds of Wikipedias going to need something like it sooner or later, which means this is much bigger than a wishlist item. I locked horns for two years with Danny who steadfastly insisted that such an important process as NPR should nevertheless stand in line with every one else and hold out its Xmas begging bowl.

We all know by now that the control over new content is faced with new and more subtle challenges, not least of all the disinterest in patrolling which leaves the community with too few capable and competent people at the NPP video console shooting up the junk before it imbeds itself in our fabric forever. We therefore have to rely increasingly on ORES, filters and other forms of artificial intelligence to get the work done. This will obviously require a bigger and dedicated team of devs for which I have been advocating for a long time.

Maybe its time to look at Page Triage as a sunk cost, keep the pretty and user friendly interfaces and their functions, but rewrite the entire code from the ground up. Who knows though, perhaps one of the days the Community may finally decide that all users must have 90/500 before they can create a first new article in mainspace, and where would that leave en:WP:NPR? Kudpung (talk) 17:07, 18 September 2019 (UTC)

I am in agreement with you and am thankful to MSchottlender-WMF for laying out a way that we could accomplish the first part of what would be necessary for the overhaul. Best, Barkeep49 (talk) 22:03, 18 September 2019 (UTC)

Communication System

A lot of work has been done on the communication system by the WMF team as part of this wishlist. This includes a couple of desired changes - the ability to leave a comment to the creator without reviewing and the ability to leave notes for other reviewers. These changes have introduced some issues, including some which were noted at the time, that I'd like to refine as part of this year's work. As Winged Blades of Godric recently noted on en-wiki and IFried (WMF) here, the inability to leave a comment when unreviewing an article creates real problems. This was something that I had noted prior to work going forward but did not comment on when replying to the subsequent long list of work. As WBG has shown this concern is shared by other reviewers and I can tell you that an unreview with-out context has caused some top reviewers to take temporary or permanent breaks from NPP. Can we find a way to change the "Add a message to creator button" (which already features a carrot) to be selectable and have an option to change to "send a message to reviewer". Ideally we could pair this with the return to "one click" communications - that is that I could send a message (to either the creator or reviewer) at the same time I mark an article reviewed or unreviewed. I know the team had marked this as resolved, but I would say that's a true description of its state in the minds of the NPP community. Best, Barkeep49 (talk) 15:25, 18 September 2019 (UTC)

Barkeep49, without looking it all up again, I'm still in confusion about a) what the wishlish asked for, and b) what is actually being done. AFAICS, leaving a message for the creator should be independent of marking as reviewed, but required if tagging the article. I believe however that every acceptance 'mark as reviewed' should send an auto message to the creator, even if it's only: 'Thank you for creating xxxx. I have marked it as fine for indexing, but don't hesitate to continue to expand and improve it' , it would encourage new users when they know that someone is actually taking notice.

On 'unreviewing', it would certainly be best if the original reviewer could be informed why. Perhaps a dropdown choice of canned reasons may be the answer. Kudpung (talk) 23:13, 19 September 2019 (UTC)

Hello, Barkeep49! There appeared to be miscommunication; I was under the impression that the changes were approved (as per the conversation on Phabricator). However, I understand the concerns of the community. For this reason, I talked with the team today about how we can restore this functionality. We’re actively looking into the issue now, and we’ll provide more updates soon. Thanks! IFried (WMF) (talk) 02:22, 20 September 2019 (UTC)

IFried (WMF), at the same time it would be appreciated if the second part of my post above could be looked at - it shouldn't be technically difficult to do. Oh, and do please ping me when you post here to keep me in the loop on these issues. Thanks. Kudpung (talk) 10:32, 20 September 2019 (UTC)

Thanks IFried (WMF). I know there's a lot going on and I apologize for any part my lack of communication caused in this. Your willingness to revisit this is appreciated. Best, Barkeep49 (talk) 17:19, 20 September 2019 (UTC)

Curation panel

@Barkeep49, Insertcleverphrasehere, and IFried (WMF): does anyone know where the fly-out Curation Panel went? Kudpung (talk) 19:49, 28 June 2022 (UTC)

Fixed already.It was a question of a .js not loading in my user prefs. Kudpung (talk) 02:36, 4 July 2022 (UTC)