2017-events: add governance notes from 2017 leadership summit
This commit is contained in:
parent
45988676be
commit
4ef9991ce6
|
|
@ -0,0 +1,107 @@
|
|||
# SIG Governance and Check-in
|
||||
|
||||
**Identify the following before beginning your session. Do not move forward until these are decided / assigned:**
|
||||
|
||||
- **Session Topic: SIG Governance and check-in**
|
||||
- **Topic Facilitator(s):** brendandburns@
|
||||
- **Note-taker(s) (Collaborating on this doc)**: jbeda@
|
||||
- **Person responsible for converting to Markdown & uploading to Github:** philips@
|
||||
|
||||
### Session Notes
|
||||
|
||||
- Core discussions about SIG leadership
|
||||
- Is the SIG lead role more like an on-call position or a team lead?
|
||||
- There are 2 parts of the role: facilitation and management of the owners files
|
||||
- authority comes from commits?
|
||||
|
||||
#### Conclusions
|
||||
|
||||
#### Key Takeaways / Analysis of Situation
|
||||
|
||||
Recommendations & Decisions Moving Forward (High-Level)
|
||||
|
||||
Specific Action Items (& Owners)
|
||||
|
||||
| **Action Item** | **Owner(s)** |
|
||||
| --- | --- |
|
||||
| SIG starter kit: Gather constructive feedback from SIGs; Create a summary of that feedback | Bob Wise |
|
||||
| How should SIG lead/governance work? Figure out a lot of this stuff. Everyone should share with the steering committee and get that ready for the full committee. | Steering Committee |
|
||||
| Schedule SIG lead office hours to coordinate around PRs and getting stuff done. | Jason DuMars |
|
||||
| SIG-architecture? | Steering Committee |
|
||||
| SIG consolidation? | Steering Committee |
|
||||
|
||||
#### Purpose
|
||||
|
||||
- Michelle
|
||||
- What is your format?
|
||||
- How is it going?
|
||||
- Are there things that you are struggling with?
|
||||
- Do we need to formalize about forming/running/governing a SIG?
|
||||
- Joe
|
||||
- How do we pick SIG leads? What type of leadership? What are the responsibilities? Is this the same across the project or per SIG?
|
||||
|
||||
#### Discussion
|
||||
|
||||
- Rob: Cross cutting sig concerns? Venn diagram? Common concerns get lost. SIG-cloud is similar.
|
||||
- What other types of horizontal/project?
|
||||
- Ops, testing, etc.
|
||||
- Bob: Would it be useful to draw connection map and formalize communication channels
|
||||
- Eric: Staff and line position? Line = line of business. Staff = centralized responsibility.
|
||||
- Q: Where would you put SIG-testing? A: staff? Testing guidance for all the SIGs.
|
||||
- Technical area (LoB) vs. staff (shared service and expertise)
|
||||
- Brendan -- there are technical staff groups vs. non-technical staff groups. Example testing vs. contrib-x.
|
||||
- Joe: without some sort of automated mechanism that forces people to communicate it won't happen. Perhaps having the SIGs own code will force discussions at time of PR
|
||||
- If we have a forcing function there requires more planning up front. Example is the rush to a release.
|
||||
- Scrum of scrums? Have the leads get together and hash over that.
|
||||
- Focus on visibility with accountability.
|
||||
- Luke: perhaps have sig leads do offline sync ups? Bring in others as necessary.
|
||||
- Vish: Sig leads may not know what is going on.
|
||||
- Quinton: have identified people in the SIG that owns relationship with specific other SIGs.
|
||||
- Bob: Getting better definition of what the sig lead job is would help.
|
||||
- Make SIG-PM be made up of SIG-leads
|
||||
- Brendan: SIG lead should be a thankless position. Very little power. Should be obligation. Somewhat like an on-call rotation vs. TL.
|
||||
- Quinton: Is there a TL position? Who is driving the overall technical direction of an area. Separate from the lead position.
|
||||
- Brendan: SIGs own directories. Approvers in those directories are TLs.
|
||||
- Bob: current model SIG leads are volunteer thing and so it is optimistic to expect too much. Do we want to have elections.
|
||||
- Brendan: worry about gaming with the openstack model wrt elections.
|
||||
- Rob: in OpenStack -- SIGs were project groups. The usage of SIG to mean project is confusing.
|
||||
- Eric: If people are going to be SIG leads -- too much power for too much responsibility. Should we solve by adding responsibility.
|
||||
- Do sig leads have power now? It is mostly influence?
|
||||
- **¦¦** Code vs. talk.
|
||||
- Bob: You can say "code talks" but getting code in and earning that position can be super frustrating. "Code == influence" just isn't true right now.
|
||||
- Adding code is easy. Reviewing code, curating tests, etc. That is the hard thing.
|
||||
- What are the expectations to put on a SIG. Keep track of issue response times?
|
||||
- Jason: What is the job of SIGs? How do we identify that and make sure it gets done? There isn't that one thing to test against.
|
||||
- Leadership follows from this mission.
|
||||
- Eric: As a governing board do we care how a sig does it as long as it does it well? I think the answer is we don't care. Doubts around template.
|
||||
- Luke: That seems fine -- but we need to share what works and what goes poorly.
|
||||
- Brendan: others said cross sig stuff is hard. Also poor communication across dependencies.
|
||||
- What is success? Depends on the SIG. Lay out a plan and then accomplish it.
|
||||
- SIG have obligations to release and own thing. Example is tests for that thing. Need to define interfaces
|
||||
- Michelle: what are the best processes for governing and monitoring a SIG. What are the best processes?
|
||||
- Aaron: Qs: Do SIG updates and recording help with communication.
|
||||
- Joe: What we discussed through bootstrap is that we should have a starter kit for the SIGs; we don't really have strong opinions on how it actually works in practice though.
|
||||
- Dalton: Clear lines of ownership for SIGs would be appreciated. Would welcome more guidance. SIG on-prem struggles with what they are responsible for today
|
||||
- Challenge for horizontal SIGs include membership (especially technical) and influence.
|
||||
- Brendan: focus on fewer larger SIGs. Not enough people with smaller SIGs. Consolidation may make things more efficient.
|
||||
- Aaron: SIG updates at community seem to help tell what the SIGs are focusing on but it doesn't help on a week to week or release wide process.
|
||||
- Does SIG-PM coordinate a snapshot of what is going on. But it isn't enough communication.
|
||||
- Ihor: Almost meeting have reports from SIGs.
|
||||
- How do we push people to write code in the right direction. What tools do we have to guide things.
|
||||
- Hope from the steering committee is that if SIGs aren't doing something they should be doing there is an escalation. Example is SIG-testing is empowered to stop queue until things change.
|
||||
- Joe: Eng reviews/SIG-architecture
|
||||
- Advise to who and where to get sign off.
|
||||
- Bob: alleviate frustrations that we had
|
||||
|
||||
Lots of discussions on how to drive communication and when things get escalated. Help SIGs coordinate between themselves.
|
||||
|
||||
Up to steering committee to help define what the requirements are on a SIG. Still unsure what that'll look like.
|
||||
|
||||
Jason: rename SIG-lead to SIG-facilitator
|
||||
|
||||
Good Practices
|
||||
|
||||
Kind of like a starter kit for SIGs? Needed and recommended?
|
||||
|
||||
- Notes and videos help
|
||||
- Focusing bi-weekly for PRs vs. design discussion.
|
||||
Loading…
Reference in New Issue