Categories in options page #3357

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

Did you try the search?

Did you try the search?

Yes, I knew would say that 🔍⏳. But this is two different things. 🔍The search requires Typing and you have to specify keywords, which can't be wrong.

In addition, they are different uses and functions.

• 🔍⏳ Search is just for quick filtering,

• ▓🏷️ The catalog classification is used for indexing and manage.

Suppose: chrome://settings/ Chrome's settings options page ((Of course, its options are longer)), If there is no catalog classification, what will be the effect?

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.

No classification will be added. New features already have a NEW marker: https://github.com/sindresorhus/refined-github/pull/2668

Ok

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)

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.

I opened https://github.com/sindresorhus/refined-github/issues/3964.