►
From YouTube: Design Up Front: Socializing Ideas with Enhancement Proposals - K Garrison & A Kaplan, C Wilson
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. 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.
Design Up Front: Socializing Ideas with Enhancement Proposals - Kirsten Garrison & Adam Kaplan, Red Hat; Christie Wilson, Google
Speakers: Christie Wilson, Kirsten Garrison, Adam Kaplan
KEPs, TEPs, SHIPs - why are contributors asked to fill these out? Many open source projects adopt enhancement proposal (EP) processes to guide new feature development. These documents can be lengthy, and contributors can be reluctant to write designs up front before their code is accepted. There is great value in writing these documents and sharing them with fellow developers. How can a project adopt an EP process without intimidating new contributors? Can these principles be used with proprietary code, or small projects?
In this panel discussion, maintainers from Kubernetes, Tekton, and Shipwright will discuss the ins and outs of their enhancement processes, and how up front design discussions have improved the quality of their code. The panel will explore the history behind their processes, how they work, and how they have evolved over time. Panelists will also share how they make their EP processes effective and engaging. After the discussion you may add EPs to your own projects!
A
My
name
is
adam
kaplan,
I'm
a
software
engineer
at
red
hat
and
the
maintainer
of
project
shipwright
an
incubating
open
source
project
under
the
continuous
delivery
foundation.
Our
project
uses
enhancement
proposals
called
ships
to
discuss.
New
ideas
with
me
are
open
source
leaders
who
also
use
enhancement
proposals
in
their
projects,
christy
wilston
and
kirsten
garrison.
B
Hi
everybody,
I'm
christy
wilson,
I'm
a
software
engineer
at
google
and
I
lead
the
techton
project,
which
is
also
a
project
under
the
continuous
delivery
foundation.
We
have
an
enhancement
proposal
called
tecton
enhancement,
proposals
or
teps,
and
I've
been
working
on
the
project,
for
I
can't
believe
it's
been
actually
three
years
now.
C
A
So
we're
all
using
this
thing
called
enhancement
proposals
and
many
folks
watching
this
may
not
know
what
we
are
talking
about
when
we
are
saying
an
enhancement
proposal
or
an
ep
so
kirsten
since
you've
been
using
caps
for
a
long
time
in
the
kubernetes
project.
Can
you
explain
what
these
are
and
how
kubernetes
uses
it
in
its
software
development
life
cycle.
C
By
ourselves,
it's
the
process
to
create
a
standardized
structure
for
proposing
changes
to
the
kubernetes
project.
Often
this
might
be
a
feature,
but
it
also
just
might
be
some
operator
facing
change
or
a
refactoring
or
some
other
sort
of
non-trivial
change
that
you
need
design
and
discussion
around
proposals
live
in
github
and
they
are
versioned
in
source
control.
They
consist
of
two
parts:
the
readme.md,
which
is
the
meat
and
potatoes
of
the
proposal,
your
design,
your
motivations,
all
the
questions
that
we
have.
C
The
production,
readiness
review,
graduation
criteria,
test
plans,
and
then
we
have
a
metadata
file
which
we
use
for
tooling,
which
helps
us
track.
The
state
author
ownership,
whether
it's
alpha
beta
or
ga,
and
what
release
the
enhancement
is
targeted
for
so
enhancements
for
us-
are
part
of
the
greater
relief
cycle
to
encourage
communication
between
all
of
the
stakeholders
pre-implementation.
A
B
Sure
so
for
techton,
we
based
our
proposal
process
on
kubernetes,
so
a
lot
of
the
process
is
similar.
One
big
difference
is
that
we
don't
target
enhancements
towards
releases
specifically
for
us.
The
enhancement
proposals
are
more
about
agreeing
as
a
community
to
what
features
we
think
should
be
in
tecton.
So,
even
if
a
proposal
is
accepted,
it
might
be
it
might
be
shortly
after
it
might
be
quite
a
long
time
until
you
see
it
actually
implemented
and
released.
B
The
process
for
us
is
very
similar.
We
also
use
github
as
the
source
of
truth.
If
you
want
to
open
an
enhancement
proposal,
you
open
a
pull
request
with
the
details.
We
have
processes
for
assigning
reviewers.
We
make
sure
that
we
have
reviewers
from
at
least
two
different
companies
do
a
bunch
of
back
and
forth
and
then,
ideally
eventually
we'll
get
to
the
point
where
everyone
signs
off
and
approves,
and
we
merge
it.
A
Yeah-
and
I
say
we
kind
of
learned
a
lot
from
techton
when
we
added
enhancement
proposals
to
shipwright,
we
more
or
less
copied
the
tecton
and
kept
process
when
we
created
ours,
but
I
think
one
thing
that's
maybe
different
for
shipwright
is
that
we
are
a
very
young
project.
Our
apis
are
alpha
and
therefore
we're
comfortable
making
lots
of
breaking
changes.
We
want
new
ideas
coming
in.
We
want
to
iterate
on
ideas
pretty
quickly.
A
The
other
big
thing
for
us-
and
this
is
also
an
artifact
of
us
being
young-
is
that
we're
pretty
small,
and
so
our
process
is
very
ad
hoc.
We
don't
have
necessarily
like
regular
reviews
per
se,
although
we
want
to
improve
that
in
the
long
run,
and
also
we
aren't
necessarily
targeting
things
to
releases
as
well.
It's
more.
We
have
an
idea,
we
agree
on
it
and
then,
when
people
have
time
to
get
to
it,
they
actually
do
it.
A
B
A
So
maybe
this
is
a
good
time
to
ask
both
of
you
kind
of,
like
the
deeper
background
of
why
you
went
forward
with
this
approach.
To
begin
with,
can
you
explain
a
little
bit
about
why
you
adopted
this
enhancement
proposal
process
and
created
not
just
the
template,
but
also
the
things
that
go
around
the
template
to
get
these
ideas
agreed
upon.
C
Previously,
we
were
doing
design
design
proposals
that
originally
lived.
I
think
in
google
documents
and
I
think
that
one
of
the
key
motivators
was
having
one
source
of
truth.
Basically,
the
entire
state
of
the
kef
and
everything
that
you
need
to
know
about
this
feature
is
going
to
live
in
one
place
in
our
git
repo.
C
It's
also
about
creating
a
common
structure
for
all
changes,
not
just
changes
that
you
feel,
like
writing
account
for,
but
for
all
changes
and
sort
of
have
a
baseline
of
quality
for
the
code
going
in
and
and
sort
of
discussion,
and
also
a
baseline
level
of
of
discussion.
So
you
have
to
talk
to
the
sig.
You
have
to
talk
to
the
api
reviewers.
B
And
for
tecton,
I
think,
having
a
single
source
of
truth
for
this
kind
of
information
was
a
big
motivator.
I
want
to
also
give
all
the
credit
for
the
fact
that
we
have
this
process
at
all
to
vincent
de
mester
who's,
the
one
that
proposed
this
process.
I
actually
was
kind
of
opposed
when
he
suggested
it.
I
liked
the
process
we
had
before
because
it
was
pretty
ad
hoc
and
we
kind
of
had
lazy
consensus.
So,
basically,
as
long
as
nobody
objected,
people
could
kind
of
go
ahead
with
what
they
wanted
to
do.
B
But
I
also
had
some
cognitive
dissonance,
because
I
also
wanted
to
review
all
the
changes
that
people
were
proposing
and
I
think
the
worst
thing
about
our
process
before
taps
was.
We
didn't
have
any
kind
of
consistent
format
and
you
kind
of
had
to
be
attending
every
single
working
group
to
actually
keep
up
with
what
was
going
on,
which
makes
it
hard
for
people
to
become
involved
with
the
community,
especially
if
they
can't
actually
attend
the
working
groups.
B
So
vincent
proposed
that
we
take
the
kubernetes
enhancement
proposals
as
a
starting
point
and
we
introduce
tecton
enhancement
proposals.
So
now
we
have
this
one
single
source
of
truth,
and
even
recently
I
found
it
really
useful
to
look
back
on.
I
think
it
was
our
second
tap
tap
two
and
look
at
the
specific
details
of
the
proposal
and
reference
them.
When
I
was
talking
about
something
else.
B
Another
thing
that
I've
personally
found
really
useful
is
all
of
the
back
and
forth.
Well,
it
can
take
a
really
long
time.
I
think
it
also
makes
all
the
proposals
better
and
I
personally
actually
have
more
confidence
when
I
create
a
proposal
now,
because
I
know
that
I'm
not
the
only
person
who's
going
to
be
thinking,
things
through
and
people
who
have
knowledge
in
areas
where
maybe
I
have
gaps
can
help
fill
that
in
and
just
help
make
the
proposal
better
in
general
and
and
selfishly.
A
Shipwright
was
originally
kind
of
a
red
hat,
sponsored
project
per
se,
and
it
was
initially
just
most
folks
at
the
company
and
it
wasn't
until
we
started
getting
contributors
from
outside
red
hat
in
this
instance,
ibm
who
are
interested
in
using
it
for
their
own
needs
that
we
decided
to
first
just
start
documenting
our
design
decisions
in
markdown
and
that's
how
we
kind
of
eventually.
We
then
took
the
cap
and
proposal
process
and
used
that
to
formalize
our
own
process
and
just
having
it
all
in
one
place
proved
really
helpful.
A
As
a
matter
of
fact,
the
all
the
original
design
documents
lived
in
one
repo.
At
one
point,
we
moved
it
to
another
github
repo.
I
initially
wanted
to
just
kind
of
start
fresh,
but
the
community
actually
really
wanted
it
all
in
one
spot
and
we
ended
up
moving.
All
of
those
old
design
docks
into
this
other
community
repo
that
we
set
up,
and
then
we
had
a
numbering
system
and
we
renumbered
everything
so
that
everything
was
kind
of
in
chronological
order,
and
we
could
see
the
progression
of
the
project
over
time.
C
For
us
also,
I
think
the
source
of
truth
is
important,
because
somebody
might
propose
the
enhancement,
but
they
might
leave
the
project.
So
you
need
a
way
to
track
this,
so
that
once
you've
committed
to
a
feature
coming
in
through
alpha
beta
nga,
anybody
else
in
the
project
is
going
to
be
able
to
pick
it
up
and
push
it
towards
the
end.
A
So
this
all
sounds
great
up
front,
but
those
of
us
who
have
actually
done
this
and
tried
to
manage
an
enhancement
proposal
process,
it's
all,
not
sunshine
and
roses.
So
can
you
perhaps
talk
about
like
what
have
been
the
more
painful
things
that
you've
experienced
in
your
ep
processes
and
maybe
talk
about
things
that
you've
experienced
in
the
past
and
how
you
have
addressed
them
and
evolved
your
ep
process.
B
I
think
there's
nothing
worse
than
putting
a
lot
of
time
into
creating
something
and
just
have
it
just
to
have
it
be
ignored
or
to
have
it
be
initially
ignored
and
then
find
out
some
long
period
of
time
later
that
you
actually
have
to
make
substantial
changes
to
it.
I
think
we've
made
a
lot
of
improvements
to
this.
B
We've
set
some
slos
around
how
quickly
people
should
at
least
get
initial
feedback,
but
people
still
miss
those,
and
I
miss
them
all
the
time
and
then
at
that
point
you
kind
of
have
to
rely
on
humans
being
involved
and
going
and
pinging
each
other
and
saying.
Can
you
please
review
this
thing?
I
really
need
feedback.
I
think
we
could
improve
this
by
adding
automation
and
the
fact
that
we
have
centered
everything
around
github
and
this
one
source
of
truth.
B
The
first
thing
they
have
to
do
is
open
a
tep
and
then
they
have
to
deal
with
the
feedback
and
they
have
to
deal
with
the
back
and
forth
and
they're,
not
even
necessarily
dealing
with
github
on
a
day-to-day
basis.
It's
this
whole
other
set
of
tools,
and
this
whole
other
thing.
They
have
to
be
aware
of
and
check,
and
I
think
that
that
can
be
a
pretty
big
stumbling
block
and
the
few
times
that
folks
have
tried.
Sometimes
it's
worked,
but
sometimes
the
taps
get
stalled.
B
They
often
get
closed
because
there's
not
enough
attention
given
to
them,
because
people
had
to
move
on
to
other
things.
Sometimes
they
get
picked
up
later,
but
I
think
that
it,
it
can
be
a
big
barrier
and
even
if
this
kind
of
process
was
more
normal
internally,
I
think
there's
still
this
other
layer,
which
is
that
with
an
open
source
project,
you
have
all
these
different
companies
who
all
have
different
priorities
and
you're,
not
kind
of
you're
sort
of
aiming
towards
the
same
goal
of
having
the
best
project
you
can.
C
This
is
a
good
idea
or
hey
think
about
this
or
hey.
No,
we
already
thought
about
that.
We're
not
doing
that,
and
I
think
that
looking
at
this
as
a
tool
for
discussion
and
as
a
meeting
of
the
alliance
and
starting
that
sooner
rather
than
later,
has
been
really
helpful
and
successful.
The
pain
point
that
we've
had
is
one
new.
One
is
now
that
we
have
this
process.
We
have
this
template.
Is
it
applicable
to
everything
right?
Can
we
make
a
better
template
for
maybe
a
process
change
as
opposed
to
a
code
change?
C
It's
very
like
code
centric
right
now,
so
that's
something
that
we're
exploring
is
adapting
the
template,
for
you
know
even
more
use
cases
to
better
tailor
the
experience
for
the
authors
as
well
as
sort
of
the
classic
open
source
problem
of
reviewer
bandwidth.
We
have
a
lot
more
people
wanting
things
into
the
in
the
repo.
Then
we
have
people
who
are
committed
to
reviewing
and
approving
things.
C
C
A
And
I
guess
for
us
with
shipwright,
since
we
are
so
young,
I
think
like
we.
We
too
commiserate
with
a
bandwidth
problem
and
it's
actually
brought
us
into
having
bigger
conversations
about
project
governments
trying
to
set
up
a
good
contributor
pipeline
and
establishing
how
someone
can
go
from
for
submitting
the
code
to
being
established
themselves
in
the
organization
to
working
their
way
up
to
being
an
approver
either
for
a
sub-component
or
in
the
case
of
the
enhancements.
We
now
have
the
dedicated
repo
and
you
can.
A
We
can
add
people
as
an
approver
there,
so
it's
definitely
helped
us
as
a
project
start
thinking
about
these
things
and
maturing,
because
we
ultimately
want
to
grow
and
scale
now.
I
also
want
to
talk
to
both
of
you
about
that
feedback
cycle
and
getting
people
involved,
because
there's
definitely
a
lot
of
work
that
needs
to
go
into
an
enhancement
proposal
which
can
be
very
intimidating
for
someone
who
is
coming
at
it
new.
C
Yeah,
I
I
think
I
mentioned
it
in
the
previous
question
a
little
bit,
but
I'll
explicitly
mention
it.
Now
we
used
to
have
the
problem
of
people
just
opening
enhancements
like
with
all
of
their
new
contributor
energy
or
new
author
energy,
and
then
the
enhancement
just
sits
there,
because
nobody
knows
that
it's
there.
Nobody
has.
They
haven't
talked
to
anybody,
and
that
was
a
really,
I
think,
frustrating
experience
for
contributors.
C
Hoping
that
somebody
sees
you
and
that's
been
really
successful
for
us,
I
would
also
just
say
at
its
core
having
an
enhancement
having
this
template.
Having
this
this
process
to
get
something
into
a
kubernetes
release,
that's
very
defined
we're
not
hiding
the
ball
for
a
new
person.
It
applies
to
everybody,
there's
no
secret,
and
I
think
that
that
that
that
that
sort
of
it's
fair,
you
know
everybody
has
to
do
this
to
get
it
in
and
we're
telling
you
what
you
have
to
do
and
we
want
you
to
do
it.
B
C
Not
so
we
are
very
community
oriented
and
we
are
a
global
community
like
there
are
people
everywhere.
There's
there
are
people
who
you
know,
they're
they're
living
in
the
future
they're
living
in
the
past,
depending
on
their
time
zone.
So
you
don't
have
to
attend
a
meeting,
we're
very
async.
You
can
send
things
to
the
mailing
list.
You
can
go
to
the
flat
channel.
You
can
put
something
on
this
big
agenda
as
well
to
discuss.
So
we
have
a
lot
of
options
there,
not
just
for
time
zones,
but
some
people
are
more
introverted.
C
They
might
not
want
to
be
on
camera.
Some
people
are
english
as
a
second
third,
fourth
language.
They
might
be
more
comfortable,
just
writing
down
their
ideas
and
communicating
that
way.
So
we're
very
flexible-
and
it's
really
just
about
that.
That
communication
happens
not
the
way.
You
know
that
it
happens.
A
Yeah
one
thing
that
for
us,
we're
kind
of
because
we're
smaller,
we
are
yes,
we're
more
relying
on
the
template,
and
so
one
of
the
things
that
we
try
to
do
with
the
template
is
make
clear
what
is
expected,
particularly
at
each
phase
of
the
life
cycle.
Since
we
have
this
provisional
implementable,
implemented
kind
of
phasing.
A
So
when
someone
has
like
that
new
contributor
energy
and
they
want
to
submit
an
idea,
we
want
to
be
able
to
say
that
this
is
the
things
that
you
need
to
fill
out
so
that
we
can
have
a
good
discussion
about
whether
or
not
this
is
a
good
idea
or
not.
So
we
have
like
a
summary,
the
motivation,
a
section
on
user
stories,
goals
which
helps
us
figure
out
what
is
in
scope
versus
what's
kind
of
out
of
scope.
What
are
the
things
that
you're
maybe
not
going
to
address
in
the
proposal?
A
So
then,
once
you
get
that
agreement
on?
Yes,
this
is
a
good
idea.
Then
you
can
start
investing
that
energy
into
actually
thinking
through
the
design
from
an
api
level
from
which
components
are
going
to
be
affected
to
even
going
into
how
you
are
going
to
test
it
which
infrastructure
you
might
need,
because,
particularly
for
software
that
can
be
deployed
kind
of
anywhere.
A
You
can
have
lots
of
different
requirements
that
your
ci
environment
may
not
be
able
to
replicate
easily.
So
knowing
that
up
front
is
actually
really
useful
information
as
to
whether
or
not
this
is
something
that
the
project
can
actually
take
on
and
accept
and
maintain
over
time,
because,
ultimately,
especially
with
open
source,
you
are
not.
A
So
that
maybe
leads
me
to
this
next
idea
and
because
we
were
involved
in
open
source,
but
we
also
work
for
big
companies
and
we
are
taking
the
open
source
projects
and
converting
them
into
projects.
So
is
there
a
compatibility
or
maybe
a
disconnect
between
the
two?
Can
you
use
this
process
for
a
product,
or
is
this
something
that
maybe
you
know
it's
great
for
open
source,
but
maybe
not
something
that
is
good
for
proprietary
software.
C
I
think
that
it's,
I
think
that
if
you
take
the
idea
of
what
is
an
enhancement,
it's
a
way
to
clearly
articulate
your
design
along
with
potentially
answering
questions
that
your
project
thinks
are
important
and
sort
of
having
a
way
to
track
the
status
of
them.
I
think
that
that
general
idea
is
totally
legitimate,
whether
it's
a
project
or
a
product.
Now
does
the
kubernetes
enhancement
proposal
process
and
release
process
work
for
a
product?
Maybe
not.
We
don't
have
people
who
are
allowed
to
come
in
and
say,
hey
like.
B
So
I
think
it's
really
important
to
kind
of
constantly
be
examining
how
you
work
and
trying
to
improve
and
tweak
it,
because
other
another
project
is
different
from
yours.
Another
product
is
different
from
yours.
The
team
is
different,
you're,
a
different
person.
Your
team
is
different
a
year
from
now,
so
I
think
that
being
able
to
I,
wouldn't
I
wouldn't
take
a
process.
Try
it
exactly
as
is,
and
then
reject
it.
I
would
try
to
examine
what
what
did
you
like
about
it?
What
didn't
you
like
about
it?
B
What
changes
could
you
make
and
I
think,
as
kirsten's
pointed
out,
there's
a
lot
of
there's?
Obviously
a
lot
of
value.
That's
come
from
this,
and
kubernetes
has
been.
I
think
I
I
think,
I'm
going
on
a
limb
and
saying
is
the
largest
open
source
project.
I
think
there
are
other
huge
projects,
but
just
the
volume
of
contributors
that
are
involved
in
kubernetes
and
the
success
and
kind
of
having
all
these
people
with
all
these
different
goals,
actually
contributing
towards
one
thing.
A
We
all
often
use
it
in
like
an
agile
process.
For
like
a
spike
story.
In
particular,
we
found
eps
to
be
a
very
useful
mechanism
to
have
like
a
concrete
deliverable
that
we
can
agree
upon
versus
like
what
might
might
be
a
more
loose
or
freeform
spike,
where
it's
just
okay,
there's
this
thing
that
we
need
to
investigate
and
research.
A
We'll
often
when
we
are
scheduling
spikes,
we
will
decide.
Okay,
these
are
the
things
that
we
need
to
investigate.
These
are
the
decisions
we
need
to
make.
These
are
the
things
that
we
want
to
have
an
idea
of
how
we're
going
to
do
and
we
are
going
to
write
the
enhancement
proposal,
get
feedback
and
get
it
to
an
implementable
state,
and
that's
we
find
that
it's
helped
us
kind
of
focus.
C
C
To
ga,
so
we
have
a
slower
process
and
that's
it's
really
baked
in,
like
the
enhancement,
supports
the
release
and
we're
trying
to
get
the
best
release
possible
and
the
best
signal
on
release
and
the
best
possibility
balance
with
number
of
features
into
a
release.
So
I
think,
that's
probably
like
where
our
process
might
feel
really
heavy
to
other
people
in
a
product.
C
C
This
is
what
it
is
like
clearly
communicating
the
state
of
your
future,
not
necessarily
over-promising,
but
really
being
able
to
deliver
something,
that's
going
to
work,
the
way
that
they
can
expect
it
to
work
and
then
incrementally
improving
it,
but
in
a
very
clear
structured
way,
also
does
have
some
value.
I
think
there's
a
lot
of
pressure
on
engineers
and
products
just
straight
to
ga
fix
a
month
later,
which
can
become
pretty
expensive
like
with
time
after
the
fact.
C
A
Yes,
I
have
actually
been
involved
in
consulting
projects
where
we've
had
different
budgets
for
features
and
bugs,
and
the
features
budget
is
the
one
where
we
were
just
billing
our
time
by
the
hour
and
those
were
more.
That
budget
was
more
lucrative,
whereas
the
bug
budget
was
fixed
and
if
we
went
over
it,
if
our
software
was
so
buggy
that
we
still
couldn't
use
it,
my
company
was
the
one
that
was
eating
the
cost.
It
wasn't
the
customer
and
the
client
who
we
were
working
for.
Who
was
paying
for
that.
B
And
I
think,
even
when
you're
not
directly
billing
someone
for
for
the
bugs,
I
think
that
if
you
look
at
how
much
it
costs
to
make
a
change
in
general
at
different
phases
in
software
life
cycle,
it's
the
most
expensive
to
make
the
change
once
the
code
is
already
written.
The
ep
process
might
feel
like
it
really
slows
things
down,
but
I
think
once
you
kind
of
get
used
to
it,
you'll
find
that-
or
at
least
I've
found
that
I
feel
like
the
part
where
you
actually
write.
B
The
code
is
not
the
hardest
part
of
the
process.
That's
kind
of
an
afterthought
because
you've
been
forced
to
sort
of
think
things
through
so
thoroughly
and
having
to
do
that
actually
gives
you
like
really
rapid
feedback
time
where
you
can
have
an
idea.
Think
it
through
talk
it
through
realize
the
implications
realize
you
need
to
make
an
adjustment
make
that
adjustment.
So
you
actually
have
these
really
quick
cycles
where
you
don't
have
to
go
as
far
as
writing.
C
A
I
would
love
to
talk
about
this
more,
but
unfortunately
we
are
running
out
of
time.
So
I'd
like
to
leave
these
last
few
minutes
so
that
we
can
share
our
takeaways
what
we
want
the
audience
to
take
back
either
to
maybe
open
source
projects
that
they're
involved
in
or
the
projects
or
companies
that
they
work
for
so
christy.
Why
don't
you
get
us
started.
B
Sure
I
think
the
main
thing
that
I'd
like
to
get
across
is,
if
possible,
I
think
it
really
helps
to
try
to
shift
your
perspective
from
viewing
these
things
as
kind
of
arduous
and
painful,
and
realize
that
actually
having
to
take
the
time
to
communicate
your
ideas
clearly
and
then
getting
feedback
and
responding
to
that
feedback
and
incorporating
it.
It
makes
your
ideas
better
and
I
think
it
can
actually
help
you
grow
as
an
engineer
and
create
better
designs
and
proposals
in
the
future.
C
Yeah
plus
one
to
christy,
I
would
also
say
that
this
is
an
inherently
flexible
process.
There's
no
one
right
way
to
do
it,
so
you
really
have
to
do
some
reflection
and
decide
what's
important
to
you
and
your
project
and
use
this
process
to
reinforce
those
values.
For
us,
it's
transparency
and
communication
and
having
this
source
of
truth
for
you,
it
might
be.
You
know,
guaranteeing
stability
or
whatever
your
priority
is
but
think
about
your
core
values
and
then
tailor
your
process
to
reflect
your
core
values,
and
I
think
you
can't
really
go
wrong.
A
And
I
think
my
main
takeaway
running
an
ep
process
is
that
you
really
need
to
invest
in
it
and
make
sure
you're
getting
the
necessary
care
and
attention
both
from
the
reviewers,
but
also
the
authors
who
are
contributing
their
ideas.
So
it's
almost
like
a
plan.
If
you've
got
like
a
vegetable
garden,
you
need
to
make
sure
that
you're
watering
and
checking
in
on
them
regularly,
if
you're,
not,
then
they're
just
going
to
wither
on
the
vine
and
fade
away.