►
Description
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18).
SIG Contributor Experience Deep Dive – Paris Pittman, Google & Tim Pepper, VMware (Intermediate Skill Level)
In this 30 minute session, we will deep dive into one of Contributor Experience current projects - a new developers guide.
About Tim
Tim is a software engineer with over 20 years open source development experience. He is currently a member of VMware's Open Source Technology Center acting as an open source developer advocate and contributing to upstream projects such as kubernetes. In his past he's worked on the linux kernel, device drivers, distributions, software update, Android, OpenStack, and an open source golang based orchestrator for multi-tenant containers and VMs that wasn't kubernetes.
About Paris
Paris is a Developer Relations Program Manager on the Google Cloud Open Source Strategy team focusing on Kubernetes Community. She has 13 years of professional experience in attracting and retaining engineering talent for organizations and open source projects. She has also been organizing communities in one form or another for over 20 years, and at one point ran enough meetups to subsist solely on the free pizza leftovers.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
My
name
is
Paris
I
work
at
Google,
I
am
a
co-chair
of
contributor
experience.
I
see
some
awesome
members
of
our
sig.
Here
already
we
are
doing
a
deep
dive.
The
intro
was
yesterday,
so
if
you
miss
the
intro
feel
free
to
watch,
the
recording
I
will
also
upload
the
slides
to
sched
I
swear
I
will
I
swear.
A
I
will
today
is
interesting,
because
this
is
the
first
time
we're
doing
a
deep
dive
for
this
sake
and
we're
doing
it
on
something
that
we
think
is
maybe
P
point
five
almost
p
zero,
but
all
of
us
are
also
extremely
busy
with
other
PZero
things,
so
we
wanted
to
really
get
a
lot
of
your
advice.
Opinions
support
possibly
ownership
of
this
topic,
which
is
developer
guide,
but
first
things.
A
First
I
wanted
to
introduce
some
people
who
are
key
players
in
this
and
also
let
you
know
that
we
want
this
to
be
as
interactive
as
possible.
This
is
not
a
regular
talk.
This
is
not
us
talking
at
you,
so
please
feel
free
to
give
us
all
of
your
opinions
at
once
or
once
at
a
time.
Maybe
so
first
things.
First.
This
is
Tim
pepper.
He
is
going
to
be.
A
The
car
driver
today
for
us,
for
the
most
part
and
Tim
will
introduce
himself
in
a
second,
but
he
has
been
an
amazing
new
contributor
who
has
stepped
in
over
the
last
six
months
and
really
helped
us
in
ways
that
has
expanded
the
project.
So
thank
you,
Tim
also
Aaron,
Craig
gun
burgers
here
Aaron,
if
you
want
to
give
a
wave
Aaron,
is
the
a
co-chair
of
sig
testing.
A
Jorge
has
been
an
integral
part
of
the
community
management
side
of
the
house,
and
next
to
him
is
Gwen
Gwen.
If
you
want
to
wave
both
of
these
awesome
folks
have
led
us
to
what
we
have
now,
which
is
the
new
contributor
guide
of
which
the
developer
guide
will
be
a
part
of
so,
as
you
can
see
now
that
we're
rolling
out
the
contributor
guide
piece.
The
next
piece
now
is
the
developer
guide.
So
that's
why
I
say
this
is
getting
to
be
of
critical
nature
problem
statement,
so
you
want
to
hit.
B
B
A
So
what
we're
talking
about,
if
you
have
laptops-
and
things
like
that
feel
free
to
follow
along
too
in
the
community
repo
of
the
kubernetes
org
on
github,
we
have
a
couple
different
areas.
One
is
called
contributors
in
that
you'll
see
an
actual
guide
section.
That's
the
contributor
guide
to
what
I
was
alluding
to
with
Gwyn
and
George's
work
as
well
as
Tim,
and
so
many
other
people
have
made
some
other
contributions
so
that
all
of
that
material
that
you
see
in
there
and
then
there's
a
develop
section.
A
The
develop
section
is
actually
this
developer
guide.
The
problem
has
been
largely
that,
as
we've
grown
as
an
explosive
community,
we've
allowed
users
and
contributors
to
just
take
a
stab
at
adding
docs
to
this,
and,
as
you
can
see,
by
the
develop
section,
most
of
these
Doc's
haven't
been
updated
in
four
plus
months.
This
is
one
of
the
areas
of
the
project
where
people
will
just
throw
out
a
doc
say
like
cherry-pick
process
or
API
conventions
or
what-have-you,
where
they
thought
that
they
ran
into
trouble.
So,
like
hey,
let's
help
out
the
community.
A
So
we
have
several
several
several
people
who
are
authors
in
this
and
unfortunately,
there's
been
no
real
and
schedule.
So
now
we've
got
a
deal
where
we've
got
a
large
large
large
section
of
documents,
but
are
they
out?
Are
they
outdated?
Should
this
even
belong
in
a
developer
guide?
What
is
confused
people?
How
can
we
make
sense
of
this
information
that
we
have
in
here
I
mean
really
like.
Like
one
of
the
bullets,
it's
really
just
been
a
tragedy
of
the
Commons.
B
B
It
was
like
from
1996
or
something
when
I
was
getting
involved,
and
this
is
all
I
had
to
try
to
figure
things
out
and
I'm
thinking.
I,
don't
want
kubernetes
to
be
that
way.
We
got
to
do
something
more
than
that
and
the
kernel
community
went
through
the
same
thing.
This
is
my
bookshelf
from
the
span
of
like
15
years,
the
books
that
I
built
up
in
the
iterations
of
the
books.
B
It's
literally
this
today
right
for
Nettie's
or
kubernetes
internals
anyway,
like
you
might
say,
well,
there's
kubernetes
up
and
running,
but
it's
focused
more
on
users
and
operators
as
a
developer.
I
don't
have
that
like
understanding
the
kubernetes
internals
book
that
tome
and
I
want
that
like
as
a
newcomer,
this
is
the
table
of
contents
from
understanding
the
Linux
kernel.
B
You've
got
all
the
major
subsystems
you
can
just
pop
it
open
and
see,
and
if
I'm
a
newcomer
I've
been
tasked,
it
is
my
job
or
I'm
a
hobbyist
I'm
interested
in
something
like
there's
a
page
as
I
turn
to
and
I
go.
Do
that
and
I
know
that
that's
gonna
sound
daunting
like
oh,
let's
write
a
book
like
who
wants
to
write
this
book
or
who
thinks
that's
even
possible.
B
Well
then,
let's
talk,
but
at
the
same
time
that's
gonna
take
a
little
while
yeah,
so
Phil
Phil,
what
Rock
just
just
volunteered
but
that's
gonna,
take
a
while
so
in
the
big
picture.
I
think
we're
missing
missing
some
architectural
stuff,
like
just
that
core
component
list,
like
if
I'm
new
and
I've
heard
about
CRTs
like
how
do
I
go
understand.
How
do
I
write
a
CRT
or
where's
the
code
associated
with
CR
DS
or
my
boss
told
me
that
our
CRT
is
broken
like
oh.
What
do
I
do
where
do
I
go?
B
Where
is
this
stuff
so,
like
kind
of
a
way
to
start
out
at
the
big
picture,
oriented
as
a
newcomer
and
then
tunnel
down
into
those
per
component
details
and
compared
to
writing
a
book?
I
think
I
believe
that
that
stuff
isn't
too
hard
to
draft
at
a
high
level.
We
just
need
volunteers,
curating,
it's
gonna
take
time
and
effort,
but
maybe
that
becomes
a
part
of
contrib
X.
Every
year
we
do
a
curation
and
we
look
at
the
get
disk
compared
to
last
time.
B
C
Ok
so
like,
as
as
an
analogy
here,
the
rust
project
has
started
a
get
book
on
the
compiler,
internals
and
so
like.
If
you
look
at
the
compiler,
internals
of
the
rust
like
rust,
is
a
fairly
complicated
language
like
compile
write,
so
it
like
I
think
that's
example
of
it's
definitely
possible
to
have
this
kind
of
structured
like
in
you
know.
The
Linux
kernel
is
obviously
complicated
too
so,
like
you
know,
we
could
I
think
we
could
totally
achieve
that
model
where
we
have
a
good
book
like
that.
So.
B
D
B
B
D
Was
actually
gonna
suggest
the
gift
book
idea
because
it
leverages
a
lot
of
what
we
already
do.
I
mean
what
other
community
on
the
planet
versions,
their
community,
Docs
and
event
notifications
through
PRS
and
github.
It's
just
this
one
like
so
I,
actually
think
the
model
where
we're
using
get
to
actually
version
our
developer
guide
through
the
kid
point
because
get
books
is
actually
it's
a
it's
a
fairly
mature
tool.
I,
don't
know
any
if
anybody's
used
it.
D
D
C
Can
you
like
drop
like
a
couple
paragraphs
into
the
book
into
the
controller
chapter
and
like
it's
obvious?
You
just
drop
it
right
here
in
this
part
where
it's
like.
Replace
constructing
your
bespoke
thing
with.
Please
use
shared
informers
like
find
more
information
here,
and
then
people
can
go
and
elaborate
on
that,
but
like
if
we
make
it
easy
for
people.
The
author
original
authors,
just
like
drop
stuff
in
there
quickly
I
think.
B
That
would
go
a
long
way,
I
think
that's
kind
of
the
gray
like
if
we
get
there,
that's
awesome,
but
even
in
the
meantime
right
now
we
already
have
all
sorts
of
like
there's
a
halo
of
blog
posting.
Somebody
eventually
beats
their
head
against
it
enough
and
writes
the
blog
post,
and
if
we
discover
that,
then
we
can
be
like
hey.
Can
you
can
we
get
that
into
the
book.
F
Okay,
I'll
be
that
I
I
just
couldn't
help,
but
look
at
that
develop
directory
as
like
a
wiki,
I'm
curious.
If
anybody
in
this
room
has
any
experience
successfully,
keeping
a
wiki
organized
and
up
to
date,
because
that
okay
cuz
I
want
to
hear
like
what
you
did
to
motivate
people
to
accomplish
that,
because,
because
ultimately,
I
think,
like
people
will
piecemeal
run
into
problems
and
then
just
dump
it
in
that
developer
key.
So
there's
no
real
organization
there.
So
nobody
really
knows
that
there
even
is
anything
to
update.
So
that's
that's
one
piece.
B
F
B
To
answer
that,
since
you
threw
it
out
there,
there's
I
really
think
this
is
a
cultural
thing
in
a
team,
so
I
I
just
changed
companies
I
worked
for
VMware
I'd
made
that
switch
relatively
recently
and
when
I
came
in
I
started.
Asking
questions
I
think
so
one
of
the
questions
and
became
was
like
so
where's.
The
wiki
cuz.
This
stuff
was
just
on
the
wiki
right
and
there
wasn't
a
wiki,
and
within
a
week
my
teammates
were
calling
me.
F
Like
I
agree
that
if
it's
known
that
that's
the
way
that
we
do
things
I
would
help,
we
don't
just
have
a
broken
window.
There
like
the
whole
building,
has
practically
been
demolished,
so
there
is
the
other.
The
other
like
concern
I
have
is,
when
you
talk
about
doing
a
rican
annual
refresh
of
this,
and-
and
I
heard
concerns
about
CRTs
and
shared
and
formers,
remember
this
project
moves
on
a
quarterly
return.
B
F
I
wanted
to
tie
back
to
one
other
thing,
which
is
I
think
like
keeping
the
docs
as
close
to
the
code
as
possible,
makes
it
more
likely
that
they're
not
going
to
fall
out
of
date,
and
one
thing
I'd
tell
me
if
I'm
wrong,
I
believe
this
project
is
atrocious
at
using
actual
doc
doc
o
files
inside
of
each
of
the
packages
to
describe
what
is
this
package?
Why
is
it
here?
What
does
it
do?
How
might
you
use
it?
F
I
think
this
is
a
good
example
of
a
tool
dedicated
to
helping
people
build
kubernetes,
constructs
and
resources
and
the
documentation
for
how
and
why
you
might
want
to
do.
That
is
also
here
so
I
like
the
idea
of
sort
of
the
the
narrative
lexicon
of
idioms
being
here,
but
I
still
think
that
the
actual
like
what
is
this
component,
and
why
is
it
here,
stuff
needs
to
live
directly
next
to
the
code,
yeah.
D
B
G
So
yeah,
I
just
wondering
about
your
concern
about
the
wiki,
so
like
one
big
difference,
I've
noticed
between
using
a
wiki
for
documentation
and
using
something
like
you
hub
is
the
fact
that
there's
like
an
owner
and
review
process
like
wiki
is
really
cool.
Cuz,
like
anyone
can
edit
it
and
I,
can
just
drop
stuff
in
there.
So
then
it
does
kind
of
end
up
being
a
big
sort
of
like
mess
and
like
conglomeration
of
stuff
and
I.
G
Think
if
there's
an
owner
and
there's
a
process,
we're
like
the
owners
have
to
review
it,
then
it
kind
of
stops
that
from
happening.
The
other
thing
is
I'm
just
curious
about
the
process
like
when
people
add
new
features.
Is
there
any
kind
of
requirement
that
they
have
to
add
documentation
because
I
think
that
would
make
a
big
difference
as
well?
It's
like
your
bundle
contribution
includes,
like
your
tests,
your
thing
you're
doing
and
in
the
docs
as
well
I.
Think.
B
F
Okay,
so
so,
first
to
go
to
the
new
features
thing
right,
the
if
you
propose
a
feature
you
need
to
have
a
design
proposal
for
what
is
this?
Why
am
I
doing
it
this
way?
What's
the
prior
art
I'm
considered?
What
is
this
explicitly
not
supposed
to
solve?
What
we
historically
is
a
project
I've
been
poor
at
doing
is
turning
those
design
proposals
of
great
ideas
into
something
that
follows
the
life
cycle
of
the
implementation
of
that
feature.
F
So
now
we
have
this
thing
called
CAF
which
I
forget
if
it's
required
or
not,
but
it's
supposed
to
try
and
give
these
things
an
explicit
life
cycle,
and
so
we
could
use
caps
to
mandate
that,
like
documentation
of
the
architecture
and
design
and
motivations
of
the
features,
should
follow
it
and
should
be
in
an
easily
discoverable
place.
So
if
you
look
at
the
code
base
and
see
that
oh,
this
is
the
the
Frog
Nasser
and
it
was
implemented
via
cap
0:07,
you
can
go.
F
Look
at
Cap,
zero,
zero,
seven
to
find
the
design,
Docs
and
all
of
that
stuff.
As
far
as
the
devel
guide
having
an
owner,
it
is
still
effectively
a
wiki
because
there
doesn't
seem
to
be
a
clear,
explicit
owner
and
I.
Think
part
of
what
I
wanted
to
see
out
of
this
session
is
much
like
the
contributors.
Guy
is
a
sub
project
of
contributor
experience.
It
has
an
owner's
file
and
the
owners
are
right
over
here
and
I
showed
them
on.
F
But
that's
the
question
who
is
sufficiently
motivated,
usually
the
people
who
get
really
cranky
about
it
being
out-of-date
or
cranky
about
it
being
out
of
date
for
their
problem
or
they'll,
be
willing
to
point
out
like
all
of
the
areas
that
they
couldn't
find
their
answers,
but
they're
not
willing
to
actually
go
in
and
dig
through
and
say.
Well,
these
were
the
ten
places
I
didn't
find.
My
answer:
here's
the
one
place
I
found
it
so
I'll
go
fix
it
at
the
one
place.
F
I
found
it,
but
I'm
gonna
forget
about
purging
all
the
10
incorrect
places
right.
There
does
need
to
be
some
real
dedicated
effort
to
it.
I
think
this
is
the
right
group
to
own
it
I'm,
just
not
sure
we
have
the
staff
for
it.
That's
all,
but
that's
totally
what
an
owner's
file
is
is
for
just
a
last
thing.
Real
quick
is
this
seems
to
be
a
problem
that
sigdoc
spaces
with
the
documentation
of
their
stuff.
F
That's
more
user
facing
all
the
time
or
what
they
do
is
they
have
to
kind
of
groups
of
reviewers,
so
they
use
the
doc
the
doc
writers
to
make
sure.
Is
it
like
a
well-written
thing,
yeah?
Is
it
in
English?
You
know
it
does.
Is
it
grammatically
correct?
Does
it
make
sense,
but
they
need
a
technical
review
or
to
go
through
and
say?
Yes,
this
is
catching
all
the
right
details
and
mentioning
all
the
correct
corner
cases
and
is
technically
correct.
A
B
One
of
the
one
of
the
things
so
that
that
link
up
at
the
top
is
the
the
umbrella
issue
on
github
for
like
doing
something
about
this
and
one
of
the
things
that
we're
hoping
to
leave
here
with
and
I
the
raising
of
the
hands
like
it
was
in
response
to
the
harder
problem.
If
who
wants
to
write
the
book
but
like
who
wants
to
be
a
part
of
fixing,
this
can.
Can
we
leave
here
today
with
like
a
people
who
are
saying,
like
I'll?
Do
some
part
of
the
solution
so
correct.
B
C
F
B
Kep
is
a
part
of
it
and
it's
a
it's.
A
nice
I
think
because
it's
a
top-level
one,
the
the
sig
leads,
are
going
to
be
approving
that
kept
to
go
through
right
and
if,
if
there's
a
part
of
that
they're
saying
oh
wait,
where's
the
docks
they
get
used
to
saying:
oh
wait,
where's
the
docks
so
like
I
could
argue.
F
That
can
be
documented
to
that
that
book
format
today,
right,
like
I,
do
think
a
book
can
be
written
on
that
some
of
that
stuff,
but
as
we're
the
implementation
of
the
rest
of
kubernetes
that's
moving
and
that
we
all
have
questions
about.
That's
a
significantly
tougher
thing,
I
kind
of
feel
like
Q
builder
or
something
like
it.
F
That's
close
to
the
code
might
might
help
us
address
that
a
little
bit
more,
but
things
like
API
conventions
or
what's
the
best
dev
dev
build
test
cycle
and
stuff,
like
that's
a
pretty
bespoke
thing
for
a
lot
of
developers
like
each
person
kind
of
has
their
own
way
of
doing
that.
That's
the
convenient
like
which
cloud
providers
they
get
for
free
things
like
that
mm-hmm
I,
just
use
gke
for
my
stuff.
F
Are
you
kidding
me
like
so
I,
don't
know,
I
feel
like
they're
kind
of
multiple
problems
here,
I'm
just
trying
to
understand
how
we
could
like
delegate
some
of
this
to
other
six
again.
I.
Think
that's
something
that
works
well
for
sig
Docs
is
they're
like
you
have
to
have
the
docs.
We
have
to
have
this,
but
we
also
cannot
possibly
have
the
expertise
necessary
to
vet.
All
of
this
material.
C
B
C
Talking
about
somewhere
in
the
will
and
and
half
of
its
kind
of
up
to
date,
almost
and
some
of
it
has
thoughts
from
people
that
are
not
clearly
distinguished
from
like
things
that
are
set
in
stone
versus
things
that
you
should
do
and
if
you've
been
on
the
project.
Long
enough,
you
can
kind
of
pick
those
two
apart
and
I
would
not
want
to
be
someone
who
had
not
been
on
the
project
long
enough
to
pick
those
two
apart,
yeah.
B
But
I
think
I
actually
think
it
can
be
an
entry
point
for
somebody
who's
a
little
bit
newer
it
you,
you
may
not
understand
that
you
may
not
be
able
to
pick
between
the
two,
but
it
can
be
like
if
it's
confusing
and
you
can
have
a
bit
of
a
sense
of
the
SIG's
who
should
know
the
answer.
You
can
go
and
say:
hey
I'm,
trying
to
improve
the
the
devil
guide.
H
Oh
hey
so
when
I
was
new,
I
would
have
very
much
appreciated,
really
just
a
shorthand.
This
is
I.
Think
I
feel
like
we're
getting
a
little
bit
sidetracked
in
terms
of
oh,
my
gosh.
What
about
all
these
different
nooks
of
the
code
and
how
are
we
going
to
keep
docs
on
them?
Really
what
I
want?
What
I
want
is
a
newcomer
in
what
I
now
want
to
help
newcomers
on
board?
What
is
currently
still
missing
from
my
become
a
contributor
spiel
is
how
do
I
set
up
my
dev
environment
and
get
started.
H
H
I
J
J
We,
we
didn't
have
any
way
to
teach
people
how
to
like
do
the
very
simple
things
that
are
necessary
in
order
to
build
and
run
cuvee
DM
like
how
do
you?
How
do
you
verify
your
changes
like?
How
do
you
like
feel
out
the
new
developer
experience
and
the
user
experience
for
for
kuba
ATM
binary,
where
you're
making
changes
to
the
code
base
and
the
answers
are
simple,
but
they
were
just
nothing
like
there
were
no,
where
and
so.
J
I
pushed
up
a
repo
into
my
own
github,
like
with
the
vagrant
and
a
readme,
with
like
ten
lines
of
code
in
it,
and
then
I
shared
it
on
the
call
and
a
bunch
of
people
like
even
some
long-term
contributors
were
like
whoa
I
want
to
go.
Look
at
that
like
what
are
you
doing?
I,
don't
even
test
the
stuff.
I
just
I
just
push
it
up
into
the
thing,
and
then
people,
lgt,
em
right.
J
Well,
we
actually
we
merged
it
to
the
to
the
kubernetes
Koopa
ATM
repo,
because
everybody
liked
it
so
because
it
was
just
a
missing
thing
and
yeah.
There
were
like
new.
There
were
new
members
who
were
joining
the
Sega
in
particular,
Matt
Kelly
from
containership
was
like
my
major
alpha
tester
on
that,
but
yeah.
B
B
A
Future
do
the
same
know
in
to
your
specific
question
contributor
experience
is
actually
going
to
run
a
survey
in
June
and
on
the
last
I
think
meeting
that
we
had
notes.
I
started
a
doc,
that's
a
good
questions
Bank.
So
if
anybody
in
here
has
questions
like
that
feel
free
to
add,
and
then
we
can
get
that
kind
of
information
flowing.
K
The
other
thing
is
I,
don't
know
if
this
is
possible,
but
maybe
if
there's
a
way
we
can
understand
what
people
are
searching
for
on
the
docks.
I,
don't
think
you
can
track
the
analytics
from
github
searches
or
anything,
but
especially
if
you
throw
all
these
markdown
files
onto
some
HTML
generator
or
something
you
can
maybe
track
what
the
searches
are.
K
I
know
that
other,
oh
okay,
yeah
I
mean
I
I,
don't
necessarily
want
it,
but
like
and
I'm
not
a
part
of
that,
but
you
guys
you
you
folks
may
want
to
know
what
to
spend
your
time
on,
because
it's
pretty
daunting
just
fixing
all
the
docks.
You
know
and
then
you
can
even
add,
what's
really
pertinent
to
sig
Docs
and
they
can
take
over
or
something
I,
don't
know.
I.
E
Just
want
to
ask
more
about
like
what
the
specific
problem
we're
trying
to
solve
or
who
what
the
target
is,
because
I
can
imagine
some
users
coming
and
they
want
to
just
learn
about,
like
I,
want
to
learn
and
build
kubernetes
right
and
then
some
folks
are
like
I
want
to
build
networking
or
something
like
that,
and
the
direction
of
the
project
is
we're
trying
to
minimize
what's
going
into
the
main
core,
and
so,
if
we're
directing
people
out
to
other
sub
projects
that
aren't
in
the
main
port.
Is
that
still
meeting
our
goals?
F
E
F
To
sort
of
tie
some
of
this
together,
I
do
think
the
like
dev
build
test
cycle
would
be
the
highest
impact.
Giving
people
like
this
is
a
way
that
definitely
works,
but
I.
Just
I,
don't
know
some
people
like
to
use
mini
cube.
Some
people
like
to
use
docker
locally,
some
people
spin
up
a
VM.
Some
people
use
their
own
cloud
that
they
get
for
free.
F
Everybody
seems
to
have
like
different
ways
of
doing
it,
but
I
think
if
a
group
of
people
wanted
to
get
together
and
make
a
concerted
effort
at
putting
together
just
a
clone,
kubernetes
change
a
thing:
how
to
test
to
make
sure
that
thing
works.
Here's
how
you
build
it!
Here's
how
you
test
it
locally.
That
would
go
a
long
way
towards
the
beginning
contributor
that
Gwyn
is
talking
about,
but
I'm
trying
to
understand
what
the
scope
of
the
our
guide
is
as
a
whole.
F
More
to
Phil's
point,
because
I
feel
like
when
this
discussion
first
started
months
back.
There
were
questions
about
things
like
API
conventions,
design
conventions
accepted
implementation
patterns
for
different
things
like
if
you
want
to
try
solving
a
problem
which
sub
project
is
the
best
place
to
try
solving
that
problem
or
like.
What's
the
pattern
you
should
follow.
Those
seem
to
be
sort
of
higher-level,
more
architectural
concerns,
which
sounds
like
there's
demand
for
that
I
don't
know,
but
at
a
bare
minimum
dev
test
build
is
what
I
think
of
when
I
think
of
developer.
B
A
A
wrap
with
time
so
clearly
there
are
opinions
here
with
a
capital
o
and
we
want
those
opinions
to
go
on
that
issue
link
seriously.
This
is
the
only
way
we're
gonna
get
started.
I
feel
like
we've
been
starting
this
for
six
months
now,
so
please
put
it
there's
actually
a
where
where's
the
one
github
the
the
gentleman
that
there
was
a
very
long
comment.