►
From YouTube: Jenkins Pipeline-Authoring SIG Meeting for 20200501
Description
Jenkins Pipeline-Authoring SIG Meeting for 20200501
A
A
We
are
recording
this
meeting
and
if
you
don't
really
recorded,
please
drop
also
a
reminder
that
this
meeting
is
governed
by
the
community
code
of
conduct
for
Jenkins,
so
be
awesome
to
each
other,
and
let's
get
going
as
an
overview.
We
have
a
couple
of
open
items.
Marky
had
dropped
to
the
head
off
to
handle
some
things
we'll
see
him
talk
to
him
next
week.
We'll
have
a
presentation
on
pipeline
as
yamo,
and
also
a
multi
pipeline
job
idea
from
Stephen
Foster,
and
we
have
some
docs
for
that
cool.
A
C
C
Stress
our
governance
under
the
project
column
in
the
blue
section
at
the
bottom,
we
haven't
really
highlighted
it
yet:
structure
and
governance
at
it,
okay
and
then
at
the
bottom.
Okay,
then
you
see
roadmap
third
link
down.
There's
thanks
yeah.
We
will
highlight
it.
It's
still
draft
right.
Alright,.
A
So,
as
you
can
see,
we
have
the
the
pipeline
is
all
currently
an
incubation,
but
it
has
been
released.
The
plugin
is
downloadable.
So,
let's
move
on
to
that,
the
pipe
Lanisha
no
plugins
been
worked
on
by
itunes
beckon,
I'm
he's
on
the
call
with
us
here
and
I
will
bring
up
the
doc
for
them.
So
that
was
a
meeting
you
guys
had
yesterday
and
okay,
I
don't
you
want
to
talk
about
this
or
what
you
want
to
tell
us.
D
About
this
is
the
name
says:
its
purpose
pipeline
is
MO
I,
just
leased
version
0.2.
Last
weeks
it
isn't
still
incubation
period.
We
have
some
issues
that
you
want
to
implement
default
going
to
version
1.
So
this
was
the
another
topic
that
we
talked
yesterday
and
after
that,
probably
it
will
be
released
as
version
1
and
it
will
and
it's
incubation
period
incredibly
so
also
I.
Yesterday
I
learnt
that
this
meeting
is
being
done
every
week.
E
A
D
D
D
D
D
D
D
D
D
You
just
put
your
Jenkins
as
5
mm
file
in
your
project,
like
the
other
drinkies
file
indicated
pipeline
syntax,
and
when
you
create
your
multi
branch
pipeline,
that's
they
define
a
move
to
lunch
pipe
down
here,
so
I'm
going
to
define
Inc
it
so
I'm
going
to
give
my
local
pet.
Could
you
see
my
black
screen
right
now?
D
D
D
D
So
you
will
see
so
much
detailed
examples
in
the
plug-in
page,
so
I
just
created
some
simple
example
about
that.
We
start
with
a
pipeline
key.
So
this
is
the
overall
structure
of
the
pipeline.
We
need
to
define
this
key.
Then
we
can
just
define
agent
with
node
definition
with
any
with
none.
So
the
usage
is
very
similar
to
what
we
have
any
decorative
pipeline.
So
I
just
try
to
keep
it
very
similar
to
what
we
have
in
the
current
thing.
So
we
have
the
another
and
one
definition.
D
So
it
is
again
similar
to
what
we
have
in
the
to
Python.
We
define
our
my
nose
as
key
value
pairs.
Then
we
have
the
auction
spot.
The
the
good
part
of
this
pipeline
do
is
it
do
not
implement
every
step
or
every
option
post
other
things
that
is
which
is
created
in
the
Jenkins
declarative
syntax
pipeline.
So
if
you
want
to
add
another
options
to
your.
D
A
E
D
I
just
got
the
disabled
configuration
bills,
okay
and
come
back
to
my
mo
file,
and
just
edit
has
another
line.
So,
as
you
see
this
pipeline
just
creates
the
structure
or
the
meta
structure
of
the
Jenkins
tech
title
pipeline
as
iam,
so
the
old
steps
already
defined
in
the
Jenkins
itself
can
be
used.
Another
example
here
that
we
can
see
we
define
stages
down
there
and
then
we
start
defining
our
a
stage
under
the
stages
so
similar
to
the
syntax.
D
D
As
a
list,
what
is
this
thing?
So
it
will
just
come
out
it
it
enormous
time
for
some
advanced
buddhist
eclipse.
Of
course,
maybe
this
usage
in
outfit,
so
there
is
another
way
of
using
eclipse,
could
do
with
eclipse
in
the
definition
or
steps.
So
it
is
similar
to
what
we
have
in
tech
data
pipeline.
We
define
steps
under
that.
We
define
the
clips
and
then
we
can
write.
D
D
I'm
copying
my
file
I'm,
going
to
add
my
local
directory
here
as
a
project
as
a
git
repository
and
also
what
I
do
is
that
very
similar
I
just
select
the
mode
by
jenkees
file
as
llamo.
So
again,
this
is
a
almost
path
default.
Is
this
definition
and
just
a
click
say
it
founds,
Jenkins
CMO
file,
then
we
come
and,
of
course
it
fails.
Murphy.
D
D
B
D
B
Like
a
model
definition-
and
it
has
an
existing
JSON
parser,
so
I'm
wondering
if,
if
you
could
leverage
the
existing
declarative
parsers
as
that
proxy
for
you
right
so
at
the
end
of
the
day
to
clear
the
pipeline's,
just
a
schema
I
wonder
if
you
could
represent
the
exact
same
schema
through
Hamill
and
then
leverage
declaratives
existing
Purser's
to
to
execute
the
PI
points.
Artifacts,
okay,.
D
I
know
this
plugin,
so
I
just
work
on
it,
but
I
will
check
it
because
I'm
using
this
models,
definition
I'll
set
a
pack
by
death
for
validating
T
computed,
take
30
Patrick.
So
before
going
to
the
pipeline
itself,
I
just
waited
through
this
class
I'm
going
to
use
it
for
another
feature
in
the
in
the
pipeline
itself.
I'm
going
demand
lately
so
I'm
running
ping
time
at
something
converting
Dec
35
time
into
mo.
So
it
will
be
much
more
easy
for
users
to
like
convert
the
partners
in
KML.
So.
D
Is
fine,
please
feel
free
to?
Let
me
show
the
pipeline
page,
so
I
just
try
to
document
every
kind
of
usage
possible
and
also
with
the
links
here.
You
can
go
to
the
test
files,
which
are
also
shows
different
definition
types,
because
I
didn't
want
to
make
the
documentation
so
long.
So
currently
we
have
all
the
definitions.
In
Dec
35
times
all
sync
amounted
here
and
mount
options,
post
tools
when
conditions
and
also
run
conditions
like
sequential
and
conditions
or
Childline
conditions.
Any
of
all
of
something
like
that.
D
A
D
A
D
D
C
And
Steven,
both
here
in
the
Indian
group,
so
Steven,
the
the
the
templating
library
that
you
had
created
that
you
had
created
and
maintained
and
have
cared
for
uses
gianna
as
its
basis
as
well.
Doesn't
it
can
you
help
me
understand?
Interactions
they're,
yours
is,
is
well
help.
Help
me
understand,
help
me
conceptualize.
This
yeah.
B
Sure
so,
there's
some
slight
differences,
so
the
plugin
I
maintain
is
called
the
Jenkins
tumbling
engine.
The
basic
idea
in
a
nutshell,
is
that
it
lets
you
pull
the
Jenkins
file
out
of
the
repo
and
create
tool
agnostic,
template
pipelines
that
can
be
reused.
So
instead
of
you
know
hard
coding
that
I'm
going
to
use
maven
for
a
build
and
Sun
are
cuter
static
code
analysis.
B
You
define
a
generic
scaffold
of
a
pipeline
like
I'm
gonna,
do
a
build
and
I'm
gonna
do
static
code
analysis,
I'm,
gonna,
deploy
and
then
the
PC
you
were
mentioning
mark
is
actually
a
configuration
file.
That's
that
lives
alongside
your
templates,
that
sort
of
hydrates
what
the
template
is
going
to
do
where
you
can
specify
what
libraries
you
want
to
load
depending
upon
the
libraries
that
you
load,
you
get
different
implementations
of
that
template
pipeline.
So
that's
actually
a
custom
groovy
DSL,
but
you
could
have
a
ml
parser
for
the
configuration.
B
C
It
thank
you
thanks
for
the
clarification
so
the,
whereas
in
in
pipeline,
is
yeah
mo
that
I
two-inch
has
created.
The
Yama
file
is
pacifically,
defining
the
the.
What
will
would
conceptually
become
the
Jenkins
file,
its
defining
the
pipeline
outright.
Yours
provides
a
layer
that
it's
using
that
as
a
data
file
thanks.
A
B
Am
very
curious
to
see
if,
like
we
can,
save
you
a
lot
of
work
from
having
to
implement
steps
in
pipeline
as
animal
on
a
per
option
basis
by
just
taking
the
mo
file
and
sending
it
to
it,
declared
have
already
offers
from
a
parsing
perspective
so
that
that
functionality
is
like
inherently
one-to-one
because
it's
running
through
the
same
engine,
so
you
don't
have
to
do
any
of
the
like
translation.
It
may
be
declared
it
could
do
all
of
that
that
work
for
you
Liam,
are
you?
Do
you
help
maintain
the
declarative,
yeah.
A
Exactly
and
I
was
gonna
say
the
the
problem
there
being
is
that
declared
it
gets
down
to
gets
down
to
the
level
of
the
steps
being
executed
and
doesn't
in
if
I
remember,
right
doesn't
actually
parse
those
steps,
at
least
at
least
not
at
the
the
model
level
once
it
actually
gets
down
into
going
from
getting
ready
to
run
it
in
run
the
job
it'll.
It
does
a
bunch
of
different
things,
but
at
the
the
model
definition
of
a
level
it
doesn't
actually
cover
that
I.
D
F
E
F
A
F
A
D
D
B
F
From
what
I
saw
the
big,
the
quick
or
the
confusing
things
are
basically
that
step
arguments
can
come
with
like
you
could
have
one
default
argument.
You
can
have
many
unnamed
arguments
or
you
can
have
many
named
arguments
and
all
of
those
would
have
different,
yellow
structures,
so
you
have
to
kind
of
figure
out
which
one
is
happening
and
which
one
is
a
lot
better.
Not
so
right!
Beware
unless.
B
B
A
A
A
G
I
guess
the
the
main
takeaway
is
not
about
actual
syntax
or
describing
the
pipeline
or
anything,
and
it's
just
drawbacks
I
encountered
and
a
feeling
that
what
I
wanted
to
do,
outgrew
a
single
pipeline
job
and
whether
or
not
that
was
kind
of
a
valid
feeling
or
whether
there
was
any
gaps
there.
So
for
the
example
being
with
the
pipeline,
I
have
it's
it's
quite
simple
it
just.
G
It
has
a
very
large
number
of
parallel
branches
that
some
of
them
most
of
them
are
unrelated
to
each
other,
and
they
can
be
grouped
by
platform
that
I'm
compiling
for
sure
and
I
started.
Writing
it
in
a
single
declarative
pipeline
and
kind
of
immediately
found
that
there
would
be
a
big
drawback
of
they're.
G
All
sharing
one
build
history,
one
kind
of
test
history
and
each
parallel
branch
is
quite
heavy
to
run
in
terms
of
it,
builds
out
on
loads
of
nodes
and
takes
up
limited
number
of
specific
hardware
to
run
its
tests,
and
things
like
that.
So
what
I
did
was
I
split
it
out
into
different
jobs
that
all
run
together,
but
Jenkins
doesn't
really
tie
them
together
in
any
meaningful
way.
So,
there's
lots
of
weird
navigation
problems
and
history
problems
that
I
was
identified
as
a
kind
of
a
gap.
G
There
could
be
a
job
that
generates
pipeline
jobs
based
on
some
other
parameters,
such
as
like
a
list
of
platform
names,
in
my
case
or
by
detecting
certain
Jenkins
files
by
some
pattern
in
a
source
control,
and
that
way
it
would
reduce
the
number
of
multi
branch
pipeline
jobs.
So
I
have
about
16
multi
branch
pipeline
jobs,
so
they're
all
wasting
time
and
doing
the
same
indexing
and
things,
and
you
need
some
way
to
navigate
between
them
for
the
same
commit
which
is
awkward.
G
A
Okay
I
mean
so.
This
has
been
something
that
I
I
mean
I,
don't
know
if
it's
been
brought
us
specifically,
certainly
not
in
this
group,
but
I've
heard
it
discussed
kind
of
and
I'm
sort
of
thought
about
it,
a
bit
where
it's
there's
the
classic
Jenkins
freestyle
jobs.
Have
this
concept
of
hey
I
have
a
job,
it
calls
it
the
jobs,
and
that
was
how
Jenkins
achieved
parallelism
for
the
beginning.
You
know
five
six
10
years
and
then
we
we
went
to
pipelines
and
there
was
this
different
sort
of
idiom.
A
A
G
Does
I
guess
it's
a
kind
of
a
judgment
call
and
based
on
where
you
see
the
point
of.
Has
this
work
outgrown
a
single
pipeline
or
not?
And
for
me
it's
because
the
the
branches,
the
parallel
branches
they're,
not
really
related,
they
can
be
grouped
into
target
platform,
but
em
they
don't
really.
They
don't
matter
to
each
other.
That
much
well.
A
I
think
that
happens
with
a
lot
of
I'm,
seeing
that,
especially
with
hearing
looking
at
questions
from
people
on
matrix
build,
for
example,
there's
a
lot
of
I
need
this
built
on
this
combination
of
platform
and
hardware
or
whatever
and
or
some
settings
and
those
individual
things
aren't
I
mean
they're
related
but
they're
not
for
you.
I.
Think
that
you're
saying
that
for
you
they're
even
more
unrelated,
but
they
are
the
same
basic
structure
right.
G
B
That's
probably
not
the
correct,
like
CPS
terminology,
but
instead
of
creating
you
know
a
bunch
of
parallel
threads
in
the
same
job
being
able
to
take
that
and
say:
okay,
let
me
create
some
jobs
that
are
going
to
execute
the
pipeline
that
was
described
so
that
so
I
get
the
benefits
of
like
build
artifacts
per
per
thread
and
I
get
the
benefits
of
like
different.
You
know,
histories
per
for
each
thread,
yeah.
G
There
was
just
kind
of
a
question
mark
there
about
how
you
generate
these
jobs,
and
so
yeah,
like
the
simplest
possible
way,
would
just
be
supply
list
of
jobs
you
want
to
generate,
but
if
you
did,
if
you
put
it
in
a
declarative
pipeline
and
they
all
use
the
same
Jenkins
file,
that
would
be
actually
a
really
good
way
of
splitting
that
up.
I.
B
A
So
I
mean
I
think
the
thing
that
we
went
into.
Oh
sorry,
Steven,
I'll,
just
jump
in
here,
real
quick,
the
thing
that
we
were
into
here
in
a
bunch
of
cases
that
you
have
subtle
differences
in
what
it
is
that
your
templating
off
of
or
what
you
want
done,
the
the
thing
that
first
pops
into
my
head.
When
you
talk
about
this
structure
and
also
the
the
org
folders,
and
the
thing
is
that
we
don't
currently
have
the
concept
of
a
of
a
folder.
G
A
That
I
mean
that's
one
different
second
spot
right
here,
where
we're
kind
of
what
you're,
what
you're?
Looking
for,
what
the
the
behavior
that
you're
kind
of
describing
is
like.
Hey
I,
want
to
run
this
this
this
job
and
have
it
sort
of
automatically
generate
and
run
these
other
jobs.
There
are
children.
D
G
A
G
A
You're
almost
talking
about
like
a
what
you're
talking
about
there
would
be
almost
that
you'd
have
to
create
a,
but
when
you
start
a
new
run
of
this
particular
pipeline,
it
creates
a
folder
in
which
it
puts
all
the
things
that
it
created,
so
each
one
of
them
would
be
its
own
like
because
you
won't
be
able
to
run.
We
run
individual
items
in
there.
Those
are
the
only
way
we
have
to
group.
Those
right
now
would
be
to
put
them
all
in
a
folder.
G
G
A
B
Feel
like
it's
like
what
we
would
expose
would
be
a
properties
layer
at
that
top
and
then
it
goes
in
and
like
automatically
creates
parameterised
jobs
beneath
it
and
when
you
run
the
top
job,
it
just
passes
input
parameters
to
the
sub
jobs
that
it
that
it
automatically
created
right
so
from
one
job
definition,
you're
able
to
then
basically
end
up
with
a
combinatorics
of
sub
jobs,
and
then
it
instead
of
you
telling
it
what
parameters
surroundings
job
with
it
knows
that
you
want
to
run
them
all.
So,
just
automatically
passed
these
parameters
to
everything.
A
E
B
And
this
could
all
be
for
one
job
right
like
for
one
repo,
so
I
could
have
my
app
in
a
repo
and
I
want
to
run
it
on
like
six
different
jobs
for
different
platforms.
So
the
difference
there
to
me
is
that
like
organization
and
multi
branch
jobs
are
assuming
they
like
your
job,
is
your
repo,
and
this
is
sort
of
like
I,
could
have
an
arbitrary
number
of
jobs
coming
from
a
single
repo
or.
E
B
A
A
F
E
A
So
I
guess
the
question
I
have
for
you.
Steven
is
what
what
even
the
next
steps
are
ons,
it
seems
like
there's,
there's
interest
at
least
like
well.
This
is
this
is
an
interesting
idea
that
there's
I
can
take
it
at
least
three
or
four
different
ways
that
it
could
be
implemented
or
how
it
might
look
and
the
advantages
and
disadvantages
of
those
like.
What's
what
do
you?
What
would
you
what's
your
next
step?
What
would
you
like
to
try,
or
what
do
you
see
this
going
next.
A
I
mean
okay,
so
there's
there's
people
that
are
that
have
more
of
it.
There
are
people
that
have
more
opinions
about
the
pipeline
engine
and,
and
some
of
those
things
are
pipeline,
design
that
and
the
internals
of
jenkin
that
the
Jenkins
internals
aspect
of
this
that
aren't
part
of
this
meeting.
So
we
probably
want
to
bring
them
into
that
I.
F
D
F
Think,
as
long
as
you
can
do
that,
I
don't
think
there
would
be
significant
pushback
I
mean,
maybe
they
they
wouldn't
like
this
approach
or
something,
but
I
think
that
you
know
like
Jenkins.
X
follows
this
kind
of
model
like
we
talked
about
like
it
says
here,
I
think
it's
very
reasonable
in
general.
I,
don't
think
it
would
require
like
extreme
gutting
of
like
super
core
pipeline.
B
Am
pretty
interested
in
like
how
do
we?
How
do
we
orchestrate
the
pipeline
API
compatibility
between
all
these
different
things
right,
like
we've,
got
the
underlying
pipeline
engine
and
CPS,
and
it
assumes
from
my
understanding
that
declarative
sort
of
sits
on
top
of
CPS
and
then
the
thing
that
I
do
for
a
living
sits
on
top
of
CPS
and
then
pipeline
is
you?
Animal
comes
in
and
sits
somewhere
in
that,
and
then
this
would
also
sit
there.
How
do
we?
How
do
we
make
sure
that
this
whole
ecosystem
is
like
orchestrated
and
works
together?
B
F
B
Probably
the
latter
right,
like
I,
think
all
these
different
pieces,
I'm
talking
about
are
developed
in
silos
without
too
much
may
be
declared
as
an
exception.
Static
declarative,
obviously
is
very
closely
intertwined
with
the
underlying
CPS
engine,
but
like
pipeline
is
Djamel,
and
if
this
job
were
to
leverage
existing
API
is
for
creating
pipelines.
The
templating
engine
leverages
some
of
the
descripton
Jinling,
maybe
maybe
I'm
not
phrasing.
My
question
there.
A
No
I
I
think
no
we're
I
think
we're
following
where
you're
headed
it's
just
sort
of
like
where
we're
trying
to
clarify
what
you're,
like
which
direction,
because
different
ways
to
take
your
question
is:
is
your
what
you're?
Saying,
though,
is
that
it's
more
question
of
how
do
we
keep
them
all
working
together
playing
to
play
together
well,
is
that
the
yeah.
B
B
So
selfishly
I
rely
on
particular
conventions
of
how
the
pipeline
engine
works,
like
I.
Don't
I
think
that
this
take
is
focused
on
authoring.
An
experience.
I'm
curious,
if,
like
things
that
live
within
the
pipeline
ecosystem
needed
its
own
conversation
between
the
different
moving
pieces
right,
so
I
I
inject
functionality
into
the
pipeline
runtime
to
enable
templating
and
governance.
You
know
if
the
underlying
API
for
how
pipeline
works,
that
that
sort
of
breaks
that
that
layer
on
top
of
it
so
I'm
constantly
trying
to
figure
out.
B
How
do
I
implement
my
pipeline
plug-in
in
the
best
way,
so
that
it's
a
it's
maintained
as
a
first-class
citizen,
as
opposed
to
like
something
with
its
duct-taped
on
to
the
pipeline
engine
without
pulling
in
the
same
developers
that
are
working
on
everything
right
like
in
my
best
case
scenario,
I
get
to
sit
down
with
with
you
Devon
and
with
you
Liam,
and
we
talked
about
like
all
these
api's
and
how
everything
integrates.
But
it's
not
the
most
capable
model
out
there.
It
can
be
difficult
to
orchestrate
I
mean.
F
I
guess,
like
the
hard
reality
pessimistic
answer,
I
guess
is
I
like
because
everything
is
so
widely
used
right.
There's
minimal
changes
to
most
of
the
core
underlying
pieces
like
workflows,
GPS
and
groupies
GPS,
with
our
bug,
fixes
or
minor
features,
etc,
but
we're
probably
never
going
to
make
really
wide
sweeping
changes
to
that
plug-in
ever
because
we
can't
because
it
would
break
too
many
things
so
like
to
a
large
extent,
I.
Think
that
technically
it's
just
like
you
know
every
change
we
make.
B
A
F
Guess
I
would
say
tears
like
at
the
end
of
the
day,
things
like
the
current
implementation
of
declarative
and
your
templating
engine
like
they
are
extremely
coupled
to
groovy
and
GPS,
and
we're
close-ups
right.
Like
that's
unfortunate.
If
we
implemented
a
new
pipeline
execution
engine,
those
things
would
just
stop
working
or
they
wouldn't
work
with
the
new
engine
at
all.
It's
like
that's,
not
ideal,
but
it
kind
of
is
what
it
is.
You
know,
there's
no
alternative
for
you
to
you,
there's
just
an
ecosystem.
That's
that's
how
the
ecosystem
is
today.
I
will.
B
Say
that
at
least
obviously
the
thing
that
I
maintain
is
fairly
decoupled,
ray
I-
and
this
is
this-
is
gonna
change,
but
right
now,
I
just
inject
executable
things
into
the
binding
that
leverage
Jenkins
pipeline
is
code.
So
you
know
if
we
were
to
change
CPS.
You
know,
there's
not
too
much
that
changes
on
the
layer,
I've
added
to
be
able
to
continue
supporting
that
unless,
like
we
get
away
from
groovy
I
depend
heavily
on
groovy
and
some
fancy
look
programming
that
goes
on
yeah.
F
What
I
imagined
so
like
the
things
that
I
imagined
as
big
changes
that
would
be
problematic
for
the
ecosystem
would
be
alternative
pipeline
engines,
as
in
groovy
no
longer
execute
on
the
master,
or
there
is
no
groovy
at
all.
It
is
truly
strict,
declarative
things.
Like
those
nature,
those
would
obviously
be
huge
breaking
changes
for
the
ecosystem,
but
I,
don't
really
think
there's
anything
we
can
do
to.
You
know,
support
those
things
in
advance
for
most
cases,
just
like
a
lot
of
the
features
are
kind
of
specific
to
groovy
and
I.
F
B
F
Yes,
I
mean
as
long
as
we
have
a
groovy
engine
that
runs
inside
of
the
master.
Most
things
are
gonna
conceptually
be
similar,
but
anything
that
changes
that
would
be
very
significant
in
terms
of
braking
compatibility
could
offer
a
lot
of
interesting
new
functionality
or
new
features
or
different
user
interaction.
Methods
avoid
a
lot
of
problems,
but
it
would
be
problem.
There'd
be
complex
for
the
ecosystem.
A
Okay,
cool
execution,
I
can
type
it'll
work,
I'm
sure
there
we
go
okay
cool,
so
you
two
can
meet
up
and
chat
a
bit
I'm,
so
Stephen
Foster,
the
I.
Guess
the
the
thing
we're
coming
up
on
our
time
here
and
I.
Guess
the
the
next
steps,
I
guess
would
be
there's
there
doesn't
seem
to
be
like
a
major
philosophical
opposition
to
this
there's
questions
about
like
how
it
would
work
with
other
things,
and
how
would
we
I
mean
I'm
for
me.
I'm
also
thinking
a
lot
about.
There's
no
Jason
right
now
so
like.
A
How
would
how
would
this
be
visualized?
Would
you
just
use,
obviously
it
wouldn't
show
up
so
well
in
blue
ocean
or
but
that's
deprecated
now
like
Howard?
What
would
this
look
like?
Where
is
that
so
the
secondary,
the
more
important
question
is:
does
it
run
but,
like
I
think,
maybe
the
next
steps
here
are
to
try
to
put
together
at
least
some
sort
of
ideas,
either
one
one
proposal
for
what
how
you'd
want
to
work,
or
maybe
work
with
some
of
the
people
here
to
kind
of
talk
about
what
it
would
what's
impossible.
A
Implementations
would
look
like
and
maybe
submitted
jab
that
people
that
other
people
would
would
be
able
to
comment
on
that
understand
the
Jeff
not
required.
But
it
is
it's
one
way
of
getting
more
feedback,
but
it
sounds
like
what
you're
doing
just
to
wrap
up
the
idea
that
sounds
like
what
you're
proposing
is
something
that
would
be
be
be
able
to
work
as
a
independent
from
the
other
things.
So
it
wouldn't
necessarily
be
something
that
you'd
have
to.
A
Take
feedback
from
other
people
right,
you
could
just
say,
I
wanted
to
look
like
this,
and
you
could
go
do
that
and
that
I
mean
that's.
That's
I
think
you
would
probably
get
more
more
engagement
by
you
know
getting
some
feedback
and
trying
to
kind
of
you
know,
do
things
together,
but
if
you
got
a
lot
of
pushback
from
people
that
did
have
a
lot
of
opposition
to
the
this,
philosophically
you
could
just
kind
of
go.
Well,
that's
your
philosophy.
A
G
D
F
A
It's
it's
kind
of
up
to
you.
If
what
you
want
that
to
look
like,
maybe
you
reply
on
the
thread
and
we
can
sort
of
hopefully,
you'll
join
us
again
at
this
meeting
and
talk
more
about
it.
You
know
sort
of
we
can
have
some
discussions
offline
and
then
bring
it
here
and
chat
about
it
and
sort
of
present
or
just
sort
of
nailed
down
any
things
that
we
need
to
do
in
real
time.
Yeah.