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

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.

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

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