No decisions about the project’s direction, bug fixes, or features may be made in private without community involvement and participation.

This is not really align with our practice or the Apache Decision Making process. There are a lot of reasons to decide certain things in private. Security, actual consensus making, etc. If we want to keep it simple lets just link to the Apache document without trying to patch it?

Is the CoC up to date? Last time (which I know of) it was "enforced" by an AC member not listed in that doc...

I think the members could be refreshed (for instance, as Jessica has left CS&S), but to me it still reflects the current state of the committee. Are you worried that the CoC committee could be just a sock puppet of the AC without actual independence and agency? If you are referring to me as a former AC member, last time I reached out to the CoC about a particular situation, they disagreed about my assessment of that situation and followed their own judgment, which I would take as a good sign of the committee's independence.

That being said, it's an open question to me how to keep a CoC committee active for such a small project because it only gets woken up once in a blue moon, making it hard to keep the practice and understandings of the tasks alive. Surely there is room for improvement, but that's something we should rather do in another PR I would say.

Whether or not the CoC is mentioned here or not doesn't change its status I would hope. This is just a link for convenience.

@Ainali the CoC contains quite a lot about governance and it's currently very badly aligned with this document, who are considered a "project leader"? can the CoC group enforce rights-changes against contributors? It's all governance, and with the ACs history of weaponizing it, I would ague it's rather important to get it right.

@Abbe98 : “with the ACs history of weaponizing it”
What do you mean? That the CoC has been use by the AC?

“project leader”: do you mean project leadership? Because that seams to me to be appropriate even if not defined.

The CoC is pretty general and more guidelines than a checklist/every step procedure. It did suits us, the project, in the last 4 years that I've participated in the committee.

Regards, Antoine

These sections create expectations around people and try to sort them into buckets of with little to no relevance to the governance. I would suggest limiting these sections to match those of GitHub contributors(the actual user rights), it would simplify this a lot while staying true to the actual state of order.

Your comment implies that this governance file should be limited in scope to just the GitHub organization. That may be one way to do it, but then I think we need another governance file covering the entire project/community and not just the parts happening on GitHub. While each of the files may be simplified, it will be harder to get an overview both of the actual state and the intended state.

@Ainali you don't need to sort people and their work into buckets to have a governance document, removing these sections wouldn't change the policy at all.

I do argue for the governance document to be split as the current approach makes things unclear and the later sections contradicts the former ones.

From here on I think the document do no longer describe the governance of the project but instead the relationship between CS&S and the AC. This is clearly not aligned with the Apache Decision Making process nor do it concern the open source project.

I would suggest moving this somewhere else.

To me the AC is currently a component of the project, so it makes sense that it's described in this document. I think @magdmartin's intention is to first update the governance document to reflect the reality of the current situation, and currently the AC does feel like a part of the project to me, so I would keep it. The intention is not to set this in stone, but do incremental updates as the subject is contentious.

There could be further changes later on: changing the way the AC works, or deleting it entirely and leaving CS&S to go back to being just a GitHub project. I think it's best to discuss those separately.

and currently the AC does feel like a part of the project to me, so I would keep it

This is probably because you are a part of it? You are the only notable GitHub contributor who are also a part of the AC...

This is done via public discussions on the forum, on github, using various user survey (see the feature survey 2024 for example) and roadmap exercise (see barcamp notes) or proposed roadmap

Increasing to seven days as per @thadguidry request. Based on how frequently a number of committers and core contributors interact, I think it makes sense to increase it so we do not create artificial pressure to vote.