Ich denke, bei jedem Prozess, der „öffentlich sein könnte, privat sein könnte“ beinhaltet, gibt es jedes Mal, wenn jemand ein Thema erstellt, Spielraum für Benutzerfehler. Ob es darum geht, die richtige Kategorie auszuwählen, sich daran zu erinnern, auf „flüstern“ zu klicken oder ein Tag hinzuzufügen, das dann magische CSS-Tricks anwendet, um es zu verstecken, und so weiter. Es gibt einen Punkt, an dem Sie diese Wahl treffen müssen, und eine damit verbundene Gelegenheit, etwas falsch zu machen. ![]()
Ich denke, eine Unterkategorie ist der richtige Weg, um Vertrauen in die Sichtbarkeitsschutzmaßnahmen zu haben. Wenn Sie keine Unter-Unterkategorien dafür aktivieren möchten (oder Ihre oberste Kategorie-Struktur mit einer Alternative wie Category Groups anpassen möchten), können Sie eine zusätzliche Unterkategorie in Support für #internal-bug-reports haben und dann den Themenfilter verwenden, um eine benutzerdefinierte Themenliste zu erstellen, die Themen aus beiden Kategorien enthält, die Sie dann zum Seitenleisten für Ihre Entwickler hinzufügen können.
Nur zum Spaß habe ich getestet, ob ich den post_type eines OP über die API ändern könnte. Und obwohl es funktionierte, erschien es immer noch in der Themenliste für einen Nicht-Flüster-Testbenutzer und gab dann einen Fehler aus, wenn er darauf klickte.
Es scheint also, dass zusätzliche Entwicklungsarbeit erforderlich wäre, um dies zu glätten (und es kann auch andere Konflikte für unerwartetes Verhalten geben, wenn Sie anfangen, herumzustochern).