2017-events: add governance notes from 2017 leadership summit

1 files changed, 107 insertions, 0 deletions

diff --git a/community/2017-events/05-leadership-summit/session-notes/1345-1430_SIGGOVERNANCE.md b/community/2017-events/05-leadership-summit/session-notes/1345-1430_SIGGOVERNANCE.md
new file mode 100755
index 00000000..397c7c6a
--- /dev/null
+++ b/community/2017-events/05-leadership-summit/session-notes/1345-1430_SIGGOVERNANCE.md
@@ -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.