Cloud Foundry's user experience is recognized as a key differentiator w.r.t. alternative products & communities.

To maintain and further improve this asset, I believe that UX needs to be valued by the community process as an asset which deserves as much care/inclusivity/process as other assets such as technical (code, design) or marketing (branding, logs) or legals (IP).

In the past, I believe CloudFoundry has brought innovative and solid UX as a result of the following practices by key contributors (in particular Pivotal):

• strong product management with investments in user research and metrics to make right product and UX decisions
• gathering community feedback on user experience alternatives (through design proposals, surveys)
• ensuring a strong backward compatibility for UX: systematically gathering community feedback on considered breaking changes in APIs, UX (including CF CLI flag or output changes)
• ensuring an overall consistent UX across CF projects, with efforts such as ubiquitous language across projects, documentation, and marketing activities.

Some suggestions for "rebooted" governance:

• While WGs have full autonomy for managing technical decisions in their scope along with TOC oversight, the
  work affecting CF UX should have a global channel to ask for community feedback (was previously cf-dev@)
• CF UX artefacts (user research, results of community surveys, user experience and design work - such as UX prototypes/personas -, and scenarios, user documentation) should be subject to clear governance, ideally be open to read/contribute by the community while protecting sales/customer details by contributors.
• There should be a process to handling UX-related community disagreements (such as deprecation windows for V2 to V3 API, or CF-on-VMS to CF-on-K8S )

https://github.com/cloudfoundry/community/blob/main/TOC.md#voter-eligibility
As a person who's contributions are mainly in the form of commenting on issues, writing design docs, commenting on design docs ... participating in working groups, I'm wondering how Anyone who has at least 50 contributions in the last 12 months is eligible to vote in the TOC election. is going to translate to these non-code contributions and also how this is going to be counted. I saw that there's an exception process via the TOC, but it would still be good to give some indication what signifies significant contributions over the past year.

Ensure that the ROLES described include all types of contributions, so that there is room for technical contributions that are not directly tied to code-based contributions. Of note, roles that are requirements for TOC eligibility.

I noticed that I don't have access to read the meeting notes linked to from the Istio or the Knative TOC descriptions. It made me wonder why those notes are not publicly viewable. In the interest of transparency, they seem like an artifact we'd want the whole community to be able to read.

My initial opinion is that we should clarify that the meeting notes from the TOC should be viewable by all. It's possible there's some nuance I'm missing here that led Knative and Istio to decide to make their TOC notes private, and I'm curious to hear whether folks have reasons to support that decision.

Comment that triggered this issue:

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 ?

Originally posted by @gberche-orange in #36 (comment)

As of now, we do not have clear info about what is required to get org membership. It would be good to describe that here: https://github.com/cloudfoundry/community/blob/main/ROLES.md

Didn't we plan to include something like this. in https://github.com/cloudfoundry/community/blob/main/TOC.md#committee-decision-making?

Looking at https://github.com/cloudfoundry/community/edit/main/TOC.md, it references VALUES.md which doesn't seem to exist. Should this point to PRINCIPLES.md instead?

In the current CFF governance process, the PMC Council is responsible for the lifecycle of PMCs, PMCs are responsible for the lifecycle of Projects, and Projects are responsible for the lifecycle of repositories.

We need to think about the incubation > active > attic model for lifecycle, and decide how repos will flow through that process (if we keep a lifecycle model).

I'm wondering if we can imagine situations where > 3 leads is desirable. Suggestion: "not more than 3 leads".

Pivotal provides the Gitbot service to synchronize issues and pull requests made against public GitHub repos with Pivotal Tracker projects.

If you do not want to use Pivotal Tracker to manage this GitHub repo, you do not need to take any action.

If you are a Pivotal employee, you can configure Gitbot to sync your GitHub repo to your Pivotal Tracker project with a pull request.

Steps:

• Add the Toolsmiths-Bots team to have admin access to your repo
• Add the cf-gitbot ([email protected]) user to have owner access to your Pivotal Tracker project
• Create new branch in this repo: cfgitbot-config (an ask+cf@ ticket is the fastest way to get write access if you get a 404)
• Add your new repo and or project to config-production.yml file
• Submit a PR, which will get auto-merged if you've done it right. Detailed steps here

If you are not a pivotal employee, you can request that [email protected] set up the integration for you.

You might also be interested in configuring GitHub's Service Hook for Tracker on your repo so you can link your commits to Tracker stories. You can do this yourself by following the directions at:

https://www.pivotaltracker.com/blog/guide-githubs-service-hook-tracker/

If there are any questions, please reach out to [email protected].

I guess we want to replace 'subgroups' with however subgroups are going to be named. E.g. TOC and WG.

Originally posted by @loewenstein in #2 (comment)

• How long is the term of the TOC Chair?
• Under what conditions does the TOC select a new chair? Any change to the TOC composition?
• Is chair selection an official Decision of the TOC, to be governed by the TOC decision-making process?
• Can the TOC Chair resign their chair responsibilities while still remaining on the TOC?

This is for things like: PMC Council becomes TOC

This issue is not intended to describe initial proposal for PMC/Project mapping into new WGs

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

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

• the list of project (prior to #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

Perhaps:

Aim for consensus first, vote if no consensus possible in a reasonable timeframe.

How many votes are needed to make a decision in the affirmative?

As a CF user

• in order to assess community health
• in order to use data to understand vendor involvement contribution
• I need to easily have access to statististics and data about community contributions (in particular code, and handling issues, reviews of PRs)

As an inspiration, the CNCF hosts the https://devstats.cncf.io/ for CNCF projects

Fortunately, the code powering devstats.cncf.io is opensource and could be used as is by the CFF.

See related KubeCon session Who What How: Understanding Kubernetes Development through DevStats with video and slides

Associated code is at https://github.com/cncf/devstats and https://github.com/cncf/devstatscode

In the discussions prior to establishing the TOC, it was suggested that the TOC itself should consider if it wants to expand itself to include one or more end user seats.

A model to review for how end users are added to the TOC, and how the TOC might qualify someone as representing the end user community, can be seen in the CNCF charter: https://github.com/cncf/foundation/blob/master/charter.md section 6(b) in the charter version posted on September 26, 2020.

Opening this issue, but will tag for followup only after the first TOC forms.

Potentially break into board liaison and let the TOC figure out how to run meetings as a group. Consider how the TOC would decide who gets the role, considering how to deal with privacy implications (including what if the board disagrees).

As of now, we have content in GOVERNANCE.md that should be split out into different .md files to document the various aspects of the governance process, perhaps keeping GOVERNANCE.md as a table of contents.

Specifically, the TOC content in GOVERNANCE.md is Julz's initial summary of the TOC model, which has been replaced with the initial load of a TOC.md sourced (with minor modifications) from the KNative community.

https://github.com/cloudfoundry/community/blob/main/TOC.md#candidate-eligibility omits any details of how, where and when (until when) self-nomination can occur.

Document how the TOC will guide itself. Ex: Is there a TOC chair? If there is not a chair, will there be a liaison to the CFF's board assigned?

The expectation is that there is a named rep from the TOC that is an observer on the CFF's board.

Number of seats?
Term for elected members?
Election cycles (overlapping?)
Limits on number of seats filled with employees from same organization?
End user seats?

Proposal:

First election places 5 people in seats. First two highest number of votes start 2 year terms. 3 next are 1 year terms. Election cycle kicks off a year later.

Initial elig proposal:

Need to propose who is elig to run for TOC initially, since the requirements post formation include roles that don't exist during startup. What if TOC elig == vote elig?

At least three reasons that someone would need to resign:

1. The TOC member chooses to resign themselves
2. A TOC member changes employers, which results in the number of TOC members for a single employer limit being reached
3. A code of conduct violation occurs, requiring the CFF board to remove a member of the TOC

small bug fix
minor feature
large feature
vulnerability fix

Document proposal for initial WGs, based on existing PMCs and Projects

Concern raised by @julz in a potential scenario where there is not enough diversity of employer represented in the nominated TOC membership list.

My understanding is that the updates of the Governance docs requires a formal approval voting at some point in time. In order to do this, companies usually ask their legal teams for review of the new terms.

From experience, this requires a bit of time (what's usually requested is two weeks) plus ideally an advance notice/projection on when this is going to happen, roughly.

Also, do we need a mechanism to handle disputes?

Github Username: test
Community participation: testing

https://github.com/cloudfoundry/community/blob/main/TOC.md#voter-eligibility mentions this as the resolving body for voter eligibility exceptions, but we do not have a steering committee.

Should this be handled by the BoD or the TOC? I don't see how the BoD would, but giving the TOC too much influence over who is eligible to vote them might be seen as a conflict of interest. Thought?

Review and update the language around what makes a person eligible to be nominated for a TOC election.

I believe the topic was discussed before but seeing the link from the README.md reminded me that it would be great to keep the documents under https://www.cloudfoundry.org/governance/ in Github as well, especially to have a clear version history (for me, it's less about the format PDF vs. markdown but more on traceability).

Current thinking is to use KNative approach: https://github.com/knative/community/blob/master/mechanics/TOC.md#election-process

Document how the CF project wants the TOC election process to determine eligibility for voting on TOC members

Consider "bootstrap" criteria as part of the change plan, and document post-bootstrap eligibility criteria in the appropriate governance doc.

https://github.com/cloudfoundry/community/blob/main/TOC.md#voter-eligibility mentions only vaguely that there should be a form.

I would suggest that we use an issue template on this repository for this. Thoughts?

Reading through https://github.com/cloudfoundry/community/blob/main/TOC.md, I was wondering if https://github.com/cloudfoundry/community/blob/main/TOC.md under https://github.com/cloudfoundry/community/blob/main/TOC.md#charter should also translate into a bullet point under https://github.com/cloudfoundry/community/blob/main/TOC.md#committee-mechanics.

Something along the lines of:

• Define, document, publish and update the technical direction of the Cloud Foundry open source project as a whole

We simply don't know how much work it is. Should remove that sentence.

We should check the TOC.md#committee-mechanics section on repetition of the TOC.md#charter and do a reflow like @emalm did in #60.

While we do want to talk about the idea of product management as a functional "role-type" for the workgroup leads, I do not believe that any description of the project should use the word product.

Example in TOC.md line 2:
product and design decisions.

Lots of ideas in the Notes section of toc/ROLES.md, but it's not structured well. Consider breaking it up into "fine print rules" and moving some of the general ideas to more appropriate summary sections.

The cloudfoundry certitication process has long lacked from transparency and the process to evaluate/adopt/reject community inputs is lacking inclusivity

https://lists.cloudfoundry.org/g/cf-dev/topic/6371996#7543
https://lists.cloudfoundry.org/g/cf-dev/message/5996?p=,,,20,0,0,0::relevance,,%222017+PaaS+Certification+Requirements%22,20,2,0,6333680

The current certification process is also hard to find, and apparently not referenced in public website at https://www.cloudfoundry.org/certified-platforms/

Propose an initial cadence for TOC meetings, general agenda and prepare to publish to the CF community

Specific attention should be paid to the WG leads, since we decided that there is significant value in ensuring that it is a norm for projects to have both "technical" and "product" oriented leadership.

https://github.com/cloudfoundry/community/blob/main/TOC.md#candidate-eligibility
Similar to #58, TOC members, WG Leads, and Approvers seems to favour code contributions over non-code contributions. I'd like to ask the question if this is the intention when it comes to TOC candidates?

Based on my comment in #31 :

We may struggle to keep this up to date... I know Chris Clark struggles to keep it up to date for the analytics dashboards. One option, which we don't need to solve for right now, might be to start moving repos into GitHub organizations dedicated to each working group. We could keep a shared GitHub org for the community repo, private repos (for CI config) and other shared code / resources.