Pods: Rótulos do GitHub

~ "Needs Changelog" como um rótulo pode ser capaz de ir. Tenho feito as atualizações do changelog como parte do processo de mesclagem e não tenho usado esse rótulo de curta duração. ~
Feito

Não tive tempo de passar um pente de dentes finos, mas não estou vendo nada brilhando imediatamente na primeira varredura. Posso encontrar alguns ajustes, omissões, exclusões em uma passagem sólida, mas meus instintos são de que isso seria uma grande melhoria em relação ao sistema de etiqueta atual, conforme proposto.

"Patch" é um que eu nunca usei no meu fluxo de trabalho, pois parece redundante para mim. Se for um PR, então é um patch. Mas @ sc0ttkclark tradicionalmente usa esse rótulo, então pode ter algum valor de fluxo de trabalho para ele.

~ Component: Multi-site seria uma boa adição, essa é outra área como API REST e modelos que seriam úteis para começar a marcar para fins de filtragem. ~

Feito

Foco: compatibilidade com versões anteriores
Foco: compatibilidade / descontinuação
Foco: Compatibilidade

Para estes três, talvez refinado:

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

Editar: Isso está feito

Além dessas pequenas coisas até agora, estou tudo indo para isso. A classificação é muito melhor e gostaria de usá-la embora 2.7.7.

Quero obter uma aprovação explícita de @ sc0ttkclark primeiro.

Qual é a diferença entre Discussion e Team Discussion ? Eles poderiam ser substituídos por Needs: Developer Feedback ?

O que é Integration ?

Aqui está minha segunda passagem. Algumas novas adições / alterações. Aqueles com pontos de interrogação iniciais podem ser descartados se não forem usados:

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

Qual é a diferença entre discussão e discussão em equipe? Eles poderiam ser substituídos por Necessidades: Feedback do desenvolvedor?

Não muito, a discussão seria aberta ao mundo e a discussão em equipe seria interna. Não acho que precisamos disso tão refinado e um único rótulo de discussão genérico é bom (a duplicação provavelmente não foi intencional). Dev Feedback é geralmente usado como um status, geralmente um tíquete que aguardava o feedback do usuário e recebeu esse feedback.

O que é integração?

Principalmente solicitações de recursos que envolvem integração com outros plug-ins, bibliotecas, temas, etc. Suponho que bugs na integração existente possam cair neste guarda-chuva, mas geralmente eles são mais apropriados como "compatibilidade", uma vez que temos integração. (então a integração possivelmente é um tipo, embora talvez faça mais sentido no Focus como você fez)

Não tenho certeza se a seção 'Necessidades: "é melhor ... Gostei da ideia deles como parte de" Status: ", pois acho que é assim que costumam ser usados.

Editar: tudo isso foi resolvido

~ Estou pensando que as seguintes palavras-chave podem ser Tipo: versão, suporte e ferramentas. ~

~ Esses parecem tipos de ingressos que não são bem descritos por nenhum dos outros. ~

Feito

Além disso, para fins de rolagem, eu me pergunto se deveríamos apenas manter a lista da mensagem inicial atualizada em vez de postar novas versões conforme avançamos.

Feito.

Eu gosto da ideia disso:

Necessidades: Feedback do desenvolvedor
Necessidades: Pesquisa
Necessidades: Lista de Tarefas
Necessidades: Teste (s)
Necessidades: Feedback do usuário
Necessidades: Verificação / Reprodução
Necessidades: Votos

Mas o 'Feedback do usuário' e 'Verificação / Reprodução' são realmente 'status / fluxo de trabalho' como @pglewis notado acima ou poderíamos colocá-los como Status: Bloqueador com as Necessidades sendo o 'motivo' para o Bloqueador.

O fluxo de trabalho de status deve, idealmente, diminuir para as raias no projeto. Olhando para esta lista de rótulos, NÃO fazia ideia de que tínhamos tantos, mas acho que vocês criaram mais alguns.

support.pods.io e docs.pods.io não deveriam estar aqui (temos repositórios para esses dois sites), a menos que estejamos planejando usar o GitHub para atualizações de suporte e documentação. Se vamos fazer isso (para o qual TODOS eu sou), então adicionamos um prefixo para Docs: e Suporte: e criamos dois projetos no GitHub neste repositório para Suporte e Documentação. Visto que ocasionalmente um problema de suporte pode se transformar em um aprimoramento / recurso real do código ou correção de bug, faz sentido usarmos a mesma interface. Claro que teremos mais, mas também nos certificaremos de obter exatamente o que precisamos para problemas de suporte e atualizações de documentação.

Eu examinei isso e gostaria de ver as seguintes mudanças:

• Digite : adicione Support & Docs Update (removendo Support de Keyword )
• Componente : não precisamos de support.pods.i o ou doc.pods.io em Component . Esses dois repo's têm seus próprios projetos. O componente deve ser inteiramente para a área de foco do Pods Core.
• Prioridade : Mova Focus da palavra-chave para Priority . Blocker está bem, contanto que saibamos o motivo, que deve ser proveniente de Necessidades .

Então, se eu seguir corretamente, tudo deve ter um:
Tipo : define que tipo de tíquete é.
Status : define onde está no Workflow. Pouca discussão sobre qual status deve ser 'Bloqueado' ou 'ToDo' ou 'Hold' se precisarmos de feedback do usuário ou verificação / reprodução. Não tenho certeza de qual seria o status para Solicitação de recurso / aprimoramento em que as necessidades são votos. Talvez eles sigam o mesmo formato de um quadro Kanban típico e seu status seja BackLog até que esteja ativamente sendo trabalhado. O bloqueador indica que não pode ser trabalhado até que as necessidades sejam atendidas.
Componente : determina a área do núcleo dos pods para recurso / aprimoramento / bug
A palavra - foco são apenas para esclarecimentos adicionais?

Removi o WaffleBot para que esses status não sejam mais adicionados automaticamente.

O bloqueador indica que não pode ser trabalhado até que as necessidades sejam atendidas.

Aqui está um caso em que não estamos usando um rótulo com as mesmas intenções. Sempre usei o Blocker (e acho que o Scott também) para problemas que bloqueiam um lançamento (ou talvez outro tíquete) e devem ser resolvidos; não pode ser punted.

Não há nenhuma razão em meu fluxo de trabalho para eu marcar algo como retendo algo por meio de 'Bloqueador' ... os rótulos de status atuais devem indicar isso. Não preciso de "Preciso de feedback do usuário" e de "Bloqueador", pois o primeiro já me diz que está bloqueando e por quê.

Meu voto é que o usamos dessa forma e o mantemos em "Prioridade: *", pois essa é uma descrição perfeita para mim.

~ Acho que o "Foco" também deve passar das palavras-chave para a prioridade. ~ Deixando as palavras-chave

Eu gosto da ideia disso:

Necessidades: Feedback do desenvolvedor
Necessidades: Pesquisa
Necessidades: Lista de Tarefas
Necessidades: Teste (s)
Necessidades: Feedback do usuário
Necessidades: Verificação / Reprodução
Necessidades: Votos

Esses são principalmente status de tíquetes para mim, então eu proponho mantê-los lá por enquanto. Se o tamanho for a preocupação, podemos abreviar alguns ("Status: Need Dev FB", "Status: Need Verification / Repro").

Acho que a "Lista de Tarefas de Necessidades" pode acabar. Não acho que isso aconteça o suficiente para justificar um rótulo. Não tenho certeza de que já usei, raramente. Provavelmente idem para "Precisa de testes". Os restantes se encaixam perfeitamente para mim em "Status: *".

Além disso, a lista está se moldando bem para mim, provavelmente devemos discutir o esquema de cores.

Mais alguns que provavelmente podem ser cortados dos Status junto com a "Lista de Tarefas de Necessidades":

• ~ "Retirado para revisão" é provavelmente apenas uma duplicação não intencional de "Pronto para revisão" ~ Deixando-o
• "Unidade testada" não é um status (pelo menos ainda não), mais diverso ... então provavelmente mudou para palavras-chave?

Isso faz com que a lista de status pareça boa para mim.

"Pulled for Review" é provavelmente apenas uma duplicação não intencional de "Ready for Review"

Discordo. Se eu criar um PR, quando ele estiver pronto, adicionarei Pronto para revisão. Mas você pode não ter tempo para fazer essa revisão até mais tarde - mas até lá, Scott não tem certeza se você começou a revisão ou não. Resumindo, são dois grupos diferentes de pessoas adicionando Pronto para Revisão e Retirado para Revisão.

Provavelmente idem para "Precisa de testes".

Por querer mais cobertura de código (embora eu ainda não tenha examinado muito pessoalmente essa área), este rótulo pode ser para dizer que "a correção é boa, mas gostaríamos de ver os testes de unidade cobrir as bordas / verificar a correção de bug específica para que nenhuma regressão seja introduzida ".

Acho que o "Foco" também deve passar de Palavras-chave para Prioridade.

As prioridades geralmente seriam - baixo, médio, alto, crítico, bloqueador - eles têm semânticas diferentes (pelo menos em minha mente) para o Foco. Um rótulo Keyword: Focus não tem relevância por si só, a menos que haja um marco para dizer em qual versão o problema está em foco _para_. Considerando que uma prioridade não tem contexto, na medida em que se aplica ao projeto como um todo. Não acho necessariamente que adicionar outras prioridades seja uma boa ideia, mas, igualmente, não acho que o Foco seja uma prioridade. Talvez o que estejamos tentando dizer é que "este tíquete é um Milestone Highlight - um grande brinde para gritar no próximo lançamento" e, se for o caso, uma palavra diferente para Focus pode ser melhor para sinalizar a intenção.

O bloqueador indica que não pode ser trabalhado até que as necessidades sejam atendidas.

Eu concordo com Phil aqui - entendi que isso significa que o problema com esse rótulo é um bloqueador de _release_. Talvez a explicação de Jim fosse mais adequada para um rótulo Status: Is Blocked ou similar, embora um Needs: * indique o mesmo.

BTW, há algum problema em excluir a lista provisória aqui: # 5016 (comentário)?

@pglewis Vá em frente e remova (ou esconda em <details>...</details> para referência histórica) o que você quiser.

support.pods.io e docs.pods.io não deveriam estar aqui de forma alguma

Fui eu que os adicionei devido à incerteza sobre a tag existente "Docs Melhorar" (vs. Docs: inline) - eles podem ser removidos se forem tratados em outro lugar.

Melhoria de Documentos pode ser melhor escrita como 'Documentos: Inline' 'Documentos: Exemplos' 'Documentos: Dicas de ferramentas' e esse tipo de coisa. A menos que estejamos lidando com o fluxo de trabalho da Documentação (ou seja, documentação escrita no site docs.pods.io) no GitHub, não há razão para isso aqui. Quaisquer melhorias de documentos em nosso código significam documentos _em_ nosso código ou gerenciados em nosso código ou como o leia-me que é analisado e enviado para o repositório de plug-ins do WordPress.org.

Eu gosto de Status: Is Blocked porque é muito informativo, mas se você fizer algo dessa natureza, também será necessário: *

Como eu disse, tudo ganha um Type e um Status . Até que estejamos fazendo o gerenciamento de projeto ágil completo com o GitHub, as prioridades não precisam ser definidas lá e, na verdade, são melhor representadas pelas unidades de trabalho necessárias para concluir a 'história'. Sempre usamos o Focus para diferenciar itens na centena de problemas que precisam ser enfocados na próxima versão de manutenção.

Meus únicos pensamentos são com relação aos rótulos de IU / CSS, já que são os que eu mais lido ... parece que talvez apenas remover CSS como um componente e apenas confiar na IU faz mais sentido para mim. Não tenho certeza se vocês têm alguma ideia a respeito, mas CSS é o resultado, não a coisa tangível que precisa ser consertada ... se isso faz sentido. UI seria a coisa tangível a ser trabalhada ou melhorada, css seria o resultado ou como foi corrigido. Do contrário, eu gosto 👍

Meus únicos pensamentos são com relação aos rótulos de IU / CSS, já que são os que eu mais lido ... parece que talvez apenas remover CSS como um componente e apenas confiar na IU faz mais sentido para mim. Não tenho certeza se vocês têm alguma ideia a respeito, mas CSS é o resultado, não a coisa tangível que precisa ser consertada ... se isso faz sentido. UI seria a coisa tangível a ser trabalhada ou melhorada, css seria o resultado ou como foi corrigido.

Sim, há um refinamento a ser feito lá. Eu usei principalmente o rótulo CSS como o sinal de morcego para você e / ou Jory filtrarem, já que vocês são os caras que procuram nessa direção.

Eu votaria em deixar o CSS e a IU como proposto por enquanto, mas certamente podemos continuar a refiná-lo após a Fase I.

RE: Necessita de Testes

Por querer mais cobertura de código (embora eu ainda não tenha examinado muito pessoalmente essa área), este rótulo pode ser para dizer que "a correção é boa, mas gostaríamos de ver os testes de unidade cobrir as bordas / verificar a correção de bug específica para que nenhuma regressão seja introduzida ".

A realidade é que precisamos manter as correções de manutenção, trabalhar em um branch de lançamento, e a barreira para escrever novos testes é bastante alta, mesmo para coisas simples. Podemos deixar o rótulo lá, mas não é provável que seja muito usado até que muito mais refatoração tenha sido feita, introduzamos os testes de unidade reais e / ou tenhamos mais recursos para dedicar a isso.

Um "Tipo: testes" seria uma boa adição, porque agora os testes adicionados são provavelmente melhores como seus próprios pares de problema / PR.

Eu gosto de Status: Is Blocked, pois é muito informativo, mas se você fizer algo dessa natureza, também será necessário: *

Não há problema em deixá-lo, mas sou principalmente aquele que rastreia os status e nunca precisei marcar nada como "está bloqueado" como um status. Qualquer coisa que esteja vagamente naquela direção que eu encontrar é melhor explicada por "Holding".

E caso ajude a esclarecer alguma coisa, este é o fluxo de trabalho típico que uso em um bug comum:

• Triagem: filtro inválido, suporte, recurso / aprimoramento; definir tipo para bug
• Normalmente, o status vai imediatamente para "precisa verificar / reproduzir"
• Pode alternar entre "precisa de feedback do usuário" e "precisa de feedback do desenvolvedor" ao longo da vida
• Verificado / reproduzido
• Precisa de pesquisa: agora que sabemos como fazer acontecer, descubra e entenda o porquê
• Pesquisado: provavelmente sou o único que usa isso. Indica que um mergulho profundo foi feito em algum ponto e provavelmente tenho detalhes internos armazenados na minha cabeça
• Fixo / Precisa de Teste

Discordo. Se eu criar um PR, quando ele estiver pronto, adicionarei Pronto para revisão. Mas você pode não ter tempo para fazer essa revisão até mais tarde - mas até lá, Scott não tem certeza se você começou a revisão ou não. Resumindo, são dois grupos diferentes de pessoas adicionando Pronto para Revisão e Retirado para Revisão.

Acho que o rótulo Hold tem sido historicamente melhor do que Pulled for Review nesses casos.

Para sua informação, no passado, usei o Blocker para indicar um problema que bloqueia um lançamento.

Podemos remover 'Patch', comecei a usar isso quando o GitHub tinha UX mais confuso entre PRs e problemas, era mais fácil ver a visão 'Release' com Patches principalmente para rever as coisas para coisas do changelog. Nós não precisamos disso.

A lista na descrição do problema original está atualizada com as mudanças que todos discutimos?

A lista na descrição do problema original está atualizada com as mudanças que todos discutimos?

Provavelmente não completamente, sinta-se à vontade para refinar alguns se quiser. Analisarei assim que tivermos todos os polegares para cima e vasculharemos qualquer coisa que decidimos que não foi atualizada.

Independentemente do que decidirmos aqui, precisamos aplicar a todos os nossos outros repositórios de pods usando uma ferramenta como https://github.com/dwyl/labels para sincronizá-los.

Movendo "Regressão" de Tipo para Palavras-chave. Bug ainda é o tipo de problema de regressão.

Isso está praticamente implementado agora. Algumas coisas diversas que coloquei em "Palavras-chave" por enquanto.

As cores são as principais coisas a serem trabalhadas neste ponto.

? Fechado: Inválido

Eu sugeriria manter pelo menos este, possivelmente o não consertará também. Eles são resoluções razoavelmente padrão em outros rastreadores de bugs.

As cores são as principais coisas a serem trabalhadas neste ponto.

As cores são secundárias neste ponto - implemente os rótulos e decida sobre um esquema de cores mais tarde.

Eu sugeriria manter pelo menos este [Inválido], possivelmente o não consertará também. Eles são resoluções razoavelmente padrão em outros rastreadores de bugs.

Vou adicionar Inválido, apenas marquei como um lembrete porque ainda não o tínhamos.

"Não vai consertar" é um daqueles que eu odeio o tom. Além disso, minha atitude é que deveríamos ter um rótulo com um motivo específico melhor para não consertar algo do que "Não consertarei".

As cores são secundárias neste ponto - implemente os rótulos e decida sobre um esquema de cores mais tarde.

Os rótulos são praticamente implementados.

Precisamos de um "Tipo: GitHub" ou algo semelhante? Este problema não tem tipo.

Type: Project ?

E se em vez de "Não vai consertar", usássemos "Deixar como está" ou algo parecido?

E se em vez de "Não vai consertar", usássemos "Deixar como está" ou algo parecido?

É uma situação incomum, portanto, sobrevivemos todo esse tempo sem precisar de algo assim. Eu voto para esperar para adicionar qualquer coisa lá até que um exemplo específico apareça.

Além disso, tomei algumas decisões arbitrárias sobre cores para alguns dos grupos. Nada está gravado ali.

Acho que provavelmente podemos encerrar este problema neste ponto e discutir quaisquer outros refinamentos por meio do Slack.

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

É uma situação incomum, portanto, sobrevivemos todo esse tempo sem precisar de algo assim. Eu voto para esperar para adicionar qualquer coisa lá até que um exemplo específico apareça.

Eu concordo. Nem tudo o que o núcleo do WordPress faz precisa ser duplicado

Eu concordo. Nem tudo o que o núcleo do WordPress faz precisa ser duplicado

É também um dos rótulos padrão ao configurar um novo repo no GH - consulte https://github.com/GaryJones/daterange/labels que possui os rótulos padrão.

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

É também um dos rótulos padrão ao configurar um novo repo no GH - consulte https://github.com/GaryJones/daterange/labels que possui os rótulos padrão.

Não me lembro quando se tornou um padrão para o GitHub, mas sempre foi uma marca terrível para anexar a um tíquete de um colaborador voluntário. Eu vi muito poucos problemas no GitHub com essa tag, mas no mundo WordPress a maioria dos tíquetes de conserto são cobertos por outro problema, precisa de mais informações para justificar a correção ou apenas esperando que ninguém volte reclamando (geralmente é o caso) .

Vou ficar com minha antipatia. Minha pergunta imediata sobre "Não Consertará" é "Por que nos recusaríamos a consertar algo?" E se alguém me der uma boa resposta concisa em um tíquete, eu diria _isso_ é o que o rótulo deveria ler ao invés de 'Não consertará'.

Acho que Out of Scope é uma resposta melhor de qualquer maneira. Não vai consertar apenas implica e não fornece "nada" para a pessoa que está abrindo o problema.

talvez pudesse ir na direção certa - sinta-se à vontade para enviar uma "solução", mas a equipe não tem recursos suficientes para fazê-lo: D talvez alguém tenha uma ideia para uma abreviatura para isso ^^

Um caso de uso pode ser um bug ou violação de CS em algum recurso, que está sendo reescrito no atacado e lançado na próxima versão de qualquer maneira.

Sinta-se à vontade para deixá-lo de fora.