@wrathwolf @eharrison24 @MarkusKuemmerle as this text was brought in by Linux Foundation, can you please comment on the issue?

My personal view is that the proposed text is less correct, as it does not mention that decisions are taken by Sub Project's Maintainers (see the role and responsibilities in ProjectStructureAndRoles.md). Without mentioning the maintainers it is unclear who has to be involved into a technical decision.

From my perspective the current sentence is clear: a technical decision (e.g. if a certain PR can be merged, if an issue can be closed, ...) can be taken by a maintainer, assuming (lazy) consensus. If there is an objection (showing that there wasn't a consensus) then the decision need to be discussed further, either achieving consensus or taking a formal vote.

From my perspective the current sentence is clear: a technical decision (e.g. if a certain PR can be merged, if an issue can be closed, ...) can be taken by a maintainer, assuming (lazy) consensus. If there is an objection (showing that there wasn't a consensus) then the decision need to be discussed further, either achieving consensus or taking a formal vote.

Yes, I agree that wording above is clear - although I would change 'assuming' to 'following' - but that's not the wording used in the Charter, which is:

"Technical decisions that only affect a single Sub Project are made informally by the maintainers of this Sub Project, and lazy consensus is assumed."

That wording can be read as 'maintainer makes an informal(?) decision, and(?) lazy consensus is assumed'

Informal is not defined, and the 'and' could be misread as meaning an action following the decision, when of course it it a prerequisite.

I think there is an additional problem with the original text as indicated by @Kevsy , there is an unclarity in the original text as it is not clear who can object (in my opinion every member of the workgroup) and how the vote is done. Is voting only done by the maintainers, all members of the workgroup or all companies in the workgroup with a single vote per company.

I would stick to the original text, possibly we can delete the word "informally" to avoid unclarities. And the group which decides is very clear, that are the maintainers of the Sub Project.

@MarkusKuemmerle I agree 'informally' should be removed - was the text in my original post provided by Linux Foundation?

And the group which decides is very clear, that are the maintainers of the Sub Project.

My understanding is that the maintainers ratify the decision, following lazy consensus. The original text reads more like 'decisions are made by the maintainers' which is subtly different from ratifying a group decision.

I'm fine with deleting the word "informally". I suppose the intention of the original authors was to express that decision should be taken without formal overhead except when no consensus can be reached and a vote is needed. But if this

Regarding who is responsible for decisions within a sub project, I refer to the ProjectStructureAndRoles.md:

The following responsibilities must be met by the Maintainer for a Sub Project

• Make and approve technical design decisions for the Sub Project.
• Set the technical direction and priorities for the Sub Project.
• ...
• Ensure a healthy process for discussion and decision making is in place and is followed by the Sub Project's Contributors.

The important decision are the pull requests towards the code base. And for that we have a detailed description in the section "Changes and contributions to CAMARA" how this should be done and who should to be involved in the process.

Make and approve technical design decisions for the Sub Project.

That sentence is also ambiguous :)

'Make' suggests autonomy (the decision is made by the Maintainer without requiring additional approval). Without further context, 'Approve' also suggests autonomy because lazy consensus is not mentioned in that sentence.

Whereas 'Ratify technical design decisions for the Sub Project, following lazy consensus' removes that suggestion of autonomy and confirms the role of the Maintainer as a 'shepherd' for technical decisions.

The important decision are the pull requests towards the code base.

I agree, however it's worth removing ambiguity in the Charter / Project Structures and Roles too, especially if there is a risk of conflict. E.g. "Make and approve technical design decisions for the Sub Project" can be misinterpreted as a veto for lazy consensus or voting.