►
From YouTube: Pipeline-Authoring SIG US Meeting for February 24, 2020
Description
Pipeline-Authoring SIG US Meeting for February 24, 2020
Agenda:
- Continued discussion regarding personas
- Next steps for matching personas with a maturity model
A
All
righty
welcome
everybody.
It
is
February
14th
2020.
This
is
the
pipeline
authoring
authoring,
sig
meeting.
This
is
our
regular
us
meeting.
My
name
is
Marky.
I
am
one
of
the
leads
for
the
sig
I
welcome
everybody
I
usually
like
to
just
say
one
of
the
things
is
be
nice
to
everybody.
Don't
don't
be
rude
to
one
another.
Yeah
I
don't
want
to
have
to
breed
anymore.
So
with
that
welcome
and
we
are
going
to
get
started.
I
have
linked.
I
have
linked
liam's
linked
in
the
chat,
the
documents
for
meetings.
A
B
A
What
what
I
mean
by
big
some
experiences,
for
example,
when
you
have
a
developer
that
comes
on
and
they
may
have
beginning
to
intermediate
level-
let's
say
Java
experience,
okay,
where,
as
opposed
to
there,
may
be
lots
of
experience
where
someone
is
like
you
know,
I
would
say
someone
like
you
know
that
knows
it
in
depth.
You
know
it
can
walk
the
codebase
fairly
easy.
A
B
B
3
by
4,
and
so
we
started,
we
were
like
okay,
I'm,
not
sure
what
we
can
do,
that
we
wanted
to
add
kind
of.
We
started
going
sort
of
a
different
direction
with
them.
Just
sort
of
tell
more
stories
tells
sort
of
a
more
focus
like
who
are
the
like
sort
of
a
big
bucket,
rather
than
these
were
smaller,
more
targeted
buckets
like
okay,
let's
try
and
what
are
the
kind
of
the
big
buckets
that
we
deal
with,
and
we
had
gotten
to
basically
like
four
so
far
and
the.
B
B
Yeah
there
we
go.
Thank
you.
So
the
and
I
think
this.
This
is
a
the
the
bridge
that
you're
talking
about
would
come
somewhere
in
here.
I
think
that
there
was
we
were
talking.
I
was
thinking.
There
needs
to
be
probably
one
more
persona
to
somewhere
in
here
between
either
between
David
and
Lisa
and
between
or
between
Erika
and
David,
just
to
kind
of
fill
in
that
gap,
because
there's
sort
of
a
combination
of
who
who
someone
is
and
what
their
role
is,
and
what
kind
of
team
they're
on
right.
A
B
A
D
I
have
a
question
then,
on
distinct,
distinguishing
personas
here.
Is
there
any
use
here
on
distinguishing
between
like
a
developer,
developer
team
member,
who
is
like
maybe
more
of
a
DevOps
side
where
versus
like
an
SRE
which
might
be
more
operational,
focused
on
a
dev
up
side
of
things
or
maybe
like
even
like
a
release,
release
or
productivity
type
team,
as
maybe
an
in-between,
or
would
that
spectrum
cover
or
like
like
us?
Essentially
these
types
of
personas?
That's
that.
B
D
Potentially
there
is
the
maybe
like
a
QA
side
of
things
where
you're
generally,
like
automating
tasks,
that
you
need
that
you're
trying
to
run
for
continuous
integration,
types
of
things
or
continuous
testing
or
things
like
that,
and
then
a
more
ops,
esre
side
of
things
where
you,
maybe
you
run
it.
You
know
you're
automating,
various
infrastructural
tasks
or
deployment
things
or
whatnot.
So
it's
kind
of
like
the
spectrum
of
dev
ops
dev
to
ops.
Does
that
make
sense,
yeah.
A
D
And
and
I
guess
to
add
to
that
a
little
bit
I've
noticed
like
especially
with
larger
companies
that
would
get
more
like
involved
in
DevOps,
and
things
would
tend
to
make
a
distinction
between,
like
the
automation
team
versus
the
the
developer
tools,
type
of
team,
even
though,
or
like
the
deployments
versus
the
interest
like
the
automate.
Basically,
various
automation,
things
would
be
kind
of
they'd
get
a
little
more
specialized
than
just
a
generic
DevOps
team.
Okay,.
B
So
I'll
I'll
cover
where
we
got
to
in
this
Marc
brought
up
utilitarian,
and
this
is
generally
the
silent
majority
I.
Think
of
those,
as
generally
those
are
the
ops
people,
those
of
the
one
that
look
I'm,
just
getting
stuff
done,
I'm
I'm,
not
as
written
getting
involved
in
the
community
I'm,
just
so
I
want
to
let's
I
would
say
this
is
the
generally
the
ops
person
right
yeah
that
makes
offs
end
of
the
spectrum.
So
what
are
you
talking
about?
What
are
you
looking
at?
B
That
is
not
being
covered
in
either
this
or
this
other
case?
Where
sort
of
this
is
sort
of
the
not
ops
person
when
some
there's
the
when
there
was
someone
on
the
team
who
got
Jenkins
going
for
for
the
team
and
started
using
it
and
the
team
has
value-
and
this
is
like
us-
these
are
sort
of
a
weird
like
space
to
be
in
right,
where
it's
like.
Okay,
that
person
left
and
now
we've
handed
this
to
somebody
else
and
they're
trying
to
you
know,
wrap
their
head
around
it
alright.
So
this
is
the
oh.
D
D
D
So
in
the
beginning,
utilitarian
could
be
even
for
just
continuous
integration
purposes
like
for
or
just
general.
Like
you
know,
your
general
automation
tasks,
any
anything
that
you
you
would
you
could
potentially
do
in
cron.
You
know,
Jenkins
is
great
for
that
type
of
thing
and
that's
right
problem.
You
know,
that's
your
typical
seems
to
be
a
utilitarian
view
of
Jenkins.
Typically,
like
I
need
a
thing
that
runs
stuff
right.
B
B
B
He
would
definitely
be
one
of
the
zones
that
we
want
to
reach
and
I
sort
of
like
was
pushing
down
on
it
a
little
bit
because
he's
Steven
is
basically
ends
up
in
the
long
term
project
contributors
bucket,
but
that's
partly
because,
but
he
before
he
became
like
a
actual
contributor.
He
was
doing
things
like
you
know,
looking
at
writing
the
templating
engine
for
for
for
his
Jenkins
team.
B
C
C
A
I
think
that
could
really
be
David.
I,
don't
think
David
has
to
be
a
DevOps
team.
Member
I
think
he
got
a
portion
of
it
when
I
went
David
it
could
be.
David
could
also
be
a
developer
that
says:
okay,
we
have
Jenkins
I'm
going
to
now.
You
know
build
something
on
top
of
it
or
some
automation
to
interface
with
it,
but
it
could
just
be
an
individual
contributor
developer.
That's
been
tasked
with
doing
that.
B
C
A
So
David
has
he's
he's
he's
felt
the
pain
he's
gone
to
the
community
to
ask
questions,
he's
seen
a
deficiency
and
he
figured
that
there's
a
way
I
can
make
I
can
plug
that
hole
and
by
plugging
that
hole.
I
built
this
and
David
being
Steven
built
the
templating
engine
right
and
there
was
the
bridge
for
him
to
become
a
long-term
contributor.
A
B
B
Because
what
you're
looking
for
there
is
someone
who
is
not
a
Jenkins
expert,
but
what
but
it's
like
hey
my
my
our
group.
We
have
a
group
that
does
Jenkins
and
they've.
Given
me
these
tools,
but
there's
this
like
how
do
I
write
the
pipeline
or
how
do
I
do
that?
Do
I
have
to
go
and
ask
them
all
the
time
or
is
there
a
community
or-
and
you
know,
dev
tools
like
a
an
IDE
so
like
I,
expect
there's
a
there's
a
persona
right
here.
B
B
E
A
A
Interest,
so
one
of
the
things
I
will
say
is
what
we
have
here
is
very,
very,
very
good,
very
detailed,
I.
Think
if
we
and
I'm
going
to
throw
this
out
as
an
idea
to
be
seen,
I
think
if
we
took
these
personas
match
them
to
the
maturity
model
and
if
we
were
to
take
the
maturity
model
and
start
linking
the
majority
model
to
current
documentation
and
that's
not
something
we're.
Obviously
gonna
do
in
one
meeting
cycle
or
even
five
meeting
cycles,
but
I
think
it
would
be
good
to
start
helping
us
to
decide.
A
As
we
have
the
personas.
We
have
the
maturity
model.
Where
does
it
fit
there
and
where
is
the
documentation?
Currently,
that
shows
how
that
matches
and
I
think
we
could
that's
where
we
start
to
really
define
the
pipeline
sig,
because
we
see
where
the
deficiencies
are
in
current
documentation
and
then
we
start
going
through
the
documentation.
A
You
say:
oh
man,
we
really
need
this
or
we
really
need
that,
and
then
we
could
interface
with
the
doc
sig
to
say
what
we
need,
and
we
start
this
sort
of
cross
seed
collaboration
and
that
will
help
future
wise
in
the
future.
That
would
really
help
us
to
start
to
then
find
out
what
we're
lacking
from
pipeline
authoring
standpoint.
B
A
Yeah
I
think
if
we
had
maybe
a
task
and
I'm
willing
to
with
the
one
minute
I
have
left,
take
that
task
from
now
to
the
next
meeting.
To
start
to
go
through
to
make
this
mapping
so
I
can
create
a
new
document
that
refers
to
maybe
some
anchor
in
the
previous
document,
and
we
could
start
to
see
the
sort
of
lineage
between
all
of
these
things.
Okay,.
B
B
E
C
B
B
B
B
Yeah
they're,
not
the
the
title,
isn't
quite
right.
Cuz
this
is,
is
the
developer
on
team
that
manages
like
multiple
Jenkins's
and
does
all
the
tooling
and
stuff
for
people,
and
this
is
the
consumer
of
that
that
person's
work
or
someone
that
is
one
into
tree.
Jenkins
I
want
to
use
Jenkins
like
I
use
any
other.
You
know
development
tool
right.
Oh.
D
Well,
I
guess,
from
a
pop
from
from
a
sort
of
power
user
perspective
you
could
have
like
both
the
the
power
user,
who
is,
you
know,
is
essentially
administering
Jenkins
and
trying
to
get
people
to
use
it
appropriately
versus
the
power
users
who
are
trying
to
use
Jenkins
for
very
advanced
scenarios.
You
know,
like
maybe
you
know
the
people
who
are
using
it
or
full-on
CI,
CD
type
things
like
where
you
you
could
use
Jenkins
with
git,
ops
or
things
like
that.
D
You
know
that
would
be
like
super
power
user
trying
to
find
best
practices
for
how
should
I
use
Jenkins
and
you
know
advanced
scenarios
or
like
modern
scenarios
or
best
practices.
Type
of
thing,
without
necessarily
being
like
I,
want
to
be
the
person
in
charge
of
running
Jenkins
and
actually
the
whole
and
maintaining
the
system
type
of
thing,
whereas
maybe
the
DevOps
team
member
cares
more
about
the
actual
build
system
itself
to
essentially.
D
Sorry
so,
which
shows
which
side
here
I'm
your
so
that
the
longer
thing
I
was
saying
would
be
the
Olivia
part
the
outside,
whereas
the
where's,
the
person,
that
being
the
person
more
interested,
perhaps
like
in
the
continuous
delivery
or
deployment
type
of
things
using
git
ops.
You
know
or
basically
trying
to
know
the
best
practices
of
using
of
using
Jenkins
and
pipelines
to
automate
the
various
things
that
trying
to
do.
Okay,
whereas
the
DevOps
team
member
might
care
more
about
the
actual
arc
like
care
more
about
how
Jenkins
is
used
right,
hey.
D
D
You
know
they
might
care
more
about
the
Jenkins
specific
stuff
like
mention
there,
with,
like
shared
libraries,
are
trying
to
you
figure
out
the
proper
architecture
of
setting
up
their
agents.
You
know,
and
all
that
sort
of
thing,
whereas
the
outside
developer
might
care
more
about.
Like
the
you
know,
the
big
picture,
type
of
thing
in
a
CI
CD
type
context,
maybe
or
that
yeah.
D
B
Think
Olivia.
That's
the
the
the
people
that
I
talk
to
them.
This
is
what
this
is.
The
kind
of
questions
that
I
get
the
most
from
people
to
look
but
they're.
Like
look
I'm
a
dev
where's,
my
dad,
my
dad
where's,
my
debugger
where's,
my
testing
testing
frameworks.
Where's,
my
you
know.
Whatever
these
all
these
things
they
sort
of
expect
to
be
there
for
what
we'd
call
them
mature
product
right.
Well,.
E
B
C
B
C
B
Words
exactly
and
Erica
doesn't
expect
there
to
be
anything
so
they're
they're
not
disappointed
they're
like
oh
whatever
it
is.
It
is
I'll
accept
what
you
give
me
and
work
with
it
right,
and
it's
really
this
person
that's
coming
in
where
they're
like
okay
I'm
ready
to
do
this,
wait
what
so
talking
about
how
this
maps
to
the
maturity
model?
B
B
B
Of
course
now
my
there,
it
is
computers
are
awesome.
Okay!
Is
that
the
right
one?
No,
that
it's
not
the
right
one!
The
link
is
this
garbage,
so
that's
not
going
to
help.
That's
the
sharing!
That's
not
what
I
needed
come
here,
wait!
Okay,
and
do
it
this
way,
or
maybe
that
is
the
right
one.
Yeah
looks
like
this:
okay.
B
B
The
David
persona
would
be
somewhere
in
the
defined
to
quantity,
managed
kind
of
end
of
things,
maybe
into
optimized
depending
on,
but
this
is
talking
about
the
teams
that
they're
on
and
I
don't
know
I
mean
you
guys
have
some
experience
with
dude
I
I.
Don't
know
that
the
except
for
maybe
David
that
there's
a
one
area
right
for
the
for
each
of
these
personas
one
kind
of
team
or
one
environment
that
they
exist
in.
B
B
Utilitarian
can
actually
sort
of
exist
anywhere
along
in
here
because
they're
there,
although
I
guess
they're
more
sort
of
in
the
mid
to
low
end,
because
again,
if
you're,
once
you
get
up
to
the
other
end,
you
eight
other
in
the
spectrum,
people
stop
being
just
throw
it
together
or
slapdash
and
being
more.
You
know,
engineering
excellence
kind
of
minded,
so
yeah
I
mean
it
probably
actually
blindside
lines
up
somewhere
in
the
overlapping
in
directly
thoughts.
E
B
E
A
A
C
E
By
late
comer
I
mean
this
meeting
is
the
first
time
I've
ever
seen
any
of
this
stuff
right.
What
are
we?
What
to
what
end
are
we
defining
these
personas
is
this,
for?
Is
this
for
organizing
our
documentation
in
a
better
way?
Is
this
just
for
sort
of
getting
our
head
around
where
we
take
pipeline
in
the
next
year,
like
what
some
and,
if
you
don't
want
to
do
that
here,
if
you
want
to
do
that,
I'll
find
Liam,
that's
cool
too,
but
just
to
sort
of
know.
That
should
what
that's
context.
B
B
Then
we
could
that
what
we
thought
that
would
help
us
focus
on
what
what
it
is
that
we
actually
want
to
because
we've
we
started
off
talking
quite
a
bit
of
a
bunch
of
different
pain
points
and
what
works
and
what
doesn't
and
things
that
we
could
try
and
it's
like.
Okay,
we
there's
lots
and
lots
of
things,
but
we
don't
know
yet
so.
B
And
so
like
the,
for
example,
Stephen
was
talking
about
teaching.
You
know
mediums
to
show
people
how
to
use
pipeline
better
if
things
like
Kokoda
or
better
documentation
or
do
we
need
better
ID
tools
or
in
that
this,
it's
really
just
a
question
of
where
do
we
focus
our
energy
next
or
where
is
the
the
best
in
making
the
the
syntax
better
or
is
it
hey?
Let's,
let's
have
an
option
to
use
yamo
instead,
if
that's
what
people
want
to
use
and
what
does
that
look
like?
B
So
this
is
what
I
this
is
we
sort
of
started
our
first
meeting
going?
Oh
my
god,
there's
so
much
so
many
different
ways
we
could
go
and
tried,
and
so
the
the
personas
that
we're
talking
about
here
are
trying
to
bring
that
bring
some
focus
to
that
and
looking
at
what
we
can
do
you
know,
how
can
we
serve
each
of
these
best
with
next
steps.
B
B
B
In
the
u.s.
he's
been
to
a
couple
of
Jenkins,
I
think
he's
in
the
US
pretty
sure
and
he's
been
to
a
couple
of
Jenkins
worlds
and
a
serious
pipeline
user
he's
been
on
a
bunch
of
the
the
the
SIG's
and
doing
work
around
Jenkins
as
far
as
I
know.
So
anything
he's
also
done
some
work
on
some
of
the
plugins,
so
yeah.
So.
B
E
E
E
B
Yeah,
what
you're
talking
about
is
so
far
most
of
the
people
in
the
group
are
either
David
or
Lisa,
that,
were
you,
know,
long-term
contributors
or
otherwise
doing
things
that
are
building
on
top
of
Jenkins
and
that
would
still
include
also
Matt
and
Devin,
and
you
Carl.
So
there's
some
need
here
to
get
a
wider
set
of
perspectives,
and
we
were
also
talking
about.
Can
we
do
a
thinking
about
doing
some
sort
of
survey
getting
getting
people
to
sort
of
give
some
feedback?
B
B
Definitely
I
mean
personally
I.
Definitely
I
think
this
is
I,
think
the
Olivia
for
me,
anyways
did
now
that
we're
talking
now
that
we
actually
created
this
and
that's
where
I
want
that's.
What
I
would
want
to
focus
right,
the
the
people
that,
because,
for
me,
anyways
these
are
the
people
that
are
he
either
either
one
of
these
two
other
people
that
are
most
likely
to
become
long-term
contributors
and
power
users
that
I've
been
going
to
ask
us
to.
You
know,
be
interested
in
in
doing
the.
B
B
B
B
The
the
that
difficulty
is
that
this
is
also
at
some
of
the
hardest
stuff,
given
the
the
framework,
oh
so
that
we
have
right,
I
know:
Devin
you're,
you
have
I
would
say
the
the
most
technical
experience
in
this
in
this
realm,
all
I
can
go,
is
sort
of
hand-wavy.
Like
that's
a
lot
of
work
in
there
you
mean,
like
debugger,
was
or
any
of
these
things
like
what
in
understanding
what
the
level
of
effort
would
be
to
do.
Something
like
this
right,
I
think.
C
Some
of
these
things
like
I,
guess
it's
like
reusing
external
libraries.
It's
like
pulling
a
separate
groovy
library
and
use
that,
like
they're
I
would
say
like
we
don't
want
you
to
do
that.
We
should
right
discourage
that,
like
some
level
of
IDE
integration,
I
think
is
certainly
possible,
especially
syntax
wise,
not
necessarily
like
super
problematic.
It's
more
like
you
know,
and
we
actually
successfully
maintained
like
a
vs
code
plugin
and
keep
it
up-to-date
and
useful.
C
It's
kind
of
feel
like,
though
the
bigger
question,
they're
debugging,
testing
I,
think
are
like
the
the
real,
more
complicated
bits.
I
know,
there's
a
lot
of
approaches
to
like
do
static,
testing
of
pipelines
and
shared
libraries,
there's
different
approaches
and
people
like
some
of
them.
Some
people
don't
like
them.
C
Debugging
would
be
nice
to
have,
but
cuz
like
technically
a
huge
hurdle,
probably
unrealistic
to
ever
happen,
or
at
least
like.
Maybe
we
could
give
you
a
debugger,
but
I,
don't
think
we
could
give
you
a
debugger
that
stepped
through
your
pipeline
in
a
way
that
was
useful.
We
could
maybe
give
you
a
debugger
that
step
through
this
synthetic
generated,
groovy
code,
which
would
be
completely
useless
right.
B
C
Like
you
could
have
something
that
steps
through
and
like
before
a
step
executes
like
wait
since
it
sounds
like
oh
the
steps
about
to
execute,
but
I
mean
like
what
information
would
you
want
to
see
when
that
happens
right?
Would
that
be
useful?
We
could
do
it,
I
mean
you
would
have
to
run
like
inside
of
Jenkins.
D
C
That
I
think
is
where
it
becomes
quickly
unfeasible
like
I.
Think
if
you
want
to
do
only
things
that
look
at
the
the
pipeline
in
terms
of
like
steps
and
flow
nodes
straight
forward
and
it's
possible.
If
you
also
want
to
interact
with
the
groovy
code,
I
think
it
becomes
significantly
more
complex
and.
C
Yeah
I
mean
really
I
would
say
for
all
of
these
we're
like
when
you
start
asking
these
questions.
I
would
say
you
probably
want
to
look
at
creating
an
external
like
command-line
tool
that
your
pipelines
use
written
in
whatever
language
you
want.
That
can
be
debugged
totally
independently
from
jenkins
and
use
any
kind
of
libraries
whatever
you
know
you
package
that
together
and
that
Jenkins
just
calls
your
command-line
tool
for
Michelle
step,
and
so
you
keep
your
your
jenkins
file
as
simple
as
possible.
Anything
that's
interesting
logic
is
in
that
command-line
tool.
C
Like
I
mean
it,
obviously
it's
a
fine
line
right,
because
you
want
people
to
be
able
to
understand
what
their
my
plan
is.
Gonna
do
and
stuff,
but
pipeline.
It's
not
really
intended
to
be
like
a
application
platform
that
you're
writing
sophisticated,
like
programs
against
that
to
where
you
would
want
a
debugger
right.
B
Why
are
people
in
this
this
spot
right
here
right?
Where
they're
like
I,
have
to
do
this
really
complex?
Then
we
could.
We
could
like
IDE
integration
for
a
while
you're
like
right
and
declarative
or
hey
what
steps
can
I
use?
That
would
be
really
helpful
for
these
people,
but
then,
when
we
get
into,
let's
just
reorder
the
users
for
a
second,
so
they're
gonna
like
ID
integration,
is
you
know
it's
a
little
bit
of
work?
C
I
mean
I
think
so,
but
it's
like
maybe
mixed
messaging
and
grand
hopes
in
the
past
of
what
these
things
could
become
and
what
how
robust
they
would
be
eventually
that
kind
of
never
materialized
right.
So,
like
this
user,
we
have
documentation
on
shared
libraries,
but
I,
don't
think
we
really
explicitly
say
like
hey.
This
should
be
for
pretty
simple
stuff.
If
you're,
you
know,
writing
like
you're
trying
to
create
like
a
arbitrary
class
or
doing
kind
of
sub
classing
or
extensive
object
models,
you're
probably
doing
too
much.
C
You
should
do
something
else,
but
it's
possible
so
people
do
it
right,
like
yeah
like
I,
would
imagine
like.
The
intention
was
more
that
your
shared
libraries
would
be
like.
Oh
here's,
a
chunk
of
like
what
would
amount
to
a
declarative
pipeline
stage
or
something
right.
You
can
go
ahead
and
call
that
if
you
want
that
was
probably
more
of
like
the
idea
of
what
people
would
do,
but
that's
not
what
people
do.
C
And
I
mean
I
think
really.
What
we
would
like
to
do
is
give
people
some
feature.
That
makes
it
very
clear
that
it
is
not
just
Ruby
or
Java
code,
and
you
shouldn't
use
it
that
way,
and
you
should
have
wanted
you
bugger,
because
I
shouldn't,
even
they
shouldn't,
even
be
something
that
should
be
useful
with
the
future.
We
give
you.
B
C
B
C
What
I
see
it
like
a
lot
of
times?
Shared
libraries
are
used
specifically
because
they
can
be
run
outside
of
the
sandbox
and
access
like
Jake,
its
internals,
for
like
some
random
thing,
this
company
wants
to
do
with
like
agents
or
something
like
that
right.
So
it's
like
I
wouldn't
say
that
everybody
does
use
it
like
really
extensively
for
that.
But
it's
a
lot
of
people
use.
It
have
at
least
like
one
or
two
things
in
their
shared
library.
That
would
not
work
and
I'm
all
aware,
shared
libraries
and
not
an
agent.
B
Anyways
sorry,
this.
That
was
a
bit
of
a
range
into
this,
but
it's
worth
talking
about
so
we're
actually
almost
a
time
and
Mark
he
hasn't
made
it
back,
so
I
think
we'll
probably
go
ahead
and
call
us
from
now.
So
the
for
next
time
mark
he's
talking
about
mapping
these
together
a
bit
more
and
making
that
choice,
and
hopefully
he'll
take
a
look
at
what
we've.
What
we
discussed
there
on
the
video
and
then
I
think
we'll
continue
well
how
what
the
this
question
is
like?