Merge pull request #275 from SysBioChalmers/develop

GECKO 3.0.1

.github/CONTRIBUTING.md

@@ -6,7 +6,7 @@ You can contribute in 2 main ways: by creating issues, and by sending pull reque
 
 ### Reporting issues
 
-Report an issue at https://github.com/SysBioChalmers/GECKO/issues if you note any of the following:
+[Report an issue](https://github.com/SysBioChalmers/GECKO/issues) if you note any of the following:
 
 * Missing feature you would like GECKO to have.
 * Bug/weird simulation results.
@@ -18,32 +18,32 @@ If you are unsure about the issue, consider asking first in our [Gitter chat roo
 When creating the issue, please make sure:
 
 * You tested your code (if any) with all of GECKO's [requirements](https://github.com/SysBioChalmers/GECKO).
-* You did your analysis in the `master` branch of the repository.
+* You did your analysis in the `main` branch of the repository.
 * You provide any necessary files/links needed for understanding the issue.
 * You checked that a similar issue does not exist already
 
-Feel free to also comment on any of the [open issues](https://github.com/SysBioChalmers/GECKO/issues). When doing so, please comply with our [code of conduct](https://github.com/SysBioChalmers/GECKO/blob/devel/.github/CODE_OF_CONDUCT.md).
+Feel free to also comment on any of the [open issues](https://github.com/SysBioChalmers/GECKO/issues). When doing so, please comply with our [code of conduct](https://github.com/SysBioChalmers/GECKO/blob/main/.github/CODE_OF_CONDUCT.md).
 
 Finally, if you like GECKO please remember to 'star' our Github page (click on the star at top right corner), that way we also have an idea of who is using GECKO!
 
 ### Contributing to GECKO
 
-Want to contribute to GECKO with some additions or improvements? Consider starting by raising an issue and assign it to yourself to describe what you want to achieve. This way, we reduce the risk of duplicated efforts and you may also get suggestions on how to best proceed, e.g. there may be half-finished work in some branch that you could start with. Also, feel free to browse our [open issues](https://github.com/SysBioChalmers/GECKO/issues): Anything tagged with "help wanted" is open to whoever wants to implement it!
+Do you want to contribute to GECKO with some additions or improvements? Consider starting by raising an issue and assign it to yourself to describe what you want to achieve. This way, we reduce the risk of duplicated efforts and you may also get suggestions on how to best proceed, e.g. there may be half-finished work in some branch that you could start with. Also, feel free to browse our [open issues](https://github.com/SysBioChalmers/GECKO/issues): Anything tagged with "help wanted" is open to whoever wants to implement it!
 
 Here's how to set up GECKO for local development to contribute smaller features or changes that you can implement yourself:
 
 1. First of all, make sure that you have all [requirements](https://github.com/SysBioChalmers/GECKO) for running GECKO.
 
-2. Fork the GECKO repository on GitHub (go to https://github.com/SysBioChalmers/GECKO & click on the upper right corner).
+2. [Fork the GECKO repository](https://github.com/SysBioChalmers/GECKO/fork) on GitHub.
 
 3. Clone your fork locally:
     ```
     git clone https://github.com/<your Github name>/GECKO.git
     ```
 
-4. Check out the branch that you want to contribute to. Most likely that will be ``devel``:
+4. Check out the branch that you want to contribute to. Most likely that will be ``develop``:
     ```
-    git checkout devel
+    git checkout develop
     ```
 
 5. Create a branch for local development based on the previously checked out branch ([see below](#branching-model) for details on the branching model and how to name your branch):
@@ -63,19 +63,21 @@ Here's how to set up GECKO for local development to contribute smaller features
     ```
     [See below](#semantic-commits) for recommendations on how to name your commits. In case of larger updates, you can of course make several commits on a single contribution. However, if you need to do too many commits, consider if your contribution could be instead split into separate PRs (making it easier for reviewing later).
 
-8. Submit a PR through the GitHub website (https://help.github.com/articles/creating-a-pull-request-from-a-fork/) to the `devel` branch of the original SysBioChalmers repo (not your fork). We recommend ticking the box "Allow edits from maintainers" if you wish for us to be able to contribute directly to your branch (speeding-up the reviewing process).
+8. Submit a PR through the GitHub website (https://help.github.com/articles/creating-a-pull-request-from-a-fork/) to the `develop` branch of the original SysBioChalmers repo (not your fork). We recommend ticking the box "Allow edits from maintainers" if you wish for us to be able to contribute directly to your branch (speeding-up the reviewing process).
 
 Note that steps 3, 4, 5 and 7 can be done, if you prefer, with any git client, such as [Github Desktop](https://desktop.github.com/).
 
-Finally, and for larger features that you want to work on collaboratively, you may consider to first request to join our development team to get write access to the repository so that you can create a branch directly in the main repository (or simply ask the administrator to create a branch for you). Once you have a new branch, you can push your changes directly to the main repository and when finished, submit a pull request from that branch to ``devel``. [See below](#development-team-guidelines) for more details.
+Try to keep pull requests relatively small: they should ideally provide one new feature or fix one bug. A few small bug-fixes maybe combined, but avoid packing pull requests with too many diverse and somewhat unrelated development. Smaller pull requests reduce reviewing time and make sure that code updates will make it into new releases faster.
+
+Finally, and for larger features that you want to work on collaboratively, you may consider to first request to join our development team to get write access to the repository so that you can create a branch directly in the main repository. On this new branch, you can push your changes directly to the main repository and when finished, submit a pull request from that branch to `develop`. [See below](#development-team-guidelines) for more details.
 
 Thank you very much for contributing to GECKO!
 
 #### Branching model
 
-* `devel`: Is the branch all pull-requests should be based on.
+* `develop`: Is the branch all pull-requests should be based on.
 
-* `master`: Is only touched by the administrator and is the branch with the tested & reviewed codebase. Each merge commit to it is associated to a release.
+* `main`: Is only touched by the administrator and is the branch with the tested & reviewed codebase. Each merge commit to it is associated to a release.
 
 * `{chore, doc, feat, fix, refactor, style}/descriptive-name`: Any other branch created in the model. If you work on a fix, start the branch name with `fix/`, if you work on a feature, start the branch name with `feat/`. Examples: `fix/bug` or `feat/new-algorithm`. [See below](#semantic-commits) for more details on the possible actions you can use.
 
@@ -101,7 +103,7 @@ This section is meant for the development team of GECKO. As a member of the deve
 
 ### Creating pull requests
 
-Changes to the source code _may not_ be directly committed to the `master` or `devel` branches (in fact they are protected). Commits are made to side-branches, after which pull requests are made for merging with `devel`. For this, follow the [instructions](#contributing-to-the-model) for contributors, but consider that as members of the development team have write access to the repository, you can create a branch directly in the main repository without needing to fork, for your convenience. This means that you can:
+Changes to the source code _may not_ be directly committed to the `main` or `develop` branches (in fact they are protected). Commits are made to side-branches, after which pull requests are made for merging with `develop`. For this, follow the [instructions](#contributing-to-the-model) for contributors, but consider that as members of the development team have write access to the repository, you can create a branch directly in the main repository without needing to fork, for your convenience. This means that you can:
 
 * Skip step 2 of the contribution process.
 * In step 3 of the contribution process, clone directly the original repo:
@@ -118,11 +120,11 @@ Follow all other steps in the same way. Also, when creating your pull request (o
 
 Every pull request must be approved by at least one reviewer before it can be merged. When reviewing someone else's pull request, keep in mind the following aspects:
 
-* **Compatibility:** Make sure the changes introduced in the PR do not generate errors when calling either `updateDatabases.m`, `enhanceGEM.m` or `generate_protModels.m`. To test the latter two functions, you may use [yeast 8.1.3](https://zenodo.org/record/1495482), as this will also help you validate any changes to the pipeline.
+* **Functionality:** The automated tests that are run as GitHub Actions should pass without any problems. Have you written a new function? Make sure that it is also tested in `tests/unit_tests/geckoCoreFunctionTests.m`.
 * **Documentation:** The reasoning for each modification should be provided, as documentation or as a comment in the pull request.
 * **Reproducibility:** If there are any added scripts, make sure that if you run them, they achieve the desired purpose.
 * **Style:** Ensure that changes to the codebase have a compliant style, and new datasets (if any) are straight-forward to understand.
-* When commenting in the review, please comply with our [code of conduct](https://github.com/SysBioChalmers/GECKO/blob/devel/.github/CODE_OF_CONDUCT.md).
+* When commenting in the review, please comply with our [code of conduct](https://github.com/SysBioChalmers/GECKO/blob/main/.github/CODE_OF_CONDUCT.md).
 * Avoid vague comments and try to be as explicit as possible (e.g.: _"Please include X here"_ instead of _"X could be included here"_).
 * As much as possible, try to keep the review process in the pull request discussion, and not in separate private emails.
 
@@ -132,23 +134,23 @@ This section is meant for the administrator of this repo. The main duties of the
 
 * To keep the repository clean and organized, i.e. avoid redundancy in functions and/or data, and keep coherency in naming of files.
 * To help in the reviewing process of external pull requests by assigning reviewers and [labels](https://github.com/SysBioChalmers/GECKO/issues/labels), if applicable.
-* To keep [issues](https://github.com/SysBioChalmers/GECKO/issues) with the proper labels, and to close issues once they are fixed in the `master` branch.
+* To keep [issues](https://github.com/SysBioChalmers/GECKO/issues) with the proper labels, and to close issues once they are fixed in the `main` branch.
 * In cases of disagreement between contributors, to decide how to resolve the issue.
-* To merge open pull requests into `devel` regularly (see [below](#merging-contributions)).
+* To merge open pull requests into `develop` regularly (see [below](#merging-contributions)).
 * To generate new releases of the model regularly (see [below](#releasing-a-new-version)).
 
 ### Merging contributions
 
-The following points should be considered when merging branches to `devel`:
+The following points should be considered when merging branches to `develop`:
 
 * Make sure the branch gets accepted by at least one developer with writing access.
 * Wait at least a day before merging, to allow other developers to inspect the pull request.
-* As soon as the branch is merged, confirm that `devel` is still possible to merge to `master` (this can be checked [here](https://github.com/SysBioChalmers/GECKO/compare/devel)). If conflicts appear, fix the conflict _locally_ as soon as possible in `devel` and then push it (note, **DO NOT** pull any other changes from `master` to `devel`, just the single file that is creating the conflict).
+* As soon as the branch is merged, confirm that `develop` is still possible to merge to `main` (this can be checked [here](https://github.com/SysBioChalmers/GECKO/compare/develop)). If conflicts appear, fix the conflict _locally_ as soon as possible in `develop` and then push it (note, **DO NOT** pull any other changes from `main` to `develop`, just the single file that is creating the conflict).
 
 ### Releasing a new version
 
-* A merge of `devel` with `master` invokes a new release.
-* A new release should be made as soon as there is substantial new work in `devel` (as rule of thumb, after 3-4 pull request merges or ~20 commits).
+* A merge of `develop` with `main` invokes a new release.
+* A new release should be made as soon as there is substantial new work in `develop` (as rule of thumb, after 3-4 pull request merges or ~20 commits).
 
 GECKO follows [semantic versioning](https://semver.org/):
 
@@ -163,22 +165,12 @@ GECKO follows [semantic versioning](https://semver.org/):
 
 When releasing, please follow these steps:
 
-1. Create a pull request from `devel` to `master`, indicating all new features/fixes/etc. and referencing every previous pull request included (examples [here](https://github.com/SysBioChalmers/GECKO/releases)). Tip: if any [issue](https://github.com/SysBioChalmers/GECKO/issues) gets solved in the release, write in the pull request description "Closes #X", where "X" is the issue number. That way the issue will be automatically closed after merge.
-2. Wait at least a day + 1 approval + passing CI.
-3. Bump to the new version x.y.z. For this, create in `devel` a single commit `chore: version X.Y.Z` with:
-    * Updated `/geckopy/HISTORY.rst` by putting at the top the same description as in the PR from step 1 (use https://pandoc.org/try for transforming markdown to ReSTructured text).
-    * Updated version in:
-      - `/docs/conf.py` (lines 57 & 59).
-      - `/geckopy/setup.cfg` (line 2).
-      - `/geckopy/setup.py` (line 22).
-      - `/geckopy/geckopy/__init__.py` (line 10).
-
-    * Updated `/README.rst` date (line 14).
-4. Push the commit and confirm that the CI tool is still passing.
-5. Merge PR -> confirm that the CI tool is still passing.
-6. In `master`, create LOCALLY a tag `vX.Y.Z` on the latest merge commit + push said tag (in git kraken or with `git push origin vX.Y.Z`) -> confirm that the CI tool is still passing and geckopy deploys to PyPI (check [here](https://pypi.org/project/geckopy/)).
-7. Make the new release at GitHub (https://github.com/SysBioChalmers/GECKO/releases/new), using the proper tag and with the same description as the corresponding PR from step 1.
-
-## Acknowledgments
-
-These contribution guidelines were written based on the contribution guidelines of [SysBioChalmers/yeast-GEM](https://github.com/SysBioChalmers/yeast-GEM/blob/devel/.github/CONTRIBUTING.md).
+1. Create a pull request from `develop` to `main`:
+   - Specify the intended version in the title, e.g. `GECKO 3.0.1`
+   - Indicating all new features/fixes/etc. and referencing every previous pull request included (examples [here](https://github.com/SysBioChalmers/GECKO/releases)).
+   - If any [issue](https://github.com/SysBioChalmers/GECKO/issues) gets solved in the release, write in the pull request description "Closes #X", where "X" is the issue number. That way the issue will be automatically closed after merge.
+2. Wait at least a day for at least one  approval. The GitHub Actions must also pass successfully.
+3. Merge the pull request from `develop` to `main`.
+4. Make the [new release](https://github.com/SysBioChalmers/GECKO/releases/new) at GitHub:
+   - Define a new tag with the version, prefixed by `v`: e.g. `v3.0.1`.
+   - Copy the description from the corresponding PR from step 1.

.github/ISSUE_TEMPLATE/bug-detected.md

@@ -4,40 +4,27 @@ about: GECKO is not working as it should...
 title: Bug detected
 labels: bug
 assignees: ''
-
 ---
 
 ### Description of the bug:
-
-
-
-#### Expected behavior:
-
-
-
-#### Current behavior:
-
-
+<!-- Try to be as clear as possible, e.g.
+- Did a function fail?
+- What is the exact error message, and other output that you got?
+- What have you tried yourself to fix it? -->
 
 #### Reproducing these results:
-
+<!-- If applicable, please attach the problematic code. -->
 ```matlab
 % If you worked on matlab, paste your code here
 ```
 
-```python
-# If you worked on python, paste your code here
-```
-
-#### Context
-
-<details>
-* Operating System:
-* Python version:
-* Matlab version:
-</details>
+#### System information
+<!-- Please report details of the system where you encountered the bug. -->
+* Operating system: <!-- (Windows/Mac/Linux; include version) -->
+* MATLAB version: <!-- E.g. 2022b -->
+* GECKO version: <!-- If you did not use the latest GECKO version, have you tried to update and encountered the same problem? -->
 
 **I hereby confirm that I have:**
 - [ ] Tested my code with [all requirements](https://github.com/SysBioChalmers/GECKO) for running GECKO
-- [ ] Done this analysis in the `master` branch of the repository
+- [ ] Done this analysis in the `main` branch of the repository
 - [ ] Checked that a similar issue does not exist already

.github/ISSUE_TEMPLATE/new-feature.md

@@ -8,9 +8,12 @@ assignees: ''
 ---
 
 ### Description of the new feature:
-
-
+<!-- Try to be as clear as possible, e.g.
+- What would be the purpose of this feature?
+- Could this feature be useful for others as well?
+- Do you have an idea on how to implement this feature?
+- Will you implement this feature yourself (in that case, you can Assign yourself in the top right corner) or need help with this? We will gladly support you in this! -->
 
 **I hereby confirm that I have:**
-- [ ] Done this analysis in the `master` branch of the repository
+- [ ] Done this analysis in the `main` branch of the repository
 - [ ] Checked that a similar issue does not exist already

.github/pull_request_template.md

@@ -1,8 +1,9 @@
 ### Main improvements in this PR:
-
-
+<!-- Pointwise mention what changes were made in what function. Examples: 
+- fix bug where `functionName` failed to do function X
+- updated all documentation 
+- resolves issue #12345 -->
 
 **I hereby confirm that I have:**
-
-- [ ] Tested my code with [all requirements](https://github.com/SysBioChalmers/GECKO) for running GECKO
-- [ ] Selected `devel` as a target branch (top left drop-down menu)
+<!-- Note: replace [ ] with [X] to check the box -->
+- [ ] Selected `develop` as a target branch (top left drop-down menu)