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 ursprünglichen Beitrag verschoben, da es sich richtig anfühlt, hier weiter über die Abstimmung für Contribute > Feature zu sprechen.
Ich mag die Idee von Grenzen, aber ich denke auch, dass es so viele offene Feature-Anfragen gibt, dass es unfair erscheint, eine sehr niedrige Grenze festzulegen. Ich fühle mich dadurch selbst eingeschränkt! Stimmen sind auch ein Signal, und indem wir den Menschen nicht erlauben, abzustimmen, entziehen wir dem Product Team dieses Signal.
Ich bin geneigt, die Grenzen in der folgenden Weise zu erhöhen. Was denkt ihr?
| 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 strikte Rationierung der wertvollen Stimmen zu begrenzten Informationen führt. Die Stimmzahlen scheinen im Allgemeinen im Verhältnis zur Anzahl der Nutzer hier niedrig zu sein. Viele Vorschläge für neue Funktionen haben mehr „Gefällt mir“-Angaben als Stimmen, aber ich vermute, dass nur die Stimmen wahrgenommen werden.
Dauerhaft ohne Stimmen dazustehen und ständig priorisieren und opfern zu müssen, um für etwas Neues abzustimmen, ist eine erhebliche Hürde. Ich prüfe meine bestehenden Stimmen, um zu sehen, wie ich Stimmen freimachen kann … doch keine der Anfragen ist unwürdig. Sie sind einfach vom Feed abgerutscht und in Vergessenheit geraten.
Soll ich sie aufgeben?
Sollte ich meine Favoriten mit einem Kommentar wieder nach oben bringen? Nach dem Abstimmen für eine Funktion wirkt ein Kommentar wie „Ja, gute Idee!“ wie überflüssiger Ballast.
Gute Ideen liegen mit ein oder zwei Stimmen da. Entdecken die Leute sie nicht, sind sie nicht interessiert oder … sind sie einfach ohne Stimmen? ![]()
Eine Erhöhung der Limits würde nicht eine Menge Codierung erfordern, und es fühlt sich an, als würde es helfen – aber ich denke auch daran, wie das Verbreitern einer Straße, um den Verkehr zu reduzieren, nur mehr Verkehr anlockt und man wieder am Ausgangspunkt landet.
Hier nur ein paar Ideen auf die Schnelle … einige funktionalen Änderungen, die viel Codierung erfordern, als Alternativen zu einem starren Limit:
- Eine bestimmte Anzahl von Stimmen pro Monat je nach Vertrauenslevel (TL) zuweisen. (Am „Stimm-Tag“ gibt es eine Flut an Aktivitäten, wenn die Nutzer Contribute > Feature besuchen und offene Punkte bewerten …)
… oder, wie heliosurge erwähnt hat, schließlich Stimmen wieder freigeben:
- Eine verbrauchte Stimme nach einer festgelegten Zeit freigeben, oder
- Das Personal prüft veraltete Funktionsanfragen fortlaufend und entweder a.) bringt das Thema erneut zur Diskussion, oder b.) kommentiert mit „Keine Pläne zur Bearbeitung“ und gibt die Stimmen frei.
… In beiden Fällen bleiben die abgegebenen Stimmen erhalten, und Nutzer können ihre Stimmenzuweisung nicht überschreiten, indem sie diese Themen erneut abstimmen.
(Einfach gesagt. Das ist wahrscheinlich eine Menge Codierung
)
@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.
Ich habe heute aus Neugier mal in Contribute > Feature reingeschaut und es war interessant, diese gefilterten Ansichten zu vergleichen:
- Gefilterte Ergebnisse für Kategorie:Feature Status:offen Sortierung:Likes-op
- Gefilterte Ergebnisse für Kategorie:Feature Status:offen Sortierung:Votes
Ich frage mich, was man mit einem Data-Explorer-Abfrage machen könnte, die sowohl Votes als auch Likes einbezieht… ![]()
Außerdem:
Gedanke zur Automatisierung: Vielleicht könnte ein „primärer“ Pool, der auf Likes basiert, Anträge in den Status „abstimmbar“ hochstufen.
Gedanke zur manuellen Kuratierung: Gelegentlich greifen Mitarbeiter:innen einen Antrag mit offensichtlicher Relevanz auf, unabhängig von der Anzahl der Stimmen. In gewisser Weise findet also bereits eine Kuratierung statt. Aber vielleicht sollte jeder Antrag einer kurzen Prüfung durch das Team unterzogen werden?
Beispiel dazu: Ich habe 8 Feature-Anfragen zum Thema „Nutzer sollen ihre eigenen Themen schließen können“ gefunden – von 2014 bis 2025 – einige davon wurden geschlossen, aber die meisten waren offen und hatten 0 Stimmen. Wenn dieselbe Anfrage immer wieder gestellt wird, während ältere Versionen unbemerkt und ungewählt bleiben, stimmt da etwas nicht.
Wenn Nutzer:innen nicht suchen – oder die Dialoge „Dein Thema ist ähnlich…“ nicht sehen –, bin ich nicht sicher, was man sonst tun könnte, außer sicherzustellen, dass initiale Anträge eine Checkpoint-Prüfung durch das Team durchlaufen:
wenn neu, verschiebe das Thema in eine Abstimmungskategorie;
wenn ein ähnlicher Antrag existiert, antworte mit einem Link.
Einfach laut nachdenkend. 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 bereits implementiert wurden oder keine Bedeutung mehr haben.
Es ergibt meiner Meinung nach Sinn, Feature-Anfragen in einer Liste derjenigen zusammenzufassen, die das Team in Zukunft hinzufügen möchte, und diese Abstimmungen erneut nutzbar zu machen.
Warum überhaupt Themenabstimmungen verwenden? Wie Sie erwähnt haben, könnten Likes/Reaktionen anstelle der begrenzten Anzahl an Stimmen verwendet werden. Die Verwendung einer bestimmten Reaktion wie
könnte ausreichend sein, um das Interesse an einer bestimmten #contribute:feature-Anfrage einzuschätzen, da Sie ein Data-Explorer-Skript in dieser Kategorie verwenden könnten, um die Top-Themen zurückzugeben, möglicherweise im Eröffnungsposting mit den meisten dieser bestimmten Reaktionen.
Im Gegensatz dazu scheint die Begrenzung der Abstimmung, die sich meiner Erfahrung nach wirklich nirgendwohin entwickelt, nicht sinnvoll, da es in dieser Kategorie keine direkten Updates dazu gibt. Es könnte ab und zu welche geben, und ich habe sie vielleicht einfach nicht bemerkt.
Ich bin mir sicher, dass einige der neu eingeführten Funktionen früher einmal eine Feature-Anfrage waren.
Meiner Meinung nach wären Themenabstimmungen besser für Wettbewerbe geeignet, bei denen die Top-X-Themen mit einem festgelegten Stichtag abgestimmt werden, um am Ankündigungstag die Top-3-Sieger bekannt zu geben. Aber in dieser Kategorie eingesetzt, fühlt es sich eher nach einem Wettbewerb ohne klare Schlussfolgerung an, bei dem man die eigenen Stimmen immer wieder 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.