Github

A plataforma Github, além de ser um repositório para armazenamento e versionamento de código, é considerada como plataforma de programação social (social coding), ou seja, oferece aos desenvolvedores mecanismos que facilitam a formação de redes sociais, a colaboração e o compartilhamento de conhecimento.

A observação não-participante da comunidade Demoiselle no GitHub, a partir de inserção e navegação, revelou que em geral os mecanismos sociais da plataforma são pouco utilizados/explorados pela comunidade Demoiselle. Esse foi o caso do mecanismo de revisão de código (pull request), que permite que um pedido de mudança seja aberto para um repositório no Github e seja discutido e analisado por outros colaboradores antes que as alterações sejam incorporadas (ou não) no repositório.

De acordo com o protocolo de pesquisa, o mecanismo de pull request se aproxima do modo combinação do processo SECI (NONAKA, 1994), à medida que um certo conhecimento, explicitado por meio do código embutido em uma proposta de alteração, seja compartilhado, analisado e, principalmente no caso de haver ciclos de discussão e melhoria da proposta até a sua aceitação e incorporação, represente uma sistematização de conhecimento, explicitado por meio de código, até que dê origem a um novo código, que pode ser considerado um conhecimento novo.

O GitHub permite percorrer o histórico de utilização de pull request. Analisando esse histórico, verificou-se que o mecanismo foi pouco usado no Demoiselle, na ordem de 3 a 10 vezes por ano e, nas vezes em que foi usado, não gerou maiores discussões ou compartilhamentos. Ou seja, o potencial de compartilhamento e sistematização de conhecimento do mecanismo pull request na prática foi pouco explorado pela comunidade Demoiselle, restringindo o uso desta

plataforma como se fosse um ba virtual de sistematização, conforme apresentado no Capítulo 2, Seções 2.2 e 2.3.

Infere-se que o mecanismo pull request tenha sido mais utilizado como colaboração na resolução de erros do que compartilhamento de conhecimento, embora houvesse uma expectativa de que pudesse corresponder ao conceito de ba virtual, segundo Nonaka e Konno (1998), à medida que o código-fonte tem o potencial de embutir conhecimento. É uma análise complexa, por envolver ao mesmo tempo a intermediação de uma plataforma virtual e a representação de conhecimento em código-fonte.

Outro mecanismo social que teve baixa utilização pela comunidade Demoiselle foi a formação de redes sociais por meio de seguidores (followers e

following). Dos 25 colaboradores do framework Demoiselle mais ativos, apenas 4

colaboradores apresentavam redes sociais pessoais mais significativas na plataforma. Por outro lado, a rede social formada pelas conexões entre os membros da comunidade demonstrou ter baixa densidade de conexões, com a maioria dos membros não conectados como seguidores uns dos outros, conforme pode ser observado pelo sociograma apresentado na Figura 29, onde os nós representam os membros, as letras são codificações anonimizadas e as cores representam grupos com vínculos organizacionais ou proximidade geográfica, exceto a cor azul, que representa membros cuja vinculação ou localização não pôde ser determinada.

Figura 29: Sociograma dos colaboradores no Github

Embora Amin e Roberts (2008) enfatizem a proliferação de comunidades

online e a riqueza sensorial de recursos multimídia, Johnson (2001) ressalta que

prover facilidades de comunicação e interação não significa que uma comunidade de prática online irá emergir. Por analogia, infere-se que mecanismos sociais presentes em plataformas como GitHub não garantem formação de redes sociais, e nem compartilhamento de conhecimento.

O terceiro e último mecanismo social do GitHub que foi analisado pela pesquisa foi o tratamento de questões (Issues), que se trata de uma seção onde solicitações podem ser abertas pelos interessados e ser tratadas com certa transparência pela comunidade do projeto, utilizando atributos como: (i) título e descrição do assunto; (ii) rótulos codificados por cores para categorizar e filtrar as questões; (iii) marco para associar a questão a recursos específicos ou fases do projeto; (iv) pessoa responsável por trabalhar na questão e (v) comentários que permitem que qualquer pessoa com acesso ao repositório comente a questão.

O mecanismo de Issue mostrou ser o mais utilizado35 _{pela comunidade do} framework Demoiselle, para diversas finalidades, inclusive discutir as novas

funcionalidades da versão 3. Foi percebido que a criação de issues de discussão para a nova versão conseguiu produzir uma discussão propriamente dita, com volume de troca de mensagens significativo, conforme pode ser visto na Figura 30. Nota-se que dois issues de discussão da versão 3 tiveram 87 trocas de mensagens, enquanto a média de pull requests é abaixo de 10 por ano.

Figura 30: Exemplo de Discussão no Github

Fonte: Capturado no Github (2018).

As referidas issues de discussão foram abertas a partir de convites explícitos para coletar expectativas da comunidade em temas específicos: (i) JEE, com 25 postagens e (ii) Front-end, com 62 postagens. Além disso, a comunidade utilizou, de forma cruzada com essas issues de discussão, material publicado em mídias sociais para fomentar a discussão, conforme exemplo apresentado na Figura 31.

Figura 31: Exemplo de convite à discussão

Fonte: Capturado no Github (2018).

Na Figura 24, destaca-se quantidade de mensagens, o convite com foco na discussão, a delimitação temática e o uso de link para um conteúdo complementar publicado em mídia social (Youtube).

Além da quantidade de mensagens trocadas, que pode ser considerado um indicativo de nível de atividade da comunidade, percebeu-se que dentro dessas issues de discussão, compartilhamento de experiências e de conhecimento. A Figura 32 apresenta uma postagem que exemplifica esse tipo de compartilhamento.

Figura 32: Exemplo de compartilhamento no Github

Fonte: Capturado no Github (2018).

Em meio ao conteúdo eminentemente técnico, percebe-se pela fala registrada em algumas postagens uma problematização elaborada (ex: “o histórico do demoiselle nos mostra que a evolução é lenta [...] atrapalha em todas as camadas, mas a view é a que mais sofre”), compromissada com a evolução (ex: “existe uma tendência forte [...]”), bem como a existência de um clima de abertura para fazer críticas e sugestões (ex: “quero dizer é que [...]”, “quem quiser [...] ótimo”).

Tais características de fala sugerem que o mecanismo de Issue do Github ou, mais especificamente, issues com o rótulo de “Discussão” que foram criados intencionalmente para discutir a evolução do framework, aproximam-se de características de ba ou de Contexto Capacitante, tornando-se ba virtuais, ou seja, espaços de compartilhamento de experiência/conhecimento. Tais espaços foram intencionais e temporários, ou seja, foram criados para discutir a evolução de determinado tema e foram posteriormente encerrados. Embora não haja uma intenção previamente declarada de criação de conhecimento, foi percebido que houve o

compartilhamento significativo de experiências pessoais dentro desses espaços virtuais, conforme exemplificado pela transcrição de mensagens a seguir.

Usei o demoiselle por um bom tempo depois vi que faltava acompanhar as mudanças, tive que mudar para o jhipster. Que na minha opinião é o que o demoiselle deveria ser. E eles acertaram ao escolher spring ao invés das especificações padrão JEE. Segue site do projeto https://...

Olha essa ferramenta de modelagem que o jhipster tem: https://.../ é fantastico!

Acho que cada framework terá seus propósitos, não quero dizer que o jhipster seja melhor, mas poderíamos nos inspirar nele e melhorar o nosso. Começando pela arquitetura, eles acertaram muito ao escolher spring como core. Com o spring vem um leque de soluções que dificilmente veremos no JEE 7 8 9 10 etc, a exemplo o spring boot, não vejo nada mais avançado e fácil em java do que ele, usa _live reload_ e muitas outras tecnologias integradas como social login(facebook, google), elesticsearch etc.

Espero voltar a usar o Demoiselle e gostaria muito de ajudar essa comunidade.

Oi @..., muito bacana a ferramenta de modelagem. Continuamos apostando na especificação JEE7, inclusive o Demoiselle deve abrir mão de parte dos seus códigos para delegar ao JEE7. De fato o Spring está sempre um passo na frente. Também entendo que a especificação vem evoluindo e atendendo grande parte das nossas necessidades, talvez esse seja um dos motivos para continuar apostando nela.

Fico feliz em tê-lo no grupo, esperamos contar com a sua experiência.

Finalizando a observação não-participante da comunidade Demoiselle na plataforma GitHub, a partir do Protocolo de Pesquisa – Apêndice C e respectiva Tradução para observação não-participante – Apêndice E, fez-se um registro semi- estruturado das percepções do pesquisador, que de outra forma acabariam dispersas em registros pontuais:

Qual é a estrutura das comunicações nessa comunidade?

Primeiramente, a respectiva comunidade é pública e qualquer interessado pode se tornar membro e ter acesso ao código-fonte do projeto, demais informações do projeto e links para outras fontes. O código-fonte, explicitado em linguagem de programação Java, é o principal elo de comunicação na comunidade. O código-fonte como principal elo de conexão não significa enviesamento da comunicação, se levamos em conta que a maioria dos membros da comunidade são programadores e que o framework é também um software, ou melhor, uma ferramenta para desenvolver software dentro de certos padrões. Qualquer membro pode sugerir modificações, por meio de um mecanismo de solicitação de mudança (pull request), mas somente membros

autorizados podem avaliar e internalizar mudanças. De tempos em tempos, abrem-se discussões, para revisão e redirecionamento do projeto, resultando em uma nova versão do software. A topologia da rede de comunicação revela a existência de um núcleo mais ativo e formado por poucas pessoas, e uma camada menos ativa e mais numerosa.

Quem está se comunicando com quem?

No GitHub, a comunicação é aberta para todos os inscritos, que recebem notificações de novas postagens, mas há uma gestão (monitoração e encaminhamento) das postagens por um núcleo mais ativo, de tal forma que a maioria das mensagens são trocadas entre o núcleo da comunidade e uma camada periférica menos ativa. Os indivíduos conectados por meio de mecanismos de seguir, tal como follow da plataforma Github, são notificados sobre as ações de outros membros, independente de ações de comunicação direta entre si, formando uma rede social impulsionada por notificações de ação. A par disso, os membros podem interagir com os conteúdos publicados e deixar suas informações de contato visíveis para os interessados iniciem alguma comunicação.

Quais são os comunicadores mais influentes nessa rede?

O núcleo da comunidade virtual, formando por poucas pessoas, é o grupo mais influente, assumindo um papel centralizado na comunicação. Dentro do núcleo, o volume de mensagens pode se concentrar em alguns membros em alguns períodos, enquanto em outros é mais distribuído. Eventuais papéis formais que os membros no núcleo exerçam, aparentemente não influenciam no volume e concentração de troca de mensagens na comunidade virtual.

Existe um grupo central e um grupo periférico?

Sim, é possível perceber a existência de um núcleo ativo formado por poucas pessoas e uma camada periférica significativa com membros menos ativos. Entretanto, não foi possível identificar os membros passivos, ou seja, aqueles que apenas acompanham o conteúdo da comunidade e a comunicação entre os membros mais ativos, sem interagir.

Existem ligações fracas?

É possível identificar conexões pouco frequentes, mas não é possível qualificar a vinculação de cada participante. Por outro lado, existe abertura para discussão de opiniões e interesses divergentes, inclusive para participantes externos ao patrocinador.

A seguir descreve-se o uso de mídias sociais pela comunidade framework Demoiselle.