►
From YouTube: Pipeline Authoring SIG for 2/21/2020
Description
Meeting notes: https://docs.google.com/document/d/1EhWoBplGl4M8bHz0uuP-iOynPGuONjcz4enQm8sDyUE/edit#
A
Cloudy
hello,
everybody:
this
is
the
Jenkins
pipeline
authoring
sig
meeting
for
February
21st
2020.
This
is
the
u.s.
meeting
and
my
name
is
Mark
E
and
we
are
going
to
get
started
with
this
meeting.
I
usually
try
to
think
of
a
better
way
to
do
that.
Entry
like
something
really
cool
and
I,
want
up
sign
the
stupid
stuff.
I
apologize
for.
A
A
A
A
Also
want
to
say
something
that
I
do
we
do
this
in
another
community
and
I'd
like
to
start
doing
it
here,
and
that's
just
remind
everybody
about
the
code
of
conduct.
The
Jenkins
has
and
really
what
it
amounts
to
is
just
being
nice
to
one
another
and
I
think
we
actually
all
do
that.
So
much
shouldn't
be
a
problem.
A
Alright,
I
have
added
being
the
entry
for
today's
notes,
we'll
go
ahead
and
get
started
with
the
first
discussion
topic
that
I've
added
due
to
overwhelming
demand
for
a
more
EU
friendly
time.
We've
created
a
second
meeting.
This
meeting
will
start
Thursday
the
27th
of
February,
and
that
will
be
at
6
a.m.
PST
I
added
in
a
time,
convertible
there's
anybody
needs
to
convert
their
times
and
largely
I.
Think
that
meaning
format
will
follow
this
meeting
format,
but
I
think
what
we
will
do
is
I
will
feed.
A
Since
that
meeting
starts
our
Thursday
and
ours
is
a
Friday.
I
will
feed
the
following
Friday's
work
items
into
that
meeting
and
then
anything
we
come
out
of
that
I
will
feed
that
into
our
next
day's
meeting.
So
we
kind
of
keep
a
good
flow
in
between
meetings
and
there's
not
a
separate
sort
of
work
streams.
A
B
I'll
summarize
a
little
bit
from
the
from
last
time,
if
I
can
get
this
to
their
account
after
you
left,
there
was
some
discussion.
Why
isn't
she
asking
that
around
this
and
we
we
didn't,
boil
them
down
so
much
as
sort
of
get
to
we
added
one
more
and
the
so
we
have
these.
Basically
that
sorry
I'll
get
my
talking
cap
on.
B
There
may
be
new
ish
depending
and
they
this
is
a
persona
that
I
definitely
see
a
lot
of
and
I
think
is
underserved
in
pipeline
tooling
and
pipeline
documentation,
and
all
these
things
is
someone
who's
who
wants
to
treat
Jenkins
pipeline
as
a
an
environment
that
they
develop.
You
know
they
write
coded,
and
so,
as
you
can
see
here,
they're
they're
coming
at
this
as
hey
where's.
A
B
A
B
Do
we
get
out
of
linking
them
to
the
maturity
model,
because
I
mean
it's
looking
at
this
last
time
and
they
sort
of
the
way
that
we've
lined
them
up?
They
they
sort
of
roughly
appear
in
you
know
the
same
columns
more
slightly.
You
know,
or
with
some
crossover
you
know.
One
to
two
is
is
on
one
side
and
then
this
replica
on
either
side
of
that
column,
sort
of
thing,
yeah,
no.
B
A
Sort
of
just
the
Jenkins
overall
documentation
for
various
parts
and
like
Larry's
part
just
like
like
how
do
I
run
a
paddle
I
start
a
pipeline.
I
am
this
persona?
Where
is
the
documentation
to
guide
me
and
I?
Think
one
of
our
earlier
meetings-
and
this
is
when
mark
mark
light-
was
on
hello
mark
he's
not
here,
but
one
of
our
earlier
meetings.
We
talked
about
the
lack
of
documentation
being
in
authoring
pipeline
and
really
what
we
want
to
think
before.
We
can
start
to
write
any
tooling
around
anything.
A
C
Yeah
I
think
there's
two
separate
concerns
right.
There's
one
concern
that
the
documentation
by
itself
she
could
be
organized,
maybe
a
little
bit
more
intuitively,
to
be
able
to
find
the
different
topics
that
you're
looking
for
and
then
there's
what
we're
talking
about
here,
which
is
I,
don't
know
that
we
need
to
functionally
categorize
the
documentation
according
to
persona.
C
B
D
A
I
see
it
as
a
bridge,
so
when
I
come
in
and
I
know
nothing
about
Jenkins,
it's
nice
to
be
able
to
look
at
a
list
of
four
summers
and
say:
oh
that's
me
and
then
that
maturity
model
links
you
to
where
your
ladder
is
right
to
be
to
be
considered.
Let's
say
an
expert
and
I'm
using
that
term
lightly,
but
to
know
how
to
get
from
one
to
the
other.
You
need
to
know
what
those
others
are
and
that's
where
that
maturity
model
goes
and
that
ties
in
with
the
persona.
A
So,
if
I
could
just
to
give
you
like
the
30,000
foot
view
if
I
come
into
Jenkins
and
I
want
to
do
a
I
need
to
know
what
a
is
or
where
I
fit
in
a
so,
you
look
at
the
personas
and
you
say:
oh
I'm,
a
new
I'm,
a
newbie
and
then
okay,
I'm
gonna,
go
and
all
this
documentation
is
now
shows
what
newbies
should
be
looking
at.
And
then
you
see
once
you've
got
this.
A
C
I
think
that
there's
there's
a
good
idea
of
having
like
a
what's
next
section,
but
the
phrase
maturity
model
I
feel
like
that
could
run
rub
someone
the
wrong
way,
because
not
every
Jenkins
user
is
going
to
need
to
be
an
expert.
So
it'd
be
interesting.
If,
under
the
persona,
there
was
a
like
things
to
look
at
next
and
then
figuring
out
how
we
can
have
some
criteria
for
when
you
actually
need
to
go
to
that
next
level
of
maturity.
Right.
C
If
someone
starts
out
learning
Jenkins,
they
need
to
write
a
pipeline
for
like
one
application,
one
team,
the
documentation
or
tips
that
we're
describing
in
our
power
user
expert
documentation.
It's
probably
way
more
than
they
need
right
so
being
able
to
quantify
how
to
avoid
premature
optimization
and
at
what
of
scale,
do
you
need
to
start
being
concerned
about
things
like
shared
libraries
or
what
have
you
that
make
sense.
A
Guess
fell
over
the
best
phrase
to
use,
and
so,
if
somebody's
saying
I
need
to
understand
how
to
write
a
shared
library
and
then
I
could
say:
okay,
here's
what
we,
how
we
do
it,
here's
sort
of
our
map-
and
you
fall
in
here
and
then
because
you
fall
in
here.
This
is
the
maturity
model.
Here's
the
links
to
the
documentation,
they'll
read
that
and
if
you
still
find
your
step
come
back
to
us
tonight,
does
that
make
sense.
I
know
it
sounds
off
pudding
by
saying:
go,
read
something
in
them.
A
B
I'm
open
to
I
mean
I,
guess
what
you're,
what
I'm
taking
from
what
you're
saying
is
that
this
is
a
another
pathway
through
the
another
way
to
find
what
kind
of
documentation
you'd
be
looking
for,
like
so
they're
on
one
end,
you
have
the
personas
and
then
another
when
you
have
a
maturity
model
and
they're
both
ways
of
people
finding
their
way
to
the
kind
of
documentation
that
they
need.
Yes,.
A
B
A
C
I'm,
just
going
to
say
that,
like
being
able
to
ask
the
question
I
want
to
learn
about
shared
libraries
has
an
inherent
assumption
that
the
person
already
knows
that
shared
libraries
are
a
thing
right.
It
might
interesting
to
talk
about
it
from
a
use-cases
perspective
like
I,
want
to
be
able
to
share
code
between
pipelines,
right
and
then
personas
and
use
cases
are
going
to
be
pretty
similar
in
their
goals
right.
C
It's
different
people
are
gonna,
have
different
scenarios
that
they're
trying
to
solve,
for
if
we
can
organize
the
documentation
around,
like
those
use
cases
that
the
personas
might
run
into,
because
it's
sort
of
like
if
you're
a
junior
software
engineer,
the
problem
is
not
that
you
can't
learn
it.
So
you
don't
know
what
words
to
Google
to
find
the
resources
that
you're
looking
for.
So
how
can
we
elevate
these
topics
without
people
having
to
know
that
they
already
exist?
C
C
D
One
of
those
XYZ
problems
where
you
have
the
problem
X
but
you're,
asking
how
do
I
solve
y,
but
people
don't
know
that
your
original
problem
is
X
and
in
in
this
case,
X
is
the
use
case
scenarios
we
can
kind
of
show
and
the
Y
might
be.
When
someone
comes
in
and
says
hey
how
do
I,
you
know
how
do
I
do
this
thing.
D
That
sounds
like
a
bad
idea,
but
you
know
it's
like
hold
on
step
back
a
second
and
see
where
you're
coming
from
and
figuring
out,
art
like
you're
saying,
are
you
asking
the
right
questions
or
even
looking
in
the
right
area,
without
knowing
based
on
your
own
maturity
level
here
of
the
product?
I
will.
A
A
A
B
A
C
Yeah
I
think
if
we
come
up
with
some
of
the
questions
that
these
different
people
are
going
to
ask
that
can't
expose
either
documentation
updates.
That
could
happen
to
make
finding
those
resources
more
readily
available
or
it
can
introduce
like
future
ideas,
and
maybe
we
need
to
think
about
so
that
this
problem
isn't
introduced
in
the
first
place
right.
A
C
C
C
Think
it'd
be
interesting
to
to
figure
out
the
types
of
questions
we
think
these
people
are
going
to
be
asking
and
then
use
those
questions
to
guide
our
decisions
around
whether
it's
a
documentation
problem
or
whether
it's
a
opportunity
to
improve
the
developer.
Experience
of
writing
pipeline
I
think.
A
A
C
So
maybe
I
always
start
to
get
into
like
the
stickier
side
of
things
which
is.
Does
the
community
have
a
preferred
way
to
do
this
locally?
Is
our
preferred
option,
you
say
docker
run
Jenkins,
do
some
port
forwarding
and
have
your
local
jenkins
and
since
or
are
we
recommending
that
people
do
Java
jar
or
Java
and
Sutton?
You
know,
I
have.
C
B
A
C
B
A
C
A
Trying
to
think
of
maybe
a
good
way,
CMN
I
think
another
problem
that
we
face,
and
this
is
a
problem
like
what
I'm
saying
about
you
know:
let's
get
a
persona
out
there
and
start
seeing
how
it
works.
I
think
one
of
the
problems
in
doing
that
is
then
we
run
into
a
rabbit,
hole
right.
We're
gonna
start
going
off
for
this
one
persona
and
it's
you
know
a
that-
could
go
on
forever.
C
Yeah
I
think
that's.
The
most
important
thing
we
can
do
is
try
to
capture
these
action
items
and
display
them
publicly
right
if
everything
we
come
up
with
in
this
meeting
is
going
to
be
reliant
upon.
The
people
that
join
the
meeting
to
implement
I
think
it's
going
to
take
a
very
long
time,
but
if
we
can
find
a
way
to
elevate
this
and
label
things
like
good
for
newcomers,
so
right
doc,
sir
just
try
to
expose
our
backlog
to
the
wider
community
and
see
where
we
can
get
help.
Yeah.
C
A
D
A
Yeah
one
of
the
things
I
I'm,
really
worried
about
I'll,
be
very
upfront
and
with
this
putting
out
a
call
for
help
and
and
doing
that
there
are
a
cluster
of
people
that
just
expect
us
to
do
everything
they
don't
want
to
contribute.
They
expect
you
know
trying
to
think
of
the
right
way
to
say
this
without
some
super
negative,
they
will
complain
about
everything,
but
they
will
do
nothing
to
fix
them.
Well,
that's
gonna,
be.
B
So
what
you
can
do,
I,
don't
I
mean
I.
Guess
it's!
It's
I
agree!
It's
a
good
idea
to
be
upfront
and
address
that,
but
I'd
rather
not
assume
that
focus
nor
assume
it
right.
The
it's!
It's
a
numbers
game
there.
There
will
be
people
that
will
contribute
and
you
have
to
I
think
we
just
have
to
sort
of
go.
Okay,
here's
what
it
needs
to
happen
and
we
overtime
either
either
it
will
be
some
of
the
gains
traction
with
people
and
they'll
be
interested
in
doing
it
or
they
won't
yeah.
A
So
maybe
what
we
can
do
is
just
get
an
email
out
to
the
dev
mailing
list
and
our
cig
mailing
list
saying
what
we've
done
for
this
month
or
it
thus
far,
but
maybe
we
get
like
and
we
make
that
a
monthly
cadence
where
we
send
out
an
email
and
say
what
we're
working
on.
And
then
somebody
may
read
that
and
say:
oh
I'd
like
to
go.
C
B
A
So
I
can
tell
you
one
of
the
things
that
is
on
the
roadmap
for
this
year,
for
the
advocacy
sig
is
getting
a,
maybe
it's
a
monthly,
but
we
meet
bi-weekly
and
we're
thinking
of
doing
a
monthly
cadence
where
every
sig
has
to
come
and
report
sort
of
the
State
of
the
Union.
If
you
owe
me,
maybe
it's
using
that
as
an
example
on
this
politically
charged
climate
is
not
a
good
thing,
but
I
think
you
get.
What
I
did
like
that?
Oh
I.
D
See
it
soon
enough,
it'll
be
modeled.
Similarly
to
larger
things,
I
mean
I'd.
Imagine
this
might
have
been
a
useful
case
for
having
a
Jenkins
board.
Where
you
know
the
SIG's
could
all
make
reports
to
the
board
and
a
board
keeping
track
I'll,
be
it
kind
of
rebroadcasting
out
to
have
all
the
other
SIG's.
What's
going
on
between
the
SIG's
kind
of
like
a
summary
report,
yeah.
A
In
another
another
community,
that
I
mean
we
have
a
monthly
meeting
that
at
various
times
of
the
month
and
I,
think
it's
each
month.
They
do
it
for
individual
SIG's
are
randomly
chosen
to
come
and
they
have
to
give
updates
with
that
meeting
and
if
they
like,
can't
make
it
I
think
they
get
like
two
passes
and
then
on
the
third
pass.
They
have
to
go
meet
with
the
with
the
steering
committee
and
tell
the
steering
committee
why
they
aren't
making
it.
A
So
maybe
so
I'll
bring
that
to
see
where
we're
at
with
that
in
the
advocacy,
sig
I
think
we
have
a
meeting
next
week
and
but
what
do
we?
How
do
we
want?
What
do
we
think
we
can
accomplish
between
now
and
the
next
meeting?
Would
it
make
sense
to
get
an
email
out
to
both
mailing
list
sort
of
seeing
what
we're
working
on.
B
B
A
Say
we're
working
on
personas,
because
what
I
really
want
to
make
sure
we're
doing
is
we're
being
as
transparent.
As
can
everybody
can
come
to
this
meeting?
We
pretty
much
blast
out
when
the
meeting
is
done
and
where
the
recording
is,
but
nobody
I
think
I
want
to
say
nobody,
some,
don't
they
don't
use
that
type
of
channel.
So
maybe
we
have
to
also
add
the
emails
monthly
to
say
what
we're
doing.
D
Box,
it
makes
sense,
I
think
that
makes
sense.
I
mean
the
that
especially
made
sense
made
sense
up
until
yeah
until
you're,
adding
the
the
European
friendly
time
for
not
for
asynchronous
viewing,
because
I
I
know
myself,
I,
typically
don't
like
to
watch
videos
of
meetings,
but
I'll
definitely
read
through
the
notes
or
things
like
that.
D
Alright,
you
know
when
it
when
it's
things
that
are
outside
my
time
zone
or
something
you
know,
especially
so
III
I
think
it
would
definitely
be
useful,
especially
for
people
who
who
might
not
have
known
what
it
is
exactly
this
sig
was
about.
You
know
no,
because
I'm
sure
there'll
be
some
people
who
have
opinions
and
want
to
help
contribute.
They
just
had
no
idea
it
was
going
on,
you
know,
could
be
time
constraints
or
they
just
were
messing
with
email
too.
So.
A
A
B
D
C
A
Emea
meeting
I
will.
This
is
the
stuff
that
I'm
gonna
talk
about
so
I'm
going
to
basically
fill
that
meaning
with
the
notes
we
have
from
here
and
then
anything
that
comes
out
of
that
I
will
fill
that
into
our
following
engagements:
cool,
okay.
Well,
let
me
gives
us
action
items
and
get
them
something
to
work
on
for
the
next
week.