|
|
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](http://cta.if.ufrgs.br/attachments/download/2753/Gerenciamento_de_projetos_do_CTA_08_Julho_2016.odp)
|
|
|
|
|
|
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](https://pt.wikipedia.org/wiki/Git).
|
|
|
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.
|
|
|
|
|
|
**Wiki**
|
|
|
|
|
|
As wikis são destinadas a conteúdo informativo sobre o projeto, conteúdo que é importante para que seja compreendido, mas que não é essencial para o seu uso, execução ou montagem. Nela então 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.
|
|
|
|
|
|
**Repositório (arquivos)**
|
|
|
|
|
|
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.
|
|
|
|
|
|
No exemplo do 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](https://githowto.com/pt-BR), ou [aqui](http://rogerdudler.github.io/git-guide/index.pt_BR.html).
|
|
|
|
|
|
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.
|
|
|
|
|
|
**Tarefas (Issue)**
|
|
|
|
|
|
As tarefas tem como objetivo inicial o registro de tarefas, evidente, 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".
|
|
|
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.
|
|
|
|
|
|
### 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](http://cta.if.ufrgs.br/projects/suporte-cta/wiki/Tutoriais).
|
|
|
|
|
|
### 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](http://cta.if.ufrgs.br/attachments/download/5730/Orienta%C3%A7%C3%B5es_Iniciais_Hackatona_CTA_2018-2019.pdf)
|
|
|
|
|
|
#### 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;
|
|
|
1. 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;
|
|
|
1. Após o refinamento do projeto, proponha ele no site como descrito [aqui](https://git.cta.if.ufrgs.br/suporte-cta/cta/wikis/Organiza%C3%A7%C3%A3o-do-CTA#gest%C3%A3o-de-projetos)
|
|
|
1. 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:
|
|
|
* Confira a plataforma [Sucupira](https://sucupira.capes.gov.br/sucupira/public/consultas/coleta/veiculoPublicacaoQualis/listaConsultaGeralPeriodicos.jsf, que contém a lista completa e atualizada de periódicos avaliados pelo sistema Qualis
|
|
|
* Para uma visão ainda mais ampla e em especial caso não tenhas necessidade de publicar em periódico avaliado pela Capes, confira outras plataformas de periódico (como [DOAJ](https://doaj.org/ e [SEER](http://seer.ufrgs.br/index.php/index/index, alguns avaliados pelo Qualis) e também o [Journal of Open Hardware](https://openhardware.metajnl.com/. Para mais fontes, confira [esta wiki](http://cta.if.ufrgs.br/projects/suporte-cta/wiki/Bibliografia/edit#Revistas-e-ferramentas-de-pesquisa-foco-em-Acesso-Aberto.
|
|
|
|
|
|
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.
|
|
|
|
|
|
---- |