Contributor Experience Charter #2843
Conversation
parispittman
added
sig/contributor-experience
k8s-ci-robot
added
do-not-merge/work-in-progress
parispittman
force-pushed
the
charterv3
branch
from
37cc3c3
to
7dcb40b
Compare
There was a problem hiding this comment.
This looks great. A few comments from me. Really, really, really appreciate all the thought and work you put into this @parispittman 🏆 !
|
|
||
| - Establish policies, standards, and procedures: | ||
| - routine GitHub management tasks, including but not limited to: org membership, org permissions, repo creation/administration. | ||
| - "Org Owner" GitHub permissions, and grant/limit these privileges accordingly |
There was a problem hiding this comment.
this line might be redundant with the previous
| - routine GitHub management tasks, including but not limited to: org membership, org permissions, repo creation/administration. | ||
| - "Org Owner" GitHub permissions, and grant/limit these privileges accordingly | ||
| - bot accounts, service accounts, webhooks, and third-party integrations for all communication platforms that we support but most importantly, GitHub. | ||
| - Establishing a "GitHub Administration team" that will oversee the execution of GitHub management tasks: inviting new members to the org, creating repos, executing moderation decisions, auditing permissions. |
| - bot accounts, service accounts, webhooks, and third-party integrations for all communication platforms that we support but most importantly, GitHub. | ||
| - Establishing a "GitHub Administration team" that will oversee the execution of GitHub management tasks: inviting new members to the org, creating repos, executing moderation decisions, auditing permissions. | ||
| - Work with other SIGs and interested parties in the project to execute GitHub tasks where required | ||
| -Own and execute events that are targeted to the Kubernetes contributor community, including: |
| - The weekly [Kubernetes Community meeting] | ||
| - [Contributor Summit(s)] | ||
| - SIG Contributor Experience face to face meetings | ||
| - [Steering Committee elections] (though we do not own policy creation, see 'out of scope' below) |
There was a problem hiding this comment.
unclear on what this involves. don't know if this is direct contribex, or is it our responsibility to provide election officers who take this on?
There was a problem hiding this comment.
@spiffxp - do you want to shed some light on this from a steering perspective?
I think contribex should own the process as it's a contributor only event and we should influence events that are solely for contributors.
There was a problem hiding this comment.
I am comfortable with the phrasing as is, but yes I read this as saying elections officers should come from contribex, as that is the SIG I trust to be most in tune with community norms and processes. The steering committee has often deferred to the officers when it comes to the details of executing the election.
| - [Group Mentoring - WIP] | ||
| - [The 1:1 Hour - WIP] | ||
| - Speed Mentoring at KubeCon | ||
| - Create best practices, trainings, policies, and [moderation] of Kubernetes communication platforms, the transparency vehicles of information throughout the project. This includes user guidelines when the contributor is the user of the platform. Moderation is an always on, never off service that we supply with trusted contributors spanning time zones. This includes immediate action when dealing with code of conduct issues in a public space that are defined below: |
There was a problem hiding this comment.
This is pretty long for a point form list, and mixes both owning the platforms, and doing moderation on them. Perhaps this can be shortened or split up?
Also, we (via the github admin team) would handle moderation on GitHub too, where that's needed.
There was a problem hiding this comment.
I took out some lines - how is this:
Create best practices, trainings, policies, and [moderation] of Kubernetes communication platforms, the transparency vehicles of information throughout the project. We supply the moderation teams that span time zones for 24/7 coverage. This includes immediate action when dealing with code of conduct issues in a public spaces, which are defined below:
parispittman
force-pushed
the
charterv3
branch
3 times, most recently
from
125db40
to
b9ff339
Compare
|
|
||
| ### In scope | ||
|
|
||
| #### Code, Binaries and Services |
There was a problem hiding this comment.
This reads like a massive and overly specific list. I would prefer to see this summarized and less exhaustively listed, but if you completely ignore this and address the rest of my comments, I won't block.
That said, some suggestions:
- I still think this would benefit from consolidating moderation/management of communication platforms into one list as I suggested in the last PR
- Consider breaking up the comms / events / services that you offer into:
- Community-focused (eg: community meeting, summits, elections, news distro, surveys)
- SIG-focused (eg: logistics, best practices, event planning / retrospective support)
- Contributor-focused (eg: mentoring, contributor guide)
- For some reason project health and automation feel distinct from the above but I can't quantify or come up with a good bullet to lump them under
| - engagement on project platforms that we manage | ||
| - Encourage automation to improve productivity for contributors where it makes sense and consult with SIG Testing if automation is covering GitHub workflows. | ||
| - Research other OSS projects and consult with their leaders about contributor experience topics to make sure we are always delivering value to our contributors. | ||
| - Provide retrospective hosting services on request to SIGs |
There was a problem hiding this comment.
this is already called out above as
Retrospective moderation for other SIGs upon request
| - The contributor experience for repos not included in the Kubernetes [associated repositories]list. | ||
| - Steering committee election policy updates and maintenance. | ||
| - We do not create SIGs/WGs but can assist in the various community management needs of their micro communities that would kick off their formation and keep them going. | ||
| - We are not the [code of conduct committee] and therefore do not control incident management reporting or decisions; however, our moderation guidelines allow us to act swiftly if there is a clear violation of terms on one of our supported platforms. If there is an action that the committee needs to take that involves one of these platforms (example: the removal of someone from GitHub), we will carry that out if none of the committee members have access. |
There was a problem hiding this comment.
clear violation of terms
the platform's TOS? our CoC? both?
There was a problem hiding this comment.
i put a line about both
| - We are not the [code of conduct committee] and therefore do not control incident management reporting or decisions; however, our moderation guidelines allow us to act swiftly if there is a clear violation of terms on one of our supported platforms. If there is an action that the committee needs to take that involves one of these platforms (example: the removal of someone from GitHub), we will carry that out if none of the committee members have access. | ||
| - Communication platforms that are out of our scope for maintenance and support but we may still have some influence: | ||
| - [r/kubernetes] | ||
| - [kubernetesio@] twitter account |
| - The weekly [Kubernetes Community meeting] | ||
| - [Contributor Summit(s)] | ||
| - SIG Contributor Experience face to face meetings | ||
| - [Steering Committee elections] (though we do not own policy creation, see 'out of scope' below) |
There was a problem hiding this comment.
I am comfortable with the phrasing as is, but yes I read this as saying elections officers should come from contribex, as that is the SIG I trust to be most in tune with community norms and processes. The steering committee has often deferred to the officers when it comes to the details of executing the election.
| - ongoing work with the CNCF to improve [DevStats] | ||
| - the contributor experience survey(s) | ||
| - engagement on project platforms that we manage | ||
| - Encourage automation to improve productivity for contributors where it makes sense and consult with SIG Testing if automation is covering GitHub workflows. |
There was a problem hiding this comment.
If this is collaboration with another SIG then I would recommend putting this in the cross-cutting section
| - Own and execute events that are targeted to the Kubernetes contributor community, including: | ||
| - The weekly [Kubernetes Community meeting] | ||
| - [Contributor Summit(s)] | ||
| - SIG Contributor Experience face to face meetings |
There was a problem hiding this comment.
this seems out of place in this list as it's specific to this SIG vs. being community-wide
| ### Subproject Creation - TODO | ||
| Pick one: | ||
| SIG Technical Leads | ||
| Federation of Subprojects |
There was a problem hiding this comment.
I need to understand what's holding us up in making a decision here. Both options prefer lazy consensus among SIG members first before resorting to a fallback vote.
IMO a large portion of this SIG's responsibilities are non technical in nature, so I'm not sure that the the TL option makes much sense. I would be comfortable expanding the "TL" option to include "TLs and Chairs" in this case, or suggest Federation of Subprojects (which a few SIGs have chosen, notably SIG Cluster Lifecycle). Or we consider "community management" a "technical" skill, and opt to choose a tech lead or two who specializes in that.
There was a problem hiding this comment.
I think in our case, Chairs + TLs is the best option. Still gives a wide perspective, but in practice, we've never needed a tie break.. consensus of the body is always best.
There was a problem hiding this comment.
updated with chairs and tls
|
I'm good with all of @spiffxp's feedback above. |
parispittman
force-pushed
the
charterv3
branch
from
b9ff339
to
1e1db92
Compare
k8s-ci-robot
added
the
approved
|
|
||
| - Deploying Changes: | ||
| When implementing policy changes we strive to balance responding quickly to the needs of the community and ensuring a disruption-free experience for project contributors. As such, the amount of notice we provide and the amount of consensus we seek is driven by our estimation of risk. We don't measure risk objectively at this time, but estimate it based on these parameters: | ||
| - Low risk changes impact a small number (<4) of SIGs, WGs, or repos, do not break existing contributor workflows, and are easy to roll back. When implementing low risk changes we: |
There was a problem hiding this comment.
| - Low risk changes impact a small number (<4) of SIGs, WGs, or repos, do not break existing contributor workflows, and are easy to roll back. When implementing low risk changes we: | |
| - Low-risk changes impact a small number (<4) of SIGs, WGs, or repos, do not break existing contributor workflows, and are easy to roll back. When implementing low-risk changes we: |
| - Code for the testing and CI infrastructure - that’s SIG Testing | ||
| - [kubernetes/community] ownership of folders for KEPs and Design Proposals. Members are to follow those folders owners files and SIG leadership for the specific issue/PR in question. | ||
| - User community management. We hold office hours because contributors are a large portion of the volunteers that run that program. | ||
| - The contributor experience for repos not included in the Kubernetes [associated repositories]list. |
There was a problem hiding this comment.
| - The contributor experience for repos not included in the Kubernetes [associated repositories]list. | |
| - The contributor experience for repos not included in the Kubernetes [associated repositories] list. |
| - Low risk changes impact a small number (<4) of SIGs, WGs, or repos, do not break existing contributor workflows, and are easy to roll back. When implementing low risk changes we: | ||
| - Socialize on kubernetes-sig-contribex@googlegroups.com and on our weekly update calls | ||
| - We will go to each lead, their mailing lists, slack channel, and/or their update meetings and ask for feedback and a [lazy consensus] process. We will follow up with a post to [kubernetes-dev@]googlegroups.com mailing list | ||
| - High risk changes impact a large number (<4) of SIGs, WGs, or repos, break existing contributor workflows, and are not easy to roll back. When implementing high risk changes we: |
There was a problem hiding this comment.
| - High risk changes impact a large number (<4) of SIGs, WGs, or repos, break existing contributor workflows, and are not easy to roll back. When implementing high risk changes we: | |
| - High-risk changes impact a large number (<4) of SIGs, WGs, or repos, break existing contributor workflows, and are not easy to roll back. When implementing high-risk changes we: |
| - Our standard time box is 72 business hours; however, there may be situations where we need to act quickly but the time period will always be clear and upfront. | ||
|
|
||
| If we need funding for any reason, we approach [CNCF]. | ||
| CNCF in many of the noted cases above, contributes funding to our platforms, processes, and/or programs. They do not play a day-to-day operations role and have bestowed that to our community to run as we see fit. Since they do fund some of our initatives, this means that they hold owner account privileges on certain platforms like Zoom and Slack. In these cases, such as Slack, there are at least two Contributor Experience [communication] subproject OWNERs listed as admins. |
There was a problem hiding this comment.
| CNCF in many of the noted cases above, contributes funding to our platforms, processes, and/or programs. They do not play a day-to-day operations role and have bestowed that to our community to run as we see fit. Since they do fund some of our initatives, this means that they hold owner account privileges on certain platforms like Zoom and Slack. In these cases, such as Slack, there are at least two Contributor Experience [communication] subproject OWNERs listed as admins. | |
| CNCF in many of the noted cases above, contributes funding to our platforms, processes, and/or programs. They do not play a day-to-day operations role and have bestowed that to our community to run as we see fit. Since they do fund some of our initiatives, this means that they hold owner account privileges on certain platforms like Zoom and Slack. In these cases, such as Slack, there are at least two Contributor Experience [communication] subproject OWNERs listed as admins. |
| We cross-cut all SIGs and WGs to deliver the following processes: | ||
|
|
||
| - Deploying Changes: | ||
| When implementing policy changes we strive to balance responding quickly to the needs of the community and ensuring a disruption-free experience for project contributors. As such, the amount of notice we provide and the amount of consensus we seek is driven by our estimation of risk. We don't measure risk objectively at this time, but estimate it based on these parameters: |
There was a problem hiding this comment.
| When implementing policy changes we strive to balance responding quickly to the needs of the community and ensuring a disruption-free experience for project contributors. As such, the amount of notice we provide and the amount of consensus we seek is driven by our estimation of risk. We don't measure risk objectively at this time, but estimate it based on these parameters: | |
| When implementing policy changes we strive to balance responding quickly to the needs of the community and ensuring a disruption-free experience for project contributors. As such, the amount of notice we provide and the amount of consensus we seek is driven by our estimation of risk. We don't measure risk objectively at this time, but estimate it based on these parameters: |
| - Deploying Changes: | ||
| When implementing policy changes we strive to balance responding quickly to the needs of the community and ensuring a disruption-free experience for project contributors. As such, the amount of notice we provide and the amount of consensus we seek is driven by our estimation of risk. We don't measure risk objectively at this time, but estimate it based on these parameters: | ||
| - Low risk changes impact a small number (<4) of SIGs, WGs, or repos, do not break existing contributor workflows, and are easy to roll back. When implementing low risk changes we: | ||
| - Socialize on kubernetes-sig-contribex@googlegroups.com and on our weekly update calls |
There was a problem hiding this comment.
| - Socialize on kubernetes-sig-contribex@googlegroups.com and on our weekly update calls | |
| - Socialize on kubernetes-sig-contribex@googlegroups.com and our weekly update calls |
| - High risk changes impact a large number (<4) of SIGs, WGs, or repos, break existing contributor workflows, and are not easy to roll back. When implementing high risk changes we: | ||
| - Socialize on kubernetes-sig-contribex@googlegroups.com and on our weekly update calls | ||
| - Seek [lazy consensus] with a time box of at least 72 business hours with a GitHub issue link (or proposal if not applicable) to the following mailing lists: | ||
| - [kubernetes-sig-contribex@]googlegroups.com |
There was a problem hiding this comment.
| - [kubernetes-sig-contribex@]googlegroups.com | |
| - [kubernetes-sig-contribex@]googlegroups.com |
| - Socialize on kubernetes-sig-contribex@googlegroups.com and on our weekly update calls | ||
| - Seek [lazy consensus] with a time box of at least 72 business hours with a GitHub issue link (or proposal if not applicable) to the following mailing lists: | ||
| - [kubernetes-sig-contribex@]googlegroups.com | ||
| - sig-leads@googlegroups.com |
There was a problem hiding this comment.
| - sig-leads@googlegroups.com | |
| - sig-leads@googlegroups.com |
| - Seek [lazy consensus] with a time box of at least 72 business hours with a GitHub issue link (or proposal if not applicable) to the following mailing lists: | ||
| - [kubernetes-sig-contribex@]googlegroups.com | ||
| - sig-leads@googlegroups.com | ||
| - [kubernetes-dev@]googlegroups.com with the GitHub issue link including the subject [NOTICE]: $announcement |
There was a problem hiding this comment.
| - [kubernetes-dev@]googlegroups.com with the GitHub issue link including the subject [NOTICE]: $announcement | |
| - [kubernetes-dev@]googlegroups.com with the GitHub issue link including the subject [NOTICE]: $announcement |
There was a problem hiding this comment.
indent these three mailing lists
| - Socialize on kubernetes-sig-contribex@googlegroups.com and on our weekly update calls | ||
| - We will go to each lead, their mailing lists, slack channel, and/or their update meetings and ask for feedback and a [lazy consensus] process. We will follow up with a post to [kubernetes-dev@]googlegroups.com mailing list | ||
| - High risk changes impact a large number (<4) of SIGs, WGs, or repos, break existing contributor workflows, and are not easy to roll back. When implementing high risk changes we: | ||
| - Socialize on kubernetes-sig-contribex@googlegroups.com and on our weekly update calls |
There was a problem hiding this comment.
the same with low-risk ones?
if so:
| - Socialize on kubernetes-sig-contribex@googlegroups.com and on our weekly update calls | |
| - Socialize on kubernetes-sig-contribex@googlegroups.com and our weekly update calls |
parispittman
force-pushed
the
charterv3
branch
from
1e1db92
to
07a0240
Compare
|
/cc @sarahnovotny |
| [DevStats]: https://k8s.cncf.devstats.io | ||
| [kubernetes-sig-contribex@]: https://groups.google.com/forum/#!forum/kubernetes-sig-contribex | ||
| [kubernetes blog]: https://www.kubernetes.io/blog | ||
| [GitHub]: https://git.k8s.io/community/github-management |
There was a problem hiding this comment.
nit: let's call this github-management instead of just GitHub? 😬
| [project list]: https://github.com/orgs/kubernetes/projects/1 | ||
| [Kubernetes Community meeting]: https://git.k8s.io/community/ | ||
| [mentoring programs]: https://git.k8s.io/community/mentoring | ||
| [Steering Committee elections]: https://git.k8s.io/community/ |
There was a problem hiding this comment.
I think this should point to https://git.k8s.io/community/events/elections
| - [Group Mentoring - WIP] | ||
| - [The 1:1 Hour - WIP] | ||
| - Speed Mentoring at KubeCon | ||
| We supply the moderation teams that span time zones for 24/7 coverage. This includes immediate action when dealing with code of conduct issues in a public spaces |
There was a problem hiding this comment.
- Is this for the speed mentoring session or in general? If in general, this needs to go as a sub-point under moderation, or else it renders with the Speed Mentoring point.
- Maybe we can rephrase this as
We supply moderation teams spanning multiple time zones for 24/7 coverage.? - s/a public spaces/public places.
| - [The 1:1 Hour - WIP] | ||
| - Speed Mentoring at KubeCon | ||
| We supply the moderation teams that span time zones for 24/7 coverage. This includes immediate action when dealing with code of conduct issues in a public spaces | ||
| - Help onboard new contributors and current into the culture, workflow, and CI of our contributor experience through the [contributor guide], other related documentation, [contributor summits] and programs tailored to onboarding. |
There was a problem hiding this comment.
nit: s/new contributors and current/new and current contributors
| - Perform issue triage on and maintain the [kubernetes/community] repository. | ||
| - Help SIGs with being as transparent and open as possible through creating best practices, guidelines, and general administration of YouTube, Zoom, and our mailing lists where applicable | ||
| - Assist SIGs/WG Chairs and Technical Leads with organizational management operations as laid out in the [sig-governance] doc | ||
| - Distribute contributor related news on various Kubernetes channels, including Cloud Native Compute Foundation [CNCF] for posting blogs, social media, and other platforms as needed. |
There was a problem hiding this comment.
nit: s/[CNCF]/([CNCF]) ... i.e. CNCF in brackets
| - Low-risk changes impact a small number (<4) of SIGs, WGs, or repos, do not break existing contributor workflows, and are easy to roll back. When implementing low-risk changes we: | ||
| - Socialize on kubernetes-sig-contribex@googlegroups.com and our weekly update calls | ||
| - We will go to each lead, their mailing lists, slack channel, and/or their update meetings and ask for feedback and a [lazy consensus] process. We will follow up with a post to [kubernetes-dev@]googlegroups.com mailing list | ||
| - High-risk changes impact a large number (<4) of SIGs, WGs, or repos, break existing contributor workflows, and are not easy to roll back. When implementing high-risk changes we: |
| [CNCF]: https://cncf.io | ||
| [GitHub issues]: https://github.com/kubernetes/community/issues | ||
| [project list]: https://github.com/orgs/kubernetes/projects/1 | ||
| [Kubernetes Community meeting]: https://git.k8s.io/community/ |
There was a problem hiding this comment.
This could point to communication#weekly-meeting
| - Code for the testing and CI infrastructure - that’s SIG Testing | ||
| - [kubernetes/community] ownership of folders for KEPs and Design Proposals. Members are to follow those folders owners files and SIG leadership for the specific issue/PR in question. | ||
| - User community management. We hold office hours because contributors are a large portion of the volunteers that run that program. | ||
| - The contributor experience for repos not included in the Kubernetes [associated repositories] list. |
There was a problem hiding this comment.
This needs a link to be mentioned below in the doc.
https://git.k8s.io/community/github-management/kubernetes-repositories.md#associated-repositories
|
|
||
| ### Additional responsibilities of Chairs | ||
|
|
||
| Chairs SHOULD plan at least one face to face Contributor Experience meeting per year |
parispittman
force-pushed
the
charterv3
branch
from
07a0240
to
96e589e
Compare
dims
changed the title
k8s-ci-robot
removed
the
do-not-merge/work-in-progress
|
/lgtm Please release hold when you wish. Charter looks good! |
k8s-ci-robot
added
do-not-merge/hold
|
/approve |
|
waiting for @sarahnovotny's final go and then I'll release the hold |
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cblecker, parispittman, sarahnovotny, spiffxp The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/hold cancel |
k8s-ci-robot
removed
the
do-not-merge/hold
Trying this charter thing out again since the mistake during the recent outage merged to master. Ref #2810.
Incorporated most of @spiffxp's review from #2810 except the GitHub management bullets which I'd rather have @cblecker weigh in directly about. Expecting another edit.