Partkeepr: Meta: Muitos problemas em aberto

então, basicamente, criamos um "backlog" de fato...
@Drachenkaetzchen você está aberto a adicionar alguns de nós ao projeto para que possamos colocar alguma ordem nos problemas?

então, basicamente, criamos um "backlog" de fato...

Tipo de. Mas, sim, essa é a ideia básica.

@Drachenkaetzchen você está aberto a adicionar alguns de nós ao projeto para que possamos colocar alguma ordem nos problemas?

Eu estaria disposto a ajudar aqui, se desejar.

Ei pessoal, esta é uma idéia muito boa e foi discutida por nós no IRC também.

Recentemente, obtive acesso ao github e vou dar uma olhada em adicionar mais algumas pessoas para ajudar com o lado organizacional a gerenciar os problemas e agradeço sua oferta para ajudar com isso.
(se devido a limitações de tempo eu esquecer, não tenha vergonha de me dar uma cutucada sobre isso)

Ok @christianlupus , adicionei você como membro do Triage a este repositório.
@baradhili você também está interessado em ajudar com isso?

Aqui estão descritos os recursos para isso: https://help.github.com/en/github/setting-up-and-managing-organizations-and-teams/repository-permission-levels-for-an-organization

Eventualmente, é claro que adicionaremos mais pessoas com acesso ao código também. Por enquanto, vamos tentar obter algum foco na organização das questões.

@dromer sim por favor

@dromer Obrigado pelo add.

Uma primeira sugestão é adicionar um rótulo needs-triage e estabelecer uma regra para colocar cada nova edição e PR neste rótulo.
Motivo: O repórter vê que uma triagem é necessária/vai ser feita. Além disso, podemos classificar (mais tarde) para esses problemas. Talvez devêssemos considerar colocar todas as questões sob esse rótulo para ver o que já foi feito e o que precisa de atenção.

E adicional: sugiro também os seguintes rótulos:

• meta : Usado para problemas não relacionados ao código em si, mas ao repositório, ao wiki, aos padrões de programação e afins
• help-requested : Usado para indicar que um problema está procurando ajuda durante a configuração, uso, etc. Isso pode ser melhor enviado para um fórum do que mantido como um problema aqui no github.

Parece bom .. embora eu sugiro que não coloquemos tudo abaixo de needs-triage porque nós simplesmente vamos acabar onde estamos agora :).. Eu também sugiro backlog , next-release e roadmap assim que colocarmos as coisas em análise

Como comecei a categorizar alguns problemas agora, achei difícil colocar rótulos neles, a menos que estejam definidos claramente (pelo menos para uma parte deles).

@christianlupus como você quer coordenar a triagem? estou em UTC+8

@christianlupus Parece que podemos precisar de outra tag "move-to-wiki"

@christianlupus como você quer coordenar a triagem? estou em UTC+8

@baradhili Estou em UTC+1 (Berlim).
Eu estava dando algumas edições alguns rótulos e um marco quando aplicável. No entanto, chega a hora de eu começar a trabalhar agora. Então vou pausar por enquanto.

Você tem alguma boa sugestão sobre a coordenação? Uma pessoa de manhã uma pessoa à noite para evitar colisões? Qual é o seu horário preferido para trabalhar nisso?

Como não sei em que cidade você mora, peguei um aleatoriamente do fuso horário nomeado: Aqui você pode obter uma visão geral rápida para gerenciar a mudança de horário. Você pode querer adotar a sua cidade.

@christianlupus Parece que podemos precisar de outra tag "move-to-wiki"

Sim, parece ser o caso.

@christianlupus Estou bug no momento. estou em Perth - provavelmente queremos sinalizar problemas complexos com algum tipo de tag para que o outro possa dar uma olhada e dar uma opinião.

@dromer, se lhe dermos uma lista de novas tags, você pode adicioná-las?

Oh, isso é algo que eu preciso fazer?

Deixe-me saber e eu vou olhar para adicionar mais alguns.

@christianlupus Estou bug no momento. estou em Perth -

OK, isso é totalmente com você. Obrigado por ajudar aqui. Estou trabalhando nas questões não rotuladas por enquanto, então não estamos colidindo.

provavelmente queremos sinalizar problemas complexos com algum tipo de tag para que o outro possa dar uma olhada e dar uma opinião.

Sim, acho que é uma boa ideia. Que tal complex-triage ?

Oh, isso é algo que eu preciso fazer?

Deixe-me saber e eu vou olhar para adicionar mais alguns.

Só podemos anexar rótulos e marcos aos problemas. Mas não podemos adicionar novos rótulos à lista de válidos. Então, sim, pedimos que você adicione os rótulos relevantes.

@baradhili Então para não temos essa lista de novos rótulos (por favor me corrija):

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

Sobre os rótulos oportunos ( backlog , roadmap , next-release ) Eu acho que isso é melhor captado por marcos, você não acha? Além disso, isso deve ser coordenado com qualquer pessoa que forneça código ao repositório.

Atualizarei este comentário assim que surgirem necessidades de novos rótulos. Tudo bem com isso? Se sim, sinta-se à vontade para perguntar ao dromer sobre isso.

@dromer
Poderíamos ter os seguintes rótulos configurados?

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

Obrigado

@baradhili Tentei organizar um pouco os rótulos em um arquivo MD . Adicionei você como colaborador para que você possa editar o arquivo.

Você está bem com as definições até onde eu as escrevi?

Tudo certo!documentação!

Em terça-feira, 14 de janeiro de 2020 às 19:36, Christian [email protected] escreveu:

@baradhili https://github.com/baradhili Tentei organizar os rótulos
em um arquivo MD
https://github.com/christianlupus/Test-PK-Pages/wiki/Issue-Labels a
mordeu. Adicionei você como colaborador para que você possa editar o arquivo.

Você está bem com as definições até onde eu as escrevi?

—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/partkeepr/PartKeepr/issues/1066?email_source=notifications&email_token=AAFC2FCNL4V3QXSEUTKI6HTQ5WPTFA5CNFSM4KF76JRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEI4JJYQ#issuecomment
ou cancelar
https://github.com/notifications/unsubscribe-auth/AAFC2FEBIIB6JH6OJENT7GLQ5WPTFANCNFSM4KF76JRA
.

--
Bret Watson
Diretor
IT Interim Management Pty Ltd T/A TICM
Turma: +61 (0)41 33 03 840
E-mail:[email protected]
"O conteúdo desta transmissão de e-mail destina-se exclusivamente ao
destinatário(s), podem ser confidenciais e podem ser privilegiadas ou não
protegidos da divulgação no interesse público. O uso, reprodução,
divulgação ou distribuição do conteúdo desta transmissão de e-mail por
qualquer pessoa que não seja o(s) destinatário(s) nomeado(s) é proibida. Se você não está
um destinatário nomeado, por favor, notifique o remetente imediatamente."

build system claramente tem a ver com o ci/cd (veja meus 2 PRs), então eu o manteria.

Vou adicionar sua lista @baradhili e espero que vocês possam pelo menos seguir em frente.
Por enquanto, acho que está tudo bem ter rótulos 'muitos' do que ter 'poucos'. Sempre podemos remover/ignorar certos rótulos.

Quaisquer cores específicas que você deseja associar a eles? :)

Ok, tarde demais, eu fui com as cores padrão por enquanto :D

@dromer Poderíamos ter um marco para 1.5.0?

@christianlupus Vou usar 1 - Ready para coisas que parecem/afirmam estar corrigidas, mas precisam ser testadas

@dromer em retrospecto .. Percebi que posso lidar com coisas que parecem que precisam ser feitas "em breve" com Must Have
@christianlupus terminou Bug .. agora trabalhando em problemas antigos sem marcos

Eu removo os rótulos como Will be closed soon! e Feedback Needed assim que um problema pode ser fechado. Isso está correto para o nosso fluxo de trabalho comum?

@dromer eu poderia ter uma tag extra .. low-hanging ? Vejo problemas de tempos em tempos que devem ser corrigidos facilmente

@christianlupus sim .. e eu deveria voltar e verificar se fiz isso

Aparentemente, o github fornece alguns 'ganchos' automatizados se você usar a tag good first issue :

Etiquetar problemas e pull requests para novos colaboradores

Agora, o GitHub ajudará potenciais colaboradores iniciantes a descobrir problemas rotulados com good first issue

Então, devo chamá-lo assim em vez disso?
Problemas com essa tag aparecerão em algumas outras visões gerais que devem incentivar as pessoas a se envolverem.

Curta em https://github.com/partkeepr/PartKeepr/contribute

funciona para mim! :)

@baradhili Eu trabalhei com os problemas não marcados agora. Para ser honesto, não vou continuar por hoje, isso foi o suficiente. No entanto, eu queria combinar com você os próximos passos. Aguardo sua resposta.

@christianlupus sim .. Descobri que posso sustentar cerca de 20/25 problemas por dia .. depois disso meu cérebro está frito ...
vou dar uma volta com ele hoje de manha..

@dromer próximos passos, provavelmente teríamos que começar a analisar a priorização .. e o mais importante .. atribuir aos devs .. temos algum devs?

@baradhili Acabei de enviar um e-mail para seu domínio ticm. Por favor, você pode verificar sua conta?

temos algum desenvolvedor?
Er... se tivéssemos não teríamos esse backlog :)

Acho que vocês estão se movendo um pouco mais rápido do que o projeto atualmente 'permite', o que é uma coisa boa, já que organizar o backlog estava atrapalhando as coisas, então espero que a priorização ajude a colocar algum foco para aqueles dispostos a contribuir. (encontrá-los, ou fazer com que eles nos encontrem, é um desafio diferente, claro)

ok pessoal .. agora temos uma lista de problemas com todos os problemas atribuídos a um marco e muitos fechados
Acho que nosso foco agora é fazer alguém desenvolver :) infelizmente eu tenho NFI em torno de ExtJS e Symfony então não posso ajudar...

opções

1. conseguimos um patrocinador e usamos freelancers no guru.com ou stackexchange
2. nós tentamos encontrar alguns nós mesmos
3. ?

Além disso, você deve certificar-se de não chutar alguém nos dentes, removendo seu trabalho duro sem entrar em contato com ele. Isso aconteceu com a minha função de impressão e desde então eu só estava observando da linha lateral o que está acontecendo aqui. Eu também fiquei com um software que é inútil na versão mais recente, porque não havia essa função adicionada novamente.

Deve haver uma estrutura clara de como lidar com essas coisas e também com decisões arquitetônicas ou o que é uma boa prática para fazer algo. O projeto em si é claramente estruturado e também pessoas que não são especialistas em php (mas especialistas em programação em outras linguagens) podem implementar as coisas facilmente com alguma ajuda nos frameworks e estruturas usadas.

@Boldie Oi Sven, especialmente os desenvolvedores _

BTW - estou assumindo que sua função de impressão faz impressão em massa? o que seria necessário para fazê-lo funcionar novamente?

Deve haver uma estrutura clara de como lidar com essas coisas e também com decisões arquitetônicas ou o que é uma boa prática para fazer algo.

Isso é principalmente correto, mas porque o projeto foi gerenciado principalmente em um projeto de uma pessoa. Não havia necessidade de definir regras para interagir com a comunidade . À medida que começamos a compartilhar o peso do projeto com várias pessoas, pode ser benéfico definir regras sobre como proceder.

O projeto em si é claramente estruturado e também pessoas que não são especialistas em php (mas especialistas em programação em outras linguagens) podem implementar as coisas facilmente com alguma ajuda nos frameworks e estruturas usadas.

Suponho que você mesmo seja um programador para poder fazer tal declaração com autoridade. Não quero ofender ninguém, mas enquanto isso, acho que é mais difícil molhar os pés desenvolvendo o código.

Eu tentei, mas foi difícil. As bibliotecas estão desatualizadas como o inferno e a documentação sobre esses códigos antigos é rara nesse meio tempo. Além disso, a documentação do projeto (por exemplo, #635) não está completa.
Não estou fazendo bullying por aqui, mas quero apontar alguns problemas críticos do software atual. Como o desenvolvedor original é praticamente inacessível no momento, precisamos de pessoas que conheçam pelo menos parte do código para colocar as coisas de volta nos trilhos. Espero que os "velhos contribuidores" possam ajudar aqui. Existem alguns bugs a serem removidos, mas o principal problema é que o software não é mais mantido e mantido em relação às dependências. Precisamos resolver os principais problemas, caso contrário o projeto IRÁ falhar.

Então eu te pergunto: Você trabalhou no código e tem experiência com as dependências relacionadas?

BTW - estou assumindo que sua função de impressão faz impressão em massa? o que seria necessário para fazê-lo funcionar novamente?

@Boldie , sugiro que você abra um novo problema para rastrear a funcionalidade ausente. Em algum momento, este problema aqui será arquivado. Como resultado, sua solicitação para que a funcionalidade de impressão volte a funcionar será esquecida pela maioria das pessoas.

BTW - estou assumindo que sua função de impressão faz impressão em massa? o que seria necessário para fazê-lo funcionar novamente?
É composto por 2 partes:

• A impressão em massa de StorageLocations / Parts para um pdf
• Imprimindo uma única peça (para etiquetas)

O primeiro era altamente integrado, mas também adiciona algumas dependências problemáticas. O segundo talvez implementado novamente melhor usando a API REST hoje. Ele ainda é rastreado em uma dessas 200 edições em aberto :)

Acabei de dar uma olhada no código: tenho alguns problemas sobre como essas coisas estão realmente funcionando. A estrutura parece usar um tipo de acoplamento fraco que é difícil de seguir. Talvez um especialista usando esse framework diga algo diferente (na maior parte do dia, tenho contato com C++ e às vezes python com django). Acabei de lembrar que também foi difícil descobrir como adicionar algumas coisas quando fiz minha primeira implementação. O problema, a meu ver, é levar esse projeto de um show mais ou menos individual para um projeto voltado para a comunidade. Infelizmente, sou a pessoa errada para ajudar no problema da dependência, mas concordo, essa deve ser a primeira coisa a resolver para diminuir o departamento técnico.

Para facilitar o desenvolvimento, sugiro configurar um tipo de ambiente que possa ser facilmente iniciado sem trabalhar duas vezes. Na minha empresa, configuramos um contêiner docker com o material e também um script para executar testes / adicionar dados de demonstração, ... para facilitar o início do desenvolvimento.

Existe uma maneira de entrar em contato com a comunidade? Acho que a maioria dos usuários não sabe que precisamos de ajuda aqui, caso contrário o projeto ficará cada vez mais desatualizado e em algum momento não poderá mais ser usado. É possível colocar uma declaração na página inicial? Como há a maioria dos downloads, as pessoas com conhecimento adequado não estão cientes da situação e deste repositório aqui.

@Boldie Boa ideia! @dromer @Drachenkaetzchen alguém tem acesso à página principal?

@christianlupus Existe uma lista aqui ou na visualização de marcos que trabalho precisa ser feito em seguida? Acho que uma das primeiras coisas é atualizar para o Symhony4 #1083 ?

@Boldie sim, houve trabalho para questões de prioridades. veja esta lista:

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

Atualizar o symfony, e outras dependências, é a maior e mais importante no momento.
(embora eu ache que a tag 'bom primeiro problema' é destinada a recém-chegados, não a uma designação 'precisa ser feito primeiro')

Existe uma maneira de entrar em contato com a comunidade?
Estamos com vários usuários no canal #partkeepr irc em irc.freenode.net
Há também os grupos do google (um público e um privado), mas acho que o rastreador de problemas + IRC são sua melhor aposta para conversar com as pessoas sobre o PartKeepr no momento (em termos de atividade).

Além disso, você deve certificar-se de não chutar alguém nos dentes, removendo seu trabalho duro sem entrar em contato com ele. Isso aconteceu com a minha função de impressão e desde então eu só estava observando da linha lateral o que está acontecendo aqui. Eu também fiquei com um software que é inútil na versão mais recente, porque não havia essa função adicionada novamente.

O motivo pelo qual tive que remover a funcionalidade está documentado aqui: https://github.com/partkeepr/PartKeepr/issues/622

Se você sente que foi chutado nos dentes, sinto muito, mas era assim naquela época.

Além disso, eu passo a maior parte do meu tempo diário escrevendo este software. por favor, entenda que se eu tiver que remover o código para fazer uma versão mais recente, então que seja. você poderia ter criado outro PR para torná-lo compatível com a nova versão

sim, estou com raiva agora. Passei tantos anos escrevendo o código de graça, fiz a maior parte do trabalho, fiz muito trabalho de suporte, tentei fazer um negócio e tudo o que recebo pelas centenas, senão milhares de horas de trabalho não remunerado, é isso.

se não fosse meu senso de responsabilidade, eu teria fechado o site e tudo mais há 2 anos.

mal tenho dinheiro nestas alturas para sobreviver um mês, tendo várias doenças que dificilmente recuperarei em breve e ainda tento manter este projecto vivo de alguma forma, embora dificilmente o consiga.

Além disso, eu passo a maior parte do meu tempo diário escrevendo este software. por favor, entenda que se eu tiver que remover o código para fazer uma versão mais recente, então que seja. você poderia ter criado outro PR para torná-lo compatível com a nova versão

sim, estou com raiva agora. Passei tantos anos escrevendo o código de graça, fiz a maior parte do trabalho, fiz muito trabalho de suporte, tentei fazer um negócio e tudo o que recebo pelas centenas, senão milhares de horas de trabalho não remunerado, é isso.

se não fosse meu senso de responsabilidade, eu teria fechado o site e tudo mais há 2 anos.

mal tenho dinheiro nestas alturas para sobreviver um mês, tendo várias doenças que dificilmente recuperarei em breve e ainda tento manter este projecto vivo de alguma forma, embora dificilmente o consiga.

Eu sei que você está em uma situação grave e este projeto incluindo a comunidade tem uma contribuição para sua situação. Eu também respeito seu trabalho e também acho que este projeto (principalmente em comparação com outros) tem uma estrutura bem feita, caso contrário eu não tentaria pensar no que posso fazer para revitalizar este projeto e como preparar uma equipe de desenvolvimento para fazer o trabalho necessário.
Não quero esquentar o passado agora. Não nos ajudará a continuar com o Partkeepr.

Do meu trabalho diário, sei que às vezes é difícil lidar com código de outras pessoas, especialmente se a pessoa não estiver acessível (para o futuro e se for necessário, todos podem entrar em contato comigo pelo endereço de e-mail do git commits ou usando o domínio e contacte-me através da minha página inicial). Todo mundo tem sua própria caligrafia ao escrever a codificação. Na minha opinião, é um tipo de habilidade para escrever código. Também tenho muita experiência com complexidade e como é difícil passar por isso, se for fazer um upgrade de uma biblioteca ou um monte de dependências. Eu fiz isso com uma equipe por meses no meu trabalho remunerado.
Então agora temos esse desafio aqui novamente e temos que pensar em uma maneira de fazer isso com a comunidade. É muito mais desafiador como em um ambiente pago onde se dirá: Faremos.

Dei uma olhada no código e como fiz algo da última vez mudou MUITO (alguém investe muito trabalho aqui!!:). Então eu tive que cavar o código novamente e começar a trabalhar. Mas para isso precisamos de uma comunicação próxima e um roteiro do que fazer a seguir. Acho que trazer de volta a funcionalidade de impressão é uma prioridade muito baixa em comparação com as outras coisas e eu ou outra pessoa podemos fazer isso mais tarde. Para mim vale mais a pena não perder meus dados com a próxima atualização do SO no futuro, porque isso também significará MUITO trabalho para migrar para outra coisa (não sei o que pode ser), deu um longo trabalho no meu tempo livre para preencher o banco de dados.

Obrigado @Boldie

@christianlupus @dromer Estou pensando que podemos fechar esse agora que as coisas estão andando de novo...!

Mais um ponto a ser discutido: Devido às mudanças no #1091, todas as novas edições terão algumas tags anexadas. Queremos ter um indicador de que nenhuma revisão humana foi realizada aqui?

Além disso, estou bem em fechar este problema agora.

como o que fizemos é diferente de uma revisão humana? :)

@baradhili isso é exatamente o que fizemos recentemente. Quero dizer o seguinte: desde que o PR nomeado foi aceito, quaisquer novos problemas terão Bug, Solicitação de recurso ou predefinição de ajuda desejada como rótulo, dependendo do tipo de problema selecionado.
Isso significa que novos problemas (que não passaram na triagem manual que fizemos recentemente) não se apresentarão como sem rótulos anexados. Portanto, não há um filtro simples no GitHub para selecionar os problemas que ainda não foram triados humanamente.

Então resumindo: queremos um need-triage ou similar para indicar.

podemos adicionar automaticamente o rótulo needs-triage no sistema de templates do github?

Sim, é uma questão de adicionar o rótulo e alterar uma linha no arquivo de modelo. Isso deve bastar.

Acabei de abrir o nº 1097 sobre o sistema de modelagem de problemas. Se o rótulo needs-triage não for desejado, sugiro remover o commit único.

fechando isso agora