Skip to content

GitLab

Last edited by Renan Ritter Soares
Page history

Gestão do Projeto

Cada projeto deve ter uma pessoa responsável e uma pessoa capacitada para orientação da pessoa responsável. Cada projeto possui seu próprio repositório onde se registra a documentação. Para a gestão e organização geral do seu projeto, sugerimos o material Gestão de projetos do CTA

Está em desenvolvimento no CTA um modelo de organização dos projetos. Nele constará o que, segundo nossa experiência, são a melhores práticas de documentação e organização de projetos. Poderão ser inclusos outros softwares de documentação e organização, além do próprio site do CTA.

Diretrizes Básicas dos Projetos

Os projetos do CTA devem possuir:

  • Objetivos claros e explícitos;
  • Planejamento (definição de tarefas): Roadmap (uma rota de ação, um mapa de ação) e Revisão de conclusão e pertinência das tarefas;
  • Comunicação (integração da equipe): Uso de e-mail e Uso adequado das notificações do site;
  • Execução (das tarefas): Definição clara de ponto de conclusão das tarefas; e Uso de ferramentas livres;
  • Registro (memória): Documentação, Organização e Licenças permissivas

Documentação

A documentação deve ser realizada no repositório git de cada projeto. Nele se tem o espaço das wikis, onde se registram informações pertinentes sobre o projeto e conteúdos associados, o repositório de arquivos, onde ficam salvos as licenças, arquivos de execução, esquemáticos e guias de uso e montagem, e as tarefas (issues), onde são registras as atas das reuniões, as tarefas e os cadernos de laboratório. Saiba mais sobre o git aqui. Cada repositório de projeto está associado a um grupo. Para se ter permissão para editar o projeto, é preciso ser membro do grupo. Por exemplo, o projeto "CTA" está dentro do grupo "Suporte CTA".

Para explicar um pouco mais de como a documentação funciona, será explicado a função de cada parte do git pensando no exemplo de um projeto de um amplificador de guitarra.

O que é o GIT?

O GIT é um sistema de controle de versões distribuído, usado principalmente para software e arquivos de textos. Além do controle de versões o git também tem um sistema de tarefas, wikis, e muitas outras ferramentas que podem ser usadas para a gestão de um projeto. O site CTA é um sistema GIT instalado nos servidores do IF/UFRGS, por isso temos todas essas ferramentas ao nosso dispor. Abaixo estão descritas algumas partes do GIT e como a usamos no CTA.

Usuários, Grupos e Projetos

Usuário: é uma conta, representa uma pessoa, por isso tem e-mail e @ próprios; cada usuário tem, automaticamente, uma página prórira onde ficam registradas as informações de atividades no site; exemplo: @renanrs . Grupo: pode ter uma ou mais pessoas, mas representa um tema, um grande projeto, da onde vários outros projetos e atividades terão origem; cada grupo tem apenas uma página, e nenhuma ferramenta, nessa página estão listados os projetos da página e uma breve descrição do grupo. Exemplo: CosmicPampa Projeto: um projeto pode ser criado diretamente da página de um usuário, ou de um grupo; no CTA os projetos devem ser preferencialmente criados a partir de um grupo, não de um usuário; dentro de cada projetos existem diversas ferramentas que podem ser usadas para o o desenvolvimento do projeto, como wikis e tarefas; exemplo: Suporte CTA

Se vocês já tem conta no site do CTA, ou no LIEF do IF/UFRGS, então você já tem um usuário no nosso GIT - caso contrário, nos mande um e-mail pedindo para criar conta! Você pode criar um projeto direto do seu usuário, ou você pode criar um grupo. Os grupos tem como objetivo reunir pessoas envolta de um mesmo projeto ou conjunto de projetos. Dentro de cada grupos é possível ter vários "projetos", que são várias etapas ou partes de um mesmo grande projeto, ou são diferentes projetos associados por um mesmo assunto. Por exemplo, o grupo "CTA" é aquele das pessoas que estão envolvidas com o CTA, e dentro desse grupo tem o projeto chamado "Suporte CTA", onde estão concentradas as informações sobre a organização do CTA, onde estão as atas de reuniões e as discussões sobre o CTA de maneira ampla. Outro exemplo é o Grupo SACADA, nesse grupos estão as várias pessoas envolvidas com diferentes etapas do desenvolvimento do SACADA, e dentro desse grupo estão vários projetos, que são partes diferentes do grande projeto SACADA, por exemplo: SACADA Pro Hardware, identidade visual do SACADA, sacada-python, etc.

Cada projeto tem, dentro de si, um conjunto próprio de wikis, de tarefas, de repositórios, etc. Isso significa que se for criada uma página Wiki no projeto sacada-python, essa wiki não vai aparecer no projeto SACADA Pro Hardware, mesmo que os dois estejam no mesmo grupo! Da mesma forma, a wiki não irá aparecer em projetos de outros grupos. O mesmo vale para a atualizações nos repositórios e tarefas. O que é feito em um projeto fica somente nesse projeto.

Repositório (arquivos)

Para projetos de software e de hardware, aqui devem estar todos os arquivos essenciais para o uso, estudo, modificação e distribuição do projeto, inclusive as licenças. Não é preciso colocar no repositório o referencial teórico, ou longas explicações sobre a motivação do projeto ou as escolhas técnicas.

O repositório é uma grande pasta onde os arquivos são guardados. O git tem um sistema de versionamento para arquivos texto. Isso significa que cada novo arquivo de texto submetido, apenas as alterações no texto em relação a versão anterior são salvas, então é fácil desfazer alterações e voltar a versões anteriores. Outra facilidade é a possibilidade de se fazer um ramo (branches). Quando um ramo de um projeto é criado, é possível que o desenvolvimento dele ocorra em dois ramos paralelos, e que, ao final, esses ramos sejam fundidos (merge) e as alterações dos dois ramos sejam somadas. Note que essa função funciona para arquivos de texto, outros formatos, como desenhos e esquemáticos não tem controle de versionamento. Isso não significa, porém, que o repositório não deve ser usado para eles. Pelo contrário, o repositório é o lugar de todos os arquivos necessário para o uso, funcionamento e montagem do projeto. A ideia é que uma pessoa interessada em reproduzir o projeto possa clonar o repositório e, a partir dos arquivos dele, reproduzi-lo.

Por exemplo, em um projeto para a construção de um amplificador de guitarra, estariam no repositório, devidamente organizados em pastas, os códigos do firmware, digamos, do Arduino, os arquivos dos esquemáticos da placa de circuito, incluindo os arquivos usados para sua impressão (os gerbers), também estariam aí os desenhos técnicos para a caixa de proteção (se for feita a mão, desenhos com detalhes de cada peça, se for impressão 3D, os arquivos CADs da peça) e arquivos de texto com lista de materiais, componentes, e guias de montagem, ou execução, para cada versão ou parte específica.

Todo repositório git tem um arquivo chamado "README.MD"; o conteúdo desse arquivo aparece na página inicial do repositório, então é essencial que nele esteja uma visão geral do projeto, explicando que informações estão no repositório, quais estão nas wikis e quais estão nas tarefas.

Pode parecer confuso de início, até porque o repositório não pode ser alterado diretamente do site, é preciso clonar o projeto para o computador, depois subi-lo de volta para o repositório. Veja mais dicas de uso do repositório aqui, ou aqui.

Obs. 1: sempre disponibilize os arquivos editáveis; por exemplo, arquivos .pdf e .stl não são editáveis, logo o projeto não pode ser modificado, por isso a importância de disponibilizar também a versão .txt/.odt e os cads. Obs. 2: disponibilize os arquivos em formatos abertos, ou seja, formatos que abrem em softwares livres; por exemplo, o arquivo .docx é editável, mas é um formato de arquivo do Word, um software proprietário; sua versão livre seria o .odt, do libre Office.

Obs.2: Projetos de estudo teórico ou de organização usam menos o repositório, de maneira que os conteúdos essenciais provavelmente estarão nas Wikis.

Wikis

As wikis são destinadas a conteúdo informativo sobre o projeto, conteúdo que é importante para que seja compreendido. Por exemplo, nela estará a explicação de o que é um amplificador de guitarra, seu funcionamento, qual o modelo escolhido, qual a etapa de desenvolvimento, qual o objetivo final, com quais outros projetos se relaciona, etc.

No caso de grupos de estudo, as wikis são um bom lugar para registras resumos, ou até produzir conteúdos inéditos, sobre os assuntos estudados.

No caso de projetos de organização interna, como o Suporte CTA, as wikis são essenciais para descreverem como a gestão do grupo funciona, informações de contatos, documentação de eventos, etc.

Tarefas (Issue)

As tarefas tem como objetivo inicial o registro de tarefas e de problemas, falhas, dos sistemas. Elas também podem ser usadas como fóruns de discussão, de uma maneira mais limitada, ou também como cadernos de laboratório. Os cadernos de laboratório são muito importantes para que se registre o andamento do projeto, registrando erros e falhas, e também para registrar testes, ou para o registro do acompanhamento da evolução de algum sistema, digamos por exemplo, o crescimento de bactérias.

Para a organização das tarefas, sugerimos fortemente o uso das etiquetas (tags), elas ajudam a organizar e classificar as tarefas, facilitando que sejam encontradas. Para o nosso exemplo em específico, alguns exemplos de etiquetas são: "reunião", "hardware", "caixa", "circuito", "firmware", "testes", "montagem", "versão0.1", "oficina", etc. As etiquetas podem ser usadas conjuntamente. Uma reunião sobre a versão 0.1 do protótipo pode ser etiquetada com "reunião" e "versão0.1". Por exemplo, as reuniões gerais do CTA são etiquetadas com "reunião', de maneira que basta clicar nesse link para acessar todas as reuniões passadas.

Um exemplo de tarefa pode ser "Desenhar o circuito da placa de amplificação". Note que uma tarefa é sempre uma ação, e a tarefa deve ter objetivos realistas e destacados, para que se entenda com facilidade sua finalidade. Nela serão registradas como o problema foi resolvido, ou as etapas do desenvolvimento. É essencial que as tarefas sejam atribuídas a alguém, e que tenham uma data limite para serem entregues. Essas são ferramentas que o git disponibiliza que contribuem muito para a organização do projeto.

Para um grupo de estudo, pode ser feita uma tarefa para cada tema, por exemplo "REA", ou para textos em específico.

Ferramentas livres - Hiperobjetos

A política de desenvolvimento do CTA está baseada no amplo uso de ferramentas livres. Sempre que possível, defendemos que o projeto deve ser desenvolvido com as opções open source das ferramentas. Por exemplo, os textos podems er esscritos em editores como o gedit, ou no Libre Office. As peças 3D podem ser desenhadas no FreeCAD, e as imagens desenhadas no Inkscape. Nem sempre a máquina que temos a disposição é um hardware aberto e livre, mas buscamos que seja possível fabricar o projeto usando o máximo de máquinas livres possíveis. Isso significa que o projeto pode ser desenvolvido num computador com windows e ser fabricado numa impressora proprietária, mas que deve prioritariamente funcionar em sistemas operacionais livres, como o Debiam, e que devem poder ser impressos em versões livres de uma impressora 3D. Por vezes, isso não será possível, como no caso do uso de máquinas de corte a LASER; como não há versões livres disponíveis, será sempre feito em uma máquina proprietária. Mesmo assim, os arquivos disponibilizados devem estar em formato aberto. No exemplo do amplificador, o microcontrolador usado poderia ser o Arduino, seu circuito ser desenhado no KiCAD ou no Fritzing, suas peças desenhadas no FreeCAD. Algumas ferramentas livres do CTA e tutoriais delas já estão registradas aqui. Um aprofundamento filosófico sobre essa questão nos leva ao conceito de Hiperobjetos, conceito que guia as ações do CTA. O assunto é abordado mais profundamente em no texto Ciência aberta: dos hipertextos aos hiperobjetos, escrito por Rafael Pezzi.

Licenças

Licenças permissivas são licenças que permitem que a obra, documentação, texto, imagens, música, etc. seja livremente usada, modificada e redistribuída. Algumas licenças exigem o direito a citação da pessoa ou grupo autora do projeto, outras não. No CTA adotamos como licenças padrões as seguintes:

Tipo Licença
Documentação, imagens, fotos, áudio-visual Creative Commons BY-SA 4.0
Códigos GNU General Public License
Desenhos hardware e peças mecânicas CERN Open Hardware Licence

Encontros periódicos

É aconselhável que cada projeto tenha pelo menos um encontro por mês e que este encontro seja sempre registrado nas tarefas do próprio projeto. Como especificado no [modelo de gestão de projetos do CTA](http://cta.if.ufrgs.br/attachments/download/2753/Gerenciamento_de_projetos_do_CTA_08_Julho_2016.odp .

Mais informações sobre os encontros periódicos podem ser encontrados no item abaixo [Dinâmicas de Reuniões e Organização, em Gestão do CTA.

Papéis

  • Mantenedor do projeto: Tem visão panorâmica sobre o projeto e atua com papel de liderança na equipe. É responsável por marcar reuniões e registros no fórum e motivar a equipe, o que exige ter especial cuidado com cada pessoa envolvida. Não é autoridade do projeto, é um(a) facilitador(a) e também atua como membro da comunidade. Posto pode ser rotativo (~ 6 meses). Gestão tem data de início e fim.
  • Zelador de Projeto: Responsável pela organização das atividades do projeto, como noção dos prazos e andamento. Cuida das reuniões (pauta, chamada, registro)e deve ter especial atenção à organização no mundo digital (documentação). Pode ter apoio dos demais para atingir seus objetivos.
  • Painel Orientador: Atua como professor(a) referência. Possui responsabilidade por introduzir o projeto aos estudantes, orientar a equipe, oferecer mentoria aos estudantes e estabelecer contatos com grupos de pesquisas, desenvolvimentos, extensão e setores da universidade ou até mesmo de outros setores sociais. Tem especial atuação em coordenar o projeto diante de alguma fonte de financiamento, como editais públicos e privados, sendo neste caso o proponente e principal responsável.
  • Colaborador: Qualquer pessoa envolvida com o projeto com eventuais atuações. Geralmente não participa ativamente da equipe de trabalho durante todo o desenvolvimento.

Leia mais em orientações iniciais para o projeto piloto Hackatona longa duração CTA

Criar um projeto

Caso você queira propor um novo projeto, esteja ciente de que todos os projetos desenvolvidos no CTA devem ser documentados publicamente nesse repositório sob licenças permissivas. Para propor um novo projeto, siga os seguintes passos:

  1. Se cadastre na lista geral e comunique ao grupo sua intenção de propor um novo projeto, ou entre em contato com um membro ativo do CTA para dialogar sobre o assunto;
  2. Apresente sua proposta na reunião semanal do CTA e dialogue com os participantes sobre a viabilidade do projeto, a infraestrutura necessária, apresentando como o projeto pode colaborar com o CTA e como o CTA pode colaborar com o projeto;
  3. Após o refinamento do projeto, proponha ele no site como descrito aqui
  4. Não esqueça de terminar de ler todo o Guia do Iniciante

Publicações acadêmicas relativas ao projeto

Para além da documentação padrão no site do CTA, é indicado à pessoa mantenedora do projeto planejar desde os primeiros passos a publicação em meios tradicionais do meio acadêmico, como os periódicos científicos.

O que há de positivo nisso? Nossos projetos ganham uma outra esfera de visibilidade, pois pessoas que costumam pesquisar por avanços científico e tecnológicos em periódicos terão maior chance de conhecê-los. Esse meio bem estabelecido de publicação também garante mais chance de financiamento para nossas iniciativas, pois essas são métricas culturalmente bem estabelecidas no meio científico. Como podemos atingir isso? É importante situar-se dentro das publicações da área (ou áreas) de pesquisa de interesse, portanto é desejável ler diversas publicações de variados periódicos. Assim é possível entender a melhor maneira de exibir os resultados de nossos projetos e inclusive identificar quais são as maiores carências da área.

Para executar esse planejamento, é sugerido um plano de ação base:

1 - Mapeamento dos periódicos:

2 - Faça teu filtro:

  • Defina critérios de interesse ou necessidade para fazer um recorte: a lista da plataforma Sucupira permite filtrar por área, por estrato de avaliação Qualis e também por palavras chave no título.
  • Estabeleça critérios seus: [O que me importa com relação à publicação? Deve ser de acesso aberto? Me preocupo com a cedência de direitos autorais? Em qual idioma pretendo publicar?[. Investigue o que é importante para você e inclua na sua lista de critérios.

3 - Listagem:

  • Percorra as listas de periódicos dos quais dispõe e selecione-os de acordo com teus critérios, fazendo uma lista filtrada.
  • Essa lista inicial deve conter o nome do periódico, o site do mesmo e informações básicas sobre os critérios de seleção. Por exemplo: nome, site, estrato, se é acesso aberto ou não.
  • Talvez caiba ser mais flexível nessa lista inicial e depois investigar mais a fundo com relação aos critérios que estabelecestes.

4 - Análise aprofundada dos periódicos selecionados

  • É hora de se aprofundar em cada um dos periódicos. Siga as seguintes sugestões no nível de profundidade que conseguires para ter uma boa visão geral inicial de cada periódico, então pare e faça sua síntese para firmar o que aprendestes. ** Explore o site. Busque palavras que remetam a orientações como: [Diretrizes/Guidelines[, [Sobre/About[, [Informações ou Orientações para autores[, [Foco e Escopo/Aims and Scope[. ** Acesse artigos publicados e os leia. Existem diferentes níveis de aprofundamento, que começam por uma visão ampla superficial que pode ir se aprofundando com o decorrer do trabalho. *** Comece lendo apenas os resumos para se situar. *** Então comece a se aprofundar, lendo também a Introdução e as Conclusões dos artigos. *** Por fim, à medida em que já tiveres uma boa visão geral e for ganhando fôlego, passe a ler os artigos por inteiro.
  • Sintetize com frases curtas baseadas nos teus critérios o que conseguistes apurar sobre cada um deles a respeito de cada periódico.

5 - Conclusão

  • Depois de amadurecer um pouco essas impressões, faça uma lista desde os periódicos que percebestes como os mais alinhados com teus critérios até os menos alinhados. É sugerido agrupá-los de acordo com semelhanças, como por exemplo: ** Periódico Preferencial ** Periódicos Prioritários (públicos, de acesso aberto, em alguns casos com uso de software livre) ** Periódicos de vanguarda na qualificação do Acesso Aberto ** Periódicos de Acesso Aberto de temática ampla e com custos minimamente acessíveis ** Periódicos de Acesso Aberto de alto impacto, temática ampla e custos altos ** Periódicos de publicação híbrida, com temáticas específicas e custos altíssimos
  • O objetivo é consolidar todo o trabalho de revisão que fizestes em uma lista que servirá de referência futura para ti e colegas, e que pode ser constantemente revisada e aprimorada.

A partir da sistematização e do aprofundamento destes passos, espera-se que fique mais fácil entender a área de publicação de interesse e como comunicar os avanços na área obtidos pelo projeto, por meio de publicações. A ideia é passar a dar mais atenção àqueles periódicos que ficaram mais ao topo da lista.

Veja um exemplo de alguém que executou esse plano de ação base em uma situação real, tanto nessa [apresentação](http://cta.if.ufrgs.br/attachments/download/5722/Leonardo_metodo_busca_analise_periodicos.pdf quanto [nesse fórum](http://cta.if.ufrgs.br/boards/52/topics/1541.

Os conteúdos dos repositórios estão sob licenças livres e são responsabilidade dos próprios autores, não representando as opiniões e posicionamento da UFRGS ou do CTA.