Yes that looks correct. Thank you.

@Reedy This looks great. Could we get RelevantLinks and ProposedSolution to be required fields as well? Otherwise I think we're good to go.

Thanks Reedy. Give me a day or two to confer with the rest of the committee.

User:U4C is correct

So as fate would have it, I stepped off ArbCom a few months ago to focus on my U4C work. Were I still on ArbCom I would say that this is "safe to try" and satisfies the request ArbCom made, but will leave that formal process to ArbCom. I have emailed the committee to ask who I should re-assign to and named who I will do so by default if this doesn't get to resolution.

In T349415#9519689, @HouseBlaster wrote:

What are the key values of Wikipedians? What do they value in research on/about Wikipedia?

Is there a place where members of the community are able to share responses to the above question?

I will say a huge thank you for all of your hard work so far!

To save time at tomorrow's meeting I will confirm that I think this is on the right track.

Is the plan to share the draft with enwik ArbCom in February or March?

They have been very clear that they prefer to have the scope smaller and have something around March 2024 (a timeline that in all fairness we proposed first;) than an expanded scope with a later delivery time.

Thanks. The two groups are arbcom-audit (or perhaps arbcom-en-audit, I have never been subscribed so I don't know if it happened before or after the en appellation) and arbcom-appeals-en (which again remains an active list but is now entirely hosted on GoogleGroups).

@Samwalton9 asked on discord today "Would enabling Nuke to operate on all temporary accounts associated with an IP return its effectiveness?" From an enwiki perspective, the answer is no. Enwiki already limits the ability of IPs to create articles. Additionally, I have concerns about how this might impact the fact that we have a substantial number of editors from countries with limited numbers of IP addresses and so the collateral damage might be higher than acceptable (the acceptable level here being, I expect based on previous community discussions, close to 0 on enwiki).

Just to add background that I know Joe knows but others may not, there was a period of time around Dec/Jan where I was aware of a number of emails that were getting caught in the emergency spam filter. I am wondering if ITS might need to take a broader look to help that account - information that might indicate possible spam (i.e. language indicating someone's life is on the line) for the normal WMF staffer is less helpful for emergency@

I think showing when a user actively logs out could indeed be very valuable evidence to help establish socking and so I would be supportive of this change.

Is there already a Phab task around vieweing deleted content which blocked admins can do? Because I view that as a similar issue.

The project can obviously be public. It's fine that people know enwiki Arbcom is using phabricator and even what we're using it for - I imagine we'll not keep it a secret onwiki and people filing appeals with us are bound to know in some way. So no problems there @Aklapper. We would want a space and for that space to be private. As I understand it there's also the ACL which would allow arbs to self control user management for the space.

To Build on what Primefac says, a lot of work currently goes into keeping track of the private business of ArbCom on ArbWiki to ensure nothing gets lost. Our goal is to find places to have technological assists on our work, allowing arbs to focus on the substance of the business rather than the secretarial work of it. Arbwiki will continue to be useful as a place for some kinds of discussion and work - such as the drafts of decisions for our cases.

@Majavah as noted above the community block has been resolved. I agree with you that this is pretty straightforward technically (and even operationally on enwiki).

We have now attempted to alert admins to this change and indicated in the message (which @Xaosflux agreed should be sent) that the change would go live the week of December 13. @Seddon is it possible to get your help with a slot sometime that week?

Thanks for clarifying Martin. I think for the moment having it remain in Beta is the wish of most arbs. This might change after the first of the year with our new group but I kind of doubt it. So I think we can mark this as resolved.

This is all new to me so apologies for the newbie questions/thinking I am about to do. I know that @Seddon has offered to help some on the technical side. I am not sure if others will be necessary to help Wug implement this patch. Beyond that, I want to avoid a possible chicken/egg scenario here. There is a desire among those discussing this on enwiki to be strategic about the change, that is to do some work to make sure people know ahead of time the change is coming. So just how much control is there over timing? Do we have the people in place that we could identify a specific backport window and go from there? If not what else might need to be done for that to happen? Thanks for the expertise and assistance already offered by others here.

Sorry for having missed the previous ping. Can someone clarify for me what promoting it out of beta would do?

Here's what the preferences looks like for me (and from what I understand others as I'm not the only arb who likes to use VE on occasion).

In T285401#7172743, @Reedy wrote:

What hack do you mean?

Put me down on team "I think OTRS is incredibly clunky and unfriendly software" and moving to some fork of that does not excite me because I am skeptical that we will want to do two transitions and so absent some forced move (like this) I think we'll continue to use that fork indefinitely. So I think we need to explore non-OTRS software now and make the right choice about what to switch to.

I really have no interest in doing mediawiki work. Let me be clear, because I was not in my first message, that I am doing this on behalf of the EN ArbCom. I had hoped, given that RU Arbcom wiki recently did this change, it would be straight forward for the same change to made to EN ArbCom wiki. If not, we will just continue to suffer from confusing tabs.

Pinging @Urbanecm who did this for RU arbcom.

I would strongly object to this being set as declined as it was included in a community wishlist which garnered support across wikis. There's interest in this. I understand why its priority is being set to lowest but again would disagree with it being declined altogether.

@Valereee because in whatever ticket it was they did the actual investigation they found whole bunch of reasons that doing this would be hard and so I think it's not getting done if I recall.

@Whatamidoing-WMF So it just occurred to me that the reason I might have done this is because I use reply link on enwiki which has a similar interface so I'm used to signing. I don't know if that is a widely used enough script to make development decisions around that, assuming that is the reason I did it, or if I'm just an unrepresentative sample.

I have been unable to reproduce this bug so it feels like this has been successfully patched.

A second instance of this issue, this time by @Adotchar https://en.wikipedia.org/w/index.php?title=Ken_Armstrong_(U.S._Coast_Guard_officer)&action=history

Thanks @DannyS712

Good news. I was quickly able to find two instances of this bug.

It seems to be working for me - took a little bit of time to come across an article with it.

I haven't experienced the bug, but I would hope if a bug can be verified about this new tool that it would be fixed not just left there to be fixed eventually.

Indeed. It's very exciting!

@Qgil thanks for concluding with the paragraph that you did. I would suggest that this ticket started from a frustration of an inability to contact paid movement workers in the same general way that we contact volunteer movement workers. Finding otherways for the foundation to be more accessible to other groups is a laudable goal but seems of a different task (and need) than this one.

@ifried the question is how many articles would the completion of this task identify and especially how many are identified that are also not labeled with some other issue (e.g. ORES potential spam).

This ticket came from a discussion held on a Wikipedia user talk page and I think it's important to remember that need when thinking about this. While the ticket description says "within Wikimedia" and I suppose by a technical definition Wikimedia space is with-in the Wikimedia movement it surely doesn't feel that way to me and, if I'm reading his comments correctly, headbomb. So that's 100% of volunteer editors surveyed who feel that way :). If/when notifications and unified log-in work perhaps I'll feel differently. But I really wish the answer to concerns about barrier to entry for discussions on MediaWiki wasn't to go off MediaWiki software but to do the kind of work Danny and his team have been working on to make MediaWiki better in this regard.

This task is not yet complete but I know it's being worked on at another task which I can't immediately locate.

It would help if we had any kind of data about the number of triggers this would pull. Would it be comparable to the edit filters?

I think Kudpung and I have been a bit more reluctant on the utility of what's being proposed here than the NPP community at large. It's hard for me to say if this is because we're more plugged in or because we happen to be coming at it from different points of view. Personally I worry about the crowding and visual clutter. It's hard for me to tell how many articles would really be flagged by this. Do you have any idea @ifried? Are we talking 1 a day? 1 every other hour? 1 a week?

Given the medium complexity I would love to wait on a decision about this until we know where things stand with some of the unknown tickets - in particular task T207761.

As @DannyS712 has pointed out this has received considerable support from among the NPP Community.

I think it's a little more useful than that - any article created from a redirect are automatically indexed for instance and if a user is creating troublesome articles (or really good ones) from redirect we can't filter by their creations. But overall I agree this is not a must have.

It means it's not done @Kudpung and Musik is saying he doesn't practically think it can be achieved.

I won't pretend to fully understand the performance implications of @Samwilson analysis but let me ask a question. Could a similarity score make this easier for recreated pages?

By way of another example, when sorting by oldest https://en.wikipedia.org/wiki/Schoomaker doesn't let me advance. Nor does https://en.wikipedia.org/wiki/Chichester_District_Council but it seems to work OK from there. So far I haven't been able to find a more recent example from the front of the queue than the ones I posted in the NPP talk page.

@Etonkovidova I think sorting order does matter. An example of an article where I can produce the bug at this moment is, with the queue sorted to oldest, https://en.wikipedia.org/wiki/Chichester_District_Council

Maybe? This has happened a few times, some of which were around when @MMiller_WMF and company were doing the AfC integration which were fixed. I do a fair amount of patrolling and this particular kind of not advancing behavior is new for me.

I believe this went live with the note to reviewers and is working.

I think it is useful, I just don't know if it is going to be useful for the time it takes to do. However, some chunk of that seems like it's already been done. But beyond all that median seems like the right gauge for me. I assume the number will be calculated correctly so that if an article is 5 days old the other 25 days are null not 0.

Sorry for being a bit daft but can you explain what the context for 1-7 is? Are they all alternatives or, from my quick look at the code, things which would trigger under different conditions?

@ifried So the sending the note without reviewing works properly, so yeah. Am I correct that there is no way to both review and send a note?

Template:Sentnote-NPF now exists and I think this is ready to go live - sorry for the delay. Work continues to be busier than normal and so I've not had as much Wikipedia time as usual.

So far kupdung is the only one who has expressed an opinion. I asked you a question at WT:NPR. Pending your answer I'll suggest a template and if no one objects within a day or two will implement it.

@ifried Works for me. Thanks for everyone's work on this element of the task.

@Insertcleverphrasehere Is is though? At some point we'll have too many indicators and clutter. COI is definitely worthy of inclusion. Is this pared down version also worthy? I'm less sure. I'm curious what the discussion at https://en.wikipedia.org/wiki/Wikipedia_talk:New_pages_patrol/Reviewers says

@ifried Yes username is already existing. I think the original person was just trying to make clear what functionality they were looking for, specifically something that brought some of the features of the NPP Browser on wiki. Especially given that the NPP Browser's current link is broken.

This will need some community feedback. I will post the querry to WT:NPR but please feel free to do so yourself. When MMiller was working on this he was active there which I know was rather appreciated.

@ifried It appears it is working. Is there a reason that there isn't accompanying text like there are for the other issues? So like "Spam - ORES has identified that this article as containing spam at one time" (is this right? I know the COPYVIO trigger never goes away even after it's been fixed and am guessing this is true for Spam, Vandalism, and attack)

@ifried I have not been active this week so apologize for the slow response. Separating out the functions is no issue that I can foresee. Making a template should be rather straight forward too. What's the name of the template that the toolbar calls now to leave a message? Changing that to work for Sentnote-NPF seems like it should be straight forward.

@MusikAnimal That works too and makes sense to me (but I am going to add the idea of wiki ownership over how the tags are applied for some future wishlist because I do think it's a good idea overall).

This discussion might be better held at https://en.wikipedia.org/wiki/Wikipedia_talk:New_pages_patrol/Reviewers but pinging @Rosguill and @DannyS712 as the two people who have dived deep into redirects most recently.

Is there anyway to not hardcode the filters that triggers this alert? To have it feed from a template or a page or some other method that would let en wiki editors maintain this rather than WMF? This way if 148 and 149 get supplemented or supplanted we're not locked into old information?

Thanks @ifried that is what I was suggesting.

Is there a reason that to must be required as opposed to just setting it to the current date if nothing is entered?

To maximize the use of this feature I would suggest some visual indicator on the toolbar itself - no clicks or flyouts necessary. I leave it to others to design the best way to do this.

Could the background of the i change (like the Check changing from grey to green when patrolled) for one of these? Perhaps make the issue change the i to red and then add an icon like @Niharika's mail icon for the message? The background color loses the number of issues present but that seems less important that alerting that there are issues in my thinking.

So as to complicated the picture, here's an example of where it would be potentially helpful to have page curation:
https://en.wikipedia.org/wiki/Malik_Ofori

That would work well in my opinion. Thanks Sam.

@kaldari thanks for that background knowledge. This makes sense and would be fine, however is not consistently the case at the moment as it seems to time out after 30 days after creation and not even necessarily 30 days in the queue.

Some indicator, ideally different from the red bubble with the number of issues, to indicate a talk page message is present would be incredibly useful with this - there aren't always reasons to open that particular panel and so a NPP note could get missed by another reviewer.

That looks fine @Samwilson but how does the toolbar indicate that a message has been left?

Yes it does. Pleasure to virtually meet you @ifried

Unreviewing someone else's review is a strong act that has caused conflict in the past. The inability to send a message noting why is less than great in my thinking.

@MusikAnimal I think your logic is right for both articles and redirects.

I could but it was a stupid comment. Please disregard.

I don't have more info for you beyond that and so I would understand prioritizing other things. @Diannaa as the one who raised the issue, thoughts?

@Niharika Is there a reason these entries appear with articles rather htan redirects when sorting the queue?

I think the article should be added to the feed in whatever state it is currently in. I don't believe, when this used to be an option, that it would either add it to the queue or mark it unreviewed. Adding it to the feed isn't the end of the world if it doesn't trigger an unreview by default. That's my two cents. Pinging @Kudpung in case he wishes to comment here directly.

Kudpung has documented that the curation toolbar being available on anypage once existed. He suggests that @kaldari might have more information about the topic. The diff where he discusses this is at: https://en.wikipedia.org/w/index.php?title=Wikipedia_talk%3ANew_pages_patrol%2FReviewers&type=revision&diff=904108131&oldid=903982992

I can confirm that things appear to be working correctly now.

Ping @Samwilson - wrong sam pinged before.

@Samwalton9 This is a new capability so there is no existing talk page feedback to show.

If it helps it also doesn't need to look beyond the last 500 talk page edits and really I can't actually imagine anything past 50 being useful - if an article is getting that much talkpage attention it's likely going to be patrolled already or else isn't patrolled for some other reason. I would anticipate in the overwhelming number of uses cases this will be one of if not the first edit to the talk page - in most cases wikiproject banners are all that are on a talk page when it is patrolled.

Thanks. The lack of deploys last week was what was confusing to me. Appreciate your work and communication.

This remains an issue of concern for the community - there was recent discussion about this still being unresolved in the NPP Discord channel. Any update?

I think that would be great. @DannyS712 has done some work around bot patrolling of these easy to patrol redirects and this seems like it would complement those efforts.