Reunião de Desenvolvedores do I2P - 07 de abril de 2016

20:00:05 <zzz> 0) Oi 20:00:05 <zzz> 1) Itens em aberto das reuniões anteriores http://zzz.i2p/topics/2093 20:00:05 <zzz> 2) Substituição dos papéis e serviços do kytv http://zzz.i2p/topics/2098 20:00:05 <zzz> 3) Atualização do planejamento da 0.9.26 http://i2p-projekt.i2p/en/get-involved/roadmap http://zzz.i2p/topics/1960 20:00:05 <zzz> 4) Planejamento para a HOPE http://zzz.i2p/topics/1968 20:00:05 <zzz> 5) Breve revisão das reuniões mensais e da gestão do projeto após 3 meses 20:00:10 <zzz> 0) Oi 20:00:12 <zzz> oi 20:00:38 <zzz> 1) Itens em aberto das reuniões anteriores http://zzz.i2p/topics/2093 20:00:55 <orignal_> oi 20:01:00 <zzz> - Preparação da campanha de reseed, até o fim de janeiro: 20:01:00 <zzz> ** Sadie vai contatar o backup para discutir ABERTO, nova data 5 de abril 20:01:11 <zzz> sadie, status? 20:02:10 <zzz> - Fortalecendo a rede - página inicial e páginas adicionais 20:02:10 <zzz> ** str4d, gravy, cacapo: Adicionar casos de uso, no que somos melhores, mais "paixão" e "substância", adicionar / destacar o Bote, até o fim de janeiro ABERTO, str4d vai adicionar casos de uso ao site até 6 de mar., mais mudanças sobre paixão etc. até 5 de abr. 20:02:15 <zzz> str4d, status? 20:03:06 <zzz> - Adicionar a "Story" da I2P / histórico / por quê 20:03:06 <zzz> ** comraden vai editar / lapidar / aprimorar / publicar até o fim de fevereiro ABERTO, nova data 1º de abr., rascunho de volta para zzz até meados de março 20:03:11 <zzz> comradenosebleed, status? 20:03:34 <str4d> oi 20:04:40 <zzz> Gerenciamento de tickets - atualmente ad hoc 20:04:40 <zzz> ** Sadie vai revisar, fazer recomendações ou possivelmente começar a gerenciá-los (para quando?) ABERTO, str4d e sadie para agendar reunião ou fazer relatório até 5 de abril(?) 20:04:50 <zzz> sadie, str4d: status? 20:05:49 <hottuna> oi 20:05:59 <zzz> str4d ABERTO - lançamento do Android 0.9.24 em 3 de mar., lista de TODO compilada até 6 de mar., rascunho do roadmap até 6 de mar., para revisão em 5-6 de mar. 20:06:05 <zzz> str4d, status? 20:06:33 <str4d> Discutimos isso 20:06:41 <str4d> (desculpe, fazendo 2 reuniões ao mesmo tempo) 20:06:54 <zzz> str4d e zzz vão revisar o ticket VRP até 12 de fev.; Vamos tomar algumas decisões durante as reuniões do roadmap em 5-6 de março (zzz fez em 8 de fev., str4d até 6 de mar.) 20:06:56 <str4d> sobre: tickets 20:06:57 <zzz> str4d, status? 20:07:29 <zzz> sadie e anonimal vão trazer edições do CoC baseadas no Monero 0mq na reunião de 5 de abril 20:07:36 <zzz> sadie, anonimal: status? 20:08:25 <str4d> Eu decidi anteriormente ter o status "new" para tickets que precisam de triagem, e ainda acho que esse é o caminho a seguir 20:09:00 <str4d> Também acho que pode ser uma boa ideia definir um horário regular para alguns de nós passarmos por esses tickets 20:09:09 <str4d> sobre: android 20:09:59 <str4d> Ainda não aconteceu porque estou bloqueado no script de build 20:10:17 <eche|on> uhh 20:10:54 <str4d> Ticket VRP: ainda não aconteceu porque eu estive doente quando planejava trabalhar nisso 20:11:00 <zzz> está claro que o estilo atual de gestão do projeto não está funcionando porque nada está acontecendo. Vamos seguir, e coloquei 5) na pauta para decidir se devemos continuar com reuniões mensais ou não 20:11:10 <zzz> quase todos esses itens têm 3 meses e 1/3 20:11:19 <str4d> O que aconteceu, que não está na lista do zzz, é que terminei a migração das especificações e estou bem avançado na migração das propostas 20:11:37 <zzz> ótima notícia sobre especificações/propostas, bom trabalho 20:12:09 <str4d> Então eu diria que "nada" é incorreto, apenas movendo priorizações que não se refletem no estilo atual de GP 20:12:17 <str4d> Então sim, precisamos refinar 20:12:20 <zzz> ok. boa perspectiva 20:12:25 <zzz> mais algo em 1) ? 20:13:04 <str4d> Para todos os demais, as coisas das propostas estão em http://vekw35szhzysfq7cwsly37coegsnb4rrsggy5k4wtasa6c34gy5a.b32.i2p/spec/proposals - por favor, revisem e comentem :) 20:13:26 <zzz> 2) Substituição dos papéis e serviços do kytv http://zzz.i2p/topics/2098 20:13:34 <zzz> há uma lista de cerca de 20 coisas que ele fazia 20:13:44 <str4d> Nada mais da minha parte 20:13:47 <str4d> (Eu fiz trabalho no I2P Android, só não consegui chegar ao lançamento) 20:13:55 <zzz> Tenho me concentrado no que vi como as maiores prioridades - launchpad e debian 20:14:14 <zzz> alguns outros estão pesquisando outras coisas, e trocamos alguns links da página inicial do console na .25 20:14:33 <zzz> para mim, a próxima coisa mais importante é o mantenedor do tails 20:15:06 <zzz> há alguém aqui que conheça tails E empacotamento debian e possa ajudar? se não, vou fazer o chamado no twitter o quanto antes 20:15:24 <zzz> seremos removidos do tails já no próximo lançamento em dois meses 20:15:32 <zzz> 2.4, creio eu 20:15:50 <zzz> é mais do que consigo assumir. Eu não farei isso. 20:16:02 <str4d> Ugh 20:16:19 <str4d> O que o Tails exige no mínimo 20:16:19 <str4d> ? 20:16:20 <zzz> o trabalho é pegar o empacotamento do debian que eu faço, ajustar/inserir no tails, testar, testar, testar, além de vários tickets do I2P no tails que já existem 20:16:49 <zzz> acho que há um grande texto que o kytv fez, está linkado no tópico do kytv no zzz.i2p 20:17:04 <zzz> basicamente a entrada para o tails é um pacote deb 20:17:19 <zzz> mas acho que eles têm uma lista de queixas acumuladas 20:17:25 <eche|on> chamado no twitter 20:17:33 <str4d> +1 no Twitter 20:17:35 <zzz> mais alguém tem algo a relatar sobre a substituição do kytv? 20:18:07 <str4d> Não avancei mais no servidor de CI (integração contínua) do Buildbot desde que mencionei no IRC uma ou duas semanas atrás 20:18:23 <str4d> Vou trabalhar mais nisso neste fim de semana 20:18:42 <zzz> ok. há muito na lista, vamos cada um escolher algo importante. 20:19:02 <zzz> última chamada para 2) 20:19:46 <str4d> Se ninguém mais fizer, eu *talvez* assuma o bot/relay de IRC. Improvável por ora. 20:20:34 <zzz> acho que os builds deb estão em forma decente mas ainda há algumas coisas como arm para jessie que talvez eu tenha corrigido hoje, ou talvez não 20:21:19 <zzz> 3) Atualização do planejamento da 0.9.26 http://i2p-projekt.i2p/en/get-involved/roadmap http://zzz.i2p/topics/1960 20:21:33 <zzz> ok quero fazer 3a) cronograma e depois 3b) GMP 6 20:21:38 <zzz> 3a) cronograma 20:22:03 <zzz> o roadmap diz 'maio' e 6–7 semanas após o último lançamento, 22 de março, seria início a meados de maio 20:22:36 <zzz> nas reuniões do roadmap há um mês, chegamos a um plano ambicioso incluindo o protocolo de assinatura do livro de endereços 20:23:16 <zzz> mas tudo desmoronou no dia seguinte quando as coisas do kytv caíram e ficou menos provável que ele voltasse 20:23:36 <zzz> então ainda não comecei nada relacionado à 26. nas últimas 2–3 semanas foi tempo integral em debian/launchpad 20:24:01 <str4d> ~sete semanas a partir de agora é o fim de maio. Você acha viável? 20:24:15 <str4d> (Agora que as coisas do debian estão em grande parte sob controle) 20:24:19 <zzz> isso empurrará a 26 provavelmente para junho, e ficará bem além do prazo do tails 2.4 20:24:37 <str4d> Ugh 20:24:37 <zzz> final de maio pode acontecer, mas está ficando menos provável a cada dia 20:24:42 <str4d> Quando é o prazo do tails? 20:25:11 <zzz> não sei de cabeça. Já pedi de novo para eles incluírem a 25 eles mesmos (eles já recusaram uma vez) 20:25:23 <eche|on> Acho que junho está ok, já que o tails está sob julgamento atualmente 20:25:45 <zzz> eles não têm visibilidade do uso do i2p no tails e não ouvem nenhum clamor, então veem como mais trabalho do que vale 20:26:18 <eche|on> sim 20:26:33 <zzz> normalmente, para um recurso grande como o protocolo de assinatura do livro de endereços, eu teria terminado uma semana antes do lançamento _anterior_, pronto para 'prop' 20:26:54 <zzz> então são 3 semanas de atraso, mais o tempo de desenvolvimento, que é de pelo menos algumas semanas, ou 5 semanas de atraso no total 20:27:39 <zzz> esse é o status. Ainda não publiquei nada no roadmap oficial, mas preciso fazer isso em breve 20:27:49 <zzz> mais algo em 3a) cronograma ? 20:27:58 <str4d> O que planejamos incluir no lançamento 0.9.27 propriamente dito? 20:28:16 <zzz> veja o link do roadmap acima 20:28:31 <zzz> ntcp2/dh/pt iniciais 20:29:18 <str4d> Ainda acho que as coisas precisam acontecer na ordem lá, então o que poderíamos fazer é empurrar o protocolo de assinatura do livro de endereços para 0.9.27 20:29:27 <str4d> Isso te dá maio para trabalhar nele 20:29:47 <zzz> mas ainda não há .26. nada aconteceu. não há nada lá além de mudanças de deb 20:29:50 <str4d> E então a .26 pode ser CRLs e alguma limpeza geral talvez 20:30:08 <zzz> até alguém (incluindo eu) fazer algo, não há nada para lançar 20:30:27 <zzz> então vamos ver como vai. Também preciso tirar alguns dias para fazer meus impostos :) 20:30:37 <zzz> mais algo em 3a) cronograma ? 20:30:55 <eche|on> não se apeguem demais ao cronograma planejado 20:30:56 <str4d> Tenho alguns ajustes iniciais de UI que surgiram das minhas discussões com a sadie que posso aplicar 20:31:20 <zzz> 3b) GMP 6 20:31:25 <str4d> (não é o grande redesenho que planejei, mas alguns refinamentos gerais) 20:31:50 <zzz> após cerca de 15 meses de trabalho, tuna e eu estamos quase prontos para fazer 'prop' do branch gmp6 para o trunk para a 26 20:32:05 <zzz> tuna tem cerca de uma centena de binários compilados ao longo dos últimos 6 meses, aguardando check-in 20:32:25 <zzz> compilados de várias formas - VMs, nativo, Microsoft, sistemas emprestados, etc. 20:32:53 <zzz> tradicionalmente fazemos check-in de notas detalhadas sobre o ambiente de compilação (revisões do compilador, detalhes do SO, etc.) para cada binário que colocamos no repositório 20:33:13 <zzz> infelizmente, o tuna não manteve registros de nenhuma das compilações. 20:34:06 <zzz> então a pergunta é: recomeçamos (possivelmente nos custando 6 meses), ou eu só construo os binários para Linux e ignoro todo o resto, ou será que realmente não precisamos dessas notas e seguimos em frente com tudo que o tuna fez? 20:34:08 <eche|on> alguma chance de refazê-los? 20:34:47 <zzz> tuna diz que é impossível. qualquer um poderia construir os binários linux 32/64. mas todo o resto é problemático 20:35:00 <eche|on> boa pergunta, neste caso: refazer ou aceitar, sem meio termo 20:35:25 <eche|on> precisamos do material gmp para mac, win e arm 20:35:29 <zzz> por último o que o tuna me disse foi: pegue ou largue, ele terminou 20:35:54 <zzz> mesmo que as compilações sejam rápidas, os testes são lentos 20:36:25 <str4d> Temos o processo de teste documentado em algum lugar? 20:36:54 <zzz> se você for à última página de http://zzz.i2p/topics/1960 ele enviou todas as notas de compilação que tem 20:36:56 <eche|on> (só para constar, já aceitamos outras coisas sem notas) 20:37:07 <str4d> porque isso parece exatamente o que deveríamos colocar em um servidor de CI 20:37:38 <zzz> ele atualizou os readmes de como compilar. há algumas informações no tópico sobre como testar, e eu desenvolvi meus próprios métodos também 20:38:07 <zzz> lembre que ele lançou 13 versões da coleção de binários nos últimos 6 meses 20:38:36 <zzz> hottuna, você tem algo a acrescentar? 20:38:37 <str4d> Se alguém puder escrever uma metodologia de testes, posso transformar isso em um tipo de build no Buildbot 20:38:58 <str4d> Aí é só encontrar máquinas para conectar isso. 20:39:08 <hottuna> um segundo 20:39:24 <str4d> Estou pensando que provavelmente deveríamos investir em um Mac que possamos deixar rodando em algum lugar como buildslave 20:39:44 <hottuna> eche|on: sobre refazer: não é impossível, mas é trabalho demais para mim agora. de longe. 20:40:02 <str4d> nada muito caro, mas algo que possamos realmente usar para completar o trio (já teremos buildslaves linux e windows assim que eu acertar as VMs com o eche) 20:40:10 <eche|on> hottuna: há alguma forma de como reconstruir? 20:40:27 <zzz> mesmo que a compilação de todos os 100 arquivos acontecesse amanhã, seriam 3 meses para testar 20:40:39 <hottuna> há um documento README que _deveria_ conter tudo o que você precisa. 20:40:48 <str4d> Pelo menos, nos beneficiamos das melhorias do hottuna nos vários scripts 20:41:10 <str4d> Mas a outra questão é: se reconstruirmos agora, pulamos para 6.1 20:41:11 <zzz> além disso, há mudanças enormes no próprio código cpuid 20:41:23 <hottuna> str4d: os scripts não estão perfeitos agora, mas de qualquer forma estão melhores. 20:41:23 <zzz> certo, talvez 6.1 20:41:25 <str4d> Sim 20:41:30 <hottuna> str4d: se reconstruirmos, devemos pular para 6.1 20:41:44 <eche|on> o novo código funciona bem? 20:41:57 <hottuna> eche|on: pelo que sabemos não tem bugs (hah!). 20:42:07 <zzz> claro que nos builds debian linkamos dinamicamente, então você teria 6.1 de qualquer forma se instalado (e isso me lembra, não testamos libs dinâmicas do gmp 6) 20:42:10 <str4d> Só não sei o quanto os scripts precisam mudar para fazer 6.1, mas espero que funcione basicamente como drop-in 20:42:14 <eche|on> se os testes estiverem ok, inclua. e vamos reconstruir com 6.1 em um canal paralelo e deixar as informações entrarem depois 20:42:38 <eche|on> pelo que vejo, já testamos isso bastante bem 20:42:51 <hottuna> eche|on: a parte complicada não foi rodar os scripts em si. conseguir máquinas, configurar ambientes e testar é que foi a parte complicada/lenta 20:43:03 <eche|on> sim 20:43:13 <str4d> hottuna, é isso que quero colocar na CI 20:43:15 <zzz> vamos voltar à questão original. Queremos jogar fora 6 meses de trabalho (na verdade estamos nisso desde o início de 2015) ou podemos aceitar os binários que temos, sem notas sobre os detalhes 20:43:25 <str4d> Quantas máquinas distintas você acha que usou? 20:43:37 <zzz> vamos deixar CI etc. de lado por um momento e decidir se temos um problema ou não 20:43:52 <hottuna> str4d: deve ser basicamente drop-in, com um ou dois alvos a mais. não faz sentido não ter suporte para as arquiteturas mais recentes suportadas pelo gmp 20:44:13 <str4d> zzz, eu me inclinaria a aceitar os binários condicionado a fazermos uma migração para 6.1 20:44:24 <hottuna> str4d: ~6 ambientes distintos 20:44:29 <zzz> 6.1 está no roadmap para o fim deste ano 20:44:39 <zzz> os binários atuais são 6.0 20:44:41 <str4d> Quais são os efeitos colaterais de aceitarmos os binários? 20:44:41 <hottuna> str4d: nenhuma máquina necessariamente se estiver cross-compilando 20:44:51 <str4d> 1) eles vão parar no mtn 20:45:01 <zzz> lembrem também, isso nos dá grandes ganhos de velocidade em certos hardwares, e também tempo constante 20:45:17 <str4d> 2) eles serão incluídos nos arquivos de atualização e instalação relevantes 20:45:21 <zzz> 'efeito colateral' = coisas ruins? 20:45:28 <str4d> 2a) aumentando bastante o tamanho do arquivo de atualização 20:45:44 <str4d> 3) se estiver quebrado em algum sistema específico, o que acontece? 20:46:03 <str4d> Já planejávamos 1) de qualquer forma 20:46:26 <zzz> só faremos check-in dos binários se forem imediatamente 'propped' para a .26. 20:46:28 <str4d> Da mesma forma para 2), mas os binários 6.0 seriam substituídos pelos 6.1 então não é grande coisa 20:46:37 <str4d> O que me preocupa é 3) 20:46:43 <zzz> apenas binários para release serão colocados no repositório 20:47:00 <str4d> 3a) existe algum código hoje para verificar um estado de falha? 20:47:04 <zzz> 3) é um risco genérico de qualquer mudança 20:47:19 <zzz> falhas no gmp geralmente são crash da JVM 20:47:26 <str4d> 3b) Há uma forma de voltar para uma libjbigi mais antiga que funcione? 20:47:44 <str4d> (automática ou manual) 20:48:00 <str4d> Poderíamos, por exemplo, renomear a libjbigi antiga para, se houver problema, podermos dizer aos usuários "vá e renomeie este arquivo" 20:48:22 <zzz> str4d, você está explorando se deveríamos jamais mudar o jbigi? esses são impactos genéricos de mudar o gmp 20:49:14 <str4d> zzz, sua preocupação é não saber a origem precisa desses binários. Minha suposição então é que estamos preocupados que, se houver um problema, se torne muito mais difícil rastrear a fonte. 20:49:27 <str4d> Então estou pensando em termos de estratégias de mitigação 20:50:00 <zzz> poderíamos não incluir jbigi.jar na atualização 26, assim somente instalações novas receberiam. Seria um rollout mais lento. 20:50:25 <zzz> novas instalações + launchpad/deb 20:50:57 <zzz> a correção genérica é remover libjbigi.so e jbigi.jar, aí você funciona sem 20:51:01 <str4d> Isso pode ser uma boa ideia de qualquer maneira 20:51:30 <str4d> Distribuir para novas instalações e, se não ouvirmos problemas, distribuir nas atualizações no próximo lançamento. 20:51:43 <zzz> Acho que o ponto do tuna é que nada é reprodutível mesmo. São todos sistemas emprestados e VMs há muito apagadas 20:52:23 <zzz> eche|on, as informações do sistema e do msvc da máquina que o hottuna usou para os builds de win estão disponíveis? 20:53:10 <zzz> o tuna não se voluntariou para nenhuma pesquisa, mas ele não pegou emprestado o laptop da sadie também? ou é tudo inútil já que upgrades podem ter acontecido nesse meio tempo? 20:53:24 <eche|on> ele teve acesso à máquina com win 10 no meu host KVM. Posso fazer login e verificar 20:53:33 <str4d> Mmm, por isso eu gostaria de fazer os builds 6.1 no Buildbot com servidores de build que possamos rastrear. 20:53:57 <hottuna> zzz: peguei emprestados dois Macs com osx de amigos diferentes 20:53:58 <eche|on> Eu não mudei a VM em nada 20:54:33 <zzz> ninguém sequer se voluntariou para assumir um Mac gratuito que nós pagaríamos, porque ninguém quer ser o 'cara do Mac' 20:54:51 <zzz> então é realmente falta de tempo e pessoal, não de dinheiro 20:55:17 <hottuna> zzz: eu só não quero gadgets que eu tenha que carregar por aí. 20:56:01 <zzz> aqui estão as notas de build completas do hottuna: 20:56:03 <zzz> Notas de build jbigi: 20:56:03 <zzz> ------------------ 20:56:03 <zzz> Windows: compilação cruzada, hosts linux. Compilador: GCC 20:56:03 <zzz> Linux: compilação nativa. Compilador: GCC 20:56:03 <zzz> FreeBSD: compilação nativa, VM. Compilador: GCC 20:56:03 <zzz> OSX: compilação nativa. Compilador: GCC 20:56:03 <zzz> Notas de build jcpuid: 20:56:03 <zzz> ------------------- 20:56:03 <zzz> Windows: compilação nativa. Compilador: MSVC 20:56:03 <zzz> Linux: compilação nativa. Compilador: GCC 20:56:03 <zzz> FreeBSD: compilação nativa. Compilador: GCC 20:56:03 <zzz> OSX: compilação nativa. Compilador: GCC 20:56:17 <zzz> isso é suficiente ou recomeçamos? 20:57:14 <str4d> Considerando que vamos migrar para 6.1 até o fim do ano, e que esses binários tiveram testes razoáveis, estou inclinado a dizer que sim. 20:57:41 <zzz> alguma objeção? 20:57:45 <eche|on> é pelo menos um começo, mas em termos de "builds reprodutíveis do Tor" não é nada. que tipo de padrões queremos? 20:58:03 <hottuna> não 20:58:34 <eche|on> eu gostaria de incluí-los em novas instalações com a flag "temp". Sei que é trabalhoso. 20:59:14 <zzz> basicamente, os testes atuais caíram a zero. A única forma de obter mais testes é colocá-los no trunk, e em um lançamento. 20:59:17 <susbarbatus> Desculpem me intrometer; tenho vários Macs, e não tenho problema em ser um cara de Mac ou de bsd. Se alguém puder me dizer o que é necessário depois da reunião, posso avaliar se é algo em que posso contribuir, caso eu tenha conhecimento suficiente / seja aprendível. 20:59:29 <zzz> ótimo, susbarbatus 20:59:44 <str4d> susbarbatus, seria fantástico 20:59:47 <zzz> ok, então vamos pedir ao hottuna para fazer o check-in 20:59:53 <eche|on> zzz: sim, nunca dissemos que lançamento é 100% seguro e completo^^ 21:00:05 <zzz> hottuna, o branch é i2p.i2p.str4d.gmp6 (NÃO i2p.i2p.zzz.gmp6) 21:00:17 <hottuna> ok 21:00:38 <zzz> hottuna, não esqueça de dar mtn drop nos que precisam ser removidos. Quando terminar, o diretório deve corresponder exatamente ao que está no seu zip v13 21:00:50 <zzz> mais algo em 3b) ? 21:00:55 <hottuna> você quer que os jcpuid/binários antigos para plataformas para as quais não compilamos sejam removidos? 21:01:09 <str4d> susbarbatus, o que eu gostaria de configurar é um buildserver, se você puder se comprometer a manter um Mac sempre ligado e estar disponível para perguntas/assistência quando algo falhar. Em geral não exigiria muita participação da sua parte, porque o buildserver seria controlado automaticamente :) 21:01:28 <zzz> Acredito que a proposta do hottuna era que a v13 fosse _exatamente_ o que seria lançado, nada mais, nada menos. 21:01:38 <zzz> se quiser podemos revisar isso de novo depois da reunião 21:01:38 <str4d> Ou se não sempre ligado, pelo menos facilmente iniciado na configuração do buildserver 21:01:51 <hottuna> zzz: esplêndido 21:01:54 <str4d> (o buildmaster vai lidar com buildservers que não estão sempre online) 21:02:12 <zzz> vamos adiar a conversa de buildserver e passar para 4) 21:02:22 <zzz> 4) Planejamento para a HOPE http://zzz.i2p/topics/1968 21:02:23 <susbarbatus> str4d: sem problema. Posso colocar meu mac mini ~2012 para isso. É lento mas não estará fazendo mais nada. 21:02:24 <str4d> ACK 21:02:33 <str4d> ^5 susbarbatus :) 21:02:52 <eche|on> hope - consegui um ingresso para gastar 21:02:57 <zzz> Me encontrei com o Lance esta semana. a proposta continua sendo que ele forneça uma sala de conf. pequena o dia todo, no dia anterior ou posterior à HOPE 21:03:04 <zzz> isto é, 21 ou 25 de julho 21:03:22 <zzz> Deixei claro para ele que precisamos de uma data e compromisso em breve, para podermos comprar as passagens 21:03:46 <zzz> isso não seria aberto ao público. só por convite, 5–6 pessoas, apenas um encontro para reuniões de roadmap etc. 21:03:51 <str4d> Neste momento não posso me comprometer a estar lá, embora haja uma pequena chance de eu estar nos EUA até lá 21:04:00 <zzz> além disso, apresentamos a ele o que estamos fazendo e vice-versa 21:04:30 <zzz> no momento tenho eu e a sadie como certos, com comradenosebleed e lazygravy como talvez. Quem mais? 21:04:49 <zzz> e qual é a data limite para vocês organizarem as viagens? 21:05:33 <zzz> se for só eu e a sadie talvez possamos cancelar tudo, mas vamos ver 21:05:39 <zzz> alguém? 21:06:04 <zzz> hottuna vai vir? 21:06:07 <str4d> (tudo depende de quando for marcada a defesa da minha tese, ainda não faço ideia de quando será) 21:06:09 <str4d> (e também de outras coisas relacionadas a visto) 21:06:17 <str4d> Se a defesa da minha tese for antes disso, eu gostaria de estar lá (mesmo que só de passagem) 21:06:17 <eche|on> Estou interessado, mas não consigo pagar voo e hotel. esp. se nos encontrarmos mais tarde em can 21:06:17 <str4d> Então me pergunte de novo em um mês mais ou menos 21:06:45 <zzz> ok, vou manter a pressão no Lance para fechar isso, e espero que as pessoas apareçam 21:06:50 <zzz> última chamada em 4) 21:07:00 <hottuna> zzz: é realmente complicado para mim em termos de agenda. tenho que estar na UE em 16 de jul. para um casamento. 21:07:15 <hottuna> Não acho que eu me atreva a me comprometer agora. 21:07:20 <zzz> ótimo, passe por NYC na volta :) 21:07:26 <hottuna> (ou de forma alguma se tiver que ser decidido agora) 21:07:33 <hottuna> hmmph.. 21:07:44 <hottuna> não é uma ideia terrível 21:07:47 <zzz> 5) Breve revisão das reuniões mensais e da gestão do projeto após 3 meses 21:07:59 <str4d> Então me coloque como "com esperança" para o meetup, e improvável para a HOPE (já que não posso me comprometer a precisar de um ingresso, mas usarei um sobrando se eu acontecer de estar lá) 21:08:26 <zzz> ok, da minha perspectiva isso não está funcionando, quase nenhum item de ação está sendo concluído, então dá para consertar as coisas ou devemos parar com as reuniões mensais? 21:08:40 <str4d> Acho que dá para consertar 21:08:42 <zzz> se ninguém está fazendo nada, não há o que gerenciar. Não está tão ruim assim, mas está perto 21:09:11 <str4d> Pelo menos, acho as reuniões mensais úteis 21:09:30 <zzz> o objetivo também era fazer a transição da gest. do projeto para a sadie mas ela nem está aparecendo nas reuniões então isso também não está no trilho 21:09:32 <hottuna> Eu concordaria com isso 21:09:44 <str4d> Ela achou que era uma hora mais cedo 21:09:49 <str4d> Ela está em outra reunião agora 21:10:19 <str4d> (ela apareceu uma hora mais cedo e ninguém estava conversando aqui) 21:10:41 <zzz> claro, todo mundo adora reuniões quando não precisa conduzi-las. Mas eu fico parecendo um bobo perguntando todo mês se algo que alguém prometeu 3 meses atrás aconteceu. Estou cansado disso. 21:10:49 <str4d> Eu discuti isso com a sadie, e agora temos reuniões semanais definidas para nos manter no trilho com itens em que ambos estamos trabalhando 21:11:19 <str4d> zzz, então não faça do foco da reunião "você fez essa coisa" 21:11:36 <zzz> talvez isso seja dramático demais, mas com a falta de progresso e o desaparecimento do kytv acho que estamos encrencados 21:11:40 <hottuna> zzz: quando a transição para a sadie deveria acontecer? 21:11:40 <str4d> Acho que as reuniões mensais deveriam servir mais para reavaliar prioridades e reorganizações 21:11:58 <zzz> ok, então como mantemos as pessoas no trilho para fazer o que prometeram? 21:12:13 <str4d> enquanto o "você fez isso" precisa de a) mais responsabilidade pessoal e b) mais acompanhamento individual 21:12:30 <hottuna> zzz: não está ótimo de forma alguma, mas "encrenca séria" provavelmente é exagero. 21:13:02 <str4d> zzz, no meu caso, marquei reuniões semanais com a sadie para me manter no trilho, e dei a ela acesso à minha lista de tarefas do I2P para que ela possa ajudar a priorizar 21:13:07 <susbarbatus> str4d: acho que o ponto é mais que, se todos estivessem cumprindo promessas/compromissos, então o zzz não teria que fazer a pergunta "você fez isso?" ;). 21:13:12 <str4d> (só tivemos uma reunião até agora, então ainda preciso ver como isso funciona) 21:13:17 <str4d> susbarbatus, sim 21:13:50 <str4d> Precisamos ser flexíveis o suficiente para lidar com o fato de que as pessoas fazem isso por diversão/voluntariado fora do trabalho regular 21:14:13 <zzz> certo. Meu sistema atualmente é que, quando você termina algo, você relata isso no tópico do zzz.i2p para a reunião, para _não_ precisarmos ocupar tempo de reunião com isso 21:14:15 <str4d> Mas também precisamos enfatizar que se alguém não está fazendo as coisas, não está ajudando 21:14:28 <zzz> só quando as pessoas não terminam e não reportam é que precisamos perder tempo aqui 21:14:42 <str4d> e é melhor passar um item para outra pessoa do que bloquear indefinidamente 21:14:54 <str4d> (diz o cara que está bloqueando indefinidamente no I2P Android :P ) 21:15:19 <zzz> então str4d e sadie configuraram um sistema paralelo e não público de gestão do projeto como experimento. isso é interessante, mas claro que não está claro como se relaciona com o que estou fazendo, ou se devo continuar fazendo 21:15:55 <str4d> zzz, é uma parte do quadro mais amplo 21:16:28 <str4d> Como eu disse acima, acho que tentar fazer o "por que você não fez isso" em uma reunião mensal não é tão útil quanto achávamos que seria 21:16:35 <zzz> então, a gestão do projeto via meu fórum e a "cobrança" nas reuniões mensais, estou preparado para declarar como um fracasso 21:16:50 <str4d> porque, se não fizeram nada nas três primeiras semanas, é improvável que façam na última 21:17:21 <str4d> por isso acho que checagens rápidas mais regulares para pessoas que têm itens pendentes são melhores, que é o que estou tentando com a sadie 21:17:34 <zzz> neste ponto não acho que vou receber o rascunho de volta do comradenosebleed, ou um CoC (Código de Conduta), ou casos de uso no site, ou um lançamento do Android, pelo menos não até alguma data específica por mais distante que seja 21:18:10 <zzz> então proponho parar a revisão mensal de itens de ação. Como de costume, as pessoas farão ou não o que quiserem no open source, e é muito, muito difícil convencer alguém a fazer qualquer coisa por aqui. 21:18:36 <zzz> as pessoas farão o que querem, e quaisquer "cenouras e porretes" que eu tenha não são eficazes 21:19:50 <str4d> Eu voto para mantermos as reuniões mensais, e usá-las para continuar ajustando nossas prioridades com base no que *de fato* é feito e no que aconteceu no mês passado (por exemplo, o que acabamos de fazer sobre a .26 depois do kytv) 21:20:56 <susbarbatus> Bem, como está funcionando o sistema de recompensas no momento? Por exemplo, é uma boa lista pública resumida com incentivo pago. As pessoas ainda olham para isso? 21:20:59 <susbarbatus> O que quero mencionar: e micropagamentos para tarefas. 21:21:03 <str4d> enquanto isso, se alguém concorda em fazer algo, também deveria concordar em manter a sadie informada sobre o progresso, ou pelo menos dar à sadie um canal de comunicação para dar uma cobrada :P 21:21:21 <zzz> ok, então proponho deixar o cargo de gestor do projeto, a ser substituído por algum sistema e pessoa a definir. Teremos reuniões mensais, mas sem revisão de itens de ação 21:21:54 <zzz> próxima reunião será na ter., 3 de maio 21:21:58 <zzz> mais algo em 5) 21:22:10 <zzz> mais algo para esta reunião? 21:22:35 <str4d> Nada da minha parte 21:22:53 <zzz> obrigado a todos, reunião longa hoje 21:22:58 * zzz *bafs* encerra a reunião