cantbewong
commented
4 years ago /kind documentation
Closed cantbewong closed 4 years ago
cantbewong
commented
4 years ago /kind documentation
cblecker
commented
4 years ago /assign
fejta-bot
commented
4 years ago Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale
fejta-bot
commented
4 years ago Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle rotten
fejta-bot
commented
4 years ago Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /close
k8s-ci-robot
commented
4 years ago @fejta-bot: Closing this issue.
This issue has been opened at the request of the steering committee to document the process and experience of creating a new User Group. (see notes for December 2, 2019 steering committee public meeting)
This issue has been opened for two purposes:
This is a summary of the User Group formation “flow chart” of steps - according to current instructions which are spread across multiple documents:
Within the sig-wg-lifecycle.md document, the following “prerequisites” are indicated. They are not numbered in a sequence so I took the instructions to mean that a parallel dispatch of these items is allowed, unless some item would clearly require another to occur first:
Read the documentation on user group governance.
Identify exactly 2 Chairs which are required to start a User Group.
Identify at least 2 required members other than Chairs to be a part of the User Group.
In this document, perhaps it’s ambiguous as to whether the term members refers to UG membership or formal Kubernetes community memberships status. But back in step 1, text says “others that hold leadership positions within a user group must be community members”. In the process of creating the first User Group, I assumed that these required inaugural member are leadership positions since they seem to be called out as a special category. Even if there is no requirement that these inaugural members be leadership positions, the governance doc indicates that leadership positions are allowed and anticipated, so I choose to deem these two inaugural members to be "tech leads", and to label them as such in related documents and yaml files.
It later became apparent that none of the potential candidates I recruited as prospective inaugural members had previously registered as community members. I suspect that this scenario will not be unusual for UG formations. I think that both the requirements for membership and the potential benefits of membership are slanted more towards code contributors than Kubernetes users. As the prospective “inaugural users” attempted to attain membership status, a secondary issue arose. They met the stated criteria, but the majority of their Kubernetes project interaction occurred with people affiliated with a single organization (a vendor doing most of the dev and support for the cloud provider they used) so that meeting the membership requirement of sponsors from two organizations proved difficult, but eventually surmountable.
Meet requirement of at least 2 sponsors from steering or lazy consensus (In case of no objection within 7 week days).
This step isn't explicit as to the procedure for ascertaining these sponsors, or the method that triggers the 7 week day countdown clock. Since there are multiple steps that would inform steering committee members of a request to form a User Group (two emails plus a sigs.yaml PR), I assumed that completion of these three steps starts the lazy consensus clock running, and that either email responses, or comments within the sigs.yaml update PR from two steering committee members could shortcut the lazy consensus.
Send an email to kubernetes-dev@googlegroups.com and steering@kubernetes.io titled "UG-Creation-Request: UG Foo" answering the following questions and wait for community discourse:
What topics are in scope for this user group?
What is the meeting cadence?
Who will chair the group, and ensure it continues to meet the requirements? Obviously these items need to also be published in an additional form beyond this required email – which the following required step accomplishes.
Submit a sigs.yaml PR as described in the GitHub section of sig-wg-lifecycle.md and add a row to the UG section:
Label with committee/steering and place a /hold on it.
Send an email to the steering committee with the sigs.yaml pull request. The instructions in the GitHub section of sig-wg-lifecycle.md uses only the term SIG. Prior community conduct has Working Groups following the SIG instructions – so I assumed that User Groups should also follow SIG instructions – except for items obviously not applicable like subprojects, schedules and roadmaps. On the basis of this assumption, these steps are needed:
Gather:
SIG User Group Name
Directory URL
Mission Statement
Chair Information
Meeting Information
Contact Methods
Any SIG User Group Stakeholders
Add these to SIG Working group related docs like charter.md, etc. to your new kubernetes/community/ug-foo directory once the sigs.yaml PR is merged.
File a Kubernetes/Org Issue for a label; read about our GitHub management services
References to specific examples of steps done during example of VMware User Group creation
PR updating sigs.yaml for VMware User Group PR requesting add of new VMware User Group Slack channel PR requesting new label associated with VMware User Group PR creating a VMware User Group Charter
Issues with my experience doing this:
The first attempt at sending the requested email to the steering committee resulted in the email being rejected. This was because of restrictions on the mailing list that have been resolved. I believe that going forward, this issue will no longer occur.
User Groups require community membership. I speculate that membership status is more commonly found with developers than it is for end users. I further speculate that even when end users have engaged in the required community participation activities in order to qualify for membership, their interactions are likely to be with less diverse and smaller numbers of people than is commonly the case with developers. Prospective inaugural members of this user group did not begin with an active membership, and while they met membership criteria, seeking out membership sponsors was time consuming. This issue may occur during formation of other user groups, so prospective initiators are advised to inquire about membership status of nominees as inaugural members.
I created a PR creating a User Group charter. There has been some discussion in the PR comments as to whether a charter is desirable for a User Group. The GitHub section of the lifecycle document is included in User Group formation instructions by reference, yet actually only mentions SIGs (not WGs or UGs). It appears that some Working Groups, but not all, have charters. This seems to indicate that charters are being treated as optional for WGs, even if not documented as such. I am mentioning to indicate that if charters are to be prohibited for User Groups, this should be documented so that future applicants don’t waste time composing one that faces certain rejection. If they are optional, no documentation change is required - neglecting to explicitly state that charters are optional does not seem to have been an issue for WGs, so it should be OK to follow this precedent for UGs as well.