In various discussions related to onboarding to Commonhaus, I've made vague comments about a bot (i.e. GitHub app) we need to install.

I've done some research and I understand better what it's all about. So, FYI:

1) A minimal thing we need to do is give https://github.com/apps/haus-manager-bot access to one repo. Logically that would be https://github.com/wildfly/wildfly-governance as this particular use case relates to governance.

The purpose of doing this is to configure GH perms for a private commonhaus repo that's for the overall WildFly project, where we can store private data or whatever related to WildFly. For example trademark info, domain administration info etc.

In the 'wildfly' GH org we create a GH team, say 'commonhaus-triage'. The members of this team would have GitHub 'triage' perms for the private WildFly repo in the commonhaus org.

The action items here are to 

* install the app

* create a team

* decide who is in the team

For the last bit we can start with Tom and I (who already have perms), but if our top-level governance model was something like what's in https://docs.google.com/document/d/1r2i17R6VtqGeslKlyH6lWVIQix0-QCiMa_6naq1tn-c/edit?tab=t.qvcns495qtsh#heading=h.npongdwksnh3 I'd suggest putting the current Commonhaus Representative, Deputy Commonhaus Representative and Project Lead for each Top-Level Project in this team. This will let the project leads help with any administrative tasks that are coordinated via the private project.

2) More interesting is it provides an optional feature where a GH org could publish a CONTACTS.yaml file in some repo, and that file provides a list of groups and the membership in each group.  In the private repo mentioned above we then maintain a mapping of groups to GH teams.

The haus-manager-bot will then keep the membership in the GH teams in sync with what's in the CONTACTS.yaml files. Basically, this lets people use git to control GH team membership, instead of relying on the GH UI.