Now that we've moved to Commonhaus, we need to adapt a new governance document for WildFly. So let's discuss!
I've created a google doc at [1] to help facilitate discussion. Anyone can comment on that doc or suggest edits. We can use doc comments to discuss and we can discuss in this thread. Let's try and do any really deep discussions here.
A challenging aspect of this kind of thing is the scope of WildFly. A number of significant projects that provide components to the WildFly AS but which have their own distinct branding, community, usage etc independent of their use in the AS moved to Commonhaus sponsorship as part of WildFly:
* Ironjacamar
* JBeret
* JBoss Parent
* JBoss Threads
* JBoss WS
* Narayana
* RESTEasy
* Undertow
* Weld
I committed to the leads of those projects that they'd be able to define their own project governance, so long as it was compatible with Commonhaus requirements. But, we do need some form of top level document, if for nothing else to define the role of the person who represents everyone on the Commonhaus Extended Governance Committee.
So, in the google doc I created a document for the overall "WildFly Commonhaus Organization" that's focused on that bit and spells out the concept of "Top Level Projects", listing the ones above along with the "WildFly Application Server" project.
And then I created a separate document for the "WildFly Application Server" project. The other projects listed above would create their own such document that suits their requirements. (The google doc also includes a kind of template for such a thing.)
I blatantly ripped off a lot of text in the google doc from Hibernate's GOVERNANCE.md[2] Hibernate has a degree of similarity to the "WIldFly Commonhaus Organization" in that there are distinct Hibernate projects (ORM, Search, Validator, etc) that are cooperatively developed.
What I've written is deliberately very light on rules about decisions are made, emphasizing cooperation and consensus. Partly that's was to keep this first draft as simple as possible. And partly it's because maybe that's best.
Note that I'd like to get something in place in the next month or so, in order to meet a Commonhaus onboarding requirement. But for sure what we come up with is not fixed in stone; if we have ideas we want to explore we can definitely iterate. I'd like to get the "WildFly Commonhaus Organization" part pretty nailed down quickly, but it's pretty simple. It's the "WildFly Application Server" top level project that is more substantive.