Partkeepr: Meta: demasiados problemas abiertos

así que básicamente creamos un "retraso" de facto...
@Drachenkaetzchen, ¿está abierto a agregar un par de nosotros al proyecto para que podamos poner algo de orden en los problemas?

así que básicamente creamos un "retraso" de facto...

Algo así como. Pero, sí, esta es la idea básica.

@Drachenkaetzchen, ¿está abierto a agregar un par de nosotros al proyecto para que podamos poner algo de orden en los problemas?

Estaría dispuesto a ayudar aquí, si lo desea.

Hola chicos, esta es una muy buena idea y también la discutimos en IRC.

Recientemente obtuve acceso a github y veré la posibilidad de agregar más personas para ayudar con el lado organizativo para manejar los problemas y agradezco su oferta para ayudar con esto.
(si debido a limitaciones de tiempo lo olvido, no sea tímido para darme un toque al respecto)

Ok, @christianlupus, te he agregado como miembro de Triage a este repositorio.
@baradhili, ¿también te interesa ayudar con esto?

Aquí se describen las capacidades para esto: https://help.github.com/en/github/setting-up-and-managing-organizations-and-teams/repository-permission-levels-for-an-organization

Eventualmente, por supuesto, también agregaremos más personas con código de acceso. Por ahora, intentemos centrarnos un poco en la organización de los problemas.

@dromer sí por favor

@dromer Gracias por el complemento.

Una primera sugerencia es agregar una etiqueta needs-triage y configurar una regla para colocar cada nuevo número y relaciones públicas en esta etiqueta.
Motivo: El reportero ve que se necesita/se va a realizar una clasificación. Además, podemos ordenar (más adelante) estos problemas. Tal vez deberíamos considerar colocar cada problema bajo esta etiqueta para ver qué se ha hecho ya y qué necesita atención.

Y adicional: también sugiero las siguientes etiquetas:

• meta : se usa para problemas no relacionados con el código en sí, sino con el repositorio, la wiki, los estándares de programación y similares.
• help-requested : se usa para indicar que un problema está buscando ayuda durante la configuración, el uso, etc. Esto podría ser mejor enviarlo a un foro que mantenerlo como un problema aquí en github.

Suena bien... aunque sugeriría que no pongamos todo por debajo de needs-triage porque simplemente terminaremos donde estamos ahora :)... También sugeriría backlog , next-release y roadmap una vez que tengamos las cosas bajo revisión

Como comencé a categorizar algunos problemas ahora, me resultó difícil ponerles etiquetas a menos que estén claramente definidos (al menos para una parte de ellos).

@christianlupus, ¿cómo desea coordinar el triaje? estoy en UTC+8

@christianlupus Parece que podríamos necesitar otra etiqueta "mover-a-wiki"

@christianlupus, ¿cómo desea coordinar el triaje? estoy en UTC+8

@baradhili Estoy en UTC+1 (Berlín).
Le estaba dando a algunos problemas algunas etiquetas y un hito cuando correspondía. Sin embargo, ya es hora de que me ponga a trabajar. Así que haré una pausa por ahora.

¿Tiene alguna buena sugerencia sobre la coordinación? ¿Una persona por la mañana una persona por la noche para evitar colisiones? ¿Cuál es tu horario preferido para trabajar en él?

Como no sé en qué ciudad vive, tomé una al azar de la zona horaria nombrada: Aquí puede obtener una descripción general rápida para administrar el cambio de hora. Es posible que desee adoptar a su ciudad.

@christianlupus Parece que podríamos necesitar otra etiqueta "mover-a-wiki"

Sí, ese parece ser el caso.

@christianlupus Estoy trabajando en problemas antiguos con etiquetas bug en este momento... Creo que puedo dedicar una hora alrededor de las 8 o las 9 a. Estoy en Perth. Probablemente queramos marcar problemas que son complejos con algún tipo de etiqueta para que el otro pueda echar un vistazo y dar una opinión.

@dromer si le damos una lista de nuevas etiquetas, ¿puede agregarlas?

Oh, ¿es esto algo que necesito hacer?

Házmelo saber y veré si agrego algunos más.

@christianlupus Estoy trabajando en problemas antiguos con etiquetas bug en este momento... Creo que puedo dedicar una hora alrededor de las 8 o las 9 a. Estoy en Perth -

Bien, esto depende completamente de ti. Gracias por ayudar aquí. Estoy trabajando en los problemas no etiquetados por ahora, por lo que no estamos chocando.

probablemente queramos marcar problemas que son complejos con algún tipo de etiqueta para que el otro pueda echar un vistazo y dar una opinión.

Sí, creo que es una buena idea. ¿Qué tal complex-triage ?

Oh, ¿es esto algo que necesito hacer?

Házmelo saber y veré si agrego algunos más.

Solo podemos adjuntar etiquetas e hitos a los problemas. Pero no podemos añadir nuevas etiquetas a la lista de válidas. Entonces, sí, le pediríamos que agregue las etiquetas relevantes.

@baradhili Entonces, para no tener esta lista de nuevas etiquetas (

• meta
• help-requested
• move-to-wiki
• complex-triage

Acerca de las etiquetas oportunas ( backlog , roadmap , next-release ) Creo que esto se capta mejor por hitos, ¿no crees? Además, esto debe coordinarse con cualquier persona que proporcione el código para el repositorio.

Actualizaré este comentario tan pronto como surjan las necesidades de nuevas etiquetas. ¿Estás de acuerdo con eso? En caso afirmativo, siéntase libre de preguntarle a dromer al respecto.

@dromer
¿Podríamos tener las siguientes etiquetas configuradas?

• meta
• help-requested
• move-to-wiki
• complex-triage
• security-issue

Gracias

@baradhili Traté de organizar un poco las etiquetas en un archivo MD . Te agregué como colaborador para que puedas editar el archivo.

¿Estás de acuerdo con las definiciones en la medida en que las escribí?

¡Todo está bien!¡documentación!

El martes 14 de enero de 2020 a las 19:36, Christian [email protected] escribió:

@baradhili https://github.com/baradhili Traté de organizar las etiquetas
en un archivo MD
https://github.com/christianlupus/Test-PK-Pages/wiki/Issue-Labels a
un poco. Te agregué como colaborador para que puedas editar el archivo.

¿Estás de acuerdo con las definiciones en la medida en que las escribí?

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/partkeepr/PartKeepr/issues/1066?email_source=notifications&email_token=AAFC2FCNL4V3QXSEUTKI6HTQ5WPTFA5CNFSM4KF76JRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEI4JJYQ#issuecomment4
o darse de baja
https://github.com/notifications/unsubscribe-auth/AAFC2FEBIIB6JH6OJENT7GLQ5WPTFANNCNFSM4KF76JRA
.

--
bret watson
Director
TI Interim Management Pty Ltd T/A TICM
Móvil: +61 (0)41 33 03 840
Correo electrónico:[email protected]
"El contenido de esta transmisión de correo electrónico está destinado únicamente a la persona nombrada
destinatario (s), puede ser confidencial y puede ser privilegiado o de otra manera
protegida de la divulgación en el interés público. El uso, reproducción,
divulgación o distribución del contenido de esta transmisión de correo electrónico por
cualquier persona que no sea el (los) destinatario(s) nombrado(s) está prohibido. Si no eres
un destinatario designado, notifique al remitente de inmediato".

build system claramente tiene que ver con el ci/cd (ver mis 2 PR) así que lo mantendría.

Agregaré su lista @baradhili y espero que al menos puedan seguir adelante.
Por ahora creo que está bien tener 'demasiadas' etiquetas que tener 'muy pocas'. Siempre podemos eliminar/ignorar ciertas etiquetas.

¿Algún color en particular que quieras asociar con ellos? :)

Ok, demasiado tarde, opté por los colores predeterminados por ahora: D

@dromer ¿Podríamos tener un hito para 1.5.0?

@christianlupus Voy a usar 1 - Ready para las cosas que parecen/se dice que están arregladas, pero necesitan pruebas

@dromer en retrospectiva... Me di cuenta de que puedo manejar cosas que parecen que deben hacerse "pronto" con Must Have
@christianlupus terminó Bug .. ahora trabajando en problemas antiguos sin hito

Elimino las etiquetas como Will be closed soon! y Feedback Needed tan pronto como se cierra un problema. ¿Está bien para nuestro flujo de trabajo común?

@dromer, ¿ podría tener una etiqueta adicional... low-hanging ? Veo problemas de vez en cuando que deberían ser soluciones fáciles

@christianlupus sí... y debería volver y comprobar que lo he hecho

Aparentemente, github proporciona algunos 'ganchos' automatizados si usa la etiqueta good first issue lugar:

Etiquete problemas y solicite extracción para nuevos colaboradores

Ahora, GitHub ayudará a los posibles contribuyentes primerizos a descubrir problemas etiquetados con good first issue

Entonces, ¿debería llamarlo así?
Los problemas con esta etiqueta aparecerán en otros resúmenes que se supone que alientan a las personas a involucrarse.

Me gusta en https://github.com/partkeepr/PartKeepr/contribute

¡funciona para mi! :)

@baradhili Me

@christianlupus sí... Descubrí que puedo soportar alrededor de 20/25 problemas por día... después de eso mi cerebro está frito...
esta mañana le daré una vuelta..

Los próximos pasos de

@baradhili Acabo de

¿Tenemos algún desarrollador?
Er... si lo hiciéramos, no tendríamos este retraso :)

Creo que ustedes se están moviendo un poco más rápido de lo que el proyecto 'permite' actualmente, lo cual es bueno, ya que la organización del trabajo atrasado estaba obstruyendo las cosas, por lo que espero que la priorización ayude a enfocar a aquellos que estén dispuestos a contribuir. (encontrarlos, o hacer que nos encuentren, es un desafío diferente, por supuesto)

ok chicos... ahora tenemos una lista de problemas con todos los problemas asignados a un hito y muchos cerrados
Creo que nuestro enfoque ahora es hacer que alguien desarrolle :) lamentablemente tengo NFI alrededor de ExtJS y Symfony, así que no puedo ayudar...

opciones

1. obtenemos un patrocinador y usamos trabajadores independientes en guru.com o stackexchange
2. tratamos de encontrar algo nosotros mismos
3. ?

Además, debe asegurarse de no patear a alguien en los dientes eliminando su trabajo duro sin contactarlo. Esto le sucedió a mi función de impresión y desde entonces solo miraba desde la línea lateral lo que está sucediendo aquí. También me quedé con una pieza de software que es inútil en la versión más nueva, porque no se agregó esa función nuevamente.

Debe haber una estructura clara sobre cómo lidiar con tales cosas y también con las decisiones arquitectónicas o cuál es una buena práctica para hacer algo. El proyecto en sí está claramente estructurado y también las personas que no son un experto en php (pero un experto en programación en otros lenguajes) pueden implementar cosas fácilmente con algo de ayuda para los marcos y estructuras utilizados.

@Boldie Hola Sven, disculpas si tu trabajo fue eliminado sin previo aviso... las cosas han cambiado mucho en el proyecto en los últimos tiempos y estamos muy interesados ​​en ganarnos la confianza de la comunidad, especialmente de los desarrolladores.

Por cierto, ¿supongo que su función de impresión realiza impresiones masivas? que seria necesario para que vuelva a funcionar?

Debe haber una estructura clara sobre cómo lidiar con tales cosas y también con las decisiones arquitectónicas o cuál es una buena práctica para hacer algo.

Esto es mayormente correcto, pero porque el proyecto se gestionó principalmente en un proyecto de una sola persona. No hubo necesidad de definir reglas para interactuar con la comunidad . A medida que comenzamos a compartir el peso del proyecto entre varias personas, podría ser beneficioso definir reglas sobre cómo proceder.

El proyecto en sí está claramente estructurado y también las personas que no son un experto en php (pero un experto en programación en otros lenguajes) pueden implementar cosas fácilmente con algo de ayuda para los marcos y estructuras utilizados.

Supongo que usted mismo es un programador para poder hacer tal declaración con autoridad. No pretendo ofender a nadie, pero mientras tanto, creo que es más difícil mojarse los pies desarrollando el código.

Lo intenté pero fue difícil. Las bibliotecas están tremendamente desactualizadas y, mientras tanto, la documentación sobre estos códigos antiguos es escasa. Además, la documentación del proyecto (por ejemplo, #635) no está completa.
No estoy intimidando por aquí, pero quiero señalar algunos problemas críticos del software actual. Como el desarrollador original es mayormente inaccesible en ese momento, necesitamos personas que conozcan al menos parte del código para volver a encarrilar las cosas. Espero que los "colaboradores antiguos" puedan ayudar aquí. Hay algunos errores que eliminar, pero el principal problema es que el software ya no se mantiene ni se puede mantener con respecto a las dependencias. Necesitamos resolver los problemas principales, de lo contrario, el proyecto fracasará.

Entonces te pregunto: ¿Trabajaste en el código y tienes experiencia con las dependencias relacionadas?

Por cierto, ¿supongo que su función de impresión realiza impresiones masivas? que seria necesario para que vuelva a funcionar?

@Boldie , le sugiero que abra un nuevo problema para rastrear la funcionalidad que falta. En algún momento, este problema aquí será archivado. Como resultado, la mayoría de las personas olvidarán su solicitud para que la función de impresión vuelva a funcionar.

Por cierto, ¿supongo que su función de impresión realiza impresiones masivas? que seria necesario para que vuelva a funcionar?
Consta de 2 partes:

• La impresión masiva de StorageLocations / Parts en un pdf
• Impresión de una sola pieza (para etiquetas)

El primero estaba altamente integrado, pero también agrega algunas dependencias problemáticas. El segundo quizás se implemente nuevamente mejor usando la API REST hoy. Todavía se rastrea en uno de estos 200 números abiertos :)

Acabo de echar un vistazo al código: tengo algunos problemas sobre cómo funciona realmente esto. El marco parece utilizar una especie de acoplamiento débil que es difícil de seguir. Tal vez un experto que use este marco diga algo diferente (la mayor parte del día, tengo contacto con C ++ y, a veces, Python con Django). Acabo de recordar que también fue difícil descubrir cómo agregar algunas cosas cuando hice mi primera implementación. El problema, como lo veo, es llevar este proyecto de un espectáculo más o menos unipersonal a un proyecto impulsado por la comunidad. Desafortunadamente, soy la persona equivocada para ayudar con el problema de la dependencia, pero estoy de acuerdo, esto debe ser lo primero que se resuelva para reducir el departamento técnico.

Para facilitar el desarrollo, sugeriría configurar un tipo de entorno que uno pueda comenzar a desarrollar fácilmente sin tener que trabajar dos veces. En mi empresa, hemos configurado un contenedor docker con las cosas y también un script para ejecutar pruebas/agregar datos de demostración, ... para facilitar el inicio del desarrollo.

Hay alguna forma de contactar con la comunidad? Creo que la mayoría de los usuarios no saben que necesitamos ayuda aquí, de lo contrario, el proyecto estará cada vez más desactualizado y en algún momento ya no se podrá utilizar. ¿Es posible poner una declaración en la página de inicio? Dado que hay la mayoría de las descargas, las personas con el conocimiento adecuado no están al tanto de la situación y este repositorio aquí.

@Boldie ¡ Buena idea! @dromer @Drachenkaetzchen ¿alguien tiene acceso a la página web principal?

@christianlupus ¿Hay una lista aquí o en la vista de hitos qué trabajo debe realizarse a continuación? Creo que una de las primeras cosas es actualizar a Symhony4 #1083.

@Boldie sí, se ha trabajado en temas de prioridades. ver esta lista:

https://github.com/partkeepr/PartKeepr/issues?q=is%3Aopen+is%3Aissue+label%3A%22Must+Have%22

La actualización de Symfony y otras dependencias es la más grande e importante en este momento.
(aunque creo que la etiqueta 'buen primer problema' está destinada a los recién llegados, no para una designación de 'necesidades hechas primero')

Hay alguna forma de contactar con la comunidad?
Estamos con varios usuarios en el canal #partkeepr irc en irc.freenode.net
También están los grupos de Google (uno público y uno privado), pero creo que el rastreador de problemas + IRC son su mejor opción para hablar con la gente sobre PartKeepr en este momento (en términos de actividad).

Además, debe asegurarse de no patear a alguien en los dientes eliminando su trabajo duro sin contactarlo. Esto le sucedió a mi función de impresión y desde entonces solo miraba desde la línea lateral lo que está sucediendo aquí. También me quedé con una pieza de software que es inútil en la versión más nueva, porque no se agregó esa función nuevamente.

La razón por la que tuve que eliminar la funcionalidad está documentada aquí: https://github.com/partkeepr/PartKeepr/issues/622

Si sientes que te han dado una patada en los dientes, lo siento, pero así era entonces.

Además, paso la mayor parte de mi tiempo diario escribiendo este software. Por favor, comprendan que si tengo que eliminar el código para hacer una versión más nueva, por el amor de Dios, que así sea. podrías haber creado otro PR para hacerlo compatible con la nueva versión

sí, estoy jodidamente enojado en este momento. Pasé tantos años escribiendo el código gratis, hice la mayor parte del trabajo, hice mucho trabajo de soporte, traté de hacer un negocio y todo lo que obtengo por los cientos, si no miles de horas de trabajo no remunerado, es eso.

si no fuera por mi sentido de la responsabilidad, habría cerrado el sitio web y todo lo demás hace 2 años.

Apenas tengo dinero en estos tiempos para sobrevivir un mes, tengo varias enfermedades de las que es poco probable que me recupere pronto y todavía trato de mantener vivo este proyecto de alguna manera, aunque apenas puedo hacerlo.

Además, paso la mayor parte de mi tiempo diario escribiendo este software. Por favor, comprendan que si tengo que eliminar el código para hacer una versión más nueva, por el amor de Dios, que así sea. podrías haber creado otro PR para hacerlo compatible con la nueva versión

sí, estoy jodidamente enojado en este momento. Pasé tantos años escribiendo el código gratis, hice la mayor parte del trabajo, hice mucho trabajo de soporte, traté de hacer un negocio y todo lo que obtengo por los cientos, si no miles de horas de trabajo no remunerado, es eso.

si no fuera por mi sentido de la responsabilidad, habría cerrado el sitio web y todo lo demás hace 2 años.

Apenas tengo dinero en estos tiempos para sobrevivir un mes, tengo varias enfermedades de las que es poco probable que me recupere pronto y todavía trato de mantener vivo este proyecto de alguna manera, aunque apenas puedo hacerlo.

Sé que estás en una situación grave y este proyecto que incluye a la comunidad tiene un aporte para tu situación. También respeto su trabajo y también creo que este proyecto (especialmente en comparación con otros) tiene una estructura bien hecha, de lo contrario no trataría de pensar qué puedo hacer para revitalizar este proyecto y cómo preparar un equipo de desarrollo para hacer el trabajo necesario.
No quiero calentar el pasado ahora, no nos ayudará a seguir adelante con Partkeepr.

Por mi trabajo diario, sé que a veces es difícil lidiar con el código de otras personas, especialmente si no se puede contactar a la persona (para el futuro y si es necesario, todos pueden contactarme por la dirección de correo electrónico de los compromisos de git o usando el dominio y contactarme usando mi página de inicio). Todo el mundo tiene su propia letra al escribir la codificación. En mi opinión, es una especie de artesanía para escribir código. También tengo mucha experiencia con la complejidad y lo difícil que es pasar por esto, si uno va a actualizar una biblioteca o un montón de dependencias. Hice esto con un equipo durante meses en mi trabajo remunerado.
Así que ahora tenemos este desafío aquí nuevamente y tenemos que pensar en una forma de hacerlo con una comunidad. Es mucho más desafiante que en un entorno pago donde uno dirá: lo haremos.

Eché un vistazo al código y, como hice algo la última vez, cambió MUCHO (¡¡alguien invirtió mucho trabajo aquí! :)). Así que tuve que profundizar en el código nuevamente y comenzar a trabajar. Pero para esto necesitamos una comunicación cercana y una hoja de ruta sobre qué hacer a continuación. Creo que recuperar la función de impresión tiene una prioridad muy baja en comparación con otras cosas y yo o alguien más podemos hacerlo más tarde. Para mí, vale más la pena no perder mis datos con la próxima actualización del sistema operativo en el futuro, porque esto también significará MUCHO trabajo para migrar a otra cosa (no sé qué puede ser esto), tomó mucho trabajo en mi tiempo libre para llenar la base de datos.

Gracias @Boldie

@christianlupus @dromer ¡Estoy pensando que podemos cerrar esto ahora que las cosas se están moviendo de nuevo...!

Un punto más para discutir: Debido a los cambios en el #1091, todos los números nuevos tendrán algunas etiquetas adjuntas. ¿Queremos tener un indicador de que no se ha realizado ninguna revisión humana aquí?

Aparte de esto, estoy de acuerdo con cerrar este problema ahora.

¿En qué se diferencia lo que hemos hecho de una revisión humana? :)

@baradhili esto es exactamente lo que hicimos recientemente. Me refiero a lo siguiente: dado que se aceptó el PR nombrado, cualquier problema nuevo tendrá un error, una solicitud de función o un preajuste de solicitud de ayuda como etiqueta, según el tipo de problema seleccionado.
Eso significa que los problemas nuevos (que no han pasado la clasificación manual que hicimos recientemente) no se presentarán como si no tuvieran etiquetas adjuntas. Por lo tanto, no existe un filtro simple en GitHub para seleccionar aquellos problemas que aún no se han evaluado humanamente.

En resumen: ¿queremos un need-triage o similar para indicar?

¿Podemos agregar automáticamente la etiqueta needs-triage en el sistema de plantillas de github?

Sí, es cuestión de agregar la etiqueta y cambiar una línea en el archivo de la plantilla. Eso debería ser suficiente.

Acabo de abrir el número 1097 con respecto al sistema de plantillas de problemas. Si no se desea la etiqueta needs-triage , sugiero eliminar la confirmación única.

cerrando esto ahora