Changes in how to handle page deletion requests

A topic that came up in the moderator discussions, but which is important to regular users as well, so putting it here.

I do handle cut requests every day and I increasingly get the impression that having them listed and processed through a central list is a bad thing:

• The delete button is on the Cut List page, not the page I am handling. Thus, I don't see the page's content when "flipping the switch", only when opening it in another tab.
• Having a large stack of cut requests dilutes the amount of attention I can devote to each item.

The cutlist gets complaints for mishandled requests regularly, so I wondered if moving off the "delete" function to the pages themselves would be a good move. This would require some technique to submit cut requests, though - using the current list would become a tabbing/navigation issue.

edited 16th Jul '15 9:35:42 AM by SeptimusHeap

...

<deep calming breath>

Okay, I want to make it clear that I honestly believed that all Cut List requests at least involved a cursory look at the page in question, and that any mishandled requests were due to the cut master working on it missing details in their inspection. Unfortunate, but it could be fixed with practice and dedication. Apparently I was wrong, and my trust in the staff properly handling this aspect of the site was misplaced.

I'm not certain whether this can be labeled as the software design (said centralized list) leading to the adoption of lax habits, there not being enough time on the hands of the cut masters to give that kind of attention to each item on the list, or some combination thereof. Either way, this needs to be fixed now. And until it is fixed, there shouldn't any more Cut List requests getting "handled", until they can be processed correctly, with proper oversight.

I'm honestly beside myself right now. This is not how this site should be run, then, now, or ever.

Edit: This post was in response to the original OP, not the current edited version.

edited 16th Jul '15 10:18:29 AM by TotemicHero

Just to be clear: I do check the page before cutting it, and I am sure others do as well. But the current system requires an extra step to check it. And it doesn't work so well for redirects, either.

You probably should have phrased the OP better, since it made me think you were admitting you all never read anything. ("Handling the request", from my view, includes all investigation involved, up until you doom it or decline the cut.)

I would have thought redirects were the simplest cut requests to deal with, since cutting them is mainly about wick or inbound count (Redirects Are Free, after all).

Edited my post. Also, while Main/ redirects are fairly simple medium-to-medium redirects have been problematic.

The vast majority of cut requests that I've seen and done are for Main/ redirects that have had their wicks namespaced and ptitles that have been created in order to be purged from the system. I'm not looking at the list nearly as frequently as Septimus or other mods, so I have to ask - what cut requests have been causing issues lately?

It's not so much specific cut requests that are the issue as much that I have the impression (from the work of reviewing articles before approving/declining cut requests on them) that the current form of the cutlist makes it unreasonably difficult to properly vet the requests. And that this difficulty may be the reason why the handling of cut requests attracted so many complaints in the past.

We are looking at consolidating the article management tools such that content reports, help reports, cut requests, type changes (pending a replacement article creation system), lock/unlock, cut actions, and so forth, can all be managed from the article itself rather than having to go to separate pages. That said, we'll still need a place to review all of the cut requests.

edited 16th Jul '15 11:17:25 AM by Fighteer