Lorawan-stack: Ausgabevorlage für Fragen

Die "Aktion" wäre also, dass wir die Dokumentation direkt aktualisieren (wenn dies die einzige Änderung ist), die auf dieses Problem verweist, und ein anderes öffnen, wenn dies zu einer Fehlerbehebungs-/Funktionsanforderung führt?

Exakt. Das Ergebnis eines "Frage"-Problems sollte normalerweise eine Änderung in unserer Dokumentation oder eine Ergänzung zu unseren FAQ sein.

Ich weiß nicht, ob es sinnvoll ist, ein "Frage"-Problem in ein "bug_report"-Problem zu kopieren. Vielleicht sollten wir einfach die relevanten Abschnitte in Kommentaren hinzufügen (oder das Problem bearbeiten), wenn wir uns entscheiden, eine Frage in einen Fehlerbericht oder eine Funktion zu verwandeln.

Zustimmen aber das sollte auch für das Forum gelten und faulenzen.

Im Wesentlichen sollten alle Informationen in der Repo-Dokumentation enthalten sein. Wenn einige Informationen Verweise auf das Forum, Probleme oder Lücken enthalten, haben wir es versäumt, eine Dokumentation zu erstellen.
Fragen oder Probleme, die in Slack aufgeworfen wurden, das Forum sollte die Änderungen im Dokument ausgleichen, es sei denn, es wurden keine Anstrengungen unternommen, um nach den Informationen zu suchen.

Anstatt eine Liste mit "Haben Sie dort nachgesehen" zu haben, würde ich einen Link zu einer Abfrage auf github / doc hinzufügen (sobald die Suche impl ist). Die Suche nach Informationen in Github-Problemen kann mühsam sein und das Forum sollte keine Informationen / Erklärungen enthalten, die das Dokument nicht hat. Ein Link zu einer bereits etablierten Abfrage (zB nach Fehlern suchen) hilft. Es ist auch vorstellbar, den Dokumenten einen Abschnitt über bekannte Fehler hinzuzufügen.

Wenn eine Frage einen Fehler aufdeckt, liegt es am Entwickler, ihn als Fehler zu qualifizieren (und den Fehler als Fehlerbericht zu bearbeiten) oder einen anderen Fehler zu öffnen, wenn der einzige Teil der Frage einen Fehler enthält.

Ich stimme voll und ganz zu, dass wir das Forum und Slack besser überwachen und (gute) Fragen in Dokumentationsverbesserungen umwandeln sollten (zumindest für die v3-Kategorie und den Lorawan-Stack-Kanal ). @Sypheos wie würden Sie das in der Praxis sehen?

Das Ziel von "Hast du hier nachgesehen" war eher ein Filter für Leute, die Probleme einreichen, bevor sie überhaupt suchen. Der nächste Abschnitt ist nützlicher, dort können wir den Einreicher des Problems bitten, auf relevante Forenbeiträge, Slack-Nachrichten usw. zu verlinken (oder diese zu zitieren).

Ich denke, das ist eine gute Idee. Lassen Sie uns den Umfang dieser Ausgabe und Ausgabevorlage wirklich eine neue Frage stellen.

Was Dokumentationsverbesserungen angeht, dh informelle Antworten in einem Forum und Slack, die wir als Teil der Dokumentation haben möchten, können wir eine zusätzliche "Dokumentationsanfrage"-Ausgabevorlage in Betracht ziehen, die minimal ist; es beschreibt im Wesentlichen die Dokumentationslücke und den Link, wo sich jetzt Informationen befinden (zB ein Link zum Forum/der Slack-Nachricht). Aber wieder für mich außerhalb des Rahmens für dieses Problem.

Für die Fragevorlage imo:
Was suchen / tun ?
Wo hast du gesucht?
_Fügen Sie alle Webseiten, Probleme, Abfragen gegen Github, die Dokumente und das Forum hinzu, sind Sie willkommen_
Warum war nicht zufriedenstellend?
_404 nicht gefunden ist eine legitime Antwort_

Label: Frage

Wenn keine Ressourcen zum Beantworten der Frage vorhanden sind, öffnen Sie eine "Dokumentationsanforderung".

Wir sollten wirklich sicherstellen, dass alle Antworten in der Dokumentation landen, sonst werden die geschlossenen Themen hier zur V3-Wissensdatenbank, und das sollten wir vermeiden. Vielleicht sollten wir also sogar die Vorlage "Frage" überspringen und direkt auf "Dokumentationsanforderung" gehen.

Auch wenn die Nutzung dieses Repositorys zunimmt und dies zu einer Anlaufstelle für Fragen wird und es uns schwer fällt, dies zu moderieren (dh auf Dokumente zu verweisen und Probleme zu schließen), werden wir dies in Zukunft möglicherweise bereuen. Beachten Sie, dass größere Repositorys wie VS Code kommunizieren, dass Sie nicht ganz aggressiv Fragen stellen sollten:

Lassen Sie uns kurz überlegen;

• Keine Fragen zulassen, nur "Dokumentationsanfrage"-Probleme. Fragen sind weiterhin gültig, aber nur, wenn sie tatsächlich nicht dokumentiert sind, ansonsten ist es keine gültige Dokumentationsanfrage und wir schließen sie
• Direkte Fragen an die Dokumente (sofern wir sie haben) und Foren

Dokumentationsanfragen sind in der Tat "Fragen", da sie nach etwas gesucht, es aber nicht gefunden haben. Am Anfang steht eine Frage, die einer Antwort bedarf.
Um in diese Richtung zu gehen, wäre es sinnvoller, einfach jede Dokumentationsanfrage und Fragen über Probleme auf github abzulehnen.

Wenn jemand eine Frage stellen möchte, geht er zu Slack oder zum Forum, wo jemand für das Kernteam oder die Moderation seine Frage in eine Dokumentations-PR / Bug- / Feature-Request-Problem umwandeln kann.

Entscheidung: Wir gehen mit https://github.com/TheThingsNetwork/lorawan-stack/issues/890#issuecomment -507324845. Fragenvorlage, die zum Forum führt, und eine Vorlage für eine Dokumentationsanfrage