Lorawan-stack: Modèle de problème pour les questions

donc "l'action" serait que nous mettions à jour la documentation directement (si c'est le seul changement) faisant référence à ce problème et en ouvrons un autre si cela entraîne une demande de correction de bogue/de fonctionnalité ?

Exactement. Le résultat d'un problème de "question" devrait généralement être un changement dans notre documentation, ou un ajout à notre FAQ.

Je ne sais pas s'il est logique de copier-coller un problème "question" dans un problème "bug_report". Peut-être devrions-nous simplement ajouter les sections pertinentes dans les commentaires (ou modifier le problème) si nous décidons de transformer une question en rapport de bogue ou en fonctionnalité.

D'accord mais cela devrait également s'appliquer au forum et au mou.

Essentiellement, toutes les informations doivent être dans la documentation du repo, si certaines informations sont des références sur le forum, des problèmes ou du jeu, nous n'avons pas réussi à créer de documentation.
Question ou problème soulevé sur Slack, le forum doit compenser le changement dans la doc à moins qu'aucun effort n'ait été fait pour rechercher l'information.

Au lieu d'avoir une liste de "avez-vous regardé là-bas", j'ajouterais un lien vers une requête sur github / doc (une fois que la recherche est impl). La recherche d'informations dans les problèmes de github peut être fastidieuse et le forum ne devrait pas contenir d'informations/d'explications que le document n'a pas. Un lien vers une requête déjà établie (comme la recherche de bogues) vous aidera. L'ajout d'une section know bugs à la doc peut également être envisagé.

Si une question met en lumière un bogue, il appartient au développeur de le qualifier de bogue (et de modifier le problème en tant que rapport de bogue) ou d'ouvrir un autre problème si la seule partie de la question concerne un bogue.

Je suis tout à fait d'accord pour dire que nous devrions mieux surveiller le Forum et Slack et transformer les (bonnes) questions en améliorations de la documentation (au moins pour la catégorie v3 et le canal lorawan-stack ). @Sypheos, comment

L'objectif du " avez-vous regardé ici " était plus un filtre pour les personnes soumettant des problèmes avant de faire la moindre recherche. La section suivante est plus utile, nous pouvons demander à l'auteur du problème de créer un lien vers (ou de citer) les messages pertinents du forum, les messages slack, etc.

Je pense que c'est une bonne idée. Gardons la portée de ce problème et le modèle de problème vraiment une nouvelle question.

En ce qui concerne les améliorations de la documentation, c'est-à-dire les réponses informelles sur un forum et Slack que nous voulons faire partie de la documentation, nous pouvons envisager un modèle de problème de « demande de documentation » supplémentaire, ce qui est minime ; il décrit essentiellement le manque de documentation et le lien vers l'endroit où se trouvent actuellement les informations (c'est-à-dire un lien vers le forum/message Slack). Mais encore une fois, pour moi, hors de portée pour cette question.

Pour le modèle de question imo :
Qu'est-ce que vous cherchez / faire ?
Où as-tu regardé ?
_Ajoutez n'importe quelle page Web, problèmes, requête contre github, les docs, le forum sont les bienvenus_
Pourquoi n'était pas satisfaisant ?
_404 non trouvé est une réponse légitime_

Libellé : question

s'il n'y a pas de ressources pour répondre à la question, ouvrez un problème de « demande de documentation ».

Nous devons vraiment nous assurer que toutes les réponses se retrouvent dans la documentation, sinon les problèmes clos ici deviennent la base de connaissances V3, et nous devons éviter cela. Alors peut-être devrions-nous même ignorer le modèle « question » et passer directement à la « demande de documentation ».

De plus, lorsque l'utilisation de ce référentiel augmente, et que cela devient le lieu de prédilection pour poser des questions et que nous avons du mal à modérer cela (c'est-à-dire en pointant vers des documents et des problèmes de fermeture), nous pouvons le regretter à l'avenir. Notez que les référentiels plus importants comme VS Code indiquent que vous ne devriez pas poser de questions de manière assez agressive :

En bref, considérons ;

• Ne pas autoriser les questions du tout, uniquement les problèmes de "demande de documentation". Les questions sont toujours valables, mais seulement si elles ne sont effectivement pas documentées sinon ce n'est pas une demande de documentation valable et nous la fermons
• Questions directes aux docs (quand nous en avons) et aux forums

Les demandes de documentation sont en fait des "Questions" car ils cherchaient quelque chose mais ne pouvaient pas le trouver. Au début, ils ont une question qui a besoin d'une réponse.
Pour aller dans cette direction, il serait plus logique de simplement refuser toute demande de documentation et toute question via des problèmes sur github.

Si quelqu'un veut poser une question, il se rend sur slack ou sur le forum où quelqu'un de l'équipe principale ou de la modération peut transformer sa question en un problème de documentation PR/bug/demande de fonctionnalité.

Décision : nous allons utiliser https://github.com/TheThingsNetwork/lorawan-stack/issues/890#issuecomment -507324845. Modèle de question qui dirige vers le forum, et un modèle de demande de documentation