user experience as 1st class asset with its associated governance about community

[loewenstein]

@gberche-orange do you think that as a first step having a WG dedicated to UX would help?

[gberche-orange]

@loewenstein I don't believe a dedicated WG to UX would help for this kind of crosscutting aspects applying to all WGs.

To take analogies with other tranversal topics, would you think that the following dedicated WGs make sense ? security WG, documentation WG , licensing/intellectual property WG, automated testing WG, defect management WG, etc...

I'd rather this UX governance be part of GOVERNANCE.md#working-groups, similar to #36, and deserves its own community discussion and concensus

community/GOVERNANCE.md

Lines 17 to 33 in 5184516

	# 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.

[loewenstein]

@gberche-orange FWIW, knative has working groups for Documentation and Productivity and Istio has one for user experience.

Now, that is of course not saying anything about this being effective and delivering what you would like to see. However, we would get a working group that takes responsibility for community feedback, UX artefacts and that would be involved in (or even in a driver seat for) UX related discussion and disagreements.

Working Group proposals, including CF CLI version deprecations would have to pass UX WG review.

If the TOC would sponsor a UX WG and give them the charter to

• coordinate and execute user research
• gather community feedback
• ensure backwards compatible UX
• ensure consistent UX across projects

Wouldn't that be in line with what you would like to see?

[gberche-orange]

Wouldn't that be in line with what you would like to see?

Yes, if adopted by the community and other WGs, this would satisfy the need for inclusivity I'm expressing.

However, my personal intuition is that centralizing all UX related activities in a dedicated UX WG would create bottlenecks and may end up in a situation with a UX WG being disconnected from WGs actually implementing the features. Would be good to have feedback from current CFF projects to enrich perspectives.