[wildfly-dev] The Commonhaus haus-manager GitHub app

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_6na... 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. This is totally optional; using this feature is not a Commonhaus requirement. It's more a service they offer. Choosing to use it can also be done on a per-GH org basis. So, if, say, wildfly-elytron found value in it but narayana did not, that's fine; one can use it and the other not. AFAICT this also only operates on the mapped groups / teams. If an org wanted to maintain some teams manually they could. We talked during the governance call a couple weeks ago about the need to audit and rationalize our GH groups. If an org wanted to use this CONTACTS.yaml feature, populating the file would be a natural outcome of that effort. Best regards, Brian