Categories in options page

[dnknn]

chrome-extension://hlepfoohegkhhmjieoechaddaejaokhf/options.html

There are many functions and the list is very long, which makes it difficult to locate the mess.

If possible, I think the layout of the classification should be restructured.
Classification is based on some large category rules.
The benefits are many, Entering the options page no longer feels like entering the maze.
1 Users can find the function options in this category very quickly.
2 It is also useful for ordinary users (not developers)
3 E.g,if I don’t use the Pull requests feature, I can find the category and disable it all. Because in this category, it’s all about Pull requests.

4 In short, with the classification options, you can clearly view or find the options corresponding to the category.
Unlike the current, many options do not know where they correspond.

category for examples 👇

• ⌨hotkey/shortcut    All about shortcuts.

• Code

• Issues

• Pull requests

• Releases

• more

• .etc.....

---

Or other classifications, in short, it is better to have a classification induction.

[sindresorhus]

There are many functions and the list is very long, which makes it difficult to locate the mess.

Did you try the search?

[fregante]

The problem with groups is that they’re arbitrary and incomplete.

Refined GitHub adds features that benefit everyone or almost everyone, so we don’t expect people to look around and pick what they want.

You should only deactivate features if you find something you disagree with. None of us wants to spend hours on the options UI to slightly improve it.

[fregante]

No classification will be added. New features already have a NEW marker: #2668

[dnknn]

Ok

[asmeurer]

The problem with groups is that they’re arbitrary and incomplete.

Refined GitHub adds features that benefit everyone or almost everyone, so we don’t expect people to look around and pick what they want.

You should only deactivate features if you find something you disagree with. None of us wants to spend hours on the options UI to slightly improve it.

This seems to be an argument for having all the features enabled by default, which seems fine. But I don't see how that's related to whether the options are sorted by category in the options page. For those who do want to go through and only enable the things they want, this would make things a lot easier.

Sure, no sorting will be "perfect", but anything would be better than what is there now. They're already categorized in the README. Why not use the same thing in the options page?

As an aside (I can open a new issue for this if you like), something that I would find really helpful in particular would be to find those options that are "destructive" in some sense, that is, those options that affect things other than just my personal view of GitHub. An example is the feature that disables wikis on new repos. These change my mental model of how GitHub works in a way that affects other users, so I prefer to disable them. ("Destructive" isn't really the right word here, but you get the idea)

[fregante]

None of us wants to spend hours on the options UI

Unfortunately this still applies. We can only add that if someone presents a very-minimal PR that:

• Adds headers in the options list (while preserving the filter functionality)
• Categorizes each feature in such list
• Ensures that new features will be categorized (likely via TypeScript type)

and

• The PR doesn't require a lot of reviews/rewrites to ensure it works

Unfortunately most requests like this fall short of actually sending a full PR, so we're back to None of us wants to spend hours on the options UI.

those options that affect things other than just my personal view of GitHub. An example is the feature that disables wikis on new repos. These change my mental model of how GitHub works

I like this argument, can you open a new issue listing the current features that would fall into this category and what could be done to improve the current situation? I'd be hesitant to have disabled-by-default features because they'd be forgotten and lost in the long Options list, while they're still likely useful to many.

[asmeurer]

I opened #3964.