Project Management notes on processes

Labels

Issues will be categorized into "types" on a regular basis with input from the project team. During weekly meetings, the status of the issues will be updated and will also be prioritized. Subsequently, issues will be assigned to milestones to organize the deliverable. Below is a description of the labels to help clarify the organization of each issue.

Types of issues

Each issue should be labeled as one of the following types:

• [bug] - OpenGrid is not behaving in a manner that you expected
• [enhancement] - a request for a new feature or capabilities of the platform. See below for guidelines on how to best request an enhancement.
• [question] - issue is predominately a question with no specific issue or feature being requested
• [documentation] - pertaining to the documentation in the repo, such as README.md, CONTRIBUTING.md, docs/, or inline comments in the code.

Issue Status

After an issue is classified into a type, these labels inform everyone on the status of an issue:

Accepted issues

• [ready] - issue ready to be worked on and can be worked on by the project team or other contributors requested will not be prioritized by the team--likely because it doesn't fit within the vision of the OpenGrid project.
• [in progress] - item is currently being worked on by the project team or partner
• [on dev] - issue has been deployed to the dev branch for final testing before released on the master branch.
• Closed - Unless labelled [wontfix], the bug has been resolved or the enhancement incorporated

Rejected issues (sorry, not sorry)

• [wontfix] - the issue won't be addressed by the project team, often because it doesn't fit into OpenGrid's product vision.
• [invalid] - the [bug] reported is not a bug
• [duplicate] - the issue is similar enough to another issue and the issue will be closed to help centralize discussions into a few threads. Check the comments to see which issue is closest to the duplicated issue.

Milestones

Milestones reflect the desired tasks in the current iteration of work. Milestones are aligned to dates, which should produce the next stable release of OpenGrid (e.g., 1.x.y). Issues are associated with each milestone to communicate which issues should be attempted in the sprint. The priority labels can also inform which issues are most important in each milestone.

Weekly Meetings

Meeting preparation

Prior to the meeting, the project manager should:

• Review notes from the existing work throughout the week, closing any issues that were addressed and updating status
• Have the product manager label existing and new issues in the repo (or note which ones that are unclear)
• Collect special agenda items from the team
• Determine if others should be invited to the meeting
• Discuss if Plenar.io team has specific updates
• Prepare a preliminary agenda based on input

Each weekly meeting should review work that is in progress or completed since the last meeting; review existing and new pull requests;

Leading the meeting

Reviewing open issues

• Review new issues as a group, ensuring there is an understanding of the issue. Determine if there is a prima facie reason to close the issue and communicate with the user for clarification as needed.

Review pull requests

Review pull requests that have been opened on the repo. All pull requests must pass all "checks", which currently includes the contributor signing the Contributor License Agreement (CLA), pass the Travis-CI build process, pass the AppVeyor build process, does not significantly reduce code coverage, nor introduces out-of-date or insecure Node dependencies.

Pull requests can be classified into two types:

• Minor pull request - provides a modification to a trivial section of the repository, such as user documentation, and cannot possibly pose any technical harm or modifies the application. These pull requests can be accepted within the meeting if there is a consensus that it would not: cause a merge conflict, modify the functionality of the application, provide a security risk, or make any other significant modification that requires UAT and test deployment.
• Major pull request - a non-minor request that must be reviewed by the project team. The pull request should be reviewed and discussed as a group, but one or more team members will be assigned to do an in-depth review of the code which likely includes deployment to UAT.

Evaluating Major Pull Requests

Most pull requests will be classified as "major".

• Ensure the pull request passes all automated checks: CLA signature, Travis-CI (Ubuntu) test build and unit tests, AppVeyor (Windows) test build and unit tests, and equivalent or greater code coverage.
• Visual inspection of code for consistency
• "Codeword" match of functions against oft-used functions that can introduce security risks.
• Test the deployment using Covarity
• Ensure new unit tests have been written and adequately test any new function or functionality

If the pull requests satisfies these requirements, it may be accepted and integrated into the dev branch.

Testing changes

In addition to automated testing, another party should conduct smoke tests and UAT tests. Below are the testing protocol that should be followed:

• Desktop device testing protocol
• Mobile device testing protocol

Releases

The conclusion of each milestone/sprint, should result in a new, stable version of the code. Once it passes all smoke tests, UAT, and unit tests, a new "release" should be announced.

Release notes

Each release should be accompanied by informative release notes. At the minimum, the release notes should outline the features introduced or bugs that were fixed since the last stable release. Preferably, the release notes should link back to the issues and pull requests that were specifically addressed in the release.

Version number

The version number should be determined at the conclusion of each milestone following Semantic Versioning 2.0.0.

Communication platforms

The new releases can be announced in a number of ways. Where as bug fixes should only have limited communication, minor and major releases should be communicated in a number of ways, including, but not limited to:

• GitHub Releases page
• Chicago Digital
• @ChicagoCDO Twitter account
• ChiHackNight meeting or Slack channel
• Code for America Slack channel

Integration to WindyGrid and chicago.opengrid.io

Once a new release has been deployed, need to work with the team to deploy the changes to WindyGrid and chicago.opengrid.io. Use the integration map to start on those activities.