Proposed text for 'Guidance for closing issues' #137
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -28,6 +28,16 @@ If you have questions about one of the issues, please comment on them, and one o | |
|
|
||
| Please provide as much context as possible when you open an issue. The information you provide must be comprehensive enough to reproduce that issue for the assignee. Therefore, contributors may use but aren't restricted to the issue template provided by the project maintainers. | ||
|
|
||
| ### Guidance for closing issues | ||
| * As per the [ProjectCharter](https://github.com/camaraproject/Governance/blob/5fc802713d71a51da64136f692b16ed620eeffa5/ProjectCharter.md), The default decision making mechanism for the CAMARA Project is [lazy consensus](https://couchdb.apache.org/bylaws.html#lazy). This means that any decision on technical issues is considered supported by the team as long as nobody objects based on substantiated technical grounds. | ||
| * Once consensus is achieved, an issue may be closed by the original author or by a maintainer in the sub-project (if not closed by a Pull Request merge, where the issue is linked as getting fixed, see below) | ||
| * Closing an issue should include a comment on how it was resolved or why it won't be resolved | ||
| * Issues that are considered stale/inactive may be closed, but must include a reference to minutes where it has been agreed to be a stale issue. | ||
| * Maintainers may not close their own issues without reference to consensus achieved. | ||
|
||
| * A sub-project participant may object to closure of an issue if they believe consensus was not reached, in which case they may reopen the issue, stating they believe consensus has not been reached. | ||
|
Collaborator
There was a problem hiding this comment. I suppose that just the statement "consensus has not reached" might be not enough, if there was a reason to close the issue. But I have no good idea what to require here, as it depends on the type of issue.
Contributor
Author
There was a problem hiding this comment. 'may object' is intended to allow flexibility here, depending on the type of issue. |
||
| * Closure of an issue may require closure of a Pull Request which only fixed that single (now closed) issue. | ||
|
Collaborator
There was a problem hiding this comment. I proposed something above. BTW: one PR can close several issues, as we have seen with camaraproject/IdentityAndConsentManagement#121 which closed about a dozen issues.
Collaborator
There was a problem hiding this comment. @Kevsy I can see that you have committed my proposal on line 34. But here I meant the proposal for line 33 and then to delete 38. Beyond that ... what about my other change proposals?
Contributor
Author
There was a problem hiding this comment. Working on them between meetings :) Will have it all done end of day |
||
|
|
||
|
|
||
| ## Contributing Code | ||
|
|
||
| You are welcome to contribute code in order to fix a bug or to implement a new feature. | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again, I don't think that especially stale/inactive issues need or even can always include a reference to an explicit decision. Sometimes Maintainers just have to clean up. Propose to omit the line as covered by the previous one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, the previous line can cover this ('closing because no update since x weeks'). Will remove this one.