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

[Kevsy]

Problem description CONTRIBUTING.md#working-on-issues does not include explicit guidance regarding when an issue can be closed.

Expected action Update the working on issues section to include:

• reference to ProjectCharter and use of lazy consensus
• that a participant may object to closure of an issue if they believe consensus was not reached, and reopen the issue
• that the issue may be closed by the original author or by a maintainer in the sub-project
• that maintainers may not close their own issues without reference to consensus achieved
• 'consensus achieved' can also include that the issue is agreed (by lazy consensus) to be stale
• closing an issue should include a comment on how it was resolved / or reference to consensus that it can not be resolved.

[hdamker]

@Kevsy see my comments on the PR - my view is that we shouldn't do it:

• the contributing document should give guidelines for contributors into the code base, it is not about decision making about issues (decision making is defined in the ProjectCharter)
• the guidance is from my perspective too formal and will not fit to all kind of issue which can come up, including technical decisions/scope change proposals/non-technical discussions/spam/...
• some of the points don't make sense to me, e.g. why can't a Maintainer close (withdraw) an own issue if they see that there is no consensus achievable on the issue?

[Kevsy]

Hi @hdamker

the contributing document should give guidelines for contributors into the code base, it is not about decision making about issues (decision making is defined in the ProjectCharter)

Fair point. I can remove this PR and make one for ProjectCharter

the guidance is from my perspective too formal and will not fit to all kind of issue which can come up, including technical decisions/scope change proposals/non-technical discussions/spam/...

I/we can expand the list - but I'm not sure what you mean by 'too formal'? The intention is to remove ambiguity.

some of the points don't make sense to me, e.g. why can't a Maintainer close (withdraw) an own issue if they see that there is no consensus achievable on the issue?

A Maintainer can close their own issue if they see that there is no consensus, but the point in the list says "that maintainers may not close their own issues without reference to consensus achieved". Which can be a pointer to minutes or other lazy consensus that the sub-project agree with that position.

some of the points don't make sense to me,

Other than the item above, any others..? I believe we should cover this topic in ProjectCharter to avoid the situation where issues are being closed without consensus achieved.

[Kevsy]

PS this is likely to be a concern in other (non-CAMARA) projects too, so e.g. Linux Foundation may have a. recommendation

[hdamker]

@Kevsy agree that LF might have something. But just to note that the decision part within the ProjectCharter is based on a proposal from LF.

@wrathwolf @eharrison24 Do you have examples of LF projects who described the types of decisions and how to handle them in more detail then we have currently in the Project Charter? I suppose that closing issues is just one of these decisions, there are other which might be more important, like a PR merge.