Pods: Etiquetas de GitHub

~ "Needs Changelog" como etiqueta podría ir. He estado haciendo que las actualizaciones del registro de cambios sean parte del proceso de fusión y no he estado usando esa etiqueta de corta duración. ~
Hecho

No he tenido tiempo de pasar con un peine de dientes finos, pero no veo nada que se deslumbre de inmediato en un primer desnatado. Puedo encontrar algunos ajustes, omisiones, eliminaciones en un pase sólido, pero mi instinto es que esto sería una gran mejora con respecto al sistema de etiquetas actual propuesto.

"Patch" es uno que nunca he usado en mi flujo de trabajo, ya que me parece redundante. Si es un PR, entonces es un parche. Pero @ sc0ttkclark ha usado tradicionalmente esa etiqueta, por lo que puede tener algún valor de flujo de trabajo para él.

~ Component: Multi-site sería una buena adición, esa es otra área como la API REST y las plantillas que serían útiles para comenzar a etiquetar con fines de filtrado. ~

Hecho

Enfoque: compatibilidad con versiones anteriores
Enfoque: compatibilidad / obsolescencia
Enfoque: compatibilidad

Para estos tres, quizás refinados:

Focus: Backward Compatibility
Focus: Deprecation
Focus: Third Party Compatibility

Editar: esto está hecho

Además de esas pequeñas cosas hasta ahora, voy a seguir con esto. La clasificación es mucho mejor y me gustaría usarla en 2.7.7.

Quiero obtener un pulgar explícito de @jimtrue y @ sc0ttkclark también, primero.

¿Cuál es la diferencia entre Discussion y Team Discussion ? ¿Podrían reemplazarse por Needs: Developer Feedback ?

¿Qué es Integration ?

Aquí está mi segundo pase. Algunas adiciones / cambios nuevos. Aquellos con signos de interrogación iniciales se pueden eliminar si no se utilizan:

Closed: Could not reproduce
Closed: Duplicate
Closed: Invalid
Closed: Out of scope
Closed: Won't Fix

Component: CSS
Component: docs.pods.io
Component: DFV
Component: Front-end Forms
Component: Multisite
Component: Pods Templates/Magic Tags
Component: REST API
Component: support.pods.io
Component: UI
Component: Unit Testing
Component: WP Admin

Focus: Accessibility
Focus: Backward Compatibility
Focus: Deprecation
Focus: Third-Party Compatibility
Focus: I18n
? Focus: Integration
Focus: Performance

? Keyword: Discussion
Keyword: Focus
Keyword: Forums
Keyword: Friends of Pods Priority
Keyword: Good First Issue
Keyword: Has Bounty
? Keyword: Patch: Manually Merged
? Keyword: Patch
Keyword: Plugin Material
Keyword: Puntable
Keyword: Release
Keyword: Support
? Keyword: Team Discussion
Keyword: Tools
Keyword: VIP

Needs: Developer Feedback
Needs: Research
Needs: Tasklist
Needs: Test(s)
Needs: User Feedback
Needs: Verification/Reproduction
Needs: Votes

Priority: Blocker

Type: Bug
Type: Code Standards
Type: Inline Documentation
Type: Enhancement
Type: Feature
Type: Refactor
? Type: Regression

Status: Fixed / Needs Testing
Status: Help Wanted
Status: Hold
Status: In progress
Status: Pulled for Review
Status: Ready for merge
Status: Ready for review
Status: Researched
Status: Unit Tested
Status: Verified/Reproduced

¿Cuál es la diferencia entre Discusión y Discusión en equipo? ¿Podrían reemplazarse por Necesidades: comentarios de los desarrolladores?

No mucho, la Discusión estaría abierta al mundo y la Discusión en equipo sería interna. No creo que necesitemos eso tan detallado y una sola etiqueta de discusión genérica está bien (la duplicación probablemente no fue intencional). Dev Feedback se usa generalmente como un estado, generalmente un ticket que se estaba reteniendo para los comentarios de los usuarios y obtuvo dichos comentarios.

¿Qué es la integración?

Principalmente solicitudes de características que involucran integración con otros complementos, bibliotecas, temas, etc. Supongo que los errores en la integración existente pueden caer bajo este paraguas, pero a menudo son más apropiados como "compatibilidad" una vez que tenemos la integración. (por lo que la integración posiblemente sea un tipo, aunque tal vez tenga más sentido en Focus como lo ha hecho)

No estoy seguro de que la sección "Necesidades:" sea mejor ... Me gustó la idea de que fueran parte de "Estado:" ya que creo que es así como se usan a menudo.

Editar: todo esto ha sido abordado

~ Creo que las siguientes palabras clave podrían ser Tipo: Lanzamiento, Soporte y Herramientas. ~

~ Esos parecen tipos de boletos que no están bien descritos por ninguno de los demás. ~

Hecho

Además, por el simple hecho de desplazarme, me pregunto si deberíamos mantener actualizada la lista del mensaje inicial en lugar de publicar nuevas versiones a medida que avanzamos.

Hecho.

Me gusta la idea de esto:

Necesidades: Comentarios de los desarrolladores
Necesidades: Investigación
Necesidades: Lista de tareas
Necesidades: Prueba (s)
Necesidades: Comentarios del usuario
Necesidades: verificación / reproducción
Necesidades: Votos

Pero los 'Comentarios del usuario' y 'Verificación / Reproducción' son en realidad 'estado / flujo de trabajo' como @pglewis señaló anteriormente o podríamos ponerlos como Estado: Bloqueador con las Necesidades como la 'razón' del Bloqueador.

Idealmente, el flujo de trabajo de estado debería reducirse a los carriles del proyecto. Mirando esta lista de etiquetas, NO tenía idea de que teníamos tantas, pero supongo que ustedes crearon algunas más.

support.pods.io y docs.pods.io no deberían estar aquí en absoluto (tenemos repositorios para esos dos sitios web), a menos que estemos planeando usar GitHub para actualizaciones de soporte y documentación. Si vamos a hacer eso (por lo que soy TODO), agregamos un prefijo para Docs: y Support: y creamos dos proyectos en GitHub en este repositorio para Support y Documentation. Dado que ocasionalmente un problema de soporte puede convertirse en una mejora / función real del código o una corrección de errores, tiene sentido que usemos la misma interfaz. Seguro que tendremos más, pero también nos aseguraremos de obtener exactamente lo que necesitamos para problemas de soporte y actualizaciones de documentación.

Revisé esto y me gustaría ver los siguientes cambios:

• Tipo : Agregar Support & Docs Update (eliminando Support de Keyword )
• Componente : no necesitamos support.pods.i o o doc.pods.io en Component . Esos dos repositorios tienen sus propios proyectos. El componente debe ser completamente para el área de enfoque de Pods Core.
• Prioridad : Mueva Focus de Palabra clave a Priority . Blocker está bien siempre que sepamos el motivo, que debería provenir de Necesidades .

Entonces, si sigo esto correctamente, todo debería tener un:
Tipo : Define qué tipo de ticket es.
Estado : define dónde se encuentra en el flujo de trabajo. Poca discusión sobre qué estado debería ser 'Bloqueado' o 'Tareas pendientes' o 'Retener' si necesitamos comentarios del usuario o verificación / reproducción. No estoy seguro de cuál sería el estado para la función / solicitud de mejora donde las necesidades son los votos. Tal vez esos sigan el mismo formato para un tablero Kanban típico y su estado sea BackLog hasta que se esté trabajando activamente. El bloqueador indica que no se puede trabajar hasta que se atiendan las necesidades.
Componente : determina el área de Pods Core para Característica / Mejora / Error
¿La palabra clave y el enfoque son solo para una aclaración adicional?

Eliminé WaffleBot para que esos estados ya no se agreguen automáticamente.

El bloqueador indica que no se puede trabajar hasta que se atiendan las necesidades.

Este es un caso en el que no estamos usando una etiqueta con las mismas intenciones. Siempre he usado Blocker (y creo que Scott también) para problemas que bloquean un lanzamiento (o tal vez otro ticket) y deben hacerse; no se puede patear.

No hay ninguna razón en mi flujo de trabajo para que marque algo como retenido en algo a través de 'Bloqueador' ... las etiquetas de estado actual deberían implicar eso. No necesito "Necesito comentarios del usuario" más "Bloqueador", ya que el primero ya me dice que está bloqueando y por qué.

Mi voto es que lo usamos de esa manera y lo mantenemos bajo "Prioridad: *" ya que esa es una descripción perfecta para mí.

~ Creo que "Focus" también debería pasar de Palabras clave a Prioridad. ~ Dejando palabras clave

Me gusta la idea de esto:

Necesidades: Comentarios de los desarrolladores
Necesidades: Investigación
Necesidades: Lista de tareas
Necesidades: Prueba (s)
Necesidades: Comentarios del usuario
Necesidades: verificación / reproducción
Necesidades: Votos

Para mí, estos son principalmente estados de tickets, por lo que propongo mantenerlos allí por ahora. Si la longitud es lo que nos preocupa, podríamos abreviar algo ("Estado: Necesita FB de desarrollo", "Estado: Necesita verificación / reprogramación").

Creo que la "Lista de tareas de necesidades" puede desaparecer. No creo que suceda lo suficiente como para justificar una etiqueta. No estoy seguro de haberlo usado alguna vez, si es así, rara vez. Probablemente lo mismo para "Pruebas de necesidades". Los restantes se ajustan perfectamente a mí en "Estado: *".

Además, la lista se perfila muy bien para mí, probablemente deberíamos discutir el esquema de color.

Un par más que probablemente se pueden recortar de Estados junto con "Necesita lista de tareas":

• ~ "Elegido para revisión" probablemente sea una duplicación involuntaria de "Listo para revisión" ~ Dejándolo
• "Unidad probada" no es un estado (al menos todavía no), es más variado ... ¿así que probablemente se haya trasladado a Palabras clave?

Eso deja la lista de estado luciendo bien para mí.

"Elegido para revisión" probablemente sea una duplicación involuntaria de "Listo para revisión"

Discrepar. Si creo un PR, cuando esté listo, agregaré Listo para revisión. Pero es posible que no tenga tiempo para hacer esa revisión hasta más tarde, pero para entonces, Scott no está seguro de si ha comenzado la revisión o no. En resumen, son dos grupos diferentes de personas que agregan Ready for Review y Pulled for Review.

Probablemente lo mismo para "Pruebas de necesidades".

En aras de querer más cobertura de código (aunque todavía tengo que investigar mucho esta área personalmente), esta etiqueta podría ser para decir que "la solución es buena, pero nos gustaría ver que las pruebas unitarias cubran los bordes / verifiquen la corrección de error específica para que no se introduzcan regresiones ".

Creo que "Focus" también debería pasar de Palabras clave a Prioridad.

Las prioridades generalmente serían: baja, media, alta, crítica, bloqueadora; tienen una semántica diferente (al menos en mi opinión) para Enfocar. Una etiqueta Keyword: Focus no tiene relevancia por sí misma a menos que haya un hito que indique en qué versión se centra el problema _para_. Mientras que una prioridad no tiene contexto, en la medida en que se aplica al proyecto en su conjunto. No creo necesariamente que agregar las otras prioridades sea una buena idea, pero igualmente, no creo que Focus sea una prioridad. Quizás lo que estamos tratando de decir es que "este boleto es un hito destacado, un gran regalo para gritar en el próximo lanzamiento", y si es así, una palabra diferente a Focus puede ser mejor para señalar la intención.

El bloqueador indica que no se puede trabajar hasta que se atiendan las necesidades.

Estoy de acuerdo con Phil aquí: entendí que significaba que el problema que tiene esta etiqueta es un bloqueador de un _lanzamiento_. Quizás la explicación de Jim sería más adecuada para una etiqueta Status: Is Blocked o similar, aunque una Needs: * indicaría lo mismo.

Por cierto, ¿está bien eliminar la lista provisional aquí: # 5016 (comentario)?

@pglewis Continúe y elimine (u oculte en <details>...</details> como referencia histórica) lo que desee.

support.pods.io y docs.pods.io no deberían estar aquí en absoluto

Ese fui yo quien los agregó debido a la incertidumbre acerca de la etiqueta "Mejora de Documentos" existente (frente a Documentos: en línea); se pueden eliminar si se manejan en otro lugar.

Mejora de Documentos podría escribirse mejor como 'Documentos: en línea' 'Documentos: Ejemplos' 'Documentos: información sobre herramientas' y ese tipo de cosas. A menos que estemos manejando el flujo de trabajo de documentación (es decir, documentación escrita en el sitio web docs.pods.io) en GitHub, no hay razón para ello aquí. Cualquier mejora de documentos dentro de nuestro código significa documentos _en_ ​​nuestro código o administrados dentro de nuestro código o como el archivo Léame que se analiza y se envía al repositorio de complementos de WordPress.org.

Me gusta el Status: Is Blocked ya que es muy informativo, pero si haces algo de esa naturaleza, también requiere un Needs: *

Como dije, todo obtiene un Type y un Status . Hasta que no hagamos una gestión ágil de proyectos completa con GitHub, no es necesario definir las prioridades allí y, en realidad, están mejor representadas por las unidades de trabajo necesarias para realizar la 'historia'. Siempre hemos utilizado Focus para diferenciar elementos en los cientos de problemas que deben enfocarse en la próxima versión de mantenimiento.

Mis únicos pensamientos son con respecto a las etiquetas UI / CSS, ya que esas son con las que más trato ... parece que tal vez simplemente eliminar CSS como un componente y confiar solo en la interfaz de usuario tiene más sentido para mí. No estoy seguro si ustedes tienen alguna idea ahí, pero CSS es el resultado, no lo tangible que necesita ser arreglado ... si eso tiene sentido. La interfaz de usuario sería la cosa tangible en la que se trabajaría o mejoraría, css sería el resultado o cómo se arreglaría. De lo contrario, me gusta 👍

Mis únicos pensamientos son con respecto a las etiquetas UI / CSS, ya que esas son con las que más trato ... parece que tal vez simplemente eliminar CSS como un componente y confiar solo en la interfaz de usuario tiene más sentido para mí. No estoy seguro si ustedes tienen alguna idea ahí, pero CSS es el resultado, no lo tangible que necesita ser arreglado ... si eso tiene sentido. La interfaz de usuario sería la cosa tangible en la que se trabajaría o mejoraría, css sería el resultado o cómo se arreglaría.

Sí, hay que hacer un refinamiento allí. Principalmente he usado la etiqueta CSS como la Bat-señal para que tú y / o Jory filtren, ya que ustedes han sido los tipos a los que acudir en esa dirección.

Votaría por dejar CSS y UI como se propuso por ahora, pero ciertamente podemos continuar refinándolo después de la Fase I.

RE: Pruebas de necesidades

En aras de querer más cobertura de código (aunque todavía tengo que investigar mucho esta área personalmente), esta etiqueta podría ser para decir que "la solución es buena, pero nos gustaría ver que las pruebas unitarias cubran los bordes / verifiquen la corrección de error específica para que no se introduzcan regresiones ".

La realidad es que necesitamos mantenernos al día con las correcciones de mantenimiento, trabajar en una rama de lanzamiento y la barrera para escribir nuevas pruebas es bastante alta incluso para cosas simples. Podemos dejar la etiqueta allí, pero no es probable que se use mucho hasta que se haya realizado una refactorización mucho mayor, introduzcamos pruebas unitarias reales y / o tengamos más recursos para dedicarle.

Sin embargo, un "Tipo: Pruebas" sería una buena adición porque en este momento las pruebas agregadas probablemente sean mejores como su propio problema / pares de relaciones públicas.

Me gusta el estado: está bloqueado, ya que es muy informativo, pero si haces algo de esa naturaleza, también requiere una necesidad: *

Estoy bien dejándolo, pero soy principalmente el que rastrea los estados y nunca he tenido la necesidad de marcar nada como "está bloqueado" como estado. Cualquier cosa que sea vagamente en esa dirección con la que me cruzo está mejor cubierta por "Holding".

Y en caso de que ayude a aclarar algo, este es el flujo de trabajo típico que uso en un error promedio:

• Triage: filtrar no válido, soporte, característica / mejora; establecer el tipo de error
• Normalmente, el estado pasa inmediatamente a "necesita verificación / reproducción"
• Puede alternar entre "necesita comentarios de los usuarios" y "necesita comentarios de los desarrolladores" a lo largo de la vida
• Verificado / Reproducido
• Necesita investigación: ahora que sabemos cómo hacer que suceda, descubra y comprenda por qué
• Investigado: probablemente soy el único que usa esto. Señala que se ha realizado una inmersión profunda en algún momento y probablemente tengo detalles internos almacenados en mi cabeza
• Pruebas fijas / necesarias

Discrepar. Si creo un PR, cuando esté listo, agregaré Listo para revisión. Pero es posible que no tenga tiempo para hacer esa revisión hasta más tarde, pero para entonces, Scott no está seguro de si ha comenzado la revisión o no. En resumen, son dos grupos diferentes de personas que agregan Ready for Review y Pulled for Review.

Creo que la etiqueta Hold ha sido históricamente mejor que Pulled for Review en esos casos.

Para su información, en el pasado, he usado Blocker para indicar un problema que bloquea un lanzamiento.

Podemos eliminar 'Patch', comencé a usar eso cuando GitHub tenía una experiencia de usuario más confusa entre PR y Issues, era más fácil ver la vista 'Release' con Patches principalmente para repasar las cosas del registro de cambios. No lo necesitamos.

¿La lista de la descripción del problema original está actualizada con los cambios que todos hemos discutido?

¿La lista de la descripción del problema original está actualizada con los cambios que todos hemos discutido?

Probablemente no del todo, siéntase libre de refinar algunos si lo desea. Lo revisaré una vez que tengamos el pulgar hacia arriba y peinaré cualquier cosa que hayamos decidido que no se haya actualizado.

Independientemente de lo que decidamos aquí, debemos aplicarlo a todos nuestros otros repositorios de Pods utilizando una herramienta como https://github.com/dwyl/labels para sincronizarlos.

Mover "Regresión" de Tipo a Palabras clave. El error sigue siendo el tipo de problemas de regresión.

Esto está prácticamente implementado ahora. Algunas cosas misceláneas que acabo de colocar en "Palabras clave" por ahora.

Los colores son lo principal para trabajar en este punto.

Cerrado: no válido

Sugeriría mantener al menos este, posiblemente el Won't Fix también. Son resoluciones bastante estándar en otros rastreadores de errores.

Los colores son lo principal para trabajar en este punto.

Los colores son secundarios en este punto: implemente las etiquetas y decida un esquema de color más adelante.

Sugeriría mantener al menos este [Inválido], posiblemente el Won't Fix también. Son resoluciones bastante estándar en otros rastreadores de errores.

Agregaré No válido, lo acabo de marcar como recordatorio porque aún no lo teníamos.

"Won't Fix" es uno de esos que simplemente odio el tono. Además, mi actitud es que deberíamos tener una etiqueta con una mejor razón específica para no arreglar algo que "No arreglará".

Los colores son secundarios en este punto: implemente las etiquetas y decida un esquema de color más adelante.

Las etiquetas están prácticamente implementadas.

¿Necesitamos un "Tipo: GitHub" o algo similar? Este problema no tiene tipo.

Type: Project ?

¿Qué pasa si en lugar de "No se arreglará" utilizamos "Dejar como está" o algo así?

¿Qué pasa si en lugar de "No se arreglará" utilizamos "Dejar como está" o algo así?

Es una situación poco común, por lo que lo hemos hecho durante tanto tiempo sin necesitar algo así. Voto para esperar a agregar algo allí hasta que aparezca un ejemplo específico.

Además, he tomado algunas decisiones de color arbitrarias para algunos de los grupos. Allí no hay nada escrito en piedra.

Creo que probablemente podamos cerrar este problema en este punto y discutir más mejoras a través de Slack.

What if instead of "Won't Fix" we used "Leave as is" or something like that?

Es una situación poco común, por lo que lo hemos hecho durante tanto tiempo sin necesitar algo así. Voto para esperar a agregar algo allí hasta que aparezca un ejemplo específico.

Estoy de acuerdo. No es necesario duplicar todo lo que hace el núcleo de WordPress

Estoy de acuerdo. No es necesario duplicar todo lo que hace el núcleo de WordPress

También es una de las etiquetas predeterminadas al configurar un nuevo repositorio en GH; consulte https://github.com/GaryJones/daterange/labels, que tiene las etiquetas predeterminadas.

I agree. Not everything that WordPress core does needs to be duplicated

También es una de las etiquetas predeterminadas al configurar un nuevo repositorio en GH; consulte https://github.com/GaryJones/daterange/labels, que tiene las etiquetas predeterminadas.

No recuerdo cuándo se convirtió en un valor predeterminado para GitHub, pero siempre ha sido una etiqueta terrible adjuntar a un ticket de un colaborador voluntario. He visto muy pocos problemas en GitHub con esa etiqueta, pero en el mundo de WordPress, la mayoría de los tickets que no se solucionan están cubiertos por otro problema, necesitan más información para justificar una solución o simplemente esperando que nadie regrese quejándose (a menudo es el caso) .

Me quedaré con mi disgusto. Mi pregunta inmediata sobre "No se arreglará" es "¿Por qué nos negaríamos a arreglar algo?" Y si alguien me da una buena respuesta concisa a eso en un boleto, diría que es lo que debería leer la etiqueta en lugar de "No se arreglará".

Creo que Out of Scope es una mejor respuesta de todos modos. Won't Fix solo implica y no proporciona "nada" a la persona que abre el problema.

tal vez podría ir en la dirección - no dude en enviar una "solución" pero el equipo no tiene suficientes recursos para hacerlo: D tal vez alguien tenga una idea para una abreviatura corta ^^

Un caso de uso puede ser un error o una violación de CS en alguna función, que de todos modos se está reescribiendo y lanzando en la próxima versión.

Sin embargo, siéntase libre de dejarlo fuera.