Editing Improvements & Changes

I think the page history should function similar to Wikipedia. In addition to pagination, this would include:

1. The main history page should only include the edit reason and various pieces of brief information such as the user who made the edit and the timestamp of the edit.
2. Each edit entry in the history should link to a fully rendered version of the page.
3. It should be reasonably simple to get the changes caused by any sequence of consecutive edits. This would make things much simpler if a user did a significant edit, and then discovered mistakes in it and made seperate edits to fix them.

It'd be a big problem for people like me who look up specific phrases or tropes in the edit history and require the entire history be rendered on one page.

Yeah, that would make it a bear to detect things like unilateral edits, and it would generally make it more frustrating to see if a specific user is editing correctly. Wikipedia's history works for it, but I don't see it being very useful for us.

&

Agreed. Text search on full edit history is a really useful tool.

someone1981, I can add pagination, a search by troper and a text search pretty easily. But i'm not sure about making it work like wikipedia, seems like too big of a change for current editors.

I think as a compromise it can be a button that hides edits' content, so the edit history can be viewed as a table.

Edited by Amonimus on Jul 18th 2023 at 10:10:35 PM

I guess I just don't see any benefit to hiding the actual edits, even if it's something you have to choose to do. What use is seeing the history as a table if the actual changes made aren't there?

I really like these suggestions. I am super thankful to anyone who helps out here.

Can there be a "null edit" option in the edit reason list?

I would appreciate that.

Also, I want to reiterate the idea of setting a "default" edit reason for a short time, that can make life easier when doing something like a wick cleaning project.

While I think leaving the site was an overreaction, I agree with Emma, and also think edit reasons work fine exactly as they are. Not every edit requires a reason, and some require more specific reasons.

Edited by PurpleEyedGuma on Jul 18th 2023 at 8:31:13 AM

Well we can just run a crowner with options like “no requirement” “required for large edits” “required for X or Y edits” etc and let that go for awhile to see where everyone is at.

Well, the idea is that you can make your own edit reason if you have to. Not all of them would be limited to the canned responses.

I don't really see much of a point to enforcing edit reasons on every edit (though I know that it's the only way to make the people who need to use them use them) but I also don't really think it would be a big deal. People would get used to it pretty quickly I think. My only real concern is it cluttering the edit reasons list.

... I don't remember, can crowners do multiple choice? xD

Of course they can, that's how we do TRS crowners and IP crowners and everything

I added "null edit" and "image quality upgrade" to the list of canned edit reasons in the OP.

to a crowner.

(Also, I would like to apologize for overreacting earlier. I wasn't in the right frame of mind when I was posting—all of you were right that my claims were ludicrous, and as I said on another thread I will strive to do better.)

Yeah, crowner sounds good, if we can work out all the feasible options people have actually shown an interest in.

And hey, I don't do crowner stuff often, I can't remember their limits.

Hm, I'm not a big fan of multi-stage processes if we're doing multiple choice anyway? At least if we can hash out the specifics that might deserve edit reasons easy enough. 'Large edits' would obviously need more work in any case, that's inherently vague.

Edited by RainehDaze on Jul 18th 2023 at 2:16:19 PM

Edits of a certain height that you have to scroll through? So you want an edit reason before scrolling through it?

I'm not sure if the requirement for a "large edit" should be based on the size of the edit as it appears on the screen or the actual size of the change in KB/MB. That's part of the reason I was thinking a general crowner should be first, to establish what route(s) we're going to go, and then work out the details.

I thought 'large edits' would be more about changes > x and some similarity score (so, we get multiple things changed and they're different) so that people making a bunch of changes at once actually explain what's going on. Probably why if that won it'd need an entire discussion to narrow it down.

Some of the other specifics are easy enough to include as-is, though. Deletes, at least; anything that might be a potential edit war change (with or without that being its own alert).

It would help if we understood what currently designates an edit as large in the system.

Can we please add something about still being able to enter a custom edit reason if we get the checklist in the sticky? I think it's creating unnecessary confusion.

Anyway, while I agree that we can vote on what constitutes "large" after determining whether those edits should need a reason given in the first place, I'm concerned that "specific" reasons may not accurately reflect everyone's opinions. For example, someone who wants edit reasons anytime an external link is inserted, but doesn't want edit reasons if single examples are removed would vote the same way as someone with the exact opposite opinion.

Because someone who is against mandatory edit reasons in all cases would presumably downvote all options anyway, I propose a crowner like so:

1. All edits
2. Large edits (if consensus, another crowner will define "large")
3. [Whatever other reasons we decide upon]
4. If edit reasons are always required, make an exception for Sandboxes
5. If edit reasons are always required, make an exception for Troper pages
6. If edit reasons are sometimes required, make an exception for Sandboxes
7. If edit reasons are sometimes required, make an exception for Troper pages