-
Notifications
You must be signed in to change notification settings - Fork 0
Maintenance of Project
Based on research into creating open-source software, the guidelines for maintaining and contributing to the project are defined as below.
For discussions of issues/bugs as well as the future of the project, a slack workspace would be used. Developers would discuss open issues on the project and the best way to maintain the project. This would include the future of the project in order to make sure it is well maintained.
Issues that are created will be marked according to the type of contribution it is: bug, feature, or documentation. A bug is an issue that is related to a bug with the current application. Feature is an issue with proposed functionality that should be added. Documentation would be an issue about the addition and maintenance of the project documentation.
Developers will follow these guidelines below. Note the workflow is adopted from the workflow for projects called git flow (https://nvie.com/posts/a-successful-git-branching-model/). I’ve elected to follow this workflow as it is similar to what chapter follows but is more in-depth for things such as hotfixes and uses a separate dev branch before going into master:
- Fork the repository (if not already done)
- Branch off of the develop branch and name a branch for the action you are doing
- If it is added functionality, the branch will be called feature-. If it is a bug fix, the branch will be named fix-.
- Add the code needed.
- Submit a PR (see the section labeled “Pull Request Review Process” for this document).
There are two other types of branches that could be made. These typically would be handled by those who are identified as head maintainers of the project.
The first is a hotfix branch. If there is a bug in the current production release of the codebase, which is on the master branch, a quick fix is made in order to ensure that there is a clean working version of the project on master.
Steps:
- Fork the repo (if not already done)
- Branch from master and label the branch hotfix-
- Once the fix is made and tested successfully, submit a PR to master and develop. Due to this being a hotfix, it would need to bypass the review process and be cleaned up afterwards.
- Merge both PRs into their respective target branch.
- Delete the hotfix branch.
The other branch type is release branch. This is to prepare for a new release of a production build of the application
Steps to create a release branch
- Branch off of develop
- Perform last minute maintenance of any kind before release
- Merge back into develop and also into master via a PR (follow formal review process in the “Pull Request Review Process” section)
- Prepare a release tag for github to benchmark the release of the project. Follow semantic versioning - https://semver.org/
When developers create a PR, they must have a descriptive title of what their PR is doing. In the summary/description of the PR, the developer must properly summarize how their functionality works. They must also reference the related issue properly by typing “Resolves #”. By doing this, Github will automatically close the issue if the PR is merged. In the contents of the PR, unit tests will be updated or created as needed. Additionally, steps to test the PR must be included so that the reviewer can see for themselves that the project behaves as required. Test coverage reports should be included in the PR for maintenance of the project. In addition to this, the developer must adhere to these requirements:
- Add or Update the maintenance information in the code files
- Follow the YARD tag style of code documentation (https://www.rubydoc.info/gems/yard/file/docs/GettingStarted.md)
- Adhere to the code of conduct (will be created when there is an established developer community)
A reviewer will be assigned to review the PR. The following review process will be followed by any reviewers:
- Ensure that the PR has a passing build for continuous integration. If this is not the case, the PR will not be reviewed until then as the tests are not passing and the PR is not stable.
- Each modification will be reviewed to ensure that the above mentioned criteria for developers is followed and the coding style set by the developer team is followed.
- Any infraction ID'd by the reviewer must be fixed.
- Once the PR is satisfactory and the reviewer manually tests the PR, the PR will be approved, then merged into the target branch
- Once all PRs for that branch are completed, the branch will be deleted.
Managing Issues
Outside of the community slack, Github Projects will be used. There will be three columns in the main board: Todo, In progress and finished. This will be used to maintain issues and be a reference to the development team.
Continuous Integration
The project will use Continuous integration. The service that will facilitate this is TravisCI (https://travis-ci.org/). Continuous Integration is used to ensure that the state of the project is always known and failing tests are made clear.
Unit tests would be written in order to ensure that functional requirements and security requirements of the project are met. This can be, and will be, created with minitest (https://github.com/seattlerb/minitest).
Since continuous integration will run for all PRs and commits, regression testing will happen simultaneously with Unit and Integration as if new functionality breaks old functionality, then the tests will fail.