Proposed text for 'Guidance for closing issues' #137
Conversation
CONTRIBUTING.md
Outdated
| * 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. | ||
| * Closing an issue should include a comment on how it was resolved, or reference to consensus that the issue can not 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. |
There was a problem hiding this comment.
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.
Yes, the previous line can cover this ('closing because no update since x weeks'). Will remove this one.
CONTRIBUTING.md
Outdated
| * Once consensus is achieved, an issue may be closed by the original author or by a maintainer in the sub-project. | ||
| * Closing an issue should include a comment on how it was resolved, or reference to consensus that the issue can not 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. |
There was a problem hiding this comment.
Why not? If even a non-Maintainer is allowed to do that? (see line 33). Propose to omit the line.
There was a problem hiding this comment.
Yes, will omit the line, as line 33 covers it.
There was a problem hiding this comment.
@Kevsy I tried to propose some changes (see my comments) but then I thought one step further and came to conclusion that it isn't possible to give a guidance which would fit to all kind of issues (e.g. technical, non-technical decisions, proposed enhancements, etc).
In addition is this document here meant more to motivate people to contribute, it wouldn't be helpful to put such formal guidance here.
My proposal is therefore to close the PR and rather spend the energy on the concrete cases if they are coming up and try to solve them in the sense of the ProjectCharter, ProjectStructureAndRoles and the Code of Conduct.
| * Closing an issue should include a comment on how it was resolved, or reference to consensus that the issue can not 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. |
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.
There was a problem hiding this comment.
'may object' is intended to allow flexibility here, depending on the type of issue.
| * 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. | ||
| * Closure of an issue may require closure of a Pull Request which only fixed that single (now closed) issue. |
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.
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?
There was a problem hiding this comment.
Working on them between meetings :) Will have it all done end of day
Well, I have seen concrete cases where comments are simply marked as resolved and people try to push their own document through without considering the comments. I'm not sure if it is bad will, but some form of documentation is needed to point to rules in order for them to accept that issues need to be resolved and discussed before simply marking it as resolved. |
Herbert's amendment Co-authored-by: Herbert Damker <[email protected]>
|
@Kevsy @eric-murray @bigludo7 I'm not quite sure what to do with this PR. Maybe you might want to add your view. |
Co-authored-by: Herbert Damker <[email protected]>
|
Please consider also the existing regulations in ProjectStructureAndRoles.md. In the section"Changes and contributions to CAMARA" it is defined that Codeowners shall close the issue. |
|
Hi |
Update following Conversation comments
|
OK I've committed @hdamker's feedback where indicated. @MarkusKuemmerle I can't see your comments in the PR review...? Overall: I don't mind which document the guidance goes in, but keeping this PR open for now until we decide where. |
|
@Kevsy : It's the comment in this tread above:
|
|
Thanks Markus - I'm happy to propose the 'guidance for closing issues' text to ProjectStructureAndRoles.md instead, and close this PR. I don't think the problem occurs frequently (@bigludo7 has a good summary of how it is usually done in practice) but as @Bart-Ericsson says, it will be good to have something to point to if needed. |
Fixes #136
What type of PR is this?
What this PR does / why we need it:
Sets a common approach for when issues can be closed.
Which issue(s) this PR fixes:
Fixes #136
Special notes for reviewers:
Additional documentation
This section can be blank.