cloudfoundry / community Goto Github PK
View Code? Open in Web Editor NEWGovernance and contact information for Cloud Foundry
License: Apache License 2.0
Governance and contact information for Cloud Foundry
License: Apache License 2.0
small bug fix
minor feature
large feature
vulnerability fix
Document proposal for initial WGs, based on existing PMCs and Projects
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.
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.
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.
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.
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.
We simply don't know how much work it is. Should remove that sentence.
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
I'm wondering if we can imagine situations where > 3 leads is desirable. Suggestion: "not more than 3 leads".
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/
Review and update the language around what makes a person eligible to be nominated for a TOC election.
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.
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).
Also, do we need a mechanism to handle disputes?
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#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?
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
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?
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.
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).
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?
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.
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.
As a community member
Lines 17 to 40 in 9fc193f
Here is a list sources of information regarding CFF projects available to the community
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.
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:
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].
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?
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.
Github Username: test
Community participation: testing
Didn't we plan to include something like this. in https://github.com/cloudfoundry/community/blob/main/TOC.md#committee-decision-making?
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):
Some suggestions for "rebooted" governance:
At least three reasons that someone would need to resign:
Propose an initial cadence for TOC meetings, general agenda and prepare to publish to the CF community
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)
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
.
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?
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:
Current thinking is to use KNative approach: https://github.com/knative/community/blob/master/mechanics/TOC.md#election-process
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?
Number of seats?
Term for elected members?
Election cycles (overlapping?)
Limits on number of seats filled with employees from same organization?
End user seats?
As a CF user
As an inspiration, the CNCF hosts the https://devstats.cncf.io/ for CNCF projects
Contributor statistics dashboards
Issue velocity dashboards
PR velocity dashboards
with Community sizing and health assessmentCompany Statistics by Repository group
per project statistics, e.g. cluster api
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
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).
Concern raised by @julz in a potential scenario where there is not enough diversity of employer represented in the nominated TOC membership list.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.