On the subject in the title: Search filters: what is missing Working notes rather than a conclusion.
A follow-up question about Search filters that I did not know to ask the first time.
The earlier thread answered what I asked. What I should have asked is below, and I think it is the one that matters.
Adding the measurement that post #2 says would settle it.
Search filters is a question about a distribution, not about a value, and treating it as a value is what produces the confident wrong answers.
The opening post describes the usual case. This is about the unusual one.
I would call the community position on Search filters likely rather than established, and I would be comfortable defending that hedge.
Accessibility: screen readers, keyboard navigation, contrast, font size — if something is not accessible to you, report it. Accessibility matters.
Logged, and thank you for the precise description. That is a wording problem rather than a logic problem — an empty state that says "no topics match both filters" is a five-minute change and a real improvement.
Adding the caveat now so it does not have to be extracted later.
Picking up post #6: that is the part I would want checked first.
What I can speak to on Search filters is narrow, so I will keep it narrow rather than generalising from it. Beyond that boundary I do not know.
Since Search filters keeps coming up, it should probably be a maintained page rather than a recurring thread. I am happy to draft it if someone with more direct experience will review it.
Guideline clarity: if the guidelines are unclear or seem to be applied inconsistently, post the specific situation so staff can clarify or reconsider.
The general answer and the answer for your case may diverge here.
Coming back to post #8, because the follow-up matters more than the original answer.
Agreed on Search filters, with one qualification that I think matters. The reasoning holds for the case as described. Change the starting assumption and it does not, and the starting assumption is the part nobody states.
Source for the Search filters figure, since it was asked for. It is in the discussion rather than the abstract, which is why the version circulating is stronger than the paper is.
Reading the surrounding paragraph is worth the two minutes. The authors are more careful than their summarisers.
That is consistent with mine, for whatever one more account is worth.
Building on post #11 rather than restating it.
That would also be the fastest way for a new member to understand what R6 actually catches, which is narrower than people assume from the text.
The confident version of this sentence would be wrong, so here is the hedged one.
Last piece of feedback: the site is much better on a narrow screen than it was six months ago and nobody said so at the time. Recording it because only the failures usually get reported.
The answer changed when I changed how I was measuring, which was informative.
Post #15 is the version of this I will quote in future. One addition.
I disagree with the framing of Search filters above, and I think it is a substantive disagreement rather than a terminological one. Setting out why, so it can be checked.
The reasoning depends on an assumption that is doing a lot of work and is never stated. If the assumption holds, the conclusion follows. I do not think it holds generally.
On post #15 — agreed on the reasoning, with one qualification.
Performance: if pages are slow to load, timeouts occur, or the site is unresponsive, that is worth reporting with details (when, which pages, how slow).
Anyone who has looked at this more carefully, please correct the record.
The most useful thing anyone has posted about Search filters in this category was a table of what had been measured and by whom. That is what I would want again.
Feedback on the trust-level page: it explains what each level unlocks, and not what a member at that level is expected to do differently. The second is what people actually want to know.
A single observation, in a thread that deserves better than single observations.
Appreciated. The plain phrasing does more work here than a longer post would.
On post #22 — agreed on the reasoning, with one qualification.
Navigation problems: if you cannot find something you expected to exist, or the path to it is unclear, report it. Site architecture affects usability.
That distinction is real and staff have discussed it twice without deciding. The risk is that a topic marked unanswered discourages the reply that would answer it. If anyone has seen it work elsewhere, say so — that is the missing evidence.
That is what the documentation says. What happens in practice is usually close.
Practical answer on Search filters, since the theoretical one is upthread: do the simplest check first, write down the result, and only then decide whether the complicated explanation is needed. It usually is not.
Adding the measurement that post #24 says would settle it.
Two people in this thread mean different things by Search filters and are disagreeing about the definition while believing they are disagreeing about the facts. Worth pausing to define it.
Post #26 describes the usual case. This is about the unusual one.
Display issues: broken layouts, images not loading, text overlapping — report with the browser and device you were using. Display bugs are platform-specific.
I checked the source rather than the summary, and they differ.
Narrowing post #28, because the general version has more than one answer.
A methods point on Search filters rather than a substantive one: if the comparison is not like for like, the difference you are measuring is the difference in method.
Everything in post #26 holds. The case it does not cover is the one I have.
Moderation decisions: if you disagree with a moderation decision, raising it here gives it visibility. Staff will reconsider if you make a substantive case.