3:49 p.m.
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.
Best regards,
Brian
[1]
https://docs.google.com/document/d/1r2i17R6VtqGeslKlyH6lWVIQix0-QCiMa_6na...
[2] https://hibernate.org/community/governance
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His