Proposta de Workflow

[casimiroarruda]

Vamos organizar um backlog de tarefas a fazer nos pŕoximos meses - cada um pode pegar uma tarefa e liderá-la - trabalhando assim em um esquema de Kanban. Teríamos as seguintes "colunas" (statuses) para nossas tarefas:

1. Proposta - a ideia detalhada, aberta a comentários. Quando esta ideia for aprovada por metade+1 ela passa para o próximo status
2. Preparado - Com a maioria dos membros cientes e aprovando a proposta, ela fica pronta para trabalhar em cima - para votar nessa tarefa adicione o seu label correspondente.
3. A Fazer - É uma tarefa preparada, mas já com nome de quem vai tocá-la e já em um Milestone. Pensei em Milestones mensais. Se passar o prazo do Milestone Expirar ela volta ao status de Preparado
4. Fazendo - É uma tarefa a fazer em sua essência, exceto que há alguém trabalhando nela. Para demonstrar esse trabalho devem ser ligados documentos a essa tarefa
5. Pronta - A tarefa está finalizada

O que acham? O primeiro Milestone termina no Intercon PHP

[casimiroarruda]

De fato não precisaríamos de labels para Proposta, Preparado e A Fazer - basta seguir seu comportamento:

Proposta: com menos de 6 "+1"
Preparada: com pelo menos 6 "+1"
A Fazer: já assinalada a um Milestone

[rdohms]

Usa isso aqui pra fazer a taskboard: https://waffle.io/
Exemplo: https://waffle.io/amsterdamphp/amsterdamphp.nl

[casimiroarruda]

Pensei nele logo no começo, um amigo me apresentou há um tempo - só testando mais algumas coisas ;)

[casimiroarruda]

Ahh... Hexagon: vi um artigo sobre abelhas, como elas trabalham... favos... aí vocês já viram.. :P no durgs :P

[rogeriopradoj]

Dúvida: as labels já criadas ("NOME +1"), qualquer um dos "NOMES" já consegue alterar?

[alexjunior012]

Boa tarde pessoal, desculpem minha ignorância, quais sao as mudanças que ocorrerão e como funcionará essas tarefas? Desde já obrigado.

[pauloelr]

Pergunta ao Evangelista Técnico da JetBrains aqui presente ( @duodraco ):

O YouTrack não serve exatamente a esse propósito?
Ele não teria alguma ferramenta de votação incluída?
Ele tem integração com repositórios do GitHub? Mais que um por projeto?

Acho que se o youTrack puder ajudar nisso agente pode usar ele mesmo
Pelo que eu sei o YouTrack é grátis até 10 usuários, mas não sei se quantos somos atualmente

Acho que se pudermos usar ele e ele tiver essa feature podemos mudar essa questão de votação pra lá e ter uma visão melhor do todo centralizada em um só lugar.
Se der também pra integrar com mais de um repositório do GItHub podemos também fazer o que eu tinha sugerido anteriormente e criar um repositório para cada coisa, como por exemplo um para o plugin de meetup e um outro para manter separado o tema de WP do PHPSP e controlaríamos as issues de todos eles do YouTrack

Essas são minhas sugestões, quando ao resto 👍 também

PS1: Respondendo ao @rogeriopradoj acho que não porque eu ainda não consigo incluir minha tag.
PS2: LInkando aqui o inicio da discussão para quem não tinha visto ainda: PHPSP/phpsp-blog#14 cc/ @alexjunior012

[casimiroarruda]

@pauloelr Tem sua tag ali - Paulo +1 :P Pensei no Github a principio para não direcionar a comunidade a mais uma ferramenta, que é um dos nossos problemas hoje, pelo menos por enquanto
@alexjunior012 O começo da conversa não está aqui, mas ainda é uma proposta de como tocaremos nossas atividades.

A ideia é que quem pode incluir tags são os membros mais ativos do grupo - que estamos chamando de evangelistas do PHPSP. Se você quer votar, e seu nome não está ali fale com um dos atuais membros mais ativos do PHPSP e saiba como ajudar... alias isso pode virar uma issue também :D

[pauloelr]

@duodraco eu vi que minha tag tá ali... mas eu não tenho permissão de inclui-la na discussão

[casimiroarruda]

@pauloelr vê agora

[williamespindola]

Pessoar e a idéia da breja? hehehe tem algum tempo que a issue via poder ficar sem votação?

[pauloelr]

Estava reparando aqui e consultando a política de votação do FIG e acho que esse esquema de somente +1 pode ter problemas com pessoas que não visitam o repositório com muita frequentaria e portanto acabam não votando.

Acho que uma maneira melhor de contar esses votos seria incluir também os -1 e dar um tempo limite para que as propostas sejam votadas, assim quando o tempo acabar nos calculamos a maioria apenas dos votantes e não de todos e consideraríamos os que não votaram como abstenções.

[augustohp]

Apesar de não estar tão ativo quanto todos que comentaram aqui, vou dar meus dois centavos:

Sou a favor do "A proposta esta aceita até que alguém diga o contrário". Até mesmo porque somos todos voluntários e não cobrar nenhum compromisso longo de ninguém irá facilitar a vida de todo mundo além de ser o melhor para o grupo.

Se alguém tem alguma idéia de como melhorar ou uma proposta, sou da opinião de que essa pessoa já pode (e deve) começar trabalhando nela. Se mantivermos um repositório com nossa organização bem exposta e as coisas que estão acontecendo, uma idéia nova seria uma pull request e o resto do workflow todo mundo já conhece.

Não sou contra a proposta do @duodraco, mas acho importante termos em mente que qualquer coisa que precise de muita explicação diminui potencialmente a contribuição.

Um exemplo prático

No repositório mencionado, eu imaginaria uma estrutura de diretórios parecida com isto:

.
├── 2014
│   └── julho
│       ├── intercon-php.md
│       └── phpub.md
├── README.md
└── membros.md

No arquivo do evento, cuidaríamos das tarefas, pendências e centralizaríamos as informações relevantes lá. Com relação a pedidos de ajuda ou avisos de novas iniciativos, eu utilizaria nosso blog.

Alguém tem algum update do evento? Pull request.

Alguém tem alguma iniciativa nova? Crie um arquivo com o nome da iniciativa dentro do diretório do ano e do mês (ou período) que pretende iniciar ela e faça uma pull request.

Se acordarmos que ninguém faz push para o master, e que uma pull request nunca pode ser mergeada pelo próprio autor; temos um ótimo workflow são para desenvolvedores experientes e algo que valhe ser aprendido por desenvolvedores nem tão experientes assim. #win-#win scenario.

[rogeriopradoj]

@augustohp, achei interessante essa forma, até por usar o mesmo repositório que já tinha "teoricamente" essa função de organizar o grupo.

Mas, uma coisa interessante que faltaria aí é o Workflow estilo Kanban que o @duodraco mostrou para nós, mas quem sabe mesclar os dois, não? Pull requests com reviews e tals, mais o Kanban nas Issues com as tags, milestones e afins.

---

Fazer o pessoal contribuir um pouco mais via GitHub nesse repo PHPSP/phpsp.github.com já estamos fazendo pelo menos nos assuntos tratados no PHPSP+Pub: https://github.com/PHPSP/phpsp.github.com/tree/master/WorkingGroups/PHPSP+Pub.

Quem chega lá deixa o assunto e o nome da conta no GitHub. Os GitHubs são adicionados no time @PHPSP/pub-sharkbowl, e a lista de assuntos e os nomes dos participantes fica num arquivo .md com a data do evento.

Depois os participantes mandam via pull request os desdobramentos, com as premissas:

• forkar o repositório e mandar pull request
• não mesclar os próprios pull requests
• interagir nos pull requests dos outros membros e mesclá-los no fim de tudo

[casimiroarruda]

@augustohp - quando pensei em fazer nesse esquema de "aceitar", considerei o seguinte:

• qualquer user do github pode abrir uma issue - e isso pode dificultar o trabalho de priorização
• fazer algo como o "karma" do php.net - quem pode "decidir" o que fazer são os membros mais ativos.
• Se alguém que não está nessa lista de membros ativos quiser participar será obviamente bem vindo, e as permissões seriam concedidas conforme o caso.
• A ideia é que não tenham compromissos longos - não ficou claro na descrição, mas os membros ficam com a responsabilidade de julgar uma tarefa muito grande e solicitar sua quebra
• E não fica como um compromisso (até por isso nem chamei nada de sprint aqui :P) - quem pegou alguma tarefa para fazer e por qualquer motivo não conseguiu no "milestone", devolve ela para o backlog para que outro possa fazê-la ou ajudar.

E você está correto em questionar isso e concordo que qualquer coisa complicada desmotiva a colaboração - embora eu não acredite não exista algo completamente simples para todos - mesmo o esquema de PR ainda é obscuro mesmo para usuários de github, e principalmente iniciantes - os quais devemos atenção também.

Só queria lembrar que, apesar de já termos inclusive votado nessa issue, ela tem que ser considerada um RFC - o qual precisa ser resolvido de maneira mais ágil que no php ou http ;)

[augustohp]

Mas, uma coisa interessante que faltaria aí é o Workflow estilo Kanban que o @duodraco mostrou para nós, mas quem sabe mesclar os dois, não? Pull requests com reviews e tals, mais o Kanban nas Issues com as tags, milestones e afins.

Sem dúvida! A prioridade é fazer alguma coisa que favoraça a colaboração. Não tenho dúvidas de que, independente do processo, iremos aprender e melhorá-lo.

Fazer o pessoal contribuir um pouco mais via GitHub nesse repo PHPSP/phpsp.github.com já estamos fazendo pelo menos nos assuntos tratados no PHPSP+Pub: https://github.com/PHPSP/phpsp.github.com/tree/master/WorkingGroups/PHPSP+Pub.

Eu vi, animal! 🍻

Quem chega lá deixa o assunto e o nome da conta no GitHub. Os GitHubs são adicionados no time @PHPSP/pub-sharkbowl, e a lista de assuntos e os nomes dos participantes fica num arquivo .md com a data do evento.

Acho que vale uma PR pro README descrevendo essa parada.

E você está correto em questionar isso e concordo que qualquer coisa complicada desmotiva a colaboração - embora eu não acredite não exista algo completamente simples para todos - mesmo o esquema de PR ainda é obscuro mesmo para usuários de github, e principalmente iniciantes - os quais devemos atenção também.

A questão da "simplicidade" que citei, vem do fato da pessoa aprender algo que pode ser aplicado em outra ocasiões. Criarmos e mantermos um workflow nosso implicaria em manter nossas interações documentados. O que, por experiência própria, não é o que acontece.

Com as PRs, a gente tem o karma de brinde. O iniciante pode se perder, mas o tempo que ele levará para ler e aprender sobre algo; será indiscutivelmente útil no dia a dia dele e não somente dentro da comunidade. Ao meu ver, matamos dois coelhos com uma cajadada só.

Nesse contexto, essa RFC seria uma PR pro README do repositório principal e discutiríamos ali. Eu criaria meu branch a partir do seu, e alteraria o que fosse relevante. Criaria a PR, referenciaria a PR anterior e nelas que rolem as votações. No ato do merge, o karma iria pra quem fez a proposta (se a minha fosse aceita, você também ganharia karma pelo seu commit, por exemplo).

[mariorez]

Buenas pessoal.
Como estou "chegando agora" não me sinto com base para dar muitas opiniões quanto as melhorias no Workflow.

Porém, quero levantar uma questão?
Ontem tivemos um PHPSP+Pub e já temos um PR de um dos participantes para enriquecer a lista dos assuntos que foram abordados.
Seria legal que alguém aceitasse o PR dele o quanto antes, aproveitando que o assunto ainda esta "quente". Mas também não acho justo cobrar esse "imediatismo" na aprovação de nenhum membro especifico pois entendo que cada um tem o seu tempo.

Pergunto: Nesse caso eu mesmo poderia aceitar o PR de outro colega? (no caso o Diego).
Uma vez que não há a necessidade de uma review de código, apenas um verificação se o texto esta coerente sobre o que foi conversado (?).
Acredito que nesse caso especifico, em que se trata apenas de uma "pauta" do bate-papo, poderíamos ter mais flexibilidade nos aceites de PR para ganharmos mais dinamismos.

Aguardo opiniões :)

[rogeriopradoj]

@mariorez, aceita logo o PHPSP/phpsp.github.com#10 !!!

:-)

A ideia era essa mesmo, que qualquer um de nós do time do @PHPSP/pub-sharkbowl aceite o de outro colega. Então, vá em frente!