GNU Health/Contribuição

Procura-se Contribuintes! editar

O GNU Health é um projeto FLOSS e você é muito bem-vindo a contribuir. Existem várias maneiras de fazer isso, a maioria dos quais não requerem que você saiba como programar!

Traduzindo o Software editar

Fornecer o GNU Health na língua nativa do usuário é uma grande parte do sucesso. Você pode ajudar a melhorar as traduções existentes, ou criar uma nova tradução em seu próprio idioma. Traduzir o GNU Health é fácil, não requer conhecimento técnico, e tudo é feito através de uma interface web. Dê uma olhada na página Localização para obter mais detalhes sobre o processo.

Redação e Tradução da Documentação editar

A documentação do GNU Health em Wikilivros (que você está lendo agora) não está completa, e ele precisa de ajustes ou adições em cada atualização do sistema.

Se você não quiser escrever documentação, você ainda pode contribuir, traduzindo-a para a sua língua, tornando-a mais fácil para os profissionais de saúde trabalharem com o GNU Health.

Reportando Erros editar

Infelizmente quase todos os software contém bugs. Enquanto nós estamos trabalhando ativamente em corrigí-los para que você não tenha problemas, por favor, reporte qualquer erro ou anomalia que você encontrar.

Relatar um erro não leva muito tempo. É feito através da plataforma Savannah.

Dica: Para uma resolução mais rápida, inclua uma descrição dos passos que realizou para chegar ao erro, e se possível incluir captura de tela do problema. Mas tenha cuidado: Não incluir as informações do paciente nas imagens ou sua descrição!

Programação editar

O GNU Health é principalmente um conjunto de módulos Trytone a linguagem de programação utilizada é Python. O código está hospedado em Savannah e versionado em Mercurial.

Obter a sua cópia do Código editar

Você pode obter uma cópia do código mais recente, ao fazer um checkout anônimo:

hg clone http://hg.savannah.gnu.org/hgweb/health/

Você também pode ver o código online.

Estilo de codificação editar

O estilo de codificação deve seguir a diretrizes do Tryton ou então melhores práticas do Python.

Personalização e Criação de Seus Próprios Módulos editar

Se você estiver instalando GNU Health para o seu centro de saúde, as chances são de que você estará personalizando-o para alimentar suas necessidades específicas. Relatórios, controles de acesso, pontos de vista são apenas alguns dos objetos que normalmente são personalizados. O conceito principal é Não toque no código padrão ou módulos, uma vez que ele será substituído na próxima atualização e muito provavelmente vai acabar em um sistema quebrado.

Os passos recomendados para personalizar GNU Health para o seu centro são:

  1. Criar o seu módulo: é altamente recomendado que você utilize a seguinte convenção de nomenclatura para os seus módulos locais: z_health_<modulename>. Por exemplo, se seu projeto é chamado de Catalina, o nome do módulo local seria z_health_catalina. Desta forma, faz com que seja fácil detectar e diferenciar seus módulos a partir do código base. Você também pode facilmente fazer o backup deles seguindo o padrão.
  2. Herdar os objetos.
  3. Modificar ou criar novos modelos.

Se você criar um novo campo personalizado, você também deve usar a convenção de nomenclatura z_<fieldname>. Isso evita colisão com nomes de campo futuros dos lançamentos oficiais. Não usaremos qualquer módulo, classe ou nome do modelo começando com z_.

A partir do GNU Health 2.8, haverá um diretório chamado Local em ~/gnuhealth/tryton/servidor/modules. Por favor, coloque seus módulos locais que contêm as personalizações para seu projeto nesse diretório.

Por favor, consulte o guia do desenvolvedor Tryton para mais informações sobre como criar um módulo.

Submissão de Correções editar

Colaboradores regulares têm acesso de escrita ao repositório de código. No entanto, se você está apenas começando, nós queremos ter certeza de que as alterações foram revisadas. A maneira de fazer isso é abrir um bug descrevendo o problema que você arrumou ou o recurso que você adicionou, e anexar a correção ao relatório de erro. Um dos desenvolvedores irá rever a sua correção e se aprovada submeterá ao ramo principal de desenvolvimento.