For developers¶
See also
Assign issues¶
If an issue is assigned to you and you need clarification from OCP, you can re-assign the issue to OCP, so that it no longer appears in your assigned issues.
Close issues¶
If OCP asks a question, DO NOT close the issue after providing the answer. Instead, you can re-assign the issue to OCP. The issue is not closed until OCP has an opportunity to act on the provided information.
Automatically, with pull requests¶
When creating a pull request that fixes one or more issues, add the text “fixes #42” or “closes #42” in the pull request’s description so that GitHub automatically closes them after merging.
Manually, with a rationale¶
All issues should be closed with a brief rationale. This makes it easy to understand what happened and affords participants an opportunity to engage with the rationale. For example:
“Resolved in the above commit” if there’s a commit referencing the issue that appears nearby
“Resolved in the [name] extension” with a link to the OCDS extension that was created
“Closing, because [explanation]”
Pull requests¶
DO NOT force-push changes to a pull request in response to a code review. Force-pushing makes it impossible to use GitHub’s View changes feature. If you want a single commit, select Squash and merge from the Merge pull request dropdown.
Projects¶
The open-contracting organization uses GitHub Projects to organize work in a Kanban system.
People expect to have visibility of all of a repository’s issues within the Issues tab; therefore, a card that is not attached to an issue should never be added to a project.
New projects should be created using the Automated kanban template.