diss
1.0.0
Después de publicar el proyecto a [email protected], IS me ha llamado la atención de que aquellos en la comunidad FOSS pueden tener preocupaciones sobre el uso de un sistema de desarrollo propietario como Github.
Dejaré este asi para fines heredados como un archivo de los esfuerzos de nuestra primera semana.
Las actualizaciones futuras estarán en la nueva casa del proyecto en Gitlab y el nuevo proyecto Wiki en Gitlab.
Le agradezco a todos por su interés en este proyecto y le dan la bienvenida a seguirnos en Gitlab. Trabajaré en la actualización de nuestro BOT IRC en el canal de desarrollo para admitir las notificaciones de Webhook del nuevo sistema. No actualizaré más esta página del proyecto.
Proyecto con el ambicioso objetivo de integrar sinérgicamente todos los recursos de apoyo de Debian y ofrecer una interfaz simple e intuitiva para los procedimientos de diagnóstico bien probados.
Esto de ninguna manera está destinado a reemplazar, y de hecho depende en gran medida de todos nuestros recursos existentes. La justificación aquí es que nuestro sistema está creciendo exponencialmente y somos "el sistema operativo universal", y que tenemos recursos de apoyo limitados y no todos saben cómo y en qué orden los usar todos correctamente, lo que resulta en muchos problemas bien conocidos y fácilmente observables.
El agotamiento del equipo de apoyo mediante el manejo de repetición, los problemas conocidos que ya hemos resuelto, teniendo que explicar nuestros procedimientos y políticas, y recopilar (a veces salen) información relevante para el problema en cuestión, etc.
Alienación del usuario a través de la falta de comprensión de los sistemas e interacción improductiva con los partidarios y demás. Ha sido una mentalidad bien documentada entre algunos de nuestros mejores partidarios, incluido que realmente no queremos ese tipo de usuarios sin experiencia porque se convertirán en un sorteo de nuestros recursos sin contribuir a nuestro proyecto. También es un hecho fácilmente observable que los desarrolladores y los usuarios más experimentados son a menudo las últimas personas en encontrar errores y problemas porque no solo tienden a ser menos aventureros para probar un software diferente porque ya saben lo que les gusta y lo usan, y lo usan de la manera en que se pretendía usarse. Se necesita a alguien inexperto para probar todo tipo de opciones y usar las cosas de manera que descubra errores oscuras. Este es un producto valioso para tener masas de usuarios inexpertos que revisan nuestra base de software en constante crecimiento, descubriendo problemas que de otro modo extrañarían. Sin embargo, debemos asegurarnos de que la retroalimentación que obtenemos de este valioso recurso sea significativo y termina en el lugar correcto sin que ocurra el problema antes mencionado, por lo que necesitamos un tipo de filtro que satisface sus necesidades y la nuestra.
También debemos asegurarnos de que se utilice todo el esfuerzo hacia esos dos problemas. Es decir, no podemos seguir que los usuarios vengan a nosotros con el interés propio de resolver un problema, y ese esfuerzo subutilizado porque no estaba bien documentado. Algunos usuarios regresan y comparten soluciones a los problemas, a veces terminamos creando un factoid al respecto, a veces termina siendo una página de wiki, informe de errores, etc. pero la mayoría de las veces ese no es el caso. Además, no siempre sabemos que esto se ha hecho cuando el problema vuelve a aparecer. Nuestro sistema actual se basa en nuestros seguidores para recordar estas cosas, y cuando aquellas personas que lo recuerdan no están mirando en ese momento, podemos terminar recurriendo al problema #2 y alienar a nuestros usuarios, o no obtener el problema documentado o resuelto en absoluto, incluso de manera ineficaz.
Cliente/Frontend (Readline, Cursas, GTK, QT), Diagnóstico (archivos de árbol de diagnóstico firmados), BOT (IRC), servidor (Tracker)
El cliente será un asistente de estilo Reportbug que permitirá a un usuario seleccionar un programa (en niveles de habilidad más bajos, usar nombres genéricos como "Filemanager" y hacer que detecte automáticamente el nombre del programa real o use una fuction de GRAB donde el usuario puede hacer clic en una ventana y obtener el comando) e ingresar una descripción de su problema y debe tener varias clases de problemas (red, sonido, sonido, construir errores, problemas del sistema de paquete, problemas de paquete) e opcionalmente una dirección cc (la dirección del correo electrónico (el correo electrónico puede ser más que las clases de los problemas. Una ID de problema y un correo electrónico se recuperaron al usuario para obtener privacidad, con la capacidad de que el usuario entonces opta por no recibir más CC enviando un correo electrónico al rastreador con la identificación que le indica que se detenga).
El primer nivel usará diagnósticos para realizar pruebas simples y solicitar más preguntas, recopilar información y compilar un informe/inicio de sesión sobre el problema.
Es muy probable que los registros sean analizados/serializados/esterilizados para eliminar o sustituir datos personales como IPS, IDS MAC, nombres de usuario, tal vez incluso los nombres de ruta/archivo y reemplazarlos con los genéricos como 1.2.3.4 o 12: 34: 56: 78: 90 o tal.
Entonces, si el problema no se puede resolver a través de procesos de diagnóstico automáticos que identifican el problema basado en soluciones simples bien conocidas, desgastadas y probadas en batalla, el cliente en el segundo nivel hará exactamente como lo hace ReportBug y los informes de errores de búsqueda (y/o publicaciones de foro/wiki) y las mostrará al usuario de las dato de conocimiento existentes que ya tenemos.
If the issue remains unsolved it will then in the 3rd tier facilitate forwarding the issue to the issue tracker and giving it an ID number, then forwarding it to our support tools (IRC/Mailing lists) that we already have, from within the client itself, and if IRC is used this will be facilitated by the bot issuing a " Issue #98153: no sound in pianobar" in the channel notifying our supporters of an open issue, and if the El usuario no recibe una solución o decide irse, el problema puede permanecer abierto y/o reenviar a las listas de correo y pueden hacer un seguimiento visitando el sitio web de Tracker con su número de identificación o recibiendo notificaciones por correo electrónico sobre el problema del rastreador.
Si el problema aún no se resuelve, se puede reenviar al 4to nivel, que serían cosas como el BTS (presentando el informe en el BTS, como se determina que es un problema de software por los partidarios), o posiblemente aguas arriba.
Los archivos de árbol de diagnóstico posiblemente pueden ser una especie de XML o tal, y deberán ser firmados y verificados, el árbol de diagnóstico central será muy parecido a lo que hace ReportBug, solo recopilará cierta información preliminar sobre el sistema y verificará que su lugar, lo que se trata de una versión, un arque de las fuentes, por ejemplo, los otros, etc. Otros que se desarrollarán y se mantendrán a lo largo del tiempo que será específico para las categorías mencionadas anteriormente, un sistema de sonido de Sound, un archivo, un archivo de Sound para que se realicen, etc. Al igual que realizar una prueba de sonido y pregúntele al usuario si escuchó el sonido, revise su mezclador, pídales que revisen sus conexiones, etc.
Estos archivos de árbol de diagnóstico también facilitarán más información de recopilación de información mediante la ejecución de comandos que recopilen más información específica del tipo de problema en cuestión. Estos comandos deberán mostrarse y explicarse, y verificarse por el usuario, así como los informes/registros/salida se muestran y (opcionalmente) serializados/esterilizados para eliminar cualquier información personal. Estos diagnósticos deberán ser firmados y calificados, y el rastreador de problemas facilitará hacerlo de la misma manera que lo hace el sistema de calificación de cualquier buen foro, solo utilizando firmas de GPG, y la calificación de una solución no solo hará que el cliente firme ese diagnóstico aumentando su confianza, sino que también aumenta la confianza de los partidarios que contribuyeron a aquellos que contribuyeron a las partes del diagnóstico.
Siempre que sea posible, se deben emplear todos los mecanismos de seguridad disponibles desde cosas como las croots hasta los mecanismos de seguridad basados en el núcleo para bloquear las cosas que hacen los diagnósticos, y deben ser simples y poco tradicionales posible. No estamos buscando crear una herramienta de diagnóstico sensible, solo unas pocas verificaciones simples para problemas de configuración conocidos, pruebas simples y compilar datos para un mayor soporte.
El BOT IRC no solo debe ser un conducto/proxy para el usuario de los canales de soporte de IRC (para mucho debate) tal vez hablar en nombre del usuario en el canal con una identificación de usuario generada o número de problema, que no solo nos permitirá garantizar que el usuario solo vea las cosas relacionadas con su problema, sino que el rastreador de problemas conoce qué respuestas de soporte pertenece a la cuestión posterior para la documentación posterior y la solución existentes como las herramientas existentes como las herramientas existentes como las herramientas existentes como las herramientas existentes como el rastreador de los problemas. semejante. Esto se puede hacer de varias maneras, y los scripts del cliente IRC se pueden escribir o las características del cliente utilizadas para completar estas ID como un Nick normal, o tal vez un seguidor puede enviarle un mensaje al bot para que "inicie sesión" a un problema para que hablar con el bot envíe información al usuario con el que se le inicia.
El BOT también facilitará el acceso al informe compilado con información recopilada por el diagnóstico y enviado por el usuario, elminando toda la charla sobre ejecutar comandos muy comunes y usar pastebins y tal. Además, el bot podría comportarse como una interfaz cliente para abrir un nuevo problema en el rastreador (posiblemente incluso si se considera necesario, solo por un seguidor conocido y registrado) por alguien en un cliente IRC independiente normal.
En resumen, el BOT es el pegamento que une a los canales de soporte IRC, y se debe tener cuidado para asegurarse de que la información termine en el canal correcto, dependiendo del lenguaje preferido del usuario, la rama de Debian, y quizás incluso qué paquete o catergory que tengan, ya que tenemos canales específicos para las cosas específicas (por lo tanto, eliminamos que las personas se referían a otros canales y cualquier paquete que tengan que tener sentimientos negativos o que tengamos sentimientos negativos sobre nosotros.
El rastreador contendrá metadatos con respecto al problema, generará un identificador de problema, realizará un seguimiento de cualquier dirección de CC que el usuario proporcione y dónde están los informes (paste.debian.net, lo más probable), y el estado del problema, así como cualquier foro, lista de correo, BT u otras cosas que el cliente o los partidarios provocan que se vinculen a este problema. No debería ser una especie de nuevo wiki o foro en sí mismo, solo una frontend que vincula y la pegar todo junto con los metadatos sobre el problema. Debe tener una interfaz web similar al BTS.
Los problemas y los errores son diferentes; Los errores son problemas reales en el software, donde los problemas suelen ser solo Pebcak o tal. Es por eso que es necesario crear un nuevo rastreador, porque este solo está sirviendo para rastrear el problema y asegurarse de que llegue al lugar de descanso final correcto. El rastreador proporcionará al Bot y al cliente la información necesaria para hacer un Factoid en nuestros bots de información existentes, presentar un informe de errores o emitir un correo electrónico a las listas de correo, y servir como un lugar donde cualquier parte interesada puede descubrir cuál de estas cosas ha ocurrido y dónde encontrarlas. No es un reemplazo, sino un envoltorio de todos nuestros sistemas existentes. Es el pegamento el que une todos los componentes de los SAS, incluidos todos los que ya tenemos.
Se ha sugerido muchas veces que simplemente mejoramos los sistemas existentes, y eso es parte de esto, pero no es en lugar de esto. Eso todavía tendría el problema del problema #2 alienando a los usuarios porque necesitarían saber y cómo usar esas cosas. Este sería un software en el sistema operativo en sí que integra y facilita el uso de todo eso de una manera intuitiva que no requiere un año o más de política y práctica de aprendizaje.
Con respecto a la mejora de los sistemas existentes, este proyecto y sus contribuyentes buscarán unificar el registro en todos y cada uno de los sistemas de soporte de Debian que requieran el registro y trabajar con los equipos actuales de esos sistemas para integrarlos de manera sinérgica.
Además, los sistemas existentes se pueden usar/adaptar en la descreción de los desarrolladores actuales que trabajan en otras áreas, por ejemplo, el BTS y el rastreador pueden ser uno y el mismo, y estos "problemas" pueden ser una clase mucho más baja de error que el mantenedor no se preocupa, y el informe de informes se puede extender para incluir estas otras características, y un bot de IRC existente puede ser bifurerado y modificado para agregar la funcionalidad necesaria. Este no es solo un proyecto con el objetivo de crear una sola nueva pieza de software, sino para adaptar todo lo que tenemos ahora para servirnos mejor en el futuro.
Necesitamos programadores. Aquellos expertos en Python, ya que parece muy adecuado para estas tareas, fáciles de codificar y lo suficientemente potentes y flexibles como para desarrollar las cosas que necesitamos con menos dependencias fuera del sistema base. Aquellos expertos en sistemas y servicios basados en la confianza, firmas de GPG, etc. aquellos con experiencia en programación GUI/frontend. Aquellos familiarizados con el proceso de desarrollo de Debian y todas las preocupaciones de los usuarios y desarrolladores por igual. Aquellos que pueden programar pilas de redes de clientes/servidores utilizando sockets, HTTP, protocolos de correo electrónico, etc. Aquellos que puedan desarrollar una API robusta para los sistemas de soporte Debian para comunicarse de manera efectiva, lo que requerirá el conocimiento de la integración de aplicaciones dentro y fuera de la web.
Necesitamos aportes y planificación en torno a nuestros sistemas existentes, el esfuerzo de los equipos existentes y la ayuda para que incorporen un sistema de credencial de inicio de sesión de Debian uniforme que funcione en todos los sitios y servicios de Debian.
Necesitamos personas que trabajen en la documentación e interactuación con la presencia en la web de este proyecto, manteniendo los objetivos de información y proyectos de estado y tan claramente definidos.
Este proyecto acaba de comenzar en las primeras horas de la mañana del viernes 13 de octubre de 2017, alrededor de las 2 de la mañana de EE. UU./EST. Al momento de escribir esto, ni siquiera tenemos 24 horas, y ya tenemos media docena de personas que salen en el canal y respuestas en varios foros. Todos estamos fideos en este punto, lanzando ideas e intentando tomar decisiones preliminares cuidadosamente que darán forma al proyecto y su diseño.
El primer objetivo aquí es establecer una presencia en la web firme con un wiki y tal que diagrama la anatomía de este sistema integrado y el progreso de la misma, para que las personas puedan entender de dónde vamos, a dónde vamos y cuán avanzados estamos.
El segundo objetivo aquí es desarrollar una API que definirá las características y las comunicaciones de este sistema, y no soy un programador muy experimentado, pero lo he visto hecho durante décadas, que a veces tienes que hacer que algo (una herramienta) haga algo más, y en este caso creo que comenzar a trabajar en la interfaz del cliente, particularmente la interfaz de la GUI se desarrollará inherentemente a la API. Y al principio sin un rastreador de problemas, los problemas no serán persistentes, será simplemente un cliente que habla con un bot rudimentario que probablemente vive en nuestro canal de desarrollo.
Debe enfatizarse que esto no es algo que queramos expulsar e implementar rápidamente, queremos obtener algún marco de trabajo y realizar pruebas alfa extensas fuera de los canales normales, inicialmente sin ninguna modificación a los servicios existentes para ayudar a facilitar la integración, ya que la API aún no está allí. Una vez que tenemos componentes de trabajo e interés de un mantenedor y aquellos que ya están dentro del Círculo de Desarrollador de Debian, queremos comenzar una fase de prueba beta para su uso solo en pruebas de no producción/sistemas inestables. Una vez que hay confianza en la implementación de mecanismos de confianza seguros para los diagnósticos, el sistema puede ser empaquetado para SID y, con suerte, en un futuro lanzamiento estable de Debian. Los archivos de diagnóstico probablemente utilizarán algún tipo de repositorio que pueda permitirles desarrollarse con el tiempo e implementarse en el cliente sin esperar un nuevo ciclo de lanzamiento de Debian, en función de una prueba rígida separada y el proceso de firma/verificación.
A largo plazo, nos gustaría ver que Debian Installer tenga una determinación de habilidades más sólida como su primer paso, con algo más que un modo de instalación normal/experto, y este cliente de soporte está instalado automáticamente de forma predeterminada en sistemas que no seleccionan niveles avanzados o de expertos. Nos gustaría ver a todos nuestros seguidores participando no solo en el soporte de libre rango, sino también registrándonos en un sistema basado en la confianza y utilizando firmas de GPG, para que nuestra base de conocimiento pueda ser de mayor calidad y más confiable.
Diss wiki
Hilo de reddit
Foros de Debian
Hilo de la lista de correo de Debian-Project
Hilo de la lista de correo de Debian-Devel
Hilo de la lista de correo de user de Debian
Publicación relacionada de la lista de correo de Debian-Project en marzo de 2017
