Guidelines for opening PR

Objectives

The key objective is to help users to be successful in adding their ideas to OLS. For this we need to understand which ideas will be most valuable to our user base:

1. Bug fixes of existing Github bug issues that affect a large number of our users will be highly appreciated.
2. Implementation of existing Github feature requests that will benefit a large number of our users.

In evaluating PRs we focus on the following:

1. Testing is of the utmost importance as we need to keep the EBI OLS instance up and running for the around 15 million requests from 100 000 unique users per month, as well for the number of self-hosted OLS instances. This means all PRs need to be well tested and will need to be tested on the EBI development infrastructure before it will be considered for going into production.
2. We aim to keep the codebase as small as possible in order to ensure the long term maintainability of OLS (and our other tools Zooma and OxO) by a team of 2 people. Here we really need to ensure that use cases implemented in OLS will serve large numbers of users.

Guidance for opening PRs

1. Before opening a PR, ensure that a focussed Github issue is opened that details the bug and/ or enhancement you want to add to OLS. Please provide as much detail of the use case(s) for your bug/enhancement as you can. This is incredibly helpful in motivating how the changes will benefit the OLS community and in our prioritisation of the change.
2. Open a Github issue well in advance before opening the PR. This gives us the time to evaluate and prioritise and consider it for our roadmap. This will avoid you doing work that is unlikely to get onto the OLS roadmap.
3. Before implementing the PR, detail your intended solution in the issue. This will give us the opportunity to consider and give feedback on any architectural and/or scalability concerns.
4. Any PR should deal with 1 focussed issue and 1 focussed issue alone. This will ensure that in the event where a change results in an OLS outage or regression, there is a clear understanding of which change needs to be reverted.
5. Any PR that results in changes to the data load or the REST APIs need to supply the outputs of the data load testing (testcases_compare_result.log) and API testing (apitester4.log) with explanations for any differences from expected outputs.