How we work

Our repositories

Project management repositories: https://github.com/agroportal/project-management, we use a centralized project board (see https://github.com/orgs/agroportal/projects/2)
Code repositories :
- Front end
  - UI code : https://github.com/ontoportal-lirmm/bioportal_web_ui
  - Our REST API Client: https://github.com/ontoportal-lirmm/ontologies_api_ruby_client
- Backend
  - API controllers/endpoints: https://github.com/ontoportal-lirmm/ontologies_api
  - Backend models/services: https://github.com/ontoportal-lirmm/ontologies_linked_data
  - Our Graph ORM-alike to interact with RDF/SPARQL backends: https://github.com/ontoportal-lirmm/goo
  - See the others here: https://github.com/orgs/ontoportal-lirmm/repositories?type=all
- Administration command lines / jobs : https://github.com/ontoportal-lirmm/ncbo_cron
- Services
  - O’FAIRE: https://github.com/agroportal/fairness
  - Annotators: https://github.com/ontoportal-lirmm/annotators
  - NCBO proxy: https://github.com/ontoportal-lirmm/ncboproxy

The way that we manage our issues and feature request

General issues (not technical) are created in the project-management repository, and the more specific ones (technical) are directly created in the related repository ( e.g if we know that the issue is directly and only related to the models, then the ontologies_linked_data is the target)

In all most all our repositories we have those issues labels (types)

Feature request issues (with the labels: bug, feature request, enhancement): these issues are requirements/specifications of fixes or new features to implement.
Support/documentation issues (with the labels: question, documentation): these issues will be subjects/questions to write and document in http://wiki.agroportal.eu/
Project management issues (with the label Project management): these issues are just project management artifacts/helpers, one of the main use cases is to gather a group of related feature request issues in a unique parent issue that represents the project of implementing it. Those project issues will help us to follow the progression of the implementation.
Content: Are issues related to the content of the portal (e.g an Ontology can’t parse)

Develop a feature / fix a bug

To build your local environment see

When we are assigned (or self-assigned) to an issue, we start by creating a pull request on the mode draft related to the issues concerned, to tell people that we started working on it.

Each issue (or the same group of issues) needs to be associated with a new branch

If its a fix, the start of the branch would be master and need to follow this norm fix/name-of-your-branch
Else if its a feature the start would be devlopment and need to follow this norm feature/name-of-your-branch

When your work is ready to be reviewed you put the pull request into open mode. A pull request is accepted and merged only if:

Is well described
Implement tests (if needed)
Pass all the tests
Have related documentation (if needed)
Got accepted by all the reviewers

Regarding the pull request formatting, here are some of our required best practices:

Naming: If it's a feature, start with Feature: your title. If it's a fix, start with Fix: your title.
Target branch: For a feature or fix, open the pull request against the development branch. For a hotfix, open it against the master branch.
PR description: Include the link to the issue the PR resolves for context. Add a brief description if necessary, then list all the changes, along with screenshots of each change.