Status do drupal-br

[Joel Wallis]

Oi Trégis, Leo, Pedro Faria, Aleagi e mantenedores.

Primeiramente, parabéns pelo trabalho que vocês fazem, mantendo o site drupal-br.org. Vos escrevo para saber em que pé anda o projeto de migrar o site para Drupal 7 e onde se encontram as documentações para ele.

Tenho algumas horas livre nos finais de semana e decidi que vou trabalhar nisso. Inicialmente vou produzir uma documentação decente do que já foi e do que ainda precisa ser feito.

Quais são os recursos previstos para a nova versão? Existem mockups? Existem protótipos navegáveis? Não estou cobrando, apenas quero saber se existem, e se não existirem, irei produzí-los antes de tudo.

Eu tenho algumas ideias para mesclar ao projeto, ideias essas que são interessantes MAS as submeterei ao nosso debate. Se rola ou não de acrescentá-las, será decidido por debate em grupo.

--
Joel Wallis

about.me/joelwallis

[GMail | Thiago Régis]

Excelente tópico, Joel. Na verdade eu já deveria ter postado essas informações antes, mas estou sem tempo até para respirar. Vai ser bom colocarmos tudo "na mesa" agora, para que outros possam ajudar. 

Eu vou expor aqui as coisas que nós decidimos (internamente) antes de criarmos uma lista pública para manutenção do DBR. Quero deixar claro que qualquer coisa que foi definida pode ser alterada, sem problemas algum.

• Primeiramente, nossa intenção não era apenas "migrar" o site para Drupal 7. Nossa ideia era redesenvolver (na nova arquitetura do D7), aproveitando para criar novas features.
• A estrutura do site seria baseada em OG. Dessa forma, os membros poderiam criar grupos de discussões baseados em interesses comuns. Isso daria uma dinâmica legal para o site e ajudaria a criar comunidades locais.
• Eu iniciei o desenvolvimento de 10 features para o novo site, conforme sugestões documentadas no dia 12/07/2011 (não fiz todas). As features estão versionadas no github e a nomenclatura seguiu o padrão sugerido pelo Pedro Faria (em tópico aberto).
• Depois disso, o Pedro Faria incrementou algumas das features, criando alguns listagens/views nas features dbr_groups e dbr_discussions. Também integrou com o Gravatar (na feature dbr_profile).
• Definimos que priorizariamos as features dbr_default (que contém as configurações básicas do site), dbr_discussions, dbr_profile e dbr_groups. Assim nós conseguiríamos concluir a parte essencial do projeto e já poderíamos começar a migrar os conteúdos do DBR atual. A partir daí, começaríamos a trabalhar nas outras features. Acho que chegamos a decidir que a dbr_tips não era necessária, poderíamos jogar tudo dentro da dbr_articles.
• Para o design, definimos o template Huddle. Ele é um tema para Wordpress, mas a arquitetura combinou muito com o que queríamos desenvolver. As listagens que o Pedro Faria criou foram baseadas nesse tema. Eu tenho uma cópia do tema aqui, com todos os arquivos fontes (inclusive PSD), posso compartilhar com todos.

Bem, acho que é isso. Se eu esqueci de alguma coisa, o Aleagi e o Xulispa poderão lembrar.

Eu realmente acho que nós precisamos documentar tudo isso que foi feito, documentar o onde queremos chegar e decidir o que manteremos e quais são os próximos passos. Se você puder ajudar nessa documentação inicial, será ótimo!

Vamos avançando por aqui... E parabéns por retomar essa discussão ;)

-- 
Abraço

Thiago Régis

http://fisqua.com

http://softfunding.com

Cursos Online de Drupal: http://cursos.fisqua.com

--
 
 

[Gedvan Dias]

Muito bom, pessoal...

As sugestões de funcionalidade estão bastante completas.

Apesar de estar com pouco tempo (mas quem não está?), me disponho também a ajudar.

Inicialmente posso trabalhar em alguns mockups de telas. Alguém já iniciou algum?

Estou pensando em começar pelo perfil do usuário, embora seja uma das mais complexas... mas acredito que será a mais legal.

Gedvan

[Joel Wallis]

Ótimo Gedvan! Show de bola! Conhece o Balsamiq Mockups?

Então, mas quais são os recursos de cada funcionalidade? O que e como será feito? Quais informações e a estrutura? Essas respostas ainda não temos, e precisamos delas pois o desenvolvimento será distribuído. Precisamos por em documentação as ideias que temos em mente.

Vamos criar tópicos aqui para discutir cada feature, e quando definirmos o que cada uma fará, como será construída, etc, publicamos isso de forma clara em uma página da wiki do Github. Podemos fazer hangouts para discutir isso com mais agilidade.

O que acham da ideia?

--
 
 

--
Joel Wallis

about.me/joelwallis

[Leonardo Silva]

Se não me falha a memória, existem documentados alguns tantos recursos que foram discutidos ao longo do tempo. Durante essa semana me comprometo em revirar as conversas, na busca de informações que possam ser úteis para soma / ampliação da documentação.

Acredito que se alguém (ou "alguéns") tiver um método eficiente de gestão e puder organizar isso será muito bom. Particularmente, acredito que a falta maior desde quando se iniciou as conversas sobre novo dbr foi a gestão da informação.

--
 
 

[Leonardo Silva]

O Bruno deu uma sugestão que achei bem bacana, no tópico "rede social para desenvolvedores" na lista drupal-br, de usar o mesmo método de issues.

O Pedro lembrou do Atrium. Mas acho que o método não funcionou pelo Atrium. Estou enganado?

[Pedro Rocha]

Olha, eu lembro de ter usado ele sem maiores problemas, para 1 tentativa de mudança do DBR mesmo e para a primeira tentativa da DrupalCamp Rio, em 2010, se não me engano. O problema não foi a ferramenta, eu acho.

No entanto, já tentei usar o Atrium para gerenciar projetos mais complexos e tive dificuldade em ser suprido, tanto que fui extendendo ele, mas tive problemas, ai abandonei a idéia de usá-lo para isso, mas por gostar muito da idéia de uma solução mais genérica ao módulo Project, que lida propriamente com projetos de software, investi no módulo Case Tracker(http://drupal.org/project/casetracker), do qual após muito pentelhar o pessoal da Phase2, me deixaram como co-mantenedor da versão para D7.

Se quiserem participar disso, seria um ótimo case para colocar à prova a versão 2.x(http://drupal.org/node/1655544), que estou fazendo com entities, etc.

abs,
Pedro Rocha

-------------

www.singleview.com.br

www.pedrorocha.net

2012/11/11 Leonardo Silva <leoopo...@gmail.com>

--
 
 

[Joel Wallis]

Legal hein Pedro! O Case Tracker é um projeto bem legal. Mas não acho que devamos descentralizar os esforços em criar uma ferramenta para gerenciar o desenvolvimento do novo drupal-br. Vamos usar algo pronto.

O Github tem as Issues e tem a Wiki. Discutimos os recursos nas Issues ou mesmos em e-mails no dbr-maintainers. As decisões, ou seja, o que for resolvido e chegar a um senso comum entre todos nós, será documentado na Wiki.

Assim poupamos nossos esforços.

[GMail | Thiago Régis]

+1

-- 
Abraço

Thiago Régis

http://fisqua.com

http://softfunding.com

Cursos Online de Drupal: http://cursos.fisqua.com

--
 
 

[Leonardo Silva]

Se for uma ferramenta plug and play que realmente faz grande diferença positiva na gestão da informação, acho que deve usar sim. Se não, pega o pronto que atende. O Atrium não usa case tracker?

Joel diz sobre gerenciamento do desenvolvimento. Acredito que para isso, tanto faz a ferramenta, desde que seja funcional. Volto a dizer sobre a questão da gestão de informação, que vem antes do desenvolvimento.

Cês conhecem o Trello - https://trello.com/? 

--
 
 

[Joel Wallis]

Eu já ia citar o Trello. Usei ele em um projeto recente e é muito bom! Podemos usar ele como gestor de tarefas.

Como ficaria o workflow então? Teríamos reuniões semanais, uma horinha em um hangout do G+ para discutir partes técnicas de uma funcionalidade, e ao decidir isso, documentar em uma página da wiki do Github, e então criar cards no Trello? Eu já acho que isso está apropriado para o momento.

O Pedro Faria me falou do git-flow e eu achei muito foda! Seria possível até manter um desenvolvimento contínuo do projeto.

Mas de antemão ressalto: não adianta usar várias ferramentas se a comunicação entre nós não for eficiente. Precisamos decidir EM GRUPO cada funcionalidade, e daí entrará a necessidade do bom senso de cada um, de saber trabalhar em equipe e respeitar ao máximo as diferenças um do outro.

Respeito acima de tudo, tanto nas limitações e/ou capacidades técnicas (teremos alguns Jrs trabalhando conosco, pois o Drupal Brasil não é nosso brinquedinho apenas) e gente de todo Brasil (eu sou cearense e não sou fodão em Drupal, então quem me chamar de cabeção ou rapadura, ou mesmo zoar minha capacidade técnica vai tomar um sacode cabuloso!). :)

E então, adotamos o workflow Hangout > Wiki do Github > Trello > Drupal e código > Git do Github?

[Leonardo Silva]

Uma questão sobre o hangout: É marcada a reunião e decide quem estiver presente, né. Caso um ou outro não possa participar não tem direito à palpite em decisão.

Digo isso porque várias vezes já aconteceu de marcar reuniões por skype em 4 pessoas e chega na hora acontece imprevisto, alguém não pode e o esquema é adiado.

Sugiro não adotar reuniões para qualquer decisão, pois excluirá muitas opiniões/idéias importantes (fugindo da democracia) ou então não irá acontecer (problema antigo já detectado e previsto inúmeras vezes em mais de 3 anos).

--
 
 

[Joel Wallis]

Ótimo. Apoio completamente. Tem poder de decisão quem estiver presente.

Mais: os assuntos do próximo hangout começam a ser discutidos assim que o hangout anterior terminar. Isso dará tempo para refletirmos nos prós e contras de cada sugestão, e até sugerir coisas melhores. Decisões hot ali, no pei-bufo, é foda.

Pra mim tá perfeito. Alguma sugestão? Por via das dúvidas vamos prolongar essa discussão até o próximo final de semana, e marcamos um hangout para falarmos sobre isso.

Próxima semana começamos o trabalho de escolha das funcionalidades e discussão de seus funcionamentos. Eu tenho algumas sugestões que trabalhei em cima para o Drupal Ceará, e acho que seria interessante para que o Drupal Brasil trouxesse retorno real para nós (não falo de dinheiro mas de reconhecimento, clientes, freelas, empregos, barcamps, contatos, business, clientes e o caralho a quatro, que também trazem dinheiro), mantenedores, e para todos os outros membros do site.

[Gedvan Dias]

Acho que os hangouts devem ser apenas para ideias e discussões (e motivação).

As decisões devem ser tomadas aqui na lista mesmo.

--
 
 

[Leonardo Silva]

Joel, eu não apoio o hangout para decisões, como eu disse. Nesse sentido, estou com o Gedvan, na opinião que as decisões devem ser tomadas de outra forma que não em reuniões (decisões tomadas na lista, por exemplo).

O que eu disse foi: se for pra tomar decisão via hangout (reunião), decide quem estiver presente (o que exclui o conceito de democracia - já disse antes mas to falando de novo pra frisar).

--
 
 

[Bruno Rios]

acho que as decisões deveriam ser tomadas por votação, por enquetes via google docs.

seria uma forma bem democrática.

os hangouts deveriam ser utilizados para discutir quais opções seriam viáveis/inviáveis.

--
 
 

--

Atenciosamente,

Bruno Rios

http://www.flashmedia.com.br

http://flavors.me/brunorios

[Joel Wallis]

Certo. Fechou a decisão por tópicos no dbr-maintainers. Vamos tentar por aqui. Se rolar, bem. Se não, apelamos pelas votações.

[Leonardo Silva]

Ô Joel, você vai ficar por conta da gestão de informação?

É um lance chato padaná de fazer, precisa ter um método bom e dedicar tempo. É uma coisa também que acho imprescindível, documentar tudo e deixar isso tudo de fácil acesso para possibilitar o desenvolvimento contínuo.

Pra fazer assim, no impulso, sem análise e avaliação de impacto e retorno, vai continuar a mesma bagunça de sempre.

--
 
 

[Joel Wallis]

Fico.

Fica assim então: eu gerenciarei as informações. Não terei tempo pra desenvolver com vcs, mas vcs são lindos e fodas.

[Pedro Rocha]

Pessoal, democracia foi um dos maiores problemas nesses 3 anos.

Democracia não é todo mundo ter poder de decisão não. Opinar, todos devem poder fazer, mas tem que ter quem bata o martelo, senão acontece o que vi muito, de gente que não participava de nada, ai vinha no final e ficava só malhando, sem acrescentar nada.

E mais ainda: todos não podem ter peso igual nas decisões. É natural e saudável que quem possui contribuições mais valiosas tenha maior peso. Valorizar somente participação também não é o caso, porque quanto mais sabemos, menos tempo livre tempos, logo, julgar que a melhor contribuição é de quem tem mais tempo livre para participar, considero equivocado.

Fica mais para anarquia do que democracia assim. Não é assim que funcionam os projetos bem sucedidos, seja open source ou não.

Está se falando muito em funcionalidades do site, mas tá errado isso. Tem que falar dos objetivos a serem alcançados com o projeto, senão vai se investir uma energia enorme em algo que pode dar resultado nenhum.

"Migrar para o Drupal 7" nunca pode ser um objetivo. Isso não leva a nada, para ninguém. Temos que aprender a pensar como gestores de um projeto, aonde cada ação tem um objetivo claro e um indicador de sucesso ou fracasso, senão nada seremos além de um monte de programadores escrevendo linhas de código(isso se fizermos código), porque dando soluções, certamente não estaremos, pois nem o problema teremos identificado.

Proponho, antes de mexer em qualquer código, pensarmos em quais são os problemas que queremos resolver e quais são os objetivos com um "novo site". Talvez, até micro-sites separados possam ser uma opção.

abs,
Pedro Rocha

-------------

www.singleview.com.br

www.pedrorocha.net

2012/11/12 Joel Wallis <joelw...@gmail.com>

--
 
 

[Joel Wallis]

Concordo e discordo.

Concordo que nem todos devem ter direito de opinião. Haverão pentelhos que só falam, criticam e não ajudam, e essas informações não serão baseadas nas nossas necessidades e no nosso trabalho. Temos que ter um critério de meritocracia mas com muita cautela. Não quero também que sejamos taxados de "donos da bola" como aconteceram com outros membros em outros projetos. Seria dar um tiro no próprio pé.

Vamos lembrar que o cliente é a comunidade brasileira, e os membros devem ser beneficiados (incluindo eu e vocês). Mas os verdadeiros membros! Os turistas que se fodam.

Discordo sobre não termos os objetivos claros. Alguns estão mais que claros para mim, outros mais que claros para o Xulispa e alguns mais que claros para você. Mas agora não é o momento de discutirmos isso. Estamos discutindo como trabalhar, para então começarmos a trabalhar.

Mas já que estamos tocando no assunto, irei fazer um breve cronograma, em outro tópico. Irei iniciar isso e vamos discutir apenas isso. Quando chegarmos a um senso comum, publicamos no Wiki do Github (nesse caso não haverá necessidade de coding, então pulamos essa parte).

Aliás, alguém pode me por como writer no projeto do Github? Meu usuário é joelwallis.

[GMail | Thiago Régis]

Joel, vou te colocar la agora.

-- 
Abraço

Thiago Régis

http://fisqua.com

http://softfunding.com

Cursos Online de Drupal: http://cursos.fisqua.com

--
 
 

[Pedro Rocha]

Bom, uma das maiores falhas em projetos é não terem os objetivos bem definidos e claros a todos os envolvidos, e como cronograma é algo a ser visto na implementação, quando já se tem tudo definido(objetivos/problemas reais a serem resolvidos, escopo, metas, etc), considero que começar pelo fim é algo temeroso.

Exatamente tudo que está sendo feito agora, foi feito antes, várias vezes, exatamente da mesma forma, só mudando as pessoas.

A única ação efetiva que mudou algo no DBR nos últimos 3 anos, foi a saída do Rafael Silva, ao entender que não estava fazendo bem à própria comunidade, por não conseguir tocar o site, e passar a bola adiante, para ver se mudava. Não teve nada relacionado a código.

Se isso não é algo a ser considerado, porque o passado é passado, temos que olhar para a frente, etc, a única coisa que posso dizer é "tomara que eu esteja errado" e desejar boa sorte a todos que forem investir energia ;)

[Joel Wallis]

"(19/11 à 25/11) discussão sobre problemas da comunidade, possíveis soluções, escolhas de funcionalidades para o projeto, definições do que será feito e quando será entregue (versão 1.0, 1.1, 1.2, etc), e quem será responsável pelo que;"

--
 
 

--
Joel Wallis

about.me/joelwallis

[Joel Wallis]

Era preciso definir o que faaremos com essas informações.

--
Joel Wallis

about.me/joelwallis

[Joel Wallis]

talvez eu tenha escolhido as nomenclaturas erradas, mas o objetivo era isso: definir como decisões serão tomadas.

--
Joel Wallis

about.me/joelwallis

[Leonardo Silva]

Os pontos que estou citando e indicando, são os pontos que presenciei e acredito, por ter passado pela experiência prática, são consideráveis.

Acredito também que o voto (não obrigatório) é um método eficaz e democrático no poder de decisão. Maiores problemas foi democracia? Nem de longe. Nem existia democracia nas questões relacionadas com a manutenção do dbr, assim não tem como uma coisa que não existe ser um problema.

Como venho dizendo, o problema maior é gestão de informação. E isso vai diretamente de acordo com as palavras do Pedro sobre objetivos. Os objetivos existem e estão documentados. Foram feitos através de entrevistas, discussões, tópicos abertos e contribuições. O grande problema: tá tudo perdido nesse mundão de informações que é a internet (leia-se listas e emails). Precisa de ajustes? Sim. Mas tem muita coisa planejada e definida, incluindo objetivos.

Joel, por favor, não me entenda mal. Não quis te atribuir uma tarefa, jamais! Até porque detesto que as pessoas façam isso comigo e esse método de atribuição de tarefas é pouco prático e nada funcional. Só gostaria que, antes de começar, não se desgastasse na função mais chata e que demanda mais tempo de dedicação, para depois ter o seu trabalho ignorado ou mal aproveitado.

--
 
 

[Joel Wallis]

Leo, eu entendo. Não fiquei chateado, até gostei da tarefa. Era nela que eu acredito me encaixar bem. Eu escrevo bem e me comunico fácil. Acho que vou contribuir bastante.

Outra coisa: NINGUÉM É OBRIGADO A COLABORAR. Colabora quem quiser, e também QUEM PUDER. Se você não pode, não colabore. Ninguém vai criticar você. Agora, se queres colaborar, COMPROMETA-SE! Você estará gastando dinheiro com isso, diretamente (seu tempo vale dinheiro e o nosso também), então não entre no projeto para brincar, por favor.

(Essa mensagem vale tanto para mim, para vocês e para os que nos acompanham nasleituras do dbr-maintainers)