@MPGuy2824 has updated the script to offer a customized message to the article author when their article is moved to draft. The author of the script, @Evad37 has been virtually inactive for almost a year and has not responded to email, so waiting for him to update his version with MPGuy's changes is not realistic. Having an interface-admin do it seems unlikely as well (see prior discussion). Continuing that conversation here, we have to decide on the rollout of the new version.

Since Evad's script is not being updated, any method will require the script users to make some change. The new version could just be a MPGuy user script, but he has said he does not want that - understandably as he has just made one relatively minor enhancement. @Xaosflux has suggested that it could be a "community script". That would keep it from being "owned" by a specific user and thus more readily update-able by interface admins.

Another option suggested is that this could be a Gadget, so it would be available in Preferences. According to WP:Gadgets, that would require a consensus at WP:VPT and Xaoflux has said approval there would need "some maintainers that know what they are doing and want to take it on".

@Kudpung has suggested it be limited to NPP/admins (he has proposed restricting Move to Draft in that way). I'm not sure about that at this time - unless moving to draft is formally restricted, we would want everyone to use this script rather than just doing it manually if the script was only available to NPP/admins. MB 16:42, 4 November 2022 (UTC)[reply]

Philosophically I'd suggest not making it a gadget because they does invite a much wider group of people to be using it. And Kudpung's rationale for why it should be a smaller group is something I agree with. So some kind of community script feels like the best option? Best, Barkeep49 (talk) 17:04, 4 November 2022 (UTC)[reply]

I redesigned this script's UI on the understanding that it would be only available to NPP and admins as I was under the impression it always was and that anyone else who is determined to move a page to draft could do it the long way, but this is certainly a juncture for restricting moving to draft entirely to NPP and admins. That would however, according to the new silly trend of needing a site-wide RfC for every nut and bolt, need a site-wide or at least a local RfC, but that is an entirely different issue to the simple but more effective uplift to the script's UI. The redesign came about because:

1. constant murmurs from the community that the use of draft is excessive,
2. constant murmurs from the community that it's used as a backdoor route to deletion,
3. constant murmurs that the default message was too aggressive/unfriendly,
4. we have an excellent new target page in the message without using alphabet soup and presenting the noobs with walls of text of policies, some of which are 9 print-pages long.
5. anticipation of using it as a new feature in the Page Curation fly-out when, following our meeting yesterday with the Director of Product and her staff, the PageCuration tools will be uprgaded for us by the WMF.

There was never any intention for it to become a gadget, if there was, its original creator, who is again incommunicado (that's why in 2018 I saved The Signpost from closing down), would have made it so. Personally I'm not concerned with the technology of how it's hosted; it's a user script and does not need a great debate or any debate, it's use like all user scripts is voluntary and not mandatory - like all user scripts it just saves work. Let's just get it rolled out one way or another with a minimum of fuss. If I were still an interface admin I would have done it already. Kudpung กุดผึ้ง (talk) 18:53, 4 November 2022 (UTC)[reply]

The current script can be used by anyone, it's just that without advanced permissions, it can't do some parts of the process, like deleting the redirect to the draft from the old title. This change to the script came about due to multiple discussions that articles were being moved without a custom message, and the default message was not getting the author to understand what was wrong with the article. I don't see this is related to #1 & 2, or that we wouldn't have wanted to do this even without #4 & #5.

The original author did not make it a gadget because that is normally reserved for widely-used tools - 1000+ users (there are currently around 730). However, making it a gadget comes with the ability to restrict its usage to users with certain rights. So if we want to take this opportunity to restrict its usage, a gadget may be the way to do that. If we went that route, we could see about getting the original script disabled also, so non-NPPers couldn't keep using it as is. MB 22:14, 4 November 2022 (UTC)[reply]

Gadget vs user script will not affect the ability to restrict it to certain user rights. In user scripts, you can check permissions with code.

The main benefit of gadgets is that they show up in Special:Preferences, which is a way to market them more widely since you just have to check a box. The main downside of gadgets is that you need to do intadmin edit requests to modify them. This is also a downside of "community scripts" not hosted in a userspace. –Novem Linguae (talk) 23:12, 4 November 2022 (UTC)[reply]

Are you sure about that? According to Xaoxflux, If a gadget, it can also be only offered to people using certain skins, or with certain permissions. MB 00:31, 5 November 2022 (UTC)[reply]

You can do the same thing in user scripts using a conditional. If ! mw.something.something('patrol') return; –Novem Linguae (talk) 01:03, 5 November 2022 (UTC)[reply]

We could restrict the users without an RFC. However that will just mean that non NPPs use the old script and not the new script that has the permissions check. Therefore I am disinclined to limit it to just NPPs at this time.

Having to do intadmin edit requests all the time just to adjust stuff is a big hassle. I'd suggest that whoever the main maintainer ends up being should host it in their userspace. Bummer that MPGuy2824 doesn't want to host it. As an alternative, I would suggest that I host the script in my userspace. Thoughts? –Novem Linguae (talk) 23:17, 4 November 2022 (UTC)[reply]

Not seeing any issue with you hosting it. Hey man im josh (talk) 23:24, 4 November 2022 (UTC)[reply]

As far as I know, non NPPers did not have access to Evad's script anyway. At least that what's in one of my test accounts, one that is autoconfirmed. I would host it in my userspace but that would be a bit silly considering I can't read or use any IT languages. I'm not worried where it's hosted, let's just get it done and available only to NPP. If anyone else wants desperately to move an article to draft they can do it the long way. We can't deny them that any more than we can deny them the use of Twinkle. Kudpung กุดผึ้ง (talk) 03:06, 5 November 2022 (UTC)[reply]

If hosting it in my/Novem's userspace seems the best solution, then sure. My suggestion was to host it in NPP space (if the requisite page protections would be there). That way it is more obvious that it is not my script and others are welcome to update/fix things in it. Making it into a Gadget sounds like a short-term hassle, but better in the long term to me. -MPGuy2824 (talk) 03:11, 5 November 2022 (UTC)[reply]

I think the gadget approach has some advantages too - as MPGuy says, no one will feel like they are solely responsible, and we won't be back in this position if NL or whoever accidentally walks in front of a bus. I get that there is some extra hassle involved in getting an update - but that seems to be more of a problem if you are asking someone to make a specific change. I presume we would always have a tested complete updated version and would just have to ask that the new version be copied over - a very straightforward change. MB 04:03, 5 November 2022 (UTC)[reply]

In that case we need to get it right first time. See the updates in the GUI image, but I forgot to incorporate the checkbox for 'Other'. The risk of NL walking in front of a bus is less likely than Evad's long periods incommunicado. I will also probably be properly retiring soon. OTOH, the gadget process will take a lot longer to get rolled out because there will probably be opposition from the policy police. Kudpung กุดผึ้ง (talk) 04:36, 5 November 2022 (UTC)[reply]

All above-mentioned issues have been resolved with the script. It's now on enwiki at User:MPGuy2824/MoveToDraft. I put this link out on discord yesterday and no one has complained of any issues, yet. Maybe we could inform NPP reviewers of this on the discussion page with the understanding that it might get moved over to a Gadget sometime in the future. -MPGuy2824 (talk) 05:16, 6 November 2022 (UTC)[reply]

I was thinking a special mass-message to the NPP mailing list, but I don't think we should do that until we decide on the final location. For now, a notice on the discussion page too is probably OK, with the disclaimer. Do you want me to put something there? MB 06:08, 6 November 2022 (UTC)[reply]

Would you? Thanks. -MPGuy2824 (talk) 06:17, 6 November 2022 (UTC)[reply]

@MB and MPGuy2824: I would be more inclined to avoid inviting any discussion for a while. Discussion only invites more negative comment than positive appreciation - it's the nature of things on Wikipedia. I would say just let people use it and they will come up with their own suggestions. Kudpung กุดผึ้ง (talk) 11:48, 6 November 2022 (UTC)[reply]

@MPGuy2824 I really don't understand. Evad's script always had a customisation option didn't it? I even changed the details of the default message with a bit of code on my common.js — Insertcleverphrasehere^{(or here)_{(or here)(or here)}} 18:24, 6 November 2022 (UTC)[reply]

I think the new version gives the option to pick from multiple messages, instead of just changing the default message. This also opens the door for other bug fixes and features now that we have an active maintainer. Hope this helps. –Novem Linguae (talk) 22:49, 6 November 2022 (UTC)[reply]

Evad's script always had a customisation option didn't it?, it still does, ICPH, it's in the freely editable 'Other' field. What the new version does is to permit reviewers to select an accurate, thematic message message to the article creator without having to make one up or 'customise' a default message. It's also less aggressive by not bombarding the creator with spoonfuls of alphabet soup, instead linking the creator to a more warmly presented help page where they can get more answers and further assistance. It takes away any perceived bad faith component that every author of a draftified article is deliberately or recklessly abusing Wikipedia policies. Lots of genuine articles with potential are also correctly draftfied. Kudpung กุดผึ้ง (talk) 23:30, 6 November 2022 (UTC)[reply]

Thanks for this, MPGuy2824. Would it be feasible to use templates for the message texts, so that they're open to editing and refinement? – Joe (talk) 08:28, 7 November 2022 (UTC)[reply]

There is only one message text with phrases added or removed, based on the issues that you find in the article. I don't think it should be hard to get that message's text from a template. I'll try to do that the next time someone asks for a change to it. -MPGuy2824 (talk) 09:00, 7 November 2022 (UTC)[reply]

The entire principle behind the UX design is to deliberately avoid templates and avoid interference from people who feel they must edit and re-edit everything they see. On Wikipedia one often ends up with more blue links than black print. The process is a simple one, that's why it links to a simple but attractive page. There are therefore deliberately no message texts. The system was the result of much discussion and many designs of both the UI and the target page before the final version was decided upon and has also been discussed with the WMF within the framework of PageTriage upgrading where it will not be available for re-editing. Kudpung กุดผึ้ง (talk) 11:31, 7 November 2022 (UTC)[reply]

"Interference from people who feel they must edit and re-edit everything"... sounds like Wikipedia's raison d'être, to me? :)

I like the current message, but I think it could use a light copyedit to fix obvious grammatical mistakes (e.g. a draft where – a draft is not a place). On a more general note, I've tried to make incremental improvements to the old draftify script's various texts before, and relying on one person to make the change was an annoying bottleneck. I don't see how using a subst'd template to store the text, as opposed the Javascript file it's currently in, would even be detectable from a UX point of view. – Joe (talk) 12:56, 7 November 2022 (UTC)[reply]

I'm not fluent enough on the detailed discussed above for full participation here, but the script text that implies / leads editors to believe that they are not allowed to move a page from draft is false and so should be fixed. Also it feels pointy/negative. I has it used on me on an article that was 2 minutes old (not by NPP) where I was going to have the GNG sources installed by the time that the article was 5 minutes old. Of course, that brings in a third issue, but as the recipient I thought that the text was both too negative and also misleading. North8000 (talk) 18:14, 27 November 2022 (UTC)[reply]

Rollout

MPGuy2824 has made two updates to the script - the better message to the author, and a warning to the user if they try to use the script on an "new/actively edited" article. So far, 11 people are using this version, which has only been publicized at WT:NPP/R. Before trying to get more people to switch, I think we should finalize things:

Restriction

Kudpung suggested using this as an opportunity to restrict usage to NPP/Admins. Barkeep49 agreed with that. I agree with that now. Since draftification is such a touchy subject it is probably prudent to limit usage to more "trusted" people. I looked at 50 users (of about 500) of the Evad script. Of those:

• 9 (18%) were Admins
• 27 (54%) were NPP
• 7 (14%) were inactive (no edits for at least a year)
• 4 (8%) were active but are not page/file movers
• 3 (6%) were active and are page/file movers
  So if we restrict the script to Admins, NPP, and Page/File Movers, that leaves 8% unable to use the script.

MB 04:41, 28 November 2022 (UTC)[reply]

Could probably get more accurate data if you went to WP:QUERY and asked them to look at recent (last 500?) MoveToDraft edit summaries, and then cross reference that to who did it and what perms they have. Or maybe the above data is close enough. –Novem Linguae (talk) 06:26, 28 November 2022 (UTC)[reply]

Location

The script is currently in MPGuy's user space. There are pros and cons to keeping it in user space as discussed above. It can be a gadget/community script and be restricted. If we use a model of having an interface admin "release" a new version that has been coded and tested, instead of making code changes to the script, it shouldn't be too much of an inconvenience. This would keep the script and it's talk/feature request page in a more central/permanent location.

MPGuy2824, you are the key person here. What do you want to do? MB 05:48, 29 November 2022 (UTC)[reply]

The default (if there is no consensus on this) would be the status quo, which is to continue hosting it from my userspace. I'm OK with that, but would definitely prefer that it be made into a gadget. I too think that the inconvenience of future code changes (once it is a gadget) would be minor. -MPGuy2824 (talk) 06:01, 29 November 2022 (UTC)[reply]

If there is some hope of getting the draftify feature into the PageTriage toolbar soon, then let's not work on converting the script into a gadget. I guess we'll have to wait till the next WMF meeting to be sure. -MPGuy2824 (talk) 06:10, 29 November 2022 (UTC)[reply]

Deprecation of Evad script

If we agree on the above items, I think we should update the old script to issue a message saying it is unmaintained and telling how to switch to the new version. MPGuy has continued the incremental version numbers, so it is really the successor/current version - not a new script/fork. We don't want the Evad version to evolve separately, so after a month or two we should have that disabled. I don't think it makes sense for people to keep using it indefinitely, and to leave messages on the T.P that go unanswered. MB 04:42, 27 November 2022 (UTC)[reply]

1. WP:NPP uses 15 minutes in three places - #1 & #2 specifically say don't CSD A1/A3/A7 an article for 15 minutes. #3 says an article should not be tagged for any kind of deletion for a minimum of 15 minutes after creation and it is often appropriate to wait an hour or more. If #1 & #2 are saying to give no-content issues time to be fixed, but are implying that other CSDs (e.g. Copyvio) can be done immediately, that is in conflict with #3 that says "any deletion" must wait at least 15 minutes. That discrepancy should be fixed.
2. Specifically regarding Draftification, I don't see why we shouldn't just say always wait at least an hour.

MB 00:29, 9 November 2022 (UTC)[reply]

For simplicity reasons, I think we should align our advice to be 15 minutes for almost everything (except for egregious cases, e.g. vandalism, attack pages, etc.). –Novem Linguae (talk) 01:12, 9 November 2022 (UTC)[reply]

We could align our advice to be 1 hour for almost everything as well. There really is no rush for non-egregious cases. Sitting in mainspace for another 45 minutes gives a much better chance of knowing if the author has an intention of making a decent article. That also aligns better with the existing guidance that says "often appropriate to wait an hour or more." I agree it is better to develop articles in User or Draft space, but policy does not require it. We even have {{under construction}}, and some people work this way. MB 03:07, 10 November 2022 (UTC)[reply]

I'm leaning towards consistency, but I'm flexible. I wrote the tutorial (or most of it) but that was yonks ago. Kudpung กุดผึ้ง (talk) 02:54, 12 November 2022 (UTC)[reply]

An hour of copyvio won't kill us (if it's fixed it can just be RD'd instead of outright deleted) but I would be opposed ot saying we need to leave an attack page up for an hour - I have a special script just so I can try to respond to those requests quickly. Best, Barkeep49 (talk) 03:19, 12 November 2022 (UTC)[reply]

IMO the {{under construction}} template should be deprecated, it's a vestige from the days when WP was so desperate for articles it was tolerated for them to be developed in mainspace. It's not necessary nowadays and it already wasn't when the old incubator was created in 2009. AFAICS Page Curation only says "Note: This page is only x minutes old. Consider waiting to tag it, unless the issue is serious." It doesnt mention a time frame. Kudpung กุดผึ้ง (talk) 04:52, 12 November 2022 (UTC)[reply]

@Novem Linguae, there seems to be agreement here that we should remove any contradictions in the tutorial. There is agreement that some issues should be marked for deletion immediately. For non-egregious cases, I favor stating a one hour minimum. The tutorial says in bold an article should not be tagged for any kind of deletion for a minimum of 15 minutes after creation and it is often appropriate to wait an hour or more. I think that may lead people to just remember that 15 minutes long enough. Jumping on articles quickly is a re-occurring complaint about NPP. It happened again today (see this at VPP). In that case, MPGuy draftified an article with no sources that had been that way for five hours. A one-hour minimum would not have made a difference here, but this shows that how some people operate. (At the same time, there is a recent complaint at ANI that we are too lenient and accept articles that don't meet their "minimum standard" of quality). A one-hour minimum would prevent some of the complaints, with little "cost". I could see someone starting an article and getting distracted by a phone call for a little while. Giving an hour filters out cases where someone it really planning to continue developing the article, and who are most annoyed that their article got swept away too quickly. This might even encourage people to review older articles instead of the newest ones. MB 05:31, 17 November 2022 (UTC)[reply]

I could also update the MoveToDraft script to alert the reviewer if the last edit was less than X minutes ago, instead of being created in the last X minutes (currently, X=15, but we can make it 60). This would take care of creators who are actively improving their article.

I think a lot of reviewers are used to 15 minutes, so if we decide to make it 60 minutes, it'll need an announcement on the main NPP talk page. -MPGuy2824 (talk) 05:48, 17 November 2022 (UTC)[reply]

I like the idea of X minutes ago, that is more in line with allowing people actively working on an article to continue. Once we finalize the time, I'll send a message to all NPPers summmarizing the improvements and reminding them to switch to the latest version (your version) of the script. MB 02:13, 18 November 2022 (UTC)[reply]

I'd be in favor of suggesting a minimum wait of over an hour to minimize the risk of interrupting a long edit in progress. _signed, Rosguill ^talk 05:53, 17 November 2022 (UTC)[reply]

I see two people on this page who have clearly stated "we should change 15 minutes to an hour". Perhaps we should do a survey here or on WT:NPPR to get a little more clarity. –Novem Linguae (talk) 07:11, 17 November 2022 (UTC)[reply]

I'm also in favour of at least an hour (with exceptions for attack pages etc.) We could also look into hiding articles less than X minutes old from the queue by default. I've a feeling that hasty reviewing this has become more of a problem now that the backlog is small and more people are hovering over new articles in real time. – Joe (talk) 07:37, 17 November 2022 (UTC)[reply]

I see myself, Rosguill, and Joe supporting one hour, Barkeep is OK with it, Kudpung is staying out of this one, MPGuy did not express any opinion and NL favoring 15 minutes. I think this is a consensus for one hour. Since the current language already suggests an hour, I think this is a small enough change that it can be made without further discussion at WT:NPPR. Comments/concerns? MB 02:31, 18 November 2022 (UTC)[reply]

1 hour (with exceptions that one is ready to defend) would be fine with me as well. -MPGuy2824 (talk) 03:02, 18 November 2022 (UTC)[reply]

I'm in the minority so I of course withdraw my objection. Please proceed. I recommend changing WP:NPP, PageTriage, and MoveToDraft. –Novem Linguae (talk) 04:18, 18 November 2022 (UTC)[reply]

Updates

• I have updates at the tutorial talk page if anyone wants to review before I make them live. MB 02:36, 20 November 2022 (UTC)[reply]

  Your proposed changes seem fine to me. -MPGuy2824 (talk)

• I've updated the MTD script to show the following message when appropriate: "Draftifying may not be appropriate per WP:DRAFTIFY, since this article was edited less than 60 minutes ago."
• Also, NL has updated the PageTriage code. This will go live with the next deployment. -MPGuy2824 (talk) 04:02, 20 November 2022 (UTC)[reply]

If anyone asks about the formatting of the Janaury 2023 newsletter spilling out to following sections, there is a missing closing div tag. See User talk:MB#New pages patrol newsletter for a discussion I started on it. isaacl (talk) 02:22, 4 January 2023 (UTC)[reply]

Hello

I'm Trizek, community relations specialist working with the Growth team.

The Growth team is exploring a project idea that aims to improve the experience of new editors by providing them with better guidance and structure in the article creation process. The hope being that by providing new editors with more structure around article creation, it will lead to newcomers creating fewer low-quality articles that create work for patrollers who check recent edits and mentors who review newcomers’ drafts.

In 2022, about 28% of newly registered users who completed the Welcome Survey indicated that they opened an account specifically to create a new article (all stats). These newcomers don't yet understand core Wikipedia principles and guidelines around notability, verifiability, conflict of interest, neutral point of view, etc. These newcomers need additional guidance or they end up frustrated and disappointed when their articles get deleted. Because they aren't receiving the proactive guidance they need, they end up creating additional work for content moderators (patrollers, admins, watchlisters…) who need to provide reactive guidance which is rarely well-received or well-understood.

While the specifics of the project, and the Growth team’s annual planning priorities, are still under consideration, we anticipate exploring ideas related to  Article creation improvements for new editors.  One possibility is a community configurable "Article wizard" or helper, which could also fulfill the 2023 Community Wishlist survey Reference requirement for new article creation proposal (ranked #26 out of 182 proposals).

We're committed to shaping the overall plan based on community feedback and needs, while adhering to the following requirements:

• The feature will be Community configurable, enabling each community to customize it to meet their unique needs.
• The feature will provide guidance and guardrails to help newcomers create higher-quality articles and improve their overall experience.
• The feature will be designed to reduce the downstream workload for content moderators.

So, we would love to hear from you:

1. Do you think this project will help new page patrollers on English Wikipedia?  
2. Do you have any suggestions for improving this idea?
3. Is there anything about this idea that you find concerning, or you want to ensure we avoid?

Or do you want the Growth team to consider a totally different idea?  Keep in mind that the Moderator Tools team and two other teams are also working the shared  “improve the experience of editors with extended rights” key result, so there will be other teams approaching this from a less new-editor centric perspective.

Thank you in advance for your replies.

Trizek (WMF) (talk) 18:23, 15 May 2023 (UTC)[reply]

Moved to Wikipedia talk:Growth Team features

 – Consolidating parallel discussions to page linked from mw:Growth/Article creation for new editors. Folly Mox (talk) 15:58, 20 May 2023 (UTC)[reply]

At this point MPGuy2824's fork of the draftify user script is a clear upgrade compared to Evad37's original. In particular, the improved multiple-choice message templates, warnings about too new or too old pages, and addition of a #moveToDraft tag make it significantly more policy-compliant than the original, which I think is reason enough to fully deprecate Evad37's in favour of MPGuy2824's (as previously suggested).

My question is, what's the best way to achieve this? Has anyone asked Evad if he's okay with passing on the torch? Could we redirect the old script to the new? Or mass message people asking them to switch? Courtesy pings @MPGuy2824 and Evad37: – Joe (talk) 17:32, 16 June 2023 (UTC)[reply]

I don't think anyone has asked Evad directly, but he must have noticed me sniffing around his script's talk page, and you now have pinged him to this thread.

There are a couple of options to deprecate Evad's script:

1. Add a small message to the UI of the script: "This script is no longer being maintained. Please switch to the current version: Edit your common.js file by changing User:Evad37/MoveToDraft.js to User:MPGuy2824/MoveToDraft.js".
2. Replace Evad's UI completely with a message asking people to switch. (screenshot attached)

   

3. Redirecting from the script to my fork.

All of them require either Evad (or an int-admin) to make changes. I think we should definitely do #1 first. I'm torn between #2 and #3. #2 is more jarring to the user, but #3 might seem like we are bamboozling them without their consent. @Evad37, thoughts? -MPGuy2824 (talk) 02:19, 17 June 2023 (UTC)[reply]

3 seems too much, 2 seems a bit pushy, but 1 seems most reasonable. Zippybonzo | Talk (he|him) 12:42, 17 June 2023 (UTC)[reply]

We need to proceed here with respect and sensitivity. Someone should definitely reach out to Evad37 via their user talk page and see what their thoughts are, then we should discuss further. Let's make sure they are involved in this discussion. –Novem Linguae (talk) 18:46, 17 June 2023 (UTC)[reply]

I left a user talk message for Evad37 just now. I want to make sure they are included in this discussion. –Novem Linguae (talk) 11:50, 20 June 2023 (UTC)[reply]

Some brainstorming: (cc Novem Linguae)

• Recruitment
• COI/UPE detection/prevention?
• Review quality?

If you have any others, leave them below. Zippybonzo | Talk (he|him) 05:03, 18 June 2023 (UTC)[reply]

Thanks for getting the conversation started. Can you elaborate on what you mean by review quality? Does this mean re-reviewing other NPP's reviews and making sure they are good? –Novem Linguae (talk) 00:57, 20 June 2023 (UTC)[reply]

Hi @MER-C and @Rosguill. Y'all are some of the names I think of when I think of UPE fighters. Is there anything that non-admins can do to help in this area? If we recruit a non-admin NPP coordinator to focus on COI/UPE issues, do you have any ideas for things they could help with, or is that not a great idea? Thanks. –Novem Linguae (talk) 01:01, 20 June 2023 (UTC)[reply]

To be honest I'm not really sure there's a specific need for COI/UPE coordination beyond reporting suspicious activity while doing regular review work, first with talk page notices and then at WP:COIN. _signed, Rosguill ^talk 01:08, 20 June 2023 (UTC)[reply]

We have a lot of talk pages:

• Wikipedia talk:New pages patrol – discussion about the main page/tutorial
• Wikipedia talk:New pages patrol/Reviewers – the main 'noticeboard'
• Wikipedia talk:New pages patrol/School – discussion about the school
• Wikipedia talk:New pages patrol/Coordination – this page, coordination
• Wikipedia talk:Page Curation/Suggested improvements – discussion of suggestions (though these are also discussed directly on Wikipedia:Page Curation/Suggested improvements)
• Wikipedia talk:New pages patrol/Awards – discussion of awards
• Wikipedia talk:New pages patrol/Newsletter – discussion of the newsletter

I think this is contrary to the way most WikiProjects do it, which is to redirect all talk pages to the main one unless it really needs to be separate. AfC has just two, for example: WT:AFC and WT:AFCP (which is their version of WP:PERM). Previously there was a consensus to do the same here and redirect everything to WP:NPR, but it seems to have been chipped away over the years. Still, none of the above pages are especially active except WP:NPR, and expecting new reviewers to watchlist 7 different pages to be fully involved in the project seems rather exclusionary to me.

I'd like to propose slimming this down to just two pages and the following redirects:

• Wikipedia talk:New pages patrol – noticeboard-like page for reviewers and the wider community
  • Wikipedia talk:New pages patrol/Reviewers
  • Wikipedia talk:New pages patrol/School
• Wikipedia talk:New pages patrol/Coordination – 'backroom' discussion for those interested in project coordination
  • Wikipedia talk:New pages patrol/Awards
  • Wikipedia talk:New pages patrol/Newsletter
  • Wikipedia talk:Page Curation/Suggested improvements

The reason I think the main page should be WT:NPP instead of WT:NPR is that that's where most people expect it to be, and time has proven that there isn't a need for a dedicated page to discuss the tutorial. There have been three threads on WT:NPP in the last year and they were all misplaced (and by the same user). I don't actually like the implied distinction between 'coordinators' and regular ol' reviewers that maintaining two pages entails, but I can see that merging them all into one would probably be a bit much. – Joe (talk) 07:10, 20 June 2023 (UTC)[reply]

Good thinking. I'd be onboard with this, with a couple of tweaks.

• I propose we keep WT:NPPR as the main talk page. Everyone is used to that being the main location.
• Redirect Wikipedia talk:New pages patrol/School to WT:NPPC.

If you feel strongly about WT:NPP being the main talk page, I propose we discuss that more/separately, and if there's consensus, do it as a second step, so as not to hold up these other good changes. –Novem Linguae (talk) 11:48, 20 June 2023 (UTC)[reply]

Moved from User talk:Novem Linguae § History merge

Hi NL, Sorry to spring a history merge on you on your first day of having the mop, but you are the best sysop for the job as you have some context to what I want doing. Could you merge the newsletter draft talk page history with the main newsletter talk page history, and then delete the newsletter draft talk page so I can redirect it to the newsletter talk page.

Links below:

• Wikipedia talk:New pages patrol/Newsletter
• Wikipedia talk:New pages patrol/Newsletter/Draft

Zippybonzo | Talk (he|him) 04:01, 18 June 2023 (UTC)[reply]

Hey. Thanks for the message. I don't think this is a good spot for a history merge because it's not fixing a copy-and-paste move of page A onto empty/new page B. Rather, this is trying to merge two different talk pages with two different sets of content together. If you'd like to merge them, I'd recommend cutting and pasting, with WP:CWW attribution of course. I'm a little hesitant to merge them, but if you think that's best we could try it out. Hope this helps. –Novem Linguae (talk) 04:20, 18 June 2023 (UTC)[reply]

I'll just put them in a collapse, and then I will need you to delete the draft talk page and redirect it to the main newsletter talk page as it's easier when everything's on one big page. Zippybonzo | Talk (he|him) 04:27, 18 June 2023 (UTC)[reply]

You can probably just BLAR it. Although I appreciate you thinking of all these opportunities for me to use my shiny new tools! :) –Novem Linguae (talk) 04:42, 18 June 2023 (UTC)[reply]

You could protect the newsletter draft page so that when I massmessage, if someone vandalises it at the exact moment I preview it, it doesn't (nearly) send vandalism to 870 people. Tbh I don't think massmessage works that way. Trust me, I'm a menace with advanced perms, I nearly rollbacked all my edits with massrollback by not paying attention and doing something else and then the popup appeared. I've also accidentally rollbacked AIV helperbot. Those are the reasons why I test the massmessage on me first, so I don't have to employ AWB to fix everything. Zippybonzo | Talk (he|him) 04:53, 18 June 2023 (UTC)[reply]

Great idea to test it on yourself. Once it's sent, it's a bit hard to unsend or change. Would need an AWB run, and making the fix would probably re-ping everyone again. Definitely better safe than sorry. –Novem Linguae (talk) 05:02, 18 June 2023 (UTC)[reply]

I think if you mark it as minor with AWB it doesn't ping, but I'm not an AWB dev. Zippybonzo | Talk (he|him) 05:05, 18 June 2023 (UTC)[reply]

On a user talk page, I think everything triggers the orange bar unless your account has the bot flag at a minimum. May also need to mark the edit as a bot edit in the API, although I'm not 100% sure about the second part. –Novem Linguae (talk) 05:43, 18 June 2023 (UTC)[reply]

It didn’t when I tested with my alt. So if I ever screw up I can spend some hours figuring a regex query to fix it without mass pinging. Zippybonzo | Talk (he|him) 05:47, 18 June 2023 (UTC)[reply]

Sorry, I got curious and couldn't help myself. I tested it just now on testwiki. A non-bot account marking the edit as minor does trigger the user talk notification. –Novem Linguae (talk) 05:50, 18 June 2023 (UTC)[reply]

It does?, can you leave me a minor edit on my talk page here. Zippybonzo | Talk (he|him) 06:15, 18 June 2023 (UTC)[reply]

Done. How'd our little experiment go? –Novem Linguae (talk) 06:42, 18 June 2023 (UTC)[reply]

You were right, the ping from my alt didn’t show up as the orange banner, though it did register as a notification. Peculiar. Zippybonzo | Talk (he|him) 06:43, 18 June 2023 (UTC)[reply]

While this thread is open, would it be NPOV/necessary to write about your adminship in the newsletter, or do we save it for the administrators newsletter. Also, I read your email. Zippybonzo | Talk (he|him) 06:31, 19 June 2023 (UTC)[reply]

I think it'd be OK to mention my RFA, as long as others don't object. Feel free to draft something up. Thanks for taking the initiative on the next newsletter :) –Novem Linguae (talk) 06:35, 19 June 2023 (UTC)[reply]

For my own curiosity, who are the moderators of the NPP discord server? Zippybonzo | Talk (he|him) 20:41, 19 June 2023 (UTC)[reply]

All the folks that already had it when I joined (Barkeep49, Insertcleverphrasehere, Oshwah, ONUnicorn), plus me. By the way, I can't remember if I invited you yet but you are more than welcome to join. –Novem Linguae (talk) 21:50, 19 June 2023 (UTC)[reply]

Moved from User talk:Novem Linguae § NPP Coordinator

Hello @Novem Linguae! I recently received a message on my talk page from an NPP coordinator inviting me to become an NPP coordinator. I accepted. I was told to ask you to be added to the group list. Could you help with this? - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 19:59, 18 June 2023 (UTC)[reply]

Here’s the thread: User talk:Illusion Flame#NPP coordination invitation - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 00:40, 19 June 2023 (UTC)[reply]

Hey Illusion, I'd suggest that, for now, you work on making your NPR right permanent. In addition to normal reviewing, the right-granting admin usually looks for regular AfD participation, along with correct CSD tagging. -MPGuy2824 (talk) 03:02, 19 June 2023 (UTC)[reply]

In an effort to keep @Novem Linguae‘s talk page tidy, could you move your comment to my talk page where relevant discussion has already occurred. Another user with similar concerns posted there and had their concerns relieved. Please read the thread on my talk and then comment further. Thank you @MPGuy2824. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 03:09, 19 June 2023 (UTC)[reply]

For the record, I advised them, as they are rather competent and would be able to help in areas such as the newsletter and backlog drives and possibly nominations for autopatrol. Zippybonzo | Talk (he|him) 05:54, 19 June 2023 (UTC)[reply]

Hey Illusion Flame. Since Zippy is vouching for you I went ahead and added you to the NPP coordinator's list. You are very new to NPP so please be careful. There's a chance some folks will object to how new you are and I may have to remove you, but for now let's try it out. I went ahead and added you as backlog drive assistant, newsletter assistant, recruitment. Those are the tasks you're interested in, right? For recruitment, we do some checking of folks using the list and procedure at User:Insertcleverphrasehere/NPR invite list, and then we send them the template on that page. Poke around there a bit and let me know if you'd like to get started with that and if you have any questions. Thanks so much for your help with NPP coordination. I look forward to working with you. –Novem Linguae (talk) 06:17, 19 June 2023 (UTC)[reply]

Understood. Thanks for adding me to the list, I look forward to being able to help out around NPP. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 11:41, 19 June 2023 (UTC)[reply]

Hello! I just wanted to ask, how often does the NPP has backlog drives. It appears that the article backlog drive has risen into moderate territory and that it may need attention in a possible July backlog drive. I am not sure if it’s rare to have 2 in a year, so if you could tell me more, that’d be great. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 01:41, 20 June 2023 (UTC)[reply]

@Illusion Flame We typically have them when the backlog is around 8000 or more, as otherwise there aren’t enough articles for people to review. Zippybonzo | Talk (he|him) 05:29, 20 June 2023 (UTC)[reply]

2 in a year is not uncommon, last year there were 2. Zippybonzo | Talk (he|him) 05:29, 20 June 2023 (UTC)[reply]

My two cents: I think we should space them out by a minimum of 6 months. There are folks that don't like them so doing them too often can bug people. Also doing them too often can lead to reviewer burnout. There's lots of good things about backlog drives too, so we need to find a good balance that keeps everyone happy. –Novem Linguae (talk) 11:39, 20 June 2023 (UTC)[reply]

By the way, any interest in moving this discussion to WT:NPPC? I feel like our discussions are getting scattered on user talk pages a bit. Feel free to use the templates {{Moved from}} and {{Moved to}}, and just cut and paste. –Novem Linguae (talk) 11:52, 20 June 2023 (UTC)[reply]

I don’t think a move is necessary as this was meant to just be a clarifying question, but I’ll start a thread there about how often we should have backlog drives. Is that okay @Novem Linguae? - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 12:01, 20 June 2023 (UTC)[reply]

I've talked about this here and on Discord, so starting a new thread and having to talk about it a third time could be a bit repetitive. Up to you though. –Novem Linguae (talk) 12:10, 20 June 2023 (UTC)[reply]

All of your points make sense. Reviewer burnout seems to be a big one. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 12:02, 20 June 2023 (UTC)[reply]