►
Description
This Jenkins online meetup talks about our effort to streamline and improve the way major contributions are made to the Jenkins project: Jenkins Enhancement Proposal (JEP) Process. We cover all the What, Why, When, and How of the JEP process: moving from early to discussion, to creating and updating designs, to completed implementation and roll out.
SPEAKERS: Bitwiseman https://github.com/bitwiseman and MarkEWaite https://github.com/MarkEWaite
Slides: https://docs.google.com/presentation/d/1b5nDuoP7Zbp_zYoPjM-XcgYbditzyQdzNGlNx_esmb8/edit?usp=sharing
A
Welcome
everyone
we're
delighted
to
welcome
you
to
this
Jenkins
online
Meetup,
I'm
mark
wait
and
the
Jenkins
project
is
delighted
to
host
a
session
today
with
Liam
Newman
presenting
for
us
the
Jenkins
enhancement
proposal
process
Jeff.
So
we're
going
to
host
this
session
through
hangouts
on
air.
We're
delighted
to
have
you
with
us.
Questions
can
be
asked
through
the
internet
relay
chat
system.
Please
use
the
Jenkins
CI
channel
and
talk
with
us
prefix
your
text
with
jom
we're
glad
to
have
you
here
Liam.
How
about
you
take
us
off.
Let's
talk
about
Jeb
cool.
B
B
B
What
we'll
do
today
is
we're
going
to
talk
about
this.
This
new
process
called
the
Jenkins
enhancement
proposal
process.
It's
nine.
Ten
months
old
now
took
us
a
while
to
get
it
off
the
ground
and
get
through
some
some
early
aerations
and
we'll
go
over
what
it
is
why
it
was
created.
Who
should
use
it,
how
it
works
when
they
use
it
when
not
to
use
it,
and
you
know
where
to
get
more
information.
B
The
things
that
we
won't
cover
in
this
talk
is
really
the
like
an
in-depth
discussion
of
all
the
details
of
Jeff
and
the
jet
process.
It's
it's
not
super
complex
will
usually
make
it
through
the
the
overview
and
in
this
hour,
but
there's
there
are
some
corner
cases
and
some
you
know
things
that
you'll
want
to
know
that
you'll
need
to
go
and
actually
read
the
Jeff
description,
the
specification
document
about
it
so
that
you
can
get
a
sense
of
those
things
but
I
think
well
by
the
time
we're
done
here.
B
Everyone
will
have
a
good
overview
of
how
this
works.
Interspersed
I'll
just
define
some
roles
in
terms
and
should
go
pretty
smoothly.
I
think
so,
first,
of
course,
what
is
Jeff
Shep
is
the
Jenkinson
health
aide
Jeff.
When
we
speak
of
a
we're
speaking
of
a
Jenkins
enhancement
proposal,
which
is
a
design
document
that
describes
any
aspect
or
new
feature
related
to
Jenkins,
so
the
it's
it's
basically
like
it'll
do
it'll
describe
the
the
motivation
for
the
change
proposes.
A
new
feature
describes
the
the
motivation
for
it
and
provides
an
overall
specification.
B
B
Now,
there's
there's
it's
really
not
intended
to
replace
things
like
email
discussions
or
anything
else.
It's
more
meant
to
give
people
an
overview
and
then
a
Jeff.
We
talked
about
the
check
process
as
a
whole.
It's
the
process
by
which
chips
are
created,
submitted,
reviewed,
finalized
and
then
maintained
once
there
once
they're
done,
and
actually
the
jep
process
is
the
first
chap
step
1.
So,
the
first
step
that
we
did,
we
described,
we
used
the
the
jet
process
to
create
that
jab
and
the
it's.
B
This
is
the
the
point
of
this
is
to
have
one
agreed-upon
process
for
proposing
major
and
new
features,
collecting
community
input
and
documenting
the
design
decisions
that
have
gone
into
Jenkins.
A
the
jet
process
is
based
on
the
Python
pep
process.
Pretty
heavily
we
fly,
the
imitation
is
the
sincerest
form
of
flattery
right.
So
thank
you
to
Python
for
their
for
their
work
there
and
I
don't
want
to
mention
right
right
now.
The
the
process
of
a
whole
as
the
whole
as
a
whole
is
generally
consensus-driven.
B
We
talk
about
consensus
will
mean,
is
general
agreement?
There's
a
lot
there's
a
lot
of
you
know
information
you
can
get
on
on
consensus,
decision-making,
Wikipedia
I
went
up
there
and
grab
their
description
for
this.
The
key
items,
the
key
characteristics
of
consensus,
driven
decision
making
are
that
its
agreements
seeking
that
we're
looking
to
find
a
an
overall
like
agreement
of
the
the
people
participating,
it's
collaborative
it,
the
participants
are,
everyone
can
contribute.
Everyone
gets
in
and
shares
the
load
of
making
the
decision.
It's
not
a
it's,
not
a
voting
or
a
debate.
B
B
It's
inclusive
that
and
it
believes
that
basically,
as
many
stakeholders
as
possible
should
be
involved
in
consensus
and
that
will
produce
a
better
result
and
it's
hard
to
support
participatory,
which
is
to
say
that
everyone
that
not
only
not
only
does
everyone
contribute,
but
also
everyone
is
invited
to
contribute.
Please
come
exactly
so.
B
As
I
said,
the
main
characteristics
of
the
jet
process
are
that
it's
consensus.
Driven
it's
intended
to
happen
in
tandem
with
implementation.
It's
very
agile,
friendly
I
mean
you
could
do
do
it
as
as
waterfall,
but
it's
it
works
just
as
well.
In
the
the
other,
in
an
agile
in
an
agile
model.
In
fact,
works,
I
would
say
better
because
you,
you
start
doing
the
JEP
and
then
you
and
the
implementation
they
sort
of
work
in
tandem.
It's
opt-in,
you
don't
have
to
use
it.
B
So,
having
said
that,
it's
the
the
process
is
consensus
driven.
We
do
have
at
least
an
out.
We
have
what's
called
a
button,
evident
beloved
if
I
can
say
it,
but
Neverland
dictator
for
life
BD
FL.
We
just
shortened
it
to
that,
because
it's
no
I
don't
want
saying
that
all
time
and
that
person
is
the
one
that
acts
as
the
trusted
decision
maker
when
a
unilateral
decision
is
needed.
B
So
as
whereas
a
is
going
through
certain
parts
of
the
process,
the
the
B
DFL
will
review
jep's
or
designate
others
to
review
jep's
bill
and
they
resolve
any
disputes
or
arguments.
Obviously
we're
trying
not
to
have
those,
but
if
that's
what
happens
there,
they
will.
They
can
be
asked
to
take
action
to
resolve
those
any
any
any
disputes
that
can't
be
resolved
through
consensus.
And
finally,
they
also
refrain
from
using
that
power
as
much
as
possible
and
leave
it
to
the
community
to
manage
themselves.
So.
A
Liam,
if,
if
there's
something
that
is
so
controversial,
that
it
needs
resolution
by
the
BD
FL
are
there?
Are
there
common
examples
of
that
things
that
I
assume
controversies?
Okay,
it's
okay
for
us
to
disagree
with
each
other.
Are
there
places
where
you've
seen
that
happen
where
the
B
DFL
had
to
get
involved
and
say
no
we're
doing
this
or
that.
B
B
He
what
he,
what
coast
K
was
the
reviewer
on
on
the
prep
that
I'm
thinking
of
and
what
he
did
was.
He
said,
okay.
This
is
what
needs
to
happen,
but
that
would
have
been
something
that
any
anyone,
even
the
any
any
reviewer
of
that
job.
If
there
had
been
a
if
there
had
been
a
be
DFL
delegate
to
that
was
reviewing
it
so
I
guess
that
sort
of
that's
that's
the
level
of
choice
yeah,
so
we
had
we've
had
a
few,
but
they
haven't
been
as
Extreme
as
like.
We
just
can't
agree.
B
B
So
let
me
talk
about
permit
about
the
the
parts
of
a
jet
there.
The
there's
some
required
set
of
the
design
of
the
jet
specifies
that
we
should
have
a
minimum
set
of
a
certain
set
of
sections
that
you
have
to
have.
There's
I,
think
ten
of
them
overall,
but
I
don't
want
to
spend
too
much
time
on
the
details
of
that.
But
let
me
give
you
at
least
you
know
a
few
highlights.
The
the
JEP
will
include
an
abstract
which
is,
like
you
know,
the
elevator
pitch
for
the
the
new
feature
or
process.
B
It'll
include
a
specification
which
says:
here's
how
the
thing
works:
here's
here's
all
the
details,
here's
the
api's
that
we've
implemented.
Here's
the
or
describes
the
process
that
it's
that
it's
being
proposed.
It
says
how
it
you
know
how
it's
going
to
work.
Maybe
you
had
a
rollout
plan
if
there's
a
if
that's
needed,
that
kind
of
thing
there'll
be
a
motivation
section
which
we'll
talk
about
the,
why
you
know
why
is
this
needed?
Why
it
wouldn't
know?
How
are
things
before
this
JEP
was
proposed?
Where
you
know,
what's
what
are
we
trying
to
solve?
B
All
of
that
and
it'll
also
have
a
reasoning
section,
which
is
where
we'll
document
the
design
choices
that
were
made,
but
generally
what
the?
Why
of
the
specification
or
the
other
reasons
or
the
other
design
choices
that
were
considered
but
rejected.
So
it's
it
takes
a
little
bit
of
practice
to
kind
of
figure
out
where
certain
different
information
goes,
but
that
that's
them
that
minimum
set
actually
is
once
you
get
a
good
think
of
hang
of
it.
It's
pretty
clear,
there's
other
sorry
what
Liam.
A
B
Exactly
and
it's
just
general
so
the
point
here
is
that
when
someone
reads
the
specification,
they
should
be
able
to
read
it
as
this
is
what
we're
doing
this
is
this.
This
is
BAM
there.
It
is
I,
don't
have
to
we're,
not
gonna
I'm,
not
gonna.
If
I'm
reading
the
specification
section
I'm
reading
what
it
is
actually
in
the
design
and
nothing
else
right.
If
I
am
reading
the
specification
I
go,
why
they
do
that
I'd
go
down
to
the
rezonings
section
and
that
would
be
most
likely
where
I'd
yeah.
B
So
when
we
decided
to,
for
example,
if
it
was
the
the
green
balls
plug-in
it's
like
with
the
reason
we
decided
to
make
the
green
the
balls
green
is
because
we
we
also
you
know
that
we
considered
other
other
colors.
We
considered
allowing
people
to
choose,
you
know
set
their
own
color,
but
that
was
out
of
scope.
That
kind
of
thing
right.
Oh
yeah,
speaking
of
the
green
balls
plug,
let
me
go
back
and
so
like.
B
If
we
use
that
as
the
example
the
abstract
would
say,
you
know
this
plugin
changes
the
color
of
a
successful
build
indicator
from
blue
to
green.
That's
your
abstract
boom
specification
for
green
ball,
so
actually
pretty
pretty
short,
but
you
could
have
more
information
about
how
it
does
it
or
you
know
what
it,
but
it
would,
for
example,
might
say
this
plugin
uses
the
standard
Jenkins
plug-in
API
is
to
change
the
color
of
a
successful
build
and
it
indicator
from
blue
to
green.
It
uses
this
color
of
green
it.
B
You
know,
etc.
I
sort
of
lay
out
what
it
does
and
the
motivation,
for
example,
would
be
many
Jenkins
users
do
not
feel
blue
as
a
strong
enough
indicator
of
success
right.
That
would
be
so.
We
chose
to
make
a
green
balls
plugin.
That
would
be
an
example
of
these
four
sections
and
then
others
there's
other
sections
that
include
backward
compatibility.
B
B
B
If
you
look
back
in
Jenkins
history,
design
documents
are
pretty
rare
and
when
people
have
come
in
to
the
Jenkins
user,
mailing
list
or
IRC
or
even
on
or
the
JIRA
or
any
of
the
other
ways
that
you
interact
with
the
project
and
they're
like
okay,
so
I'd
like
to
contribute
to
this
area
or
I'm
interested
in
this
or
I
use.
This
and
I
want
to
help.
How
do
I,
you
know
where
do
I
find
the
design
information?
B
B
So
Jeff
takes
us
into
feature.
It
takes
us
into
the
into
the
size
of
the
project
that
Jenkins
has
become.
It
gives
us
clear,
as
I
said
earlier,
clear,
understandable
and
bite-sized
eye
design.
Documents
gives
us
a
consistent
process
that
we
that
we
went
through
the
same
consensus-driven
process
to
create
this
process,
and
so
we've
had
gathered
a
lot
of
information.
There's
a
lot
of
things
mentioned
in
the
reasoning
section
of
jak1
about
okay.
We
considered
this.
We
thought
about
that,
and
but
the
but
here's
how
we
went
with
this
and
generally
just
it's.
B
It's
open
and
inclusive
and
gives
us
less
chaos
and
more
productivity,
and
it
will
let
us
have
larger
groups
of
people.
Work
together,
including
larger
organizations,
be
able
to
come
in
and
say
when,
when
we
have
groups
of
people
or
a
larger
organization
say
well,
how
can
we
participate?
We
can
say:
well,
here's
how
you
can
here's,
how
you
can
propose
changes
and
interact
with
the
community
and
come
in
and
work
through
processes
with
us.
B
B
Anyone
with
a
new
idea
for
improving
Jenkins
Kanpur
can
say:
hey
I'd
like
to
participate
in
this
process
and
and
come
in
and
work
through
it,
which
the
question
of
when
do
you
do
it
and
when
don't
you
do
it
generally
speaking
so
far,
what
I've
seen
people
say
is
you
know,
basically,
someone
there'll
be
a
discussion
going
on
on
an
on
the
mailing
list
at
this
point
generally,
the
developer
mailing
list
and
people
will
say
eventually
I've
about
at
a
certain
way.
Through
there's
been
some
discussion
back
and
forth
and
some
will
go.
B
B
Basically,
when
an
issue
is,
you
know,
complex
or
broad
enough
that
it
requires
collaborating
and
consensus
building
and
basically,
if
you
feel
like
you
or
a
future,
you
might
appreciate
a
design
document
that
that's
when
you'll
need
a
simple
or
small
changes.
Not
so
much
you
don't
need
a
jet
for
hey
I've
found
a
bug
in
this
thing.
I
want
to
fix
it,
go
ahead
and
do
that
anything
that
you
would
perform
in
the
normal
development
process.
B
You
know
just
a
single
PR
generally,
don't
need
doesn't
need
a
jet,
but
but
basically
it's
when
you,
when
you
start
getting
beyond
just
your
own
area,
you
want
you
want
to
bring
more
people
in
or
make
sure
that
you're
that
you're
working
in
a
consents.
This
way,
that's
what
you
do
and
of
course,
do
you
I
have
to
create
a
job.
No,
but
it's
these
days
for
any
feature
or
idea
of
significant
size.
It's
worth
considering
at
least.
A
Thanks
yeah,
so
Liam
Tyler
makes
a
good
point
in
the
IRC
that
the
JEP
and
no
JEP,
simple
and
small
changes
might
in
fact
mean
a
small
change
across
many
places
and
that
probably
justifies
a
Jeb.
It's
for
me,
the
boundary
I
think
as
you're,
describing
if
it's
inside
one
plug
in
it's
probably
not
worth
a
JEP,
but
as
soon
as
it
starts
touching
multiple
people
or
multiple
places
or
multiple
plugins.
It
may
be
time
to
that's.
That's
a
good
time
to
consider.
Is
this
a
Jenkins
enhancement
proposal
topic
you.
B
Know
I'm
not
I'm,
not
sure
they're
actually
because
I
mean
so.
For
example,
we
have
the
the
Jenkins
configuration
is
code
plug-in
mm-hmm,
which
is
a
single
plug-in.
However,
its
effect
a
lot
of
plugins,
so
that
wouldn't
that
would
that
would
meet
your
bar
for
that
you're.
That
you're
suggesting
I
would
say,
though,
that
you
could
have
you
know
one
plug-in
that
you
know
you
are
that
you've
decided
hey
I
want
to
make
this
plugin
I
want
to
support
kubernetes
and
Jenkins.
No,
that's
not
going
to
do
that.
B
If
you
want
to
just
work
on
that
on
your
own-
and
you
didn't
really
want
to
you-
weren't
worried
about
whether
or
not
you
were
going
to
collaborate
with
other
people
in
the
Jenkins
prod
Jenkins
project,
then
yeah
you
wouldn't
need
a
Jeff.
But
if,
if
you
were
hey,
I've
got
this
testing
framework
I
want
to
implement
for,
but
I
want
to
make
sure
that
I'm
doing
that
I'm
doing
it
in
a
design
that
the
design
I'm
using
is,
is
good
and
and
agreed
upon
for
Jenkins
and
also
I'd,
like
collaborators
to
come
and
help.
B
A
So
so,
there's
one
that
Jesse
Glick
just
raised
in
the
internet
relay
chat
system
about
the
use
utf-8
for
pipeline,
build
blogs,
Gipp
that
was
proposed,
and
the
question
was
should
that
be?
Should
is
that
JEP
level
thing
and
my
mind
was
hey
something
as
as
big
as
changing
character
set
across
things?
That
was
certainly
worthy
of
a
Jeb,
but
what's
your
what's
your
feeling
on
it?
So
this
was.
The
proposal
was
JEP
206
use
utf-8
for
pipeline,
build
logs,
yeah.
B
Yeah
that
yeah,
that
that
would
definitely
make
sense
and
I'm
glad
that
he
did
that
because
in
some
cases
it's
it's
a
matter
of
okay
I.
Would
you
know
I
think
this
is
the
right
way
to
go.
There's
enough
of
a
change.
It
might
be
controversial,
there
might
be
some
back-and-forth
and
or,
and
even
if
there
isn't,
it
means
having
done
the
JEP
means
that
if
someone
goes
comes
in
a
year
from
now
or
whenever
and
says,
why
do
they
do
this
like
or
why
do
they
make
this
change?
B
They
can
go
back
and
look
at
the
and
someone
can
say:
hey
look
at
the
JEP,
and
that
is
the
one.
You
know
it's
a
design
document,
it's
a
one
place
and
they
can
go
and
read.
Oh
yeah,
we
had
this
motivation.
We
these
are,
you
know,
there's
these
discussions
occurred
and
this
this
is
the
way
that
we
decided
to
roll
it
out
and
just
basically,
it
sits
in
that
case.
I
feel
like
like
it's
due
diligence.
A
It's
it's
feeling
to
me,
like
I'm,
probably
currently,
more
biased
towards
not
creating
a
JEP
than
I
should
be,
and
if
I'm
feeling
that
way,
probably
others
have
the
same
pattern
that
they
might
consider.
You
should,
if
you
think,
should
I
or
should
I
not
create
a
think
very
carefully.
You
probably
should
create
a
jet
I,
wouldn't.
B
I
would
lean
towards
yes,
but
that's
my
bias,
of
course,
and,
and
is
the
the
final
point
I'll
make
on
this,
is
no,
you
know
a
lot
of
people,
it's
very
common
for
people
not
to
want
to
stop
what
you
know,
stop
what
they're
doing
and
write
down
and
write
things
down
right,
I'm,
like
no
I'll
just
go:
do
it
right,
I'll
write
the
code
will
be
cool
but
having
this
prep.
The
reason
why
we
have
this
process
is
to
sort
of
keep
everyone
on
the
same
page
as
well.
B
So,
finally,
having
gotten
this
far,
let's,
let's
talk
about
how
this
works.
Well,
it's
basically
just
a
series
of
states
from
submitting
a
JEP,
the
jet
will
become
a
draft
it'll
get
reviewed,
it'll
then
be
accepted
and
then
finalized,
so
that
okay,
we're
done
I'm
going
no
mic
drop.
No,
so
to
start
with,
you
have
an
idea.
Someone
has
an
idea
for
improving
Jenkins.
B
So
that's
someone:
they
have
an
idea
for
a
new
feature
and
they
start
by
emailing
the
Jenkins
CI
dev
list
and
asking
the
community
hey
I've
got
this
idea.
What
do
you
think
from
the
moment
they
send
that
email
or
even
before
they
can
start
doing,
prototyping
begin
implementing
stuff
and
as
they're
doing
that
prototyping
and
they
have
that
email
out
to
the
community.
They'll
gather
some
initial
feedback,
given
some
a
general
positive
response.
B
B
So
let's
talk
about
sponsor
for
a
second
or
sponsor
of
you
guys
use
that
term
a
couple
times
now
the
sponsor
is
the
the
leader
of
a
jet.
They
are
the
primary
consensus
builder.
They
they
are
responsible
for
the
for
the
jet
in
in
toto,
and
the
state
of
the
Japanese
represents
ensuring
that
it
represents
the
consensus
of
the
community,
the
document
dissent,
dissenting
opinions,
they
might
coordinate
contributors
work
and
they
ensure
that
it's
you
know
in
the
right
style
has
good
quality
and
they'll
maintain
the
Jeff
after
it's
finalized.
B
If
there's
any,
you
know
tweaks
or
edits
or
changes
later
on,
they
will
they'll
be
the
ones
to
do
that.
They're,
not
necessarily
the
primary
implementer
of
the
the
future
in
question.
You
can
be
the
sponsor
and
know
and
write
no
code.
You
can,
you
can
be
the
sponsor
and
also
not
really
write
the
the
majority
of
the
jet
might
be
written
by
could
be
written
by
other
contributors.
B
So
from
from
that
really
discussion
and
early
implementation,
someone
said
hey,
you
should
put
up
a
jet
for
this,
and
so
the
person,
the
the
sponsor,
will
now
submit
that
jab
they'll
create
a
jet
document.
It'll
be
an
ASCII
Doc.
The
template,
as
I
mentioned,
that
jet
will
link
to
supporting
documentation,
discussion,
it'll
link
to
the
prototype
implementation.
If,
if
it,
if
there
is
implementation,
it's
going
to
be
done
there
and
then
they
will
submit
that
that
Jeff
for
approval
is
draft
by
the
jet
occurs.
B
The
key
thing
to
keep
in
mind
here.
This
is
a
an
initial
conformance
check.
It's
not
a
design
review.
So
when
you
put
this
up,
you
may
feel
like
I'm.
This
is
something
that
you
want
to
do
early
so
that
okay,
here
it
is
here's
the
basic
structure:
here's
the
overall
early,
you
know,
design
choices
that
we've
made
and
let's
and
and
that
moves
that'll
move
the
into
a
draft
state.
This
will
maybe
this
should
maybe
take
one
to
two
days
at
most.
Early
discussion
could
go
on
for
a
week
or
so.
A
B
So
the
the
Jeff
editors
are
a
small
group.
There's
five
of
us
right
now
who
administer
the
process?
It's
it's
a
very
you
know,
sort
of
editor
who
I'm
on
a
better.
It's
it's
the
least
glamorous
job
of
this
process,
we're
just
process
administrators
for
the
process.
So
when
someone
submits
it
to
a
Jeff
for
approval,
as
draft
we'll
check
that
it
has
all
of
the
the
sections
in
it
that
you
know
generally,
it
has
complete
sentences
and
it
has
you
know
the
right.
B
You
know
the
right
format
overall,
we'll
assign
the
Jeff
number
to
it
and
will
we
perform
other
administrative
tasks
like
merging
PRS
other
people's
PRS
once
they
say,
hey
yeah.
This
is
this
is
good,
so
it
that
that
initial
submission
we
say:
okay,
here's
all
it
has
all
the
sections.
It
has
a
reasonable
start
to
the
design
and
and
and
has
a
sponsor,
and
hopefully
a
B
DFL
delegate
will
review
it
later
on
and
then
the
Jeff
we
come
and
draft.
B
At
that
point,
the
Jeff
sort
of
goes
into
a
cycle
here.
The
sponsor
or
contributors
will
gather
feedback,
modify
their
design
based
on
that
feedback
record
the
reasons
for
the
design
decisions
record
the
different
views
you
know
if
there
were
there
was
controversy
of
any
sort
they'll
put
that
in
the
reasoning.
Section
and
they'll
modify
the
implementation
to
match
the
design
and
then
repeat
that
just
kind
of
you
know
continue
that
sort
of
cycle
of.
A
Along
this
line,
Jessi
Glick
asked
in
the
Internet
Relay
Chat.
If
we
need
to
have
a
reference,
implementation
may
be
flawed
and
complete,
etc
to
file
a
draft,
or
can
we
file
a
draft
even
without
yet
having
a
reference
implementation?
Could
a
draft
be
filed
for
something
that
is
still
in
a
conceptual
stage
and
hasn't
yet
hasn't
yet
got
even
a
skeleton
implementation,
so.
B
That
that's
an
that's
a
little.
That's
a
little
bit
of
a
controversial
question
there.
There
are
people
that
are
like.
We
should
always
have
a
an
implementation.
If
there's
going
to
be
one
right,
some
Japs
don't
have
implementation,
they
don't
have
code
written
for
them,
don't
have
documents
there.
It's
a
there's,
a
type
of
jet,
that's
informational
or
a
profit
which
is
like
hey
here's,
some
information
we
wanted
to
record
it
or
there's
a
there,
are
processed
jets
that
are
okay.
Well,
here's
here's
a
new
process
for
doing
something.
B
B
B
How
would
you
call
this?
We
don't
want
drive-by
Jets
like
hey,
we
should
do
this.
One
runs
off
the
the
a
jet
that
is
not
it
doesn't
have
any
implementation
or
any
or
sufficient
design.
Details
probably
would
be
like
a
bug
like
you
would
file.
That
is
like
we
should
do
this,
or
this
is
a
you
know,
a
that's
more
of
a
feature,
enhancement,
request
and
less
of
a
proposal.
B
The
proposal
proposal
in
at
least
in
my
mind,
you
would
participant
in
you
to
participate
in
that,
and
so
I
would
I
respect
it
to
be
at
least
some
degree
of
energy
having
been
put
into
okay.
This
is
this:
has
enough
interest
we're
going
like,
for
example,
if
there
were
discussion-
and
you
know
there
were
five
five
or
six
people-
they
were
like.
Oh
yeah,
this
is
really.
This
is
really
interesting.
I'm
I'm,
really,
you
know
enthusiastic
to
work
on
this.
B
Let's
get
a
Jeff
going
on
it,
I
could
be
like
I
could
see
how
that
would
work
as
an
editor.
I
would
not
stop
that
from
becoming
a
draft
just
because
I
would
I
would
probably
say
as
long
as
someone's
like.
Yes,
we
haven't
started
the
foundation,
but
we're
going
to
shortly
because
there's
four
to
make
sure
that
people
are
involved
like
in
a
job
and
the
implementation
sort
of
indicates
a
level
of
commitment
and
effort.
Thank.
A
You
and
Tyler
in
the
internet
relay
chat
system
noted
as
an
example.
The
Jenkins
essentials
Jeff
came
out
initially
without
an
implementation
and
so
and
then
that
was
used
to
refine
and
evolve.
So
it's
not
a
mandatory
and
I
think
I.
Think
Jesse's
got
a
good
point
that
it's
implementations
are
good
and
probably
should
be
generally
there,
but
not
a
not
a
mandatory
right
right.
Thank
you.
Okay,.
B
And
just
repeat,
as
an
editor
I
would
I
wouldn't
I
as
an
editor.
Checking
for
checking
a
submission
I
would
not
I
would
not
I
would
go
ahead
and
approve
that
I
would
approve
that
mostly
because
it
still
meets
the
conformance
point
there.
It's
like
the
the
point
of
that
initial
thing
is
to
get
to
of
reaching
Draft.
B
To
begin
with
is
to
have
enough
info
in
there
to
meet
that
the
structures
there
that
also,
probably
the
other
point
here,
is
that
that
Jeff's
can
stay
in
draft
status
for
as
long
as
necessary,
so
and
it's
more
of
a
description
of
the
overall
like
state
of
the
of
the
Jeff
and
not
whether
or
not
people
think
it's
good
or
important
or
their
enthusiasm
about
it.
It's
like
note,
the
design
is
still
changing.
We're
going
to
keep
this
in
draft
state
until
the
design
levels
off.
A
B
This
I,
this
is
a
bit
of
a
like
really
do.
We
need
this,
but
yeah.
It's
important
to
note
that
everyone
can
be
a
contributor.
I've
said
that
before,
but
it's
worth
I
wanted
to
highlight
it.
Anyone
who
helps
right,
implement,
discuss
or
offers
feedback
about
a
Jeff
is
contributing
to
that
and
then-
and
everyone
is
encouraged
to
do
so.
B
If
someone's
looking
at
a
job
and
they're
like
oh
this,
this
I
think
this
should
happen.
You
know
we
should
change
this
design,
they
might
send
a
mail
on
on
the
dev
list
or
they
could
just
submit
a
PR
directly
and
then
have
some
discussion.
There,
I
I'm
a
big
fan
of
go
ahead
and
be
the
change
you
want
to
see
in
the
Jeff
go
ahead
and
make
the
change
you
know,
propose
the
you
know,
submit
PRS
and
and
that's
how
we
move
forward.
That's
how
people
contribute.
B
At
that
point,
the
sponsor
will
and
then
that
that
that
point
is
up
to
the
sponsor
to
sort
of
figure
out
and
keep
an
eye
on
and
decide
and
when
the
sponsor
decides
that
they
will
submit
the
jet
for
review
the
at
that
point.
So
the
reviewer
will
verify
that
the
the
jet
meets
the
criteria
for
acceptance.
This
is
the
completely
different
thing
than
approvals
graph.
B
This
is
the
acceptance
point
which
is
they'll
they'll
verify
that
it
provides
a
and
that
improvement
that
it
represents
the
consensus
of
the
community,
including
documenting
you
know,
dissenting
opinions
and
design
choices
and
how
they
were
made.
The
they'll
make
sure
that
it
clearly
defines
the
scope
of
the
features
so
that
it
doesn't
like
I,
always
just
keep
kind
of
keep
going
and
they
open
open-ended.
B
The
it
needs
to
describe
a
complete
design
and,
as
I
said,
addresses
any
major
questions
and
at
that
point
the
implement
at
this
point
at
the
pointer
to
review.
The
implementation
definitely
needs
to
be
far
enough
along
to
for
the
reviewer
to
look
at
it
and
say
yes,
I
believe
this
ensures
that
the
design
had
all
that
the
major
design
choices
and
decisions
have
been
made
and.
B
That's
just
so
that
we
have
a
single
word
for
talking
about
that,
and
a
reviewer,
though,
can
be
anyone
who
has
a
sufficient
technical
expertise
in
the
area
and
that
understanding
in
the
community.
For
for
someone
to
say
you
know,
when
the
Jeff
has
created
hey,
will
you
be
the
DB
DFL
DFL
delegate?
Will
you
review
this
that
that
can
be
something
that
other
people
nominate
you
for
or
if
you
would
like
to
be
the
the
B
DFL
delegate
for
something
you
can
stand
up
and
volunteer,
but
so.
B
B
The
the
people,
the
contributors
working
on
on
the
that
proposal
will,
you
know,
continue
to
implement
code
or
add
documentation
or
deploy,
or
do
all
the
other
things
that
are
specified
in
the
JEP,
but
there
at
that
point.
We
really
expect
there
to
be
no
further
changes,
at
least
not
major
changes
to
the
job
and
a
chapel
minute
remaining
in
accepted
state
for
as
long
as
the
implementation
continues.
As
long
as
it
isn't
isn't
done,.
B
And
when
it's
finally
done
the
sponsor
will
say:
okay,
we're
done.
Please
set
this
to
final
or
active
in
the
case
of
some
jep's,
when
all
the
implementation
is
complete.
All
the
changes
are
incorporated,
and
you
know
document
documented
some
little
the
JEP
would
come
and
final
some
jep's,
such
as
the
jet
process,
become
active
because
they're
ongoing
processes
that
will
continue
to
use
the
distinction
is
really
just
you
know.
Are
we
done
or
are
we
you?
Are
we
doing
it
right
and
that,
of
course,
that's
that's
forever.
So
we're
done.
B
That's
it
mostly
there's
plenty
of
that
I
haven't
covered
here.
You
know
what
what
what
maintenance
has
to
happen
for
a
JEP
is
how
Jeff's
might
be
superseded
by
newer
Jets
I
didn't
mention
the
three
types
but
I'm
didn't
go
into
a
lot
of
the
details.
There
there's
other
possible
outcomes
for
jets
that
this
is
the
golden
path
that
I
would
apologize
follow,
but
that
isn't
necessarily
the
case.
B
We
mentioned
handling
disputes,
but
we
didn't
go
into
any
of
the
details
of
how
that's
you
know
how
that's
done
and
how
that's
raised
to
the
be
DFL
or
whatever
else
so,
there's
there's
more
details,
there's
a
lot.
The
document
has
considerably
more
detail
than
what
I've
talked
about
here,
but
really
it's
not
that
it's
it's
in
the
best
case,
it's
as
simple
as
this
right.
B
So,
let's
talk
for
a
minute
about
some
examples
of
current
trips.
We
did
that
a
little
bit
earlier,
actually
too,
but
so
JEP
won
the
Jenkins
intense
one
proposal
process
is
currently
active
this
floor,
using
that's
what
I'm
describing
we
have
also
another
process
JEP
that
was
this
JEP
for
it's
a
special
interest
groups.
It
describes
how
we
will
go
about
creating
SIG's
special
interest
groups
for
the
Jenkins
project.
B
Following
of
you
know,
he
went
through
the
process
that
what
was
proposed
and
went
oh
yeah.
This
needs
to
change
this.
So
even
though
that's
still
in
draft
state
we've
started,
I
would
say
testing
that
process
right
so
and,
and
it
continues
to
be
modified
and
updated
right
now.
I
expect
that
relatively
soon
it'll
it'll,
probably
become
active,
all
looks
pretty
thorough.
B
B
B
The
this
was
a
switch
for
our
of
our
remoting
from
a
black
list
to
a
white
list,
and
it
that
affected
hundreds
of
hundreds
of
plugins
and
had
a
several
months
of
rollout,
a
number
of
blog
posts
and
communications
that
had
to
happen
in
order
to
community
to
people.
Hey
we're
making
this
change.
It's
a
breaking
change
and
I'm.
I
was
I'm
really
pleased
with
this.
This
particular
Jeff.
A
Liam
on
that
one,
there
are
even
now,
after,
after
all
the
effort
that
went
into
JEP
two
hundred
they're
still
occasions
where
something
pops
up
that
needs
additional,
so
a
JEP
in
final
does
not
mean
that
all
work
on
that
has
ceased
or
that
everything
is
done
done
and
it'll
never
change
again.
How
does
how
what's
your
sense
there?
How
that,
how
that
works,
I
would.
B
So
so,
if
you
have
version
1.0
and
then
you
have
some
bug
fixes
that
you
that
you
make
that
you
know
if
we
in
the
case
of
this
JEP,
if
we
were
trying
to
wait
until
all
plugins
were
no
longer
affected
at
all,
it
would
never
be
final
right.
We
would
never
be
able
to
be
sure
it
would
just
it
would
be
a
gargantuan
task
as
it
was.
It
was
still
a
very
large
task
and
it
was
more
that
the
the
role
of
that
what
this
is
talking
about
is
the
the
role
out
of
that.
B
So
the
the
change
is
released.
The
it's
in
core
that
implantation
has
finished
has
been
finished
and
all
of
the
rollout
tasks
that
we
had
in
terms
of
making
sure
that
the
major
plugins
were
a
major
plugin
issues
were
addressed.
That
is
that
it.
So
how
do
I
say
this?
It
described
the
scope
of
the
work
the
Jeff
described
that
Jeff
described
the
scope
of
the
work
that
we
would
do
for
that.
That
effort
and
that
scope
of
work
has
been
completed
so
its
final.
B
If
we,
if
there
were
another
like
if
someone
wanted
to
create
another
job
to
say
I,
we
should
fix
all
of
the
the
plugins,
for
example.
That
would
be
another
scope.
We
probably
would
create
another
Jeff.
That
said,
here's
here's,
the
scope
of
that
work
and
that
Jeff
might
never
become
final
or
might
or
might
say
we're.
Gonna
fix
the
next.
You
know
50%
and
scope
your
work
to
that
and
then,
when
that
scope
was
done,
you
would
mark
in
his
final.
B
A
Now
I
see
on
your
list:
for
instance,
Jeff
300
for
Jenkins
essentials
is
accepted.
How
is
that
evolving?
If
the
the
Jeff
has
been
accepted,
because
Jenkins
essentials,
I,
don't
think
has
released
yet
to
the
world?
Are?
Is
it
evolving,
through
additional
jep's
or
through
through
revisions
to
that
that
Jeff
itself
so.
B
Both
Jeff
201
and
Jett
300
are
what
we've
begun
to
call
mission
and
goals
Jeffster,
it's
not
an
actual
type
of
Jeff,
but
we
were
using
it
as
a
because
of
the
size
of
the
things
that
we're
trying
to
do.
We've
we've
found
that,
and
we
haven't
actually
changed
the
jet
process
to
add
a
new
type.
This
is
just
sort
of
where
whatever
shoehorning
in
for
the
moment,
but
both
of
these
trips
are,
though,
that
kind
of
jet
they
they.
What
they
describe
is
the
overall
goal.
B
B
It
has
many
many
moving
parts,
but
let's
say
your
search
up
to
a
1
is
Evelina
Vikash
and
I'm
Nicola
Daniels
right
and
the
essentials
is
the
sponsor,
for
that
is
our
Tyler,
so
the
the
those
each
of
those
those
groups,
but
they
basically
figured
out,
was
like
it's
it's
better
to
have
that.
We've
reached
consensus
on
this
overarching
direction
and
then
and
that
people
can
look
at
that
design
and
say
yeah.
This
looks
like
the
right
way
to
divide
up
this
work
right.
This
is
the
the
overall
that
and
how
we
can.
B
Here's
that
we've
that
we've
sort
of
reached
consensus
on
this
design
overall
looks
right.
This.
This
high-level
design
looks
right.
We
could
we've
also
everyone.
That's
looked
at
as
it
reviewed
it
sort
of
said.
Yes,
this
is
a
good.
This
is
what
we
we
agree,
that
this
is
the
way
to
go,
and
then
individual
parts
can
be
worked.
We
can
work
towards
consensus
on
the
design
of
the
lower
level
design
of
individual
parts
separately.
B
A
You
jesse
has
a
an
interesting
question
on
that
same
line
of
the
200
/
300,
so
the
ending
in
zero
zero
numbering
scheme
for
goal
or
or
big
picture
meta
jep's
we're
not
doing
that
retro
actively.
Do
we
intend
to
continue
doing
that?
So
201
is
really
a
bunch
of
things.
It
will
stay
as
201.
Are
you
in
general,
following
the
goal
process
with
with
the
0
0
endings
I.
B
B
If
not
the
editor
who's
approving
the
submission
will
choose
a
number.
This
was
just
by
convention
for
the
300s.
We
just
knew
that
Jenkins
essentials
was
going
to
be
a
big,
bigger
thing.
Jeff
200
was
the
first
item.
It's
not
actually
emissions
and
goals
so
that
wouldn't
it's
not
really
that
I
also,
that
was
my
choice,
actually
put
it
up
higher,
because
I
figured
there
were
going
to
be
a
number
of
low-level
jep's
like
the
the
special
interest
groups
of
the
the
CVD
number.
B
Do
you
think
that
we
wanted
to
put
sort
of
earlier
lower
numbers
to
indicate
their
I
guess
long
longer
longer
longer
lived
something
I,
it's
as
I
said.
It's
it's
it
is.
The
numbering
is
arbitrary,
so
the
and
the
the
ones
that
you've
seen
here
by
convention
so,
for
example,
Jeff
tool,
one
didn't
start
as
a
mission
in
goal
a
no
as
an
overall.
You
know
high
level
design
document
Jeff.
It
started
as
okay,
here's
the
design
boom,
and
but
there
was
enough
people
found
there
was
enough
moving
parts
that
we
had
to.
B
B
Potential
future
jumps
your
ideas
here.
That's
that's
what
I
wanted
to
say
this
is
this
is
where
I
would
like
to
see
more
happen.
I
mean
I,
know
that
what's
your
Andrew
bears
are
going
to
be
probably
submitting
some
chips
for
changes
to
declarative
pipeline
syntax
and
also
other
new
features
that
are
coming
down
the
pipe
there.
The
the
ocean
team
has
submitted
some
a
couple
of
chips
for
their
extensibility
API,
but
I'm,
assuming
that
they'll
have
other
jep's
for
other
extension
points
or
other
changes
that
they're
going
to
make.
A
B
B
It's
worth
also
taking
it
to
sort
of
read
and
understand
how
consensus
works,
especially
if,
as
sponsors,
it's
important
that
that
we
try
to
build
community
and
build
that
inclusive
and
positive
feeling
from
everyone
and
that
consensus
can
bring.
So
that's
that's
one
more
thing,
I
would
also
say,
and
actually
before
we
go
to
questions
I'm
going
to
take
just
a
minute
to
say.
A
Thanks
Liam
I
think
we've
we've
got
other
questions
and
the
other
the
questions
that
I've
seen
in
IRC
I've
been
interrupting.
You
as
we
go
along
correct,
so
I
don't
feel
at
all
guilty.
I.
Think
we've
done!
Thank
you
very
much
for
presenting
the
Jenkins
enhancement
proposal
to
us
excellent.
This
feels
like
it's
effective
and
looking
forward
to
using
it.
Alright.