Standardize WG metadata to ease community interactions

[gberche-orange]

Expected behavior

As a community member

• in order to easily discover and interact with CFF working groups
• I need a consistent/standardized way to consume WG metadata:
  • WG members and their roles (such as istio/istio/CODEOWNERS or kubernetes-sigs/service-catalog/OWNERS)
  • Roadmap pointer
  • Public CI pointer (and associated git repo)
  • Pointers to design and architecture documents
  • List of git repos
  • Slack channel
  • Security contacts (in addition to CFF level security contacts)

Observed behavior

community/GOVERNANCE.md

Lines 17 to 40 in 9fc193f

	# Working Groups
	* Sponsored by TOC for major areas, e.g. scheduling, logging etc
	* Roughly equivalent to projects today
	* Some may be focused on one area, some may be cross-cutting
	* Should have a charter (mission, goals, scope etc)
	* Should maintain a Roadmap
	* Anyone can join the WG
	* Weekly meetings, slack channel etc
	* All work in the open
	* Leadership, N (1-3ish) Leads appointed as below
	* Generally, WG should make decisions by consensus, but the leads are ultimately responsible
	* Create subgroups as needed (e.g. could create a team to focus on a specific, time-bound deliverable, potentially that team may work in a tracker/pairing model) - no formal model for these
	* If consensus not reached Leads generally make decision, but can escalate to TOC
	*Note:* the working group does _not_ privilege pairing or tracker by default. (It may split out a subgroup to work on a task or deliverable in a pairing model which is then adopted on completion by the WG, or becomes its own WG). In general the WGs default to open, so both pairing and non-pairing contributions are the same. Of course, members of the WG may choose to pair, and the WG may choose to have a daily (open) standup, and to practice TDD, but there’s not a magic different backlog for people pairing, and pairing does *not* skip the need for an /approve (tho 1 of the pair may be an approver). Contentious decisions should trigger a conversation on a github issue etc, they should _not_ be resolved by an offline conversation with a PM that doesn’t end up back on the issue.
	# Working Group Roles
	Modelled after https://github.com/knative/community/blob/master/ROLES.md
	* Member:
	* Actively contributing
	* Has power to lgtm PRs (requirement to merge: 1 lgtm, 1 approve)
	* Approver/Maintainer (of a part of the code): roughly

does not yet describe standard format for WG to expose their metadata/assets to the community

Here is a list sources of information regarding CFF projects available to the community

• the list of project (prior to Change plan needs to describe how existing CFF governance morphs into new #6) at https://www.cloudfoundry.org/projects/ is largely outdated.
• the https://github.com/cloudfoundry/pmc-notes/ repo provides up-to-date project news to the community
• @gberche-orange maintains at https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/Design-Documents pointers to
  • project roadmaps (in pivotal tracker or github projects)
  • project public CI and their associated git repos
  • architecture and design documents

[chipchilders]

Absolutely agree with this. Does anyone want to propose a PR that addresses more details about metadata for the WG's? @cloudfoundry/governance-wg or anyone else?

[gberche-orange]

thanks @chipchilders

BTW, it seems that @cloudfoundry/governance-wg is'nt yet public as https://github.com/orgs/cloudfoundry/teams/governance-wg is returning a 404. Any chance to open read visibility of teams in the cloudfoundry community for everyone ?

[gberche-orange]

Unfortunately, according https://docs.github.com/en/free-pro-team@latest/github/setting-up-and-managing-organizations-and-teams/changing-team-visibility github organization teams seems to only be visible to organization members.

Any chance for CFF to add representative of CFF members to the organization, or more generally CFF community users ?

[chipchilders]

Unfortunately, according https://docs.github.com/en/free-pro-team@latest/github/setting-up-and-managing-organizations-and-teams/changing-team-visibility github organization teams seems to only be visible to organization members.

Any chance for CFF to add representative of CFF members to the organization, or more generally CFF community users ?

Opened #38 to address this question.

[chipchilders]

thanks @chipchilders

BTW, it seems that @cloudfoundry/governance-wg is'nt yet public as https://github.com/orgs/cloudfoundry/teams/governance-wg is returning a 404. Any chance to open read visibility of teams in the cloudfoundry community for everyone ?

Sorry... that team was specifically to get through the process of forming a proposal here in this repo. The members today are: @jenspinney @loewenstein @julz @friegger @smoser-ibm @aclark801 (and myself for support).

[chipchilders]

TOC will need to address this once started. Tagging with icebox.

[emalm]

We've embedded YAML documents in each WG charter that provide a more structured representation of the WG membership and repository scope, and https://github.com/cloudfoundry/community/blob/main/toc/working-groups/WORKING-GROUPS.md has some regularized info about the WG processes. If there is other information that's important to represent systematically, we can handle that on specific new issues.