On 9/1/20 1:58 PM, Matt Wilson wrote:

Perhaps you are suggesting is that end-users having a *binding vote*
in a fixed-Seat governing body, where formal voting happens most often
by convening the holders of those seats at an appointed time, at
which having 60% of the Seats shall constitute a quorum?

This can actually be a great structure for a project with a small number
of vendors doing most of the technical work, but larger number of
users. The difficulty is recruiting users with a sufficient depth of
technical knowledge to have meaningful input, e.g. if the end-user SC
members don't really understand the API, they're not gonna spot a
breaking change.

The other problem is avoiding "captive" users. If a project's
leadership group contains only the staff of one vendor, and that
vendor's commercial users, then it's still a single-company project.
You'd need to have at least a few "freeware" users in there to mix
things up.

--
--
Josh Berkus
Kubernetes Community
Red Hat OSPO