Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposed text for 'Guidance for closing issues' #137

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

Kevsy
Copy link
Contributor

@Kevsy Kevsy commented May 16, 2024

Fixes #136

What type of PR is this?

  • documentation

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.

CONTRIBUTING.md Outdated Show resolved Hide resolved
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.
Copy link
Collaborator

@hdamker hdamker May 16, 2024

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.

Copy link
Contributor Author

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.

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.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not? If even a non-Maintainer is allowed to do that? (see line 33). Propose to omit the line.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, will omit the line, as line 33 covers it.

Copy link
Collaborator

@hdamker hdamker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

CONTRIBUTING.md Outdated Show resolved Hide resolved
* 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.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

'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.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed and committed

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Working on them between meetings :) Will have it all done end of day

@Bart-Ericsson
Copy link
Collaborator

@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.

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 <52109189+hdamker@users.noreply.github.com>
@hdamker
Copy link
Collaborator

hdamker commented Jun 4, 2024

@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 <52109189+hdamker@users.noreply.github.com>
@MarkusKuemmerle
Copy link
Collaborator

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.

Copy link
Collaborator

@MarkusKuemmerle MarkusKuemmerle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please find my comment in the PR

@bigludo7
Copy link
Collaborator

bigludo7 commented Jun 4, 2024

Hi
My 2 cents on this topic as codeowner or contributors to several CAMARA API... from my view, in these projets, we go thru the issues during the call and we decide here in the issue needs to be close (and this tabbed in the minutes). If the issue author is not there we can keep it for next meeting but I think as long as the decision is done by the 'team' it seems to be the best solution (which is not contradictory with @MarkusKuemmerle point as the codeowner host the meeting and 'click on the button').

Update following Conversation comments
@Kevsy
Copy link
Contributor Author

Kevsy commented Jun 4, 2024

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.

@MarkusKuemmerle
Copy link
Collaborator

@Kevsy : It's the comment in this tread above:

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.

@Kevsy
Copy link
Contributor Author

Kevsy commented Jun 5, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

CONTRIBUTING.md does not include explicit guidance on when an issue can be closed
5 participants