search

PHPSP / hexagon-project

Renovação do PHPSP
MIT License
11 stars 3 forks source link

Mudança no Processo de Criação de Propostas e Votação #27

Open pauloelr opened 9 years ago

pauloelr commented 9 years ago

Motivação

A criação desse repositório para discussões gerais sobre o PHPSP foi uma ideia muito boa do @duodraco, porém, como acredito que já foi percebido por outras pessoas, o processo de voatação através de labels se tornou muito lento pois exige que no mínimo metade +1 dos participantes vejam e aprovem cada uma das issues, o que pode variar muito dependendo da disponibilidade dos participantes no periodo

Pesquisa

Para elaboraçã dessa proposta tomei como base os processos atuais de RFC e Votação do PHP Internals (https://wiki.php.net/rfc/voting) e do FIG (https://github.com/php-fig/fig-standards/tree/master/bylaws)

Se avaliarmos hoje o processo de votação do PHP Internals temos algo do tipo:

Porém esse número leva em conta somente a quantidade relativa dos votos apresentados no periodo difinido para isso, conforme descrito no documento:

O mesmo documento defini que o autor da proposta deve definir quando a votação deve iniciar e quando deve terminar. No nosso caso acho que cabe ao autor da proposta também se responsabilizar por realizar o que for decidido ou indicar algum responsável (ou grupo de responsáveis) após já ter negociado isso com eles.

Proposta

  1. Definir tipos de Propostas, como por exemplo
    • Proposta de Evento
    • Proposta de Desenvolvimento
    • Proposta de Canal Social
    • Outras Propostas
  2. Definir o que é necessário para cada um dos tipos, como por exemplo
    • Periodo de Discussões
    • Data de Inicio da Votação
    • Periodo de Votação
    • Quantidade de Votos Necessários para Aprovação
    • Responsável (eis)

As labels então poderiam ser utilizadas para marcar os tipos de propostas e não mais os votos e os milestones poderiam ser utilizados para marcar as etapas das propostas

Conclusão

Aredito que ao modernizarmos o sistema de votação atual poderemos imprimir mais dinamizmo na aprovação dos temas propostos e tornar o processo de votação mais transparente para novos participantes

williamespindola commented 9 years ago

E veja se eu entendi. Se cria a proposta ela tramita, entre uma data se durante a data ela atingir a quantidade necessária ela é implementada se não morre. É isto?

Algumas das discussões no hexagon não tiveram a quantidade de votos mas foram executadas com êxito. Talvez a implementação de votos negativos e neutros pode ajudar na votação. Exemplo, caso alguém não se interessa ou não tenha opinião sobre ela vota nulo, a partir dai a quantidade para aprovação pode diminuir. E o negativo atingindo a quantidade para definição mata a proposta. Ter uma data final pode ser legal.

Isto deve ser o mais simples e direto possível, porque senão via congresso nacional. hehehe

pauloelr commented 9 years ago

O voto negativo seria sim implementado, o voto nulo nesse caso é o mesmo que não votar. A decisão do tempo em que a votação deve permanecer aberta na minha opinião deveria ficar a cargo do autor da issue, mas esse é exatamento o ponto que quero que é objetivo dessa Issue, chegar a um método mais eficiente de se tomar as decisões no grupo.

williamespindola commented 9 years ago

Sim falei do voto nulo buscando diminuir a quantidade necessária para atingir a meta. Tipo, é necessário 7 se 2 se anularam é necessário apenas 5, fica mais fácil de atingir a meta e não precisa esperar a data final. Mas a data é bem legal.

pauloelr commented 9 years ago

Sim, realmente, o voto nulo poderia servir para fechar a votação antes mesmo da data limite, mas para isso precisariamos manter atualizada a lista de participantes com direito a voto, e como alguem que entra no grupo hoje passa a ter direito a esse voto.

Esse é outro ponto que já foi levantado quando conversamos sobre a criação de um sistema de karma e que poderia influenciar nas decisões dessa Issue

jpjoao commented 9 years ago

Acho que as issues no github não seja o melhor canal para isso. Apesar de dar bastante margem à discussão peca (e muito) na gerência de votos. Complicado demais para votar, contabilizar votos e entender o que esta acontecendo.

Sugiro a criação de uma sessão no site (tipo de post novo) para as "RFCs". Onde elas seria discutidas e votadas (sistema de enquete).

Dúvidas:

pauloelr commented 9 years ago

@jpjoao

Hoje concordo com você de que as issues não seriam o melhor lugar para realizar a votação. Na época nem o canal do Slack ainda não existia, hoje acredito que ele pode ajudar nesse processo de discussão e votação, principalmente de discussão, mas as issues ainda poderiam ser utilizadas para discutir alterações nos documentos e os Pull Requests para validar os documentos que descrevem as decisões antes de serem de fato publicados.

jpjoao commented 9 years ago

Vejo duas possíveis soluções: Issues são quase que exclusivamente apenas para problemas. Se tem um problema, abre a issue e pronto.

Modificações e sugestões seria feitas pro RFCs que, se é quando aprovadas, gerariam uma issue.

PRs seriam criados contra issues e pronto.

Ou: Issues são criadas para qualquer coisa. Relatam o problema ou sugerem melhoria.

Pessoas entram lá e opinam. Em algum momento uma RFC surge e se rejeitada fecha a issue.

PRs são feitos contra issues com RFCs aprovadas.

Eu acredito mais na primeira opção.

O que tem acontecido hoje (motivo de minha crítica) é que o mesmo tema é discutido em vários lugares (às vezes em várias frentes nos mesmos lugares) e nada avança. Essa issue mesmo tem uma duplicada nesse repo e esta também sendo discutida no Slack.

On Wednesday, March 18, 2015, Paulo Eduardo notifications@github.com wrote:

@jpjoao https://github.com/jpjoao

Hoje concordo com você de que as issues não seriam o melhor lugar para realizar a votação. Na época nem o canal do Slack ainda não existia, hoje acredito que ele pode ajudar nesse processo de discussão e votação, principalmente de discussão, mas as issues ainda poderiam ser utilizadas para discutir alterações nos documentos e os Pull Requests para validar os documentos que descrevem as decisões antes de serem de fato publicados.

— Reply to this email directly or view it on GitHub https://github.com/PHPSP/hexagon-project/issues/27#issuecomment-83104651 .

Sent from my GMail

pauloelr commented 9 years ago

Eu acredito mais na segunda opção, acho meio difícil controlar quais issues as pessoas vão abrir, ainda mais sendo esse um repositório público (com razão de ser).

Agora sobre discutir as issues em diversos canais eu não vejo isso como um problema, acho que elas podem sim ser discutidas onde cada um achar melhor, veja o caso do php.net, existe a lista de discussões onde devem ser anunciados os RFC's e Votações, mas as discussões não se restringem a essa lista, muita coisa é discutida nas próprias redes sociais, como Twitter e Facebook, canais do IRC também são frequentemente usados para discutir as RFC's

A única coisa que acho que tem que ser centralizado é um lugar fácil para votação (o php.net tem a wiki com o próprio sistema de votação, controle de acesso e karma) e um lugar onde ficariam documentadas as decisões que forem tomadas (O FIG documenta isso em arquivos Markdown no próprio repositório que são espelhados com uma formatação melhor no site deles, mas o site é somente um espelho, os documentos oficiais estão no repositório).

Concluindo, acho impossível limitar as discussões e as issues, e por isso acho que deveríamos focar mais em regulamentar o que é possível como votação e karma.

jpjoao commented 9 years ago

Do Slack: @pauloelr Você tem razão. Eu não desliguei meu cérebro corporativo antes de pensar nas soluções. Como comunidade faz mais sentido “abrir as pernas” pra issues. O que eu disse de discussão em vários lugares, na verdade era mais o problema de vários lugares para votar e não discutir. Por ter 2 issues abertas e usar as issues pra votar poderia ter uma coisa aceita em uma e rejeitada na outra.

Se forem criadas várias issues sobre o mesmo tema, podemos fechar todas e unificar em uma única com uma RFC e uma única votação. Não sei, temos que discutir isso.

Mas acredito ser um consenso que precisamos de uma solução para as RFCs, suas votações e consequentes decisões. Acho que seria possível, ao menos no princípio, fazer um esquema de usar um "post type" para criar as RFCs, instalar um plugin de votação só para usuários de ao menos um certo role (talvez um genérico de "membro ativo da comunidade"). o flow seria: usuário cria conta no site, envia a RFC, um moderador aprova a RFC e cria a votação; Votação rola e decisão é tomada.

Note que ignorei o karma e fui vago no que significa "membro ativo da comunidade". Ambos foram propositais.

jpjoao commented 9 years ago

Acabo de lançar a versão 0.0.1 (focado em RFC) do plugin de wordpress wit-like-post: https://github.com/jpjoao/wti-like-post/tree/0.0.2

Essa versão permite a escolha da categoria de posts que é para entrar em votação, votos sim e não para usuários logados, mostra os votantes, possui data limite (por post) para fim da votação.

jpjoao commented 9 years ago

Plugin agora conta com sistema de "karma". Somente usuários com essa opção podem votar. Somente admins podem colocar ou tirar karma de usuários. Karma, por enquanto, é booleano. Quando tivermos um sistema de métrica para karma ele pode ser baseado em valor mínimo. O voto pode ser modificado a qualquer momento (enquanto a votação estiver aberta).

image

Detalhes em: https://github.com/jpjoao/wti-like-post/tree/dev