Was halten die Leute für eine vernünftige Anzahl von Stimmen pro Vertrauensstufe? Ich sehe, dass wir auf Meta TL0 von 2 auf null Stimmen und TL4 von 10 auf 8 geändert haben. Mir ist aufgefallen, dass mir selbst die Stimmen ausgehen, obwohl ich hier Administrator bin! ![]()
Ich habe immer gedacht, dass die Anzahl bewusst begrenzt ist, damit sie als eine Art „Das ist mir wirklich wichtig“-Indikator dient. Ich kann immer noch alle Anfragen mögen und meinen Anwendungsfall zu Funktionsanfragen hinzufügen, auch wenn mir die Stimmen ausgehen. Und ich kann immer noch für diese Themen abstimmen, sobald eine andere von mir gewählte Funktionsanfrage abgeschlossen und das Thema geschlossen ist.
@tobiaseigen, ich würde sie nicht einschränken… Ich benutze Stimmen nie, weil ich entweder etwas unterstütze oder ablehne; zu versuchen, festzustellen, ob mir etwas wirklich wichtig ist, ist keine besonders pragmatische Nutzung meiner Zeit, wenn es stattdessen Likes gibt.
Ich habe diese aktuelle Diskussion in Jammydodgers Original verschoben, da es richtig erscheint, hier weiter über Abstimmungen zu sprechen.
Ich mag die Idee von Limits, aber ich denke auch, dass es so viele offene Funktionsanfragen gibt, dass es unfair erscheint, ein sehr niedriges Limit zu haben. Ich fühle mich selbst dadurch eingeschränkt! Stimmen sind auch ein Signal, und indem wir den Leuten keine Stimme geben, berauben wir das Produktteam dieses Signals.
Ich neige dazu, die Limits wie unten beschrieben zu erhöhen. Was meinen die Leute dazu?
| Vertrauensstufe | Aktuelle Stimmen | Vorgeschlagene Stimmen |
|---|---|---|
| TL0 | 0 | 0 |
| TL1 | 4 | 10 |
| TL2 | 6 | 20 |
| TL3 | 8 | 24 |
Imo 24 macht dies praktisch unbegrenzt.
Ich mag die aktuellen Grenzen, sie regen zum Nachdenken an.
Ich frage mich, ob die strenge Rationierung wertvoller Stimmen zu begrenzten Informationen führt. Die Stimmenzahlen scheinen im Allgemeinen niedrig für die Anzahl der Benutzer hier zu sein. Viele Funktionsvorschläge haben mehr Likes als Stimmen, aber ich stelle mir vor, dass nur Stimmen beachtet werden.
Ständig keine Stimmen mehr zu haben und immer wieder auswählen und opfern zu müssen, um für etwas Neues zu stimmen, ist eine erhebliche Hürde. Ich überprüfe meine bestehenden Stimmen, um zu sehen, wie ich Stimmen freigeben kann … aber keine der Anfragen ist unwürdig. Sie sind einfach vom Feed gerutscht und wurden vergessen.
Soll ich sie aufgeben?
Soll ich meine Favoriten mit einem Kommentar pushen? Nachdem ich für eine Funktion gestimmt habe, fühlt sich ein Kommentar wie „Ja, gute Idee!“ wie überflüssiger Ballast an.
Gute Ideen bleiben mit ein oder zwei Stimmen liegen. Werden die Leute sie nicht entdecken, sind sie nicht interessiert oder … haben sie einfach keine Stimmen mehr? ![]()
Die Limits zu erhöhen würde keine Menge an Code erfordern und es scheint, als würde es helfen – aber ich denke auch daran, wie das Verbreitern einer Straße, um den Verkehr zu reduzieren, nur mehr Verkehr anzieht und man wieder am Anfang ist.
Nur ein Brainstorming … einige funktionale Änderungen, die viel Code erfordern, als Alternativen zu einem harten Limit:
- Zuweisen einer Anzahl von Stimmen pro Monat basierend auf der TL. (Am „Stimm-Tag“ gibt es einen Schwall von Aktivitäten, da die Leute Feature besuchen und offene Punkte bewerten …)
… oder, wie heliosurge erwähnte, Stimmen schließlich freigeben:
- Eine verwendete Stimme nach einer festgelegten Zeit freigeben oder
- Mitarbeiter überprüfen veraltete Funktionsanfragen auf rollierender Basis und entweder a.) den Thread für eine weitere Chance pushen oder b.) mit „keine Pläne zur Behebung“ kommentieren und Stimmen freigeben.
… In beiden Fällen bleiben abgegebene Stimmen bestehen, und Benutzer können ihre Stimmenzuweisung nicht überschreiten, indem sie diese Themen weiter abwählen.
(Leicht für mich zu sagen. Das ist wahrscheinlich viel Code
)
@sam, bei mir nicht, da ich nur Likes verwende. Die aktuelle Implementierung wirkt etwas redundant – ähnlich wie die Tatsache, dass es sowohl Upvotes als auch Daumen-hoch für GitHub Discussions gibt.
Zustimmung, dass doppelte Signale verwirrend sind
„Ich mag, wie Sie die Funktionsanfrage geschrieben haben, klingt für mich gut“
Vs
„Dies ist sicherlich in meinen Top 8, ich denke, Discourse sollte es bauen“
Es könnte ein interessantes Experiment sein, Op-Likes zu deaktivieren, wenn Topic-Voting aktiviert ist.
Es gibt etwas daran, einige Anfragen mit „Entschuldigung, wir tun das nicht“ zu schließen.
Es gibt sicherlich etwas äußerst Überzeugendes daran, 2 Jahre alte abgeschlossene Funktionen als erledigt zu schließen und Funktionsanfragen, die keinen Sinn mehr ergeben, als veraltet zu kennzeichnen.
Ich glaube nicht, dass sich das am Ende so viel ändern würde. Die meisten meiner Stimmen wurden vor einem Jahr hinzugefügt. Ja, ich hätte über mehr Themen abstimmen können, aber sobald ich alle meine Stimmen verbraucht habe, ist es wieder dasselbe: Ich müsste warten, bis eines abgeschlossen und geschlossen ist, oder ich müsste meine Stimme von einem anderen Thema zurückziehen. Ich bin mir ziemlich sicher, dass es auch mehr als 20 gute Funktionsanfragen auf Meta gibt ![]()
Wie ich bereits sagte, sind Stimmen für mich etwas Stärkeres als ein Like. Aber ich denke immer noch, dass Likes auf dem ersten Beitrag auch sehr hilfreich sind, um Interesse zu wecken. Sie sind seit über 10 Jahren der Indikator, als das Abstimmen noch nicht aktiviert war. Sie zu ignorieren, insbesondere bei langjährigen Anfragen, bedeutet, die einzige Möglichkeit zu ignorieren, mit der Benutzer damals Unterstützung zeigen konnten.
Außerdem denkt vielleicht niemand, dass die Funktionsanfrage etwas ist, das er so sehr braucht, um eine Stimme dafür auszugeben, aber viele Benutzer mögen sie, weil sie denken, dass sie hilfreich wäre. Sagt eine Stimme (normalerweise vom Autor der Anfrage) mehr darüber aus, wie hilfreich diese Funktion für eine Reihe verschiedener Discourse-Sites wäre, als mehrere Likes?
Ich frage mich, ob es nicht besser wäre, die Anzahl der Themen, über die sie verteilt werden können, zu begrenzen, anstatt die Anzahl der „Ich bin wirklich daran interessiert“-Stimmen zu erhöhen.
Anstatt also 378[1] Themen aus diesem Jahr zur Abstimmung zu haben, könnte es sinnvoll sein, sie vorab auszuwählen.
Zum Beispiel sind nur Anfragen mit einer bestimmten Anzahl von Reaktionen, die das Interesse mehrerer Benutzer signalisieren, diejenigen, über die abgestimmt werden kann, oder Sie könnten sie nach Zeit begrenzen und sagen, dass die Abstimmung auf Themen aus einem bestimmten Zeitraum beschränkt ist, um die Favoriten innerhalb dieser Gruppe von Funktionen zu finden.
Sie könnten auch sagen: „Wir überarbeiten die Überprüfungswarteschlange. Welche Anfragen fallen Ihnen ein?“ Dann würden diese in eine Unterkategorie verschoben und abgestimmt werden.
Die Möglichkeit, 4 Stimmen über ~100 Themen zu verteilen, wäre proportional mehr, als die Möglichkeit, 10 Stimmen über alle offenen Funktions-Themen zu verteilen.
\n
↩︎
@sam, ich hatte auf das Gegenteil gehofft. Bieten Abstimmungen technisch etwas, das Likes nicht bieten? Ich bezweifle, dass jemand ein FR mag, das er nicht unterstützt.
Wenn Likes deaktiviert würden, wenn Abstimmungen aktiviert sind, würde das meiner Meinung nach “Intelligenz reduzieren”. Zum Vergleich: Dass Forgejo und GitLab keine Upvotes einschränken, könnte darauf hindeuten, dass es einen Wert darin gibt, sie als einfachen Unterstützungs- oder Nicht-Unterstützungsindikator zu haben.
Aus Neugierde habe ich mir heute Feature angesehen, es war interessant, diese gefilterten Ansichten zu vergleichen:\n- Gefilterte Ergebnisse für Kategorie:feature Status:open Reihenfolge:Likes-op\n- Gefilterte Ergebnisse für Kategorie:feature Status:open Reihenfolge:votes\n\nIch frage mich, was man mit einer Data Explorer-Abfrage machen könnte, die sowohl Stimmen (Votes) als auch Likes einbezieht…
\n\nAußerdem:\n[quote="Moin, post:30, topic:308402"]\nanstatt 378 Themen aus diesem Jahr zur Abstimmung zu haben, könnte es sinnvoll sein, sie vorab auszuwählen\n[/quote]\n\nAutomatisierungsgedanke: Vielleicht könnte ein „primärer“ Pool, der auf Likes basiert, Anfragen in den abstimmbaren Status überführen.\n\nGedanke zur manuellen Kuratierung: Gelegentlich wird eine Anfrage mit offensichtlichem Wert von Mitarbeitern unabhängig von den Stimmen aufgegriffen, sodass auf eine Weise bereits eine gewisse Kuratierung stattfindet. Aber vielleicht sollte alles einer schnellen Überprüfung durch die Mitarbeiter unterzogen werden?\n\nBeispiel zur Unterstützung: Ich habe 8 Funktionsanfragen zum Thema „Benutzer sollen ihre eigenen Themen schließen können“ gefunden – von 2014 bis 2025 – einige geschlossen, aber die meisten davon offen mit 0 Stimmen. Etwas funktioniert nicht gut, wenn dieselbe Anfrage wiederholt gestellt wird, während ältere Versionen unbeachtet und ohne Stimmen bleiben.\n\nWenn Benutzer nicht suchen – oder die Dialogfelder „Ihr Thema ist ähnlich…“ nicht sehen – bin ich mir nicht sicher, was sonst getan werden könnte, als dass anfängliche Anfragen einen Kontrollpunkt der Mitarbeiter erreichen:
wenn neu, Thema in eine Abstimmungskategorie verschieben;
wenn eine ähnliche Anfrage existiert, mit einem Link antworten.\n\nIch denke nur laut nach. Ich weiß, dass alles Ressourcen kostet…
Das Limit wäre in Ordnung, wenn das Team die Stimmen veröffentlichen würde, nachdem es eine Liste der abgestimmten Themen zusammengestellt hat. Vielleicht sollten die Stimmen vierteljährlich veröffentlicht werden. Das Update könnte sogar Details zu Funktionen enthalten, die das Team in die Roadmap aufgenommen hat, mit einem möglichen Zeitplan in Bezug auf die Priorität.
Ansonsten sind 24 wirklich nicht unbegrenzt, da einige Stimmen über ein Jahr und möglicherweise länger gebunden sind. Es ist auch mühsam, zu versuchen, Stimmen bei scheinbar toten Funktionen zu entfernen, die möglicherweise nicht einmal in Betracht gezogen werden.
Vielleicht wäre eine Idee, ab und zu eine Liste der Funktionen zu erstellen, die das Team ernsthaft in Betracht zieht, und eine Umfrage zu erstellen, über die die Leute abstimmen können, und dann die Dinge von dort aus zu aktualisieren. Die Themenabstimmung ist nicht schlecht, wenn es einen Veröffentlichungszyklus gibt. Wie dieser Zyklus aussehen sollte, ist etwas, das das Team besprechen und entscheiden muss.
[quote=“Heliosurge, post:33, topic:308402”]Das Limit wäre in Ordnung, wenn das Team die Abstimmungen veröffentlichen würde, nachdem es eine Liste der abgestimmten Themen zusammengestellt hat.
[/quote]
folge ich nicht, könnt ihr nicht über Dinge abstimmen lassen, die euch nicht mehr wichtig sind?
Das setzt voraus, dass diese zuvor abgestimmten Dinge umgesetzt wurden oder keine Bedeutung mehr haben.
Die Zusammenfassung von Funktionswünschen in einer Liste derjenigen, die das Team in Zukunft in Betracht zieht, und die Freigabe dieser Stimmen zur erneuten Nutzung ergibt meiner bescheidenen Meinung nach Sinn.
Warum überhaupt Themenabstimmungen verwenden? Wie Sie erwähnt haben, könnten die „Gefällt mir“-Angaben/Reaktionen anstelle einer Begrenzung auf eine bestimmte Anzahl von Stimmen verwendet werden. Die Verwendung einer bestimmten Reaktion wie
könnte ausreichen, um das Interesse an einer bestimmten #Feature-Anfrage einzuschätzen, da Sie ein Data Explorer-Skript in dieser Kategorie verwenden könnten, um die Top-Themen, möglicherweise im Op-Beitrag, mit den meisten dieser speziellen Reaktion zurückzugeben.
Im Gegensatz dazu fühlt sich die Begrenzung der Abstimmungen nicht so an, als würde sie irgendwohin führen, da es meiner Erfahrung nach keine direkten Updates zu dieser Kategorie gibt. Vielleicht gibt es von Zeit zu Zeit welche, und ich habe es vielleicht einfach nicht bemerkt.
Ich bin mir sicher, dass einige der neuen Funktionen, die eingeführt wurden, irgendwann einmal eine Funktionsanfrage waren.
Meiner bescheidenen Meinung nach könnten Themenabstimmungen besser für Wettbewerbe geeignet sein, bei denen über die Top X Themen abgestimmt wird, mit einem festgelegten Abschlussdatum für den Ankündigungstag der Top 3 Gewinner. Aber in dieser Kategorie fühlt es sich mehr wie ein Wettbewerb ohne klaren Abschluss an, bei dem man seine Stimmen hinterfragen muss.
Ich habe hier eine ganze Menge zum Prozess kommentiert, aber fairerweise gibt es viele Funktionsanfragen, die als #abgeschlossen markiert sind – Gefilterte Ergebnisse für Kategorie:Funktion Tag:abgeschlossen
Das abgeschlossene Tag hilft. Aber ich finde, wenn das Team mehr Interesse an Funktionswünschen einschätzen möchte. Die Begrenzung der Stimmen kann kontraproduktiv sein.
Wie Sam mit den verschiedenen Signalen wie „Gefällt mir“/Reaktionen erwähnt hat. (Eine bestimmte Reaktion auswählen) Oder sogar keine Stimmbegrenzung. Da nicht alle Ideen von Leuten gewählt/reagiert werden, da sie möglicherweise an einer bestimmten Idee nicht interessiert sind. Zum Beispiel gibt es, glaube ich, eine Anfrage zur Wahl eines Forumsteams.
Während dies in einigen Foren eine Idee/Option sein mag, möchten viele nicht, dass ein möglicher Beliebtheitswettbewerb darüber entscheidet, wer das Forum leitet.
Sie erhalten also immer noch Funktionen mit mehr Stimmen/Reaktionen, die das allgemeine Interesse der Community signalisieren, anstatt es auf eine festgelegte Anzahl zu beschränken, was eher dazu führt, dass sich das Interesse aufteilt und viel mehr Unentschieden entstehen, um es so auszudrücken.
Die Überprüfung des Tags hilft tatsächlich dabei, zu sehen, wie viel hinzugefügt wurde. Es fühlt sich nur zu einschränkend an, das Abstimmungsinteresse zu begrenzen. Sogar einige der abgeschlossenen Funktionen hatten minimale bis keine Stimmen. Zugegebenermaßen sind einfache, schnelle Erfolge natürlich gut.
Mein Traum wäre es, dass jeder seine eigenen, personalisierten, nach Priorität geordneten Ansichten von Funktionen hat, die wir dann durch verschiedene „Sichtweisen“ in verschiedenen kollektiven Ansichten zusammenfassen könnten.
Anstatt also bei allem nur eine binäre Abstimmung/Nicht-Abstimmung zu haben, könnte ich meine „Top 10“-Liste zusammenstellen und sie nach Präferenz ordnen. Sie könnten dasselbe tun. Und dann könnte ich Dinge tun wie „Zeige mir die Top-Ten-Liste für Leute, die letztes Jahr zu Meta gekommen sind“ oder „Zeige mir die Top-Ten-Liste für Leute, die auf unserem Starter-Plan gehostet werden“, usw.
In der Zwischenzeit habe ich einige andere Ideen, wie wir die Dinge hier etwas überschaubarer gestalten können, die mit Ideen zusammenhängen, wie wir einen offenen Fahrplan und ein Backlog im Allgemeinen verwalten. Diese beinhalten einige Änderungen daran, wie wir die Kategorien für Fehler (Bugs), Funktionen (Features) und UX verwalten, und wie wir offenere Ideenfindung von konkreteren Vorschlägen und/oder Spezifikationen für Dinge trennen, die wir entweder zu bearbeiten planen oder bei denen wir uns über Beiträge freuen würden.
Ich hoffe, bis Ende des Jahres etwas wie ein RFC (Request for Comments) hierzu zur Diskussion zusammenstellen zu können.