Add session notes - Leadership Summit
Add session notes - Leadership Summit
This commit is contained in:
nyener
parent
c63ad0ebc6
commit
6329c17d31
|
|
@ -0,0 +1,108 @@
|
||||||
|
State of the Kube
|
||||||
|
=================
|
||||||
|
|
||||||
|
Identify the following before beginning your session. Do not move
|
||||||
|
forward until these are decided / assigned:
|
||||||
|
|
||||||
|
- **Session Topic**: STATE OF THE KUBE
|
||||||
|
- **Topic Facilitator(s)**: Tim Hockin
|
||||||
|
- **Note-taker(s) (Collaborating on this doc)**: Jason Singer DuMars,
|
||||||
|
Nilay Yener
|
||||||
|
- **Person responsible for converting to Markdown & uploading to
|
||||||
|
Github:** nyener@
|
||||||
|
|
||||||
|
### Session Notes
|
||||||
|
|
||||||
|
- 789 companies
|
||||||
|
- 15 timezones
|
||||||
|
- 41.3 commits daily
|
||||||
|
- 2505 devs
|
||||||
|
- 100 days between releases
|
||||||
|
- 3549 commits since v1.6.0
|
||||||
|
- 200+ meetups
|
||||||
|
- 8365 Github forks
|
||||||
|
- 4793 open issues on k/k
|
||||||
|
- 26.6% commits from top 10 devs
|
||||||
|
- 23642 stars
|
||||||
|
- 658 open PRs
|
||||||
|
|
||||||
|
Needs SIG label is good on stale issues If it’s old and not relevant,
|
||||||
|
close it Open PRs are a problem - should the be closed and reopened when
|
||||||
|
they are ready to work
|
||||||
|
|
||||||
|
Companies are not necessarily easy to identify by contribution
|
||||||
|
|
||||||
|
Growth : Change of the number of commits release by release
|
||||||
|
|
||||||
|
Do we want more contributors? Brendan Burns: Maybe not
|
||||||
|
|
||||||
|
E Tune: We can’t continue having more and more content
|
||||||
|
|
||||||
|
B Burns: We need to make it easier to contribute code
|
||||||
|
|
||||||
|
Lots of hard problems remain. This place is even beyond what has been
|
||||||
|
done at Google
|
||||||
|
|
||||||
|
Generated code is a huge problem as well
|
||||||
|
|
||||||
|
DOCS API reference is a problem
|
||||||
|
|
||||||
|
People and companies want to contribute/consume but it’s not easy to do,
|
||||||
|
e.g. namespace best practices
|
||||||
|
|
||||||
|
B Burns: there’s not one best practice
|
||||||
|
|
||||||
|
Stability first and features second - needs to be front of mind, SIG
|
||||||
|
silos cannot exist
|
||||||
|
|
||||||
|
etune: Aren’t update scripts to help keep organized part of the contribx
|
||||||
|
problem?
|
||||||
|
|
||||||
|
bburns: there can be organic parts of sub-projects, there’s no reason to
|
||||||
|
html docs in there for example
|
||||||
|
|
||||||
|
jbeda: we over-focus on kubernetes/kubernetes
|
||||||
|
|
||||||
|
thockin: we can break it up, but k/k is still the gravity well
|
||||||
|
|
||||||
|
Getting time and leeway to execute on these things is hard/impossible
|
||||||
|
|
||||||
|
We have to assign responsibility and divvy up the work. No one owns it
|
||||||
|
so nothing gets done
|
||||||
|
|
||||||
|
SIGs have some part but not all of it, no unified view, and do SIGs know
|
||||||
|
what they own
|
||||||
|
|
||||||
|
Conformance is going to be a big thing, especially as more integration
|
||||||
|
happens
|
||||||
|
|
||||||
|
#### Q&A :
|
||||||
|
|
||||||
|
- Q: Are we pivoting from accepting technical debt? Yes. But not a
|
||||||
|
hard pivot. Instability will cause us to fail A: BBurns: We’ve gone
|
||||||
|
past the edge of what is necessary, and now we’re in the area of
|
||||||
|
value add via stability
|
||||||
|
|
||||||
|
- Q: Are we going to decide to pay down our debt? A: Given a choice
|
||||||
|
between feature/fix, we should err on the side of fix , core should
|
||||||
|
be stable, and the bar has gone up fr
|
||||||
|
|
||||||
|
- Q: Are we missing that message? A: We’re talking about it, but not
|
||||||
|
doing it - more on this later
|
||||||
|
|
||||||
|
- Q: Did 1.6 accomplish stability? Do we need to re-brand these? A:
|
||||||
|
Some SIGs did, yes
|
||||||
|
|
||||||
|
- Q: Do we need to formalize tech debt burn down? Show of hands… A:
|
||||||
|
Deferred, but everyone seems interested in stabilizing k/k
|
||||||
|
|
||||||
|
### Conclusions
|
||||||
|
|
||||||
|
#### Key Takeaways / Analysis of Situation
|
||||||
|
|
||||||
|
#### Recommendations & Decisions Moving Forward (High-Level)
|
||||||
|
|
||||||
|
Specific Action Items (& Owners)
|
||||||
|
|
||||||
|
[Link to original
|
||||||
|
doc](https://docs.google.com/document/d/1bWx40ASZ-6eKvCJO26l84qvYdNSAY-vHAKTMRWS7yyE/edit?usp=sharing)
|
||||||
|
|
@ -0,0 +1,81 @@
|
||||||
|
Project Goals & Roadmap
|
||||||
|
=======================
|
||||||
|
|
||||||
|
Identify the following before beginning your session. Do not move
|
||||||
|
forward until these are decided / assigned:
|
||||||
|
|
||||||
|
- **Session Topic**: Project Goals and Roadmap
|
||||||
|
- **Topic Facilitator(s)**: Apart Sinha, Google & Ihop Dvoretskyi,
|
||||||
|
Mirantis
|
||||||
|
- **Note-taker(s) (Collaborating on this doc)**: Jason Singer DuMars,
|
||||||
|
Nilay Yener
|
||||||
|
- **Person responsible for converting to Markdown & uploading to
|
||||||
|
Github:** nyener@
|
||||||
|
|
||||||
|
### Session Notes
|
||||||
|
|
||||||
|
(primarily discussion, for the presentation see:
|
||||||
|
[Link](https://docs.google.com/presentation/d/1XXHk-oy-8eeqGMGRHQwOolOV4hFHlLu-KDpoXuU-C74/edit?usp=drivesdk)
|
||||||
|
)
|
||||||
|
|
||||||
|
BGrant: Need help formalizing the proposal process, it’s not documented,
|
||||||
|
need to automate assignment of the proposals, reach out to Brian Grant -
|
||||||
|
|
||||||
|
- Q: Don’t we want to stop taking features? A: We’ll take the idea,
|
||||||
|
but not necessarily implement
|
||||||
|
|
||||||
|
Anecdote: IBM has struggled with how to contribute Lots of cross-SIG
|
||||||
|
implementations, needs improvement Containerization growth 3% to 15% in
|
||||||
|
a year Lower number than expected of companies doing orchestration ECS
|
||||||
|
is at the top
|
||||||
|
|
||||||
|
- Q: Does Docker mean the docker runtime? A: Yes. Not swarm or orch
|
||||||
|
tools, data is very consistent across surveys - means we need to be
|
||||||
|
a strong community and understand the roadmap implications of the
|
||||||
|
users. Last docker survey said people use Docker for development
|
||||||
|
|
||||||
|
Aparna: We’re aware of the developer experience, but it needs more
|
||||||
|
attention
|
||||||
|
|
||||||
|
Node has a huge surface area, and we saw in Borg as well. Every feature
|
||||||
|
touches node/API Machinery
|
||||||
|
|
||||||
|
M Rubin: Perception piece that it’s easy to tie something to node, so it’s an easy place to throw things
|
||||||
|
|
||||||
|
BGrant:Need to take that into account when triaging
|
||||||
|
|
||||||
|
BGrant: check out Istio
|
||||||
|
|
||||||
|
MRubin: Need to look at HPC more
|
||||||
|
|
||||||
|
Bburns: More conflict re: numa vs.
|
||||||
|
stable kubernetes
|
||||||
|
|
||||||
|
Etune: The list was not authoritative
|
||||||
|
|
||||||
|
Bburns: Are we after people with “deep pockets” or are we after the community?
|
||||||
|
|
||||||
|
Jbeda:
|
||||||
|
work on decoupling over prioritizing new features in the wrong direction
|
||||||
|
|
||||||
|
R Hirschfeld: the initial build experience is very important to overall
|
||||||
|
community health
|
||||||
|
|
||||||
|
M Rubin: need to make deprio clear, and why Need to
|
||||||
|
make it clear that we’re working on first getting things out of k/k SIGs
|
||||||
|
have the ability to set the roadmap
|
||||||
|
|
||||||
|
BGrant: lots of critical features
|
||||||
|
that big users need i.e. RBAC, in beta over introducing new APIs, some
|
||||||
|
users will not use non-GA features
|
||||||
|
|
||||||
|
### Conclusions
|
||||||
|
|
||||||
|
#### Key Takeaways / Analysis of Situation
|
||||||
|
|
||||||
|
#### Recommendations & Decisions Moving Forward (High-Level)
|
||||||
|
|
||||||
|
Specific Action Items (& Owners)
|
||||||
|
|
||||||
|
[Link to original
|
||||||
|
doc](https://docs.google.com/document/d/1tIGA2V04C7iAqvMvUa_udy2pPbbWEr6qqlC1piMazjg/edit?usp=sharing)
|
||||||
|
|
@ -0,0 +1,98 @@
|
||||||
|
Updates : Governance & CNCF
|
||||||
|
===========================
|
||||||
|
|
||||||
|
Identify the following before beginning your session. Do not move
|
||||||
|
forward until these are decided / assigned:
|
||||||
|
|
||||||
|
- **Session Topic**: Updates : Governance & CNCF
|
||||||
|
- **Topic Facilitator(s)**: Brian Grant, Google & Brandon Philips,
|
||||||
|
CoreOS
|
||||||
|
- **Note-taker(s) (Collaborating on this doc)**: Jason Singer DuMars,
|
||||||
|
Nilay Yener
|
||||||
|
- **Person responsible for converting to Markdown & uploading to
|
||||||
|
Github:** nyener@
|
||||||
|
|
||||||
|
### Session Notes
|
||||||
|
|
||||||
|
[Link](https://docs.google.com/presentation/d/1pc-nayPpUZQlS10VPKqc-fb0Y3FXeSLeGAJ81g8NsCg/edit#slide=id.p)
|
||||||
|
|
||||||
|
BGrant: Please do not rathole on minutiae, but please comment on the
|
||||||
|
governance documents, we need to understand that this formalizes the
|
||||||
|
escalation path B Philips: Steering committee is focused on watching the
|
||||||
|
details
|
||||||
|
|
||||||
|
Q: Vertical is vertical in the diagram? A: Bgrant: we need to understand
|
||||||
|
how cross-cutting decisions are made and organized
|
||||||
|
|
||||||
|
Q: Aaron C: Escalation should be clearly defined A: BGrant: We want each
|
||||||
|
SIG to have a formal charter for responsibility and authority + scope
|
||||||
|
|
||||||
|
Q: Aparna: Definition of what a SIG is? A: Def of what a SIG can cover
|
||||||
|
and what it is, steering committee oversees new SIGs, need to resolve
|
||||||
|
overlap BGrant: Every identifiable part of the project needs a SIG owner
|
||||||
|
|
||||||
|
Q: Criteria for level of activity? A: Yes
|
||||||
|
|
||||||
|
Q: ETune: is the steering committee deciding what a Kubernetes component
|
||||||
|
is A: yes, but not the bootstrap
|
||||||
|
|
||||||
|
Q: What is the responsibilities of SIG to communicate with other SIGs?
|
||||||
|
A: This is a very large item of discussion and out of scope
|
||||||
|
|
||||||
|
Q: R Hirschfeld: How do we handle cross-cutting concerns? i.e.
|
||||||
|
Operations / tie-breaking authority in the steering committee? A:
|
||||||
|
Working groups, SIGs etc can do it, but we need to figure that out /
|
||||||
|
yes, e.g. the supreme court Please read the docs Q: Examples of working
|
||||||
|
groups? Would snapshots be one? A: jobs, internationalization ETune:
|
||||||
|
it’s a mailing list + sharing the activities
|
||||||
|
|
||||||
|
Bgrant: the eligibility for voting is wrong, we know it, and part of
|
||||||
|
this is increasing inclusivity Comments until 6/15, in place by 8/1 \~
|
||||||
|
need to build tools and mechanisms for voting, need help with this
|
||||||
|
|
||||||
|
Need help with this process, this is a big hurdle for CNCF graduation
|
||||||
|
BGrant is on the CNCF technical oversight committee, meetings Tuesdays
|
||||||
|
8am PST
|
||||||
|
|
||||||
|
Steering Committee Nominations - get notified : https://goo.gl/bQBQMu
|
||||||
|
|
||||||
|
Q: Aparna: CNCF has been offering training, governing board meeting
|
||||||
|
wanted to mention “CNCF has no ambition to interfere with the community,
|
||||||
|
CNCF is willing to devote as much as possible” A:
|
||||||
|
|
||||||
|
Q: Same guidelines as the Linux foundation? A: 2 Kubernetes seats, one
|
||||||
|
the first year
|
||||||
|
|
||||||
|
Q: Aaron C: CNCF doesn’t define the how but what? A: There are some
|
||||||
|
bars, but not that many requirements. Can be discovered on the site and
|
||||||
|
in the charter. V 1.0 of the graduation criteria is out. CoC needs to be
|
||||||
|
re-written.
|
||||||
|
|
||||||
|
Election by 8/13
|
||||||
|
|
||||||
|
Q: Aaron C: How do we formalize for 1.8? A: Bootstrap committee and SIGs
|
||||||
|
until the full committee is formed, Not a clear definition of feature
|
||||||
|
size, and that needs to evolve, need people to chip in Lazy consensus
|
||||||
|
worked for 1.6 decision making, so we should continue that for now
|
||||||
|
Decide here that 1.8 is stabilization, finishing things, need to get
|
||||||
|
everything GA this year
|
||||||
|
|
||||||
|
Q: Do we skip features lined up for 1.8 and move to 1.9? A: The
|
||||||
|
stabilization work will help this
|
||||||
|
|
||||||
|
Q: Where do we handle this today? Steering committee needs to intervene
|
||||||
|
when necessary Resource gaps need to be addressed Aaron C: First thing a
|
||||||
|
SIG needs to do is formalize what a SIG owns Need to create a charter
|
||||||
|
template ASAP then give SIGs time to come up with charter All project
|
||||||
|
pieces need to be categorized as owned by some SIG
|
||||||
|
|
||||||
|
### Conclusions
|
||||||
|
|
||||||
|
#### Key Takeaways / Analysis of Situation
|
||||||
|
|
||||||
|
#### Recommendations & Decisions Moving Forward (High-Level)
|
||||||
|
|
||||||
|
Specific Action Items (& Owners)
|
||||||
|
|
||||||
|
[Link to original
|
||||||
|
doc](https://docs.google.com/document/d/1Ch-aH_dyuL7pXv5ic-2Rb1j5w4us2FCj3U0cgpQTnOw/edit)
|
||||||
|
|
@ -0,0 +1,193 @@
|
||||||
|
Architectural Roadmap
|
||||||
|
=====================
|
||||||
|
|
||||||
|
Identify the following before beginning your session. Do not move
|
||||||
|
forward until these are decided / assigned:
|
||||||
|
|
||||||
|
- **Session Topic**: Architectural Roadmap
|
||||||
|
- **Topic Facilitator(s)**: Brian Grant
|
||||||
|
- **Note-taker(s) (Collaborating on this doc)**: Jason Singer DuMars,
|
||||||
|
Nilay Yener
|
||||||
|
- **Person responsible for converting to Markdown & uploading to
|
||||||
|
Github:** nyener@
|
||||||
|
|
||||||
|
### Session Notes
|
||||||
|
|
||||||
|
[Link](https://docs.google.com/presentation/d/1oPZ4rznkBe86O4rPwD2CWgqgMuaSXguIBHIE7Y0TKVc/edit)
|
||||||
|
|
||||||
|
Not using “core” because it is overloaded - substituting “nucleus”
|
||||||
|
instead \~ absolute necessities for Kubernetes to function
|
||||||
|
|
||||||
|
Q: Aaron C: What is an add-on? A: Concept is any Kubernetes resource
|
||||||
|
managed by the cluster for its own internal consistency/function - e.g.
|
||||||
|
extensible cluster functionality / pulling context
|
||||||
|
|
||||||
|
Q: Are CNI also add-ons? A: Yes.
|
||||||
|
|
||||||
|
Q: How do we differentiate between addons and required addons? A: Part
|
||||||
|
of conformance, if they are managed as part of the cluster, by the
|
||||||
|
cluster manager, they are an addon \~ like a driver in the kernel
|
||||||
|
|
||||||
|
Q: Helm Charts tied to lifecycle of the cluster? A: There’s an issue for
|
||||||
|
addons v2 via Justin Santa Barbara, but the lifecycle is different than
|
||||||
|
for Helm - it’s possible to use charts, but would prefer sources
|
||||||
|
accessed directly for bootstrapping
|
||||||
|
|
||||||
|
Q: How do addons get scheduled? Daemon sets only? A: bash script,
|
||||||
|
one-shot scheduler, in Google it’s called “babysitter” and predates
|
||||||
|
Borg, inspired kubelet “run once” mode, addon manager manages the
|
||||||
|
replicaset object
|
||||||
|
|
||||||
|
Q: Are these strict layers? The concept of layers introduces hierarchy
|
||||||
|
and precedence (governance does not have an implicit reliance on
|
||||||
|
application layer) A: Trying to avoid 9 layers, so we need flexibility
|
||||||
|
in the release process, more modular the better
|
||||||
|
|
||||||
|
Q: Eric Tune: Nucleus : abstract my cloud, Application: Run my workload,
|
||||||
|
Governance: Enterprise I need to do stuff A: Yes
|
||||||
|
|
||||||
|
Comment: Let’s make sure we keep this as simple as possible. BG: We want
|
||||||
|
to ensure that the user community is not significantly impacted, nor
|
||||||
|
cluster operators, one change needed will be breaking up the monolithic
|
||||||
|
V1 API group, pods in V1 group, pods in other API group, want to evolve
|
||||||
|
them more easily.
|
||||||
|
|
||||||
|
Q: Addons are at the lowest level, but we might want higher level addons
|
||||||
|
A: Bootstrapping needs attention, similar to other self-hosting issues,
|
||||||
|
some people may not run the aggregated API server
|
||||||
|
|
||||||
|
Q: Three implications: code organization / nucleus and others would be
|
||||||
|
in one repo versus another. Where is the line? 2. SIG alignment 3.
|
||||||
|
roadmap / where do we invest more? A: 1. Code org is another discussion,
|
||||||
|
but there’s a desire for more modularity. SIGs with their own codebases.
|
||||||
|
2. 3. e.g. Priority for admission controller was increased for 1.7, want
|
||||||
|
to make API aggregation important
|
||||||
|
|
||||||
|
Q: What are the lifecycles around each layer? Would they release
|
||||||
|
separately? A: There’s the release cadence, introduction of new
|
||||||
|
features, and the evolution of the APIs -- may adopt git flow processes
|
||||||
|
|
||||||
|
Q: Adding extension points is the only thing that should permit more
|
||||||
|
technical debt A: Agreed, but may also apply to cloud providers
|
||||||
|
|
||||||
|
C: Need to be able to say no to things that are obsoleted by the list
|
||||||
|
|
||||||
|
C: Cloud provider extension work is being done by one person - this is
|
||||||
|
not a good thing
|
||||||
|
|
||||||
|
### Conclusions
|
||||||
|
|
||||||
|
#### Key Takeaways / Analysis of Situation
|
||||||
|
|
||||||
|
Are there questions/concerns?
|
||||||
|
|
||||||
|
We need to get feedback on the docs and diagrams.
|
||||||
|
|
||||||
|
When these are happening, we expect support from all the SIGs, and how
|
||||||
|
to work this into backlogs.
|
||||||
|
|
||||||
|
#### Recommendations & Decisions Moving Forward (High-Level)
|
||||||
|
|
||||||
|
Specific Action Items (& Owners)
|
||||||
|
|
||||||
|
Architectural Roadmap
|
||||||
|
=====================
|
||||||
|
|
||||||
|
Identify the following before beginning your session. Do not move
|
||||||
|
forward until these are decided / assigned:
|
||||||
|
|
||||||
|
- **Session Topic**: Architectural Roadmap
|
||||||
|
- **Topic Facilitator(s)**: Brian Grant
|
||||||
|
- **Note-taker(s) (Collaborating on this doc)**: Jason Singer DuMars,
|
||||||
|
Nilay Yener
|
||||||
|
- **Person responsible for converting to Markdown & uploading to
|
||||||
|
Github:** nyener@
|
||||||
|
|
||||||
|
### Session Notes
|
||||||
|
|
||||||
|
[Link](https://docs.google.com/presentation/d/1oPZ4rznkBe86O4rPwD2CWgqgMuaSXguIBHIE7Y0TKVc/edit)
|
||||||
|
|
||||||
|
Not using “core” because it is overloaded - substituting “nucleus”
|
||||||
|
instead \~ absolute necessities for Kubernetes to function
|
||||||
|
|
||||||
|
Q: Aaron C: What is an add-on? A: Concept is any Kubernetes resource
|
||||||
|
managed by the cluster for its own internal consistency/function - e.g.
|
||||||
|
extensible cluster functionality / pulling context
|
||||||
|
|
||||||
|
Q: Are CNI also add-ons? A: Yes.
|
||||||
|
|
||||||
|
Q: How do we differentiate between addons and required addons? A: Part
|
||||||
|
of conformance, if they are managed as part of the cluster, by the
|
||||||
|
cluster manager, they are an addon \~ like a driver in the kernel
|
||||||
|
|
||||||
|
Q: Helm Charts tied to lifecycle of the cluster? A: There’s an issue for
|
||||||
|
addons v2 via Justin Santa Barbara, but the lifecycle is different than
|
||||||
|
for Helm - it’s possible to use charts, but would prefer sources
|
||||||
|
accessed directly for bootstrapping
|
||||||
|
|
||||||
|
Q: How do addons get scheduled? Daemon sets only? A: bash script,
|
||||||
|
one-shot scheduler, in Google it’s called “babysitter” and predates
|
||||||
|
Borg, inspired kubelet “run once” mode, addon manager manages the
|
||||||
|
replicaset object
|
||||||
|
|
||||||
|
Q: Are these strict layers? The concept of layers introduces hierarchy
|
||||||
|
and precedence (governance does not have an implicit reliance on
|
||||||
|
application layer) A: Trying to avoid 9 layers, so we need flexibility
|
||||||
|
in the release process, more modular the better
|
||||||
|
|
||||||
|
Q: Eric Tune: Nucleus : abstract my cloud, Application: Run my workload,
|
||||||
|
Governance: Enterprise I need to do stuff A: Yes
|
||||||
|
|
||||||
|
Comment: Let’s make sure we keep this as simple as possible. BG: We want
|
||||||
|
to ensure that the user community is not significantly impacted, nor
|
||||||
|
cluster operators, one change needed will be breaking up the monolithic
|
||||||
|
V1 API group, pods in V1 group, pods in other API group, want to evolve
|
||||||
|
them more easily.
|
||||||
|
|
||||||
|
Q: Addons are at the lowest level, but we might want higher level addons
|
||||||
|
A: Bootstrapping needs attention, similar to other self-hosting issues,
|
||||||
|
some people may not run the aggregated API server
|
||||||
|
|
||||||
|
Q: Three implications: code organization / nucleus and others would be
|
||||||
|
in one repo versus another. Where is the line? 2. SIG alignment 3.
|
||||||
|
roadmap / where do we invest more? A: 1. Code org is another discussion,
|
||||||
|
but there’s a desire for more modularity. SIGs with their own codebases.
|
||||||
|
2. 3. e.g. Priority for admission controller was increased for 1.7, want
|
||||||
|
to make API aggregation important
|
||||||
|
|
||||||
|
Q: What are the lifecycles around each layer? Would they release
|
||||||
|
separately? A: There’s the release cadence, introduction of new
|
||||||
|
features, and the evolution of the APIs -- may adopt git flow processes
|
||||||
|
|
||||||
|
Q: Adding extension points is the only thing that should permit more
|
||||||
|
technical debt A: Agreed, but may also apply to cloud providers
|
||||||
|
|
||||||
|
C: Need to be able to say no to things that are obsoleted by the list
|
||||||
|
|
||||||
|
C: Cloud provider extension work is being done by one person - this is
|
||||||
|
not a good thing
|
||||||
|
|
||||||
|
### Conclusions
|
||||||
|
|
||||||
|
#### Key Takeaways / Analysis of Situation
|
||||||
|
|
||||||
|
Are there questions/concerns?
|
||||||
|
|
||||||
|
We need to get feedback on the docs and diagrams.
|
||||||
|
|
||||||
|
When these are happening, we expect support from all the SIGs, and how
|
||||||
|
to work this into backlogs.
|
||||||
|
|
||||||
|
#### Recommendations & Decisions Moving Forward (High-Level)
|
||||||
|
|
||||||
|
Specific Action Items (& Owners)
|
||||||
|
|
||||||
|
Action Item |Owner(s)
|
||||||
|
------------|------------
|
||||||
|
SIG Architecture Creation (ratified per unanimous vote, 6/3/2017) | Jaice Singer DuMars, Brian Grant Lead
|
||||||
|
Refine and approve Brian’s architecture | SIG Architecture
|
||||||
|
|
||||||
|
[Link to original
|
||||||
|
doc](https://docs.google.com/document/d/1nD3Y1-Tbb-hhSNg6TGPRLxKSzIuRSnVfdHginl0brrc/edit#)
|
||||||
|
[Link to original
|
||||||
|
doc](https://docs.google.com/document/d/1nD3Y1-Tbb-hhSNg6TGPRLxKSzIuRSnVfdHginl0brrc/edit#)
|
||||||
Loading…
Reference in New Issue