Lorawan-stack: Plantilla de emisión para preguntas

Entonces, ¿la "acción" sería que actualicemos la documentación directamente (si ese es el único cambio) que hace referencia a este problema y abramos otro si esto resulta en una solicitud de función/corrección de errores?

Exactamente. El resultado de un problema de "pregunta" generalmente debería ser un cambio en nuestra documentación o una adición a nuestras Preguntas frecuentes.

No sé si tiene sentido copiar y pegar un problema de "pregunta" en un problema de "informe_error". Tal vez deberíamos simplemente agregar las secciones relevantes en los comentarios (o editar el problema) si decidimos convertir una pregunta en un informe de error o una función.

De acuerdo, pero eso también debería aplicarse al foro y la holgura.

En esencia, toda la información debe estar en la documentación del repositorio, si alguna información es una referencia en el foro, los problemas o la holgura, entonces no pudimos hacer una documentación.
Pregunta o problema planteado en Slack, el foro debe compensar el cambio en el documento a menos que no se haya hecho ningún esfuerzo para buscar la información.

En lugar de tener una lista de "miraste allí", agregaría un enlace a una consulta en github/doc (una vez que la búsqueda sea impl). Buscar información en problemas de github puede ser tedioso y el foro no debe contener información/explicación que el documento no tenga. Un enlace a una consulta ya establecida (como buscar errores) ayudará. También se puede considerar agregar una sección de errores conocidos a los documentos.

Si una pregunta aclara un error, depende del desarrollador calificarlo como un error (y editar el problema como un informe de error) o abrir otro problema si la única parte de la pregunta implica un error.

Estoy completamente de acuerdo en que deberíamos monitorear mejor el Foro y Slack y convertir (buenas) preguntas en mejoras de documentación (al menos para la categoría v3 y el canal lorawan-stack ). @Sypheos, ¿cómo

El objetivo de "ha mirado aquí" era más un filtro para las personas que envían problemas antes de realizar cualquier búsqueda. La siguiente sección es más útil, allí podemos pedirle al remitente del problema que enlace (o cite) publicaciones relevantes del foro, mensajes de holgura, etc.

Creo que es una buena idea. Mantengamos el alcance de este problema y la plantilla de problema realmente como una pregunta nueva.

En cuanto a las mejoras en la documentación, es decir, respuestas informales en un foro y Slack de que queremos parte de la documentación, podemos considerar una plantilla de problema de "solicitud de documentación" adicional, que es mínima; básicamente describe la brecha en la documentación y el enlace a donde se encuentra la información ahora (es decir, un enlace al foro/mensaje de Slack). Pero de nuevo, para mí, fuera del alcance de este tema.

Para la plantilla de pregunta imo:
¿Qué está buscando/que hacer?
¿Dónde miraste?
_Agregue cualquier página web, problemas, consulta contra github, los documentos, el foro son bienvenidos_
¿Por qué no fue satisfactorio?
_404 no encontrado es una respuesta legítima_

Etiqueta: pregunta

si no hay recursos para responder a la pregunta, abra un tema de "solicitud de documentación".

Realmente deberíamos asegurarnos de que las respuestas terminen en la documentación, de lo contrario, los problemas cerrados aquí se convierten en la base de conocimiento de V3, y debemos evitar eso. Entonces, tal vez deberíamos omitir la plantilla de "pregunta" e ir directamente a "solicitud de documentación".

Además, cuando el uso de este repositorio crezca, y este termine siendo el lugar al que acudir para hacer preguntas y tengamos dificultades para moderar eso (es decir, señalar documentos y cerrar problemas), es posible que lo lamentemos en el futuro. Tenga en cuenta que los repositorios más grandes como VS Code comunican que no debe hacer preguntas de manera bastante agresiva:

En resumen, consideremos;

• No se permiten preguntas en absoluto, solo cuestiones de "solicitud de documentación". Las preguntas siguen siendo válidas, pero solo si no están documentadas; de lo contrario, no es una solicitud de documentación válida y la cerramos.
• Preguntas directas a los documentos (cuando los tengamos) y foros

La solicitud de documentación son, de hecho, "Preguntas", ya que estaban buscando algo pero no pudieron encontrarlo. Al principio tienen una pregunta que necesita una respuesta.
Para ir en esa dirección, tendría más sentido simplemente denegar cualquier solicitud de documentación y preguntas a través de problemas en github.

Si alguien quiere hacer una pregunta, debe ir a Slack o al foro donde alguien del equipo central o moderador puede convertir su pregunta en una documentación PR / problema de error / problema de solicitud de función.

Decisión: Iremos con https://github.com/TheThingsNetwork/lorawan-stack/issues/890#issuecomment -507324845. Plantilla de pregunta que dirige al foro y una plantilla de solicitud de documentación