Resolvendo o fluxo de trabalho do PHP Internals

Postei uma “história da carochinha”, que, como qualquer fábula, tem uma moral no final. A moral foi que apesar de as entranhas do PHP terem lá seus problemas, estes estão sendo perpetuados por um pequeno grupo, e há um claro caminho para resolver os problemas.

O artigo parece ter reverberado para muitas pessoas:

A great tale of trolls and heroes on php-internals, from @philsturgeon. http://t.co/M0F99SXtmJ

— Ben Ramsey (@ramsey) September 10, 2013

Agree with everything @philsturgeon has to say here http://t.co/tv9HkuuhI7

— Jonathan H. Wage (@jwage) September 10, 2013

@philsturgeon Hilarious & on-point as always. Thanks for writing it up for the rest of us who couldn’t cringe through yet another bitchfest.

— Nate Abele (@nateabele) September 10, 2013

Yay I’m famous! Phil tells the story of my first nightmarish foray in #PHP #internals http://t.co/wJfxNXPgNN

— Chad Minick (@cythrawll) September 10, 2013

Hora de outra história.

Passei a fazer parte do PHP-FIG enquanto os votos de PSR-1 e PSR-2 estavam finalizando, e por não ter me envolvido com a sua criação além de uns poucos feedbacks e uma ou outra sentença.

O PSR-3 chegou quando eu já era um membro ativo e tive a oportunidade de colocar algum feedback, o que foi complicado de decidir – entre outras coisas – se interfaces devem ser chamadas de FooInterface ou Fooable. Sério, foram aproximadamente 60 e-mails.

Eu vi aquela conversa acontecendo e eu era parte das conversas sobre Caching PSR, uma para clientes HTTP (que mais tarde se transformou em HTTP Messages), e alguns outros PSRs sendo discutidos.

Na época, as coisas pareciam ótimas. O FIG era o velho oeste, e estávamos fazendo a nossa parte. A lista de e-mails estava modelada internamente, estávamos todos dando nossas opiniões, estávamos progredindo aqui e ali e, por um tempo, as coisas pareciam ok. De vez em quando aparecia um troll e a situação desandava, mas nós fazíamos com que ele se moderasse e a conversa voltava ao normal.

Mas então, um ano mais tarde, apenas o PSR-3 tinha sido publicado. HTTP estava parado, Caching estava “próximo de ser votado” há meses, um novo autoloader quase passou, mas então fomos atacados com três propostas alternativas diferentes nos 45m do segundo tempo e todo tipo de loucura.

Logo ficou muito claro que essa abordagem nunca funcionaria.

Precisávamos de um fluxo de trabalho, e o PHP precisava também.

Agora, o processo interno está delineado no Como Criar um RFC. Novatos são encaminhados para um blog da Oracle para aprender sobre o processo:

Se você é novo no desenvolvimento do core do PHP, envie e-mail para a lista para julgar o interesse antes de iniciar o seu RFC. Se não houver reação (isso é provável) ou reação positiva, então crie o RFC. Desenvolvedores PHP Core com karma saberão quando pular esta etapa.

Você acabou de chegar ao PHP, e o processo é postar para os internos. Então, se não receber reação, o que fazer?

Problema 1: não obtive reação para minha mensagem e descobri semanas depois que houve um bug no sistema da lista de e-mail. Como saber que a ideia de alguém não está recebendo feedback ou que está silenciosamente aprovada?

Problema 2: apesar das recomendações precisas do guia, é comum aceitar que “um RFC sem um patch é apenas barulho”. Isso tem duas problemas:

Problema 3: não sabe C? Vá aprender, porque não vamos te levar a sério de outro modo.

Problema 4: não sabe como funcionam os detalhes do parser/serializador/etc.? Vá aprender, porque não te levaremos a sério de outra forma.

Algo como o fluxo de trabalho do FIG viria bem a calhar nessa hora. Temos a ideia da proposta “Pré-Rascunho”. Esse é apenas algum arquivo na Internet ou em algum outro lugar e não tem relação com qualquer outra coisa. Qualquer um pode colocar toda a informação que quiser – mesmo que esteja incompleta – encontrar padrinhos dentro do FIG, entre eles alguém que vai levar ao início de um Voto de Entrada.

• Qualquer um pode propor um PSR.
• Se passar do Voto de Entrada, aprovamos o trabalho na ideia.
• Existem pessoas que sabem como implementá-la e que estão interessadas.

Quando esse PSR Rascunho estiver pronto, será levado para a lista para “revisão”. As pessoas chegam nesse ponto quando ele já tem alguma forma e está mais pronto do que as ideias iniciais. As pessoas fazem várias perguntas, o meta documento é atualizado, FAQs são feitos e mantidos lá por duas semanas para que as pessoas tenham a chance de oferecer feedback.

Então, depois de duas semanas, ele vai para outro voto. Se passar por esse voto, ele é “Aceito”, e temos um novo PSR.

O PHP precisa de um fluxo de trabalho

Um fluxo idêntico não funcionaria,  no entanto, algo certamente poderia ser feito de forma a beneficiar a todos. Algo que PRECISAMOS fazer é afastar o pensamento do tipo “se você não sabe C, vá se ferrar”.

Eu entendo perfeitamente que ideias são fáceis e implementações são difíceis. Trabalhei em startups tempo suficiente para saber que todo mundo tem um milhão de ideias diariamente, muitas das quais são uma droga, irrealistas ou maravilhosas, mas que, sem uma implementação, são apenas palavras.

Não estou esperando alguém dizer “que bom, você teve uma ótima ideia, deixe que eu vou passar três semanas escrevendo esse código para você”. O que eu espero é que possamos chegar a um ponto em que grupos de três ou mais pessoas se proponham a trabalhar juntas para detalhar uma ideia, conseguir uma aprovação do tipo “sim, nós gostamos dessa ideia” de uma maioria e só então focar em COMO ela pode ser implementada antes de despender tempo e esforço para realmente implementá-la.

Por exemplo, o RFC de Nomeação de Parâmetros (Named Parameter) contém referências para as minhas sugestões de sintaxe. Essas sugestões de sintaxe vieram de mim (alguém que não toca num código C desde a faculdade), que estou interessado o suficiente no tema para colocar um conjunto de prós e contras de potenciais opções de sintaxe.

Não é melhor que essa pesquisa sobre sintaxes potenciais possa evoluir (e que as pessoas na lista de e-mails possam votar nas potenciais sintaxes) antes de alguém colocar seu tempo e esforço em criar a sintaxe?

Conseguir uma aprovação ANTES da implementação resolve MUITOS problemas.

• Evita que pessoas desperdicem seu tempo com contribuições repetidas.
• Evita que o trabalho das pessoas se apegue ao seu ego porque “seu filho” pode estar mais alinhado com o que a maioria deseja antes que eles comecem.
• Facilita o processo de RFC, já que as pessoas obviamente já delinearam um interesse no recurso ANTES que tenhamos chance de revisar o patch ou votar.

PHP Internals pode ser INCRÍVEL

Recentemente, tivemos um dia explosivo para a equipe interna, na maior parte por causa de um entendimento retumbante de coisas que não estavam ok.

O pedido para que a lista de e-mail fosse movida para um sistema de fórum foi combatido duramente no início, mas evoluiu para uma solução brilhante: melhorar a interface web para o news.php.net para manipular as threads arquivadas por lá e manipular as conversas por lá, enquanto continuaremos podendo enviar mensagens para a lista de e-mail – mantemos a comunidade em um único lugar, mas removemos outra barreira para a entrada de novos e espertos contribuidores.

Há pessoas reclamando e sugerindo que isso não resolverá todos os problemas, mas resolverá MUITOS deles. Bem parecido com um ativista pró-desarmamento que diz que “dificultar a aquisição de armas não irá resolver TODOS os crimes à mão armada!” Eu diria que “é claro que não resolverá tudo, mas qualquer porcentagem de melhora já é uma evolução, e não há bala de prata.” #trocadilho

Solucionar a interface permitirá que muitas pessoas se envolvam, aumentará a transparência e espera-se que seja capaz de trazer sangue novo ao grupo.

Esse é o passo n° 1.

Passo 2? Melhorar o fluxo de trabalho para que exista uma caminho claro para ter um recurso aprovado. No FIG, ter um processo regulamentado melhorou drasticamente a comunicação e os maus entendidos, e as pessoas precisam ler muito menos conteúdo ao mesmo tempo em que sabem melhor o que está acontecendo no grupo.

Se alguém de dentro quiser entrar em contato comigo e quiser detalhar um processo bem parecido com que fiz no PHP-FIG, por favor, faça através do meu formulário de contato, Twitter ou como achar melhor. Podemos facilmente fazer com que o PHP Internals seja um lugar produtivo onde todos são bem-vindos, com algumas poucas regras que todos podem seguir.

Não precisamos de liderança, não precisamos de um BFDL, temos apenas que parar de discutir como se fôssemos “meninas más” e fazer algo útil. Umas poucas regras podem fazer com que isso aconteça e eu ficaria feliz em escrevê-las.

***

Artigo traduzido pela Redação iMasters, com autorização do autor. Publicado originalmente em http://philsturgeon.co.uk/blog/2013/09/solving-the-php-internals-workflow