►
From YouTube: 2023-04-11 Pipeline Authoring team - Design discussions
Description
Pipeline authoring team meeting
- Catalog design: Components project details page
- Syntax and keywords: with and inputs/parameters
A
No,
then
I'll
go
for
the
first
item
and
I
I
haven't
shared
with
a
lot
of
team
members
yet,
but
I
think
this
is
a
perfect
timing
for
you
to
provide
me
a
lot
of
feedback
so
like
last
week,
I
I
had
some
time
to
work
on
this
page.
I
can
probably
walk
you
through
by
sharing
my
screen
so
that
you
don't
need
to
be
lost
in
this
disorganized.
Wars.
Sorry
about
that,
because
it
was
just
started.
A
So
it's
a
little
bit
messy
so
like
for
the
details
page
while
we
call
so,
let's
say,
user,
coming
to
the
catalog
list,
View
and
then
for
now.
If
user
click
one
item
it
just
goes
to
the
Gila
project,
but
in
the
later
iteration
we
are
like
expecting
something
like
okay.
This
is
your
component
project,
and
these
are
the
details
like
who
is
using
these
components,
maybe
perhaps
in
much
later
iteration
like
to
where
like
is
there
any
statistic?
That
would
be
awesome,
but
that's
for
the
future
brainstorming.
A
But
this
information
I
gather
a
lot
of
good
feedback
from
our
previous
design
sketching
session
and
then
I
kind
of
like
grab
all
of
your
ideas
from
them
and
then
just
start
working
on
this
very,
very
low
Fidelity
prototype
and
then
I
also
talk
with
myself
once
they're
like
yeah
like
this
is
the
product
that
I
was
working
on
and
myself
I
also
like
made
some
progress,
so
there
will
be
some
new
screen
that
you
haven't
seen.
So
this
is
the
style
that
I
work
on
like
okay
law,
Pro
Fidelity
prototype.
A
What
kind
of
information
should
we
present
here
and
then
I
move
on
to
the
Hi-Fi
prototype,
so
this
so
I
just
named
the
board
as
NBC,
but
I,
don't
think
like
everything
that
I
design
here
is
like
visible
for
the
NBC,
although
for
first
iteration,
but
this
is
something
that
I
kind
of
Imagine
for
The,
Details,
page
and
I'm,
open
to
like
scope
out
a
couple
of
things
and
then
also
open
to
hear
your
feedback
that,
like
what
about
adding
this
information
there?
What
about
removing
this
information
because
of
many
different
reasons?
A
So
this
is
the
feedback
that
I
wanted
to
get
from
you
and
actually
Marcel
and
I
had
a
pair
design
session
already
last
week.
So
this
metadata
section
is
came
out
from
that
pair
designing
session,
so
I
I
think
I
I
didn't
touch
that!
Is
it
correct
myself,
I
think
this
is
exactly
the
same
as
we
work
on
and
I
just
use.
The
same
example
that
Fabio
created
for
the
CI
Alpha
program
that
you
use
the
real
blue.
It's
not
real!
A
Look
like
it's
a
real
example,
so
I
copy
and
pasted
this
with
me,
so
that
it
looks
more
realistic,
so
yeah.
So
this
is
from
product
readme.md.
So
we
can
just
fetch
this
data
for
the
first
iteration,
and
so
this
is
my
main
question.
What
kind
of
metadata
can
we
add
or
remove
it
from
here
and
another
question
for
me
is
like
I
know
that
we
have
this
easier
navigation,
folder
with
me.md
file,
but
not
sure.
A
B
A
So
so
it
was
here
so
I
thought.
Maybe
it
would
be
nice
if
we
just
use
the
full
width
for
the
instruction,
but
only
this
side
is
coming
from,
so
I
can
make
it
more
clear.
So
only
this
side
is
fetch
from
the
readme.md
and
then
this
is
more
like
dogs.
We
have
the
right
side,
navigation
and
then
user
can
easily
navigate
to
the
like
titles
like
h2h3,
something
like
this
so
yeah.
Maybe
it's
nicer
if
we
had
this
easy
navigation,
but
when
I
started
to
working
on
the
Hi-Fi
prototype.
A
So
this
was
the
initial
idea
like
okay,
we
can
have
some
colored
background
and
then
we
can
provide
like
on
this
page.
You
can
navigate
to
component
build
component
deploy,
but
at
the
same
time
like
there
are
a
lot
of
space
left
and
then
there's
always
designers
stress
came
out
from
this,
like
I
want
to
use
that
space
because
it's
consumed
a
lot
of
width
already.
I
know
that
it's
super
handy
to
have
this
easy
navigation
here,
but
I
also
want
to
show
more
metadata
at
the
same
time.
A
B
C
B
B
C
B
Kind
of
a
legend
like
that
I
think
that
would
be
useful,
and
that
would
help
that
would
definitely
help
users
to
navigate
or
to
clearly
see
component
names.
But
if
they
don't,
you
know
for
MVC
like
if
they
don't
structure.
Their
read
me
well,
like
that.
We
do
have
a
chance
of
that.
Looking
quite
messy
and
bad
right.
A
D
C
D
Just
for
free
like
because
that
button
is
all
already
there,
so
if
you
visit
the
repo
where
the
readme
exists-
yes,
it's
there
so
kind
of,
as
in
MVC
like.
If
you
want
to
really
dig
into
the
readme,
you
can
just
click
on
on
the
link
wherever
it'll
be
in
the
UI
to
go
to
that
page
for
kind
of
better
navigation.
B
A
Okay,
yeah.
That
sounds
good
to
me
because,
like
yeah,
there's
already
a
lot
of
information
and
then
maybe
at
a
quick
link
to
read
me
somewhere
in
the
next
iteration
it'd
be
nice
and
I
was
also
thinking.
Maybe
it's
a
good
idea
to
add
a
quick
link
to
each
job
or
each
component
at
some
point
would
be
also
nice,
but
that
is
outside
of
NBC
school
for
sure,
but
we
will
have
some
more
feedback
when
we
have
a
okay.
This
is
our
product.
A
I
came
up
from
the
team
discussion
and
that
we
can
run
a
user
testing.
So
I'm
not
worrying
that
much,
but
maybe
at
some
point
we
also
need
those
feature
and
I
have
another
question.
So
there
is
a
very
long
discussion
ongoing
regarding
publishing
flow.
I
am
also
sure,
like
all
of
you,
have
followed
those
discussion
or
not,
but
maybe
at
some
point
maybe
in
the
beta
we
will
have
this
Manifesto
file
then
do
you
think
like?
A
B
A
Yeah,
that
is
my
understanding
and
I,
think
we're
like
discussing
like.
Should
we
have
this
part
of
the
open
offer,
or
should
this
be
part
of
like
open,
Beta
or
later
iteration,
but
when
we
have
that
manifest
file,
it
should
be
a
required
component
to
Market
as
okay.
This
is
CI
components,
project
and
I
I
want
to
release
it
on
our
catalog
page,
so
it
should
be
a
required
at
some
point,
but
from
the
discussion
that
I've
seen
so
far,
it's
not
required
for
now.
B
C
B
C
D
B
A
Hey
so
yeah
like
either
drop
down
or
tap
I
I
also
need
to
think
about
which
components
should
we
use
it
here,
but
probably
we
also
need
to
consider,
like
those
information
inside
this
manifest
file,
to
convey
it
here
or
maybe
in
the
new
tab.
Maybe
inside
some
drop
down,
I
need
some
more
time
to
like
think
about
like
which
component
should
I
use,
but
okay,
so
maybe
some
design
changing
is
needed
after
we
introduce
a
new
flow
yeah.
B
I
wonder
if
we
do
like
a
use
case
test
to
see
which
is
more
important
to
developers
whether
they
see
the
readme
or
if
they
see
the
Manifest
file,
because
I
imagine
that
a
lot
of
people
that
use
cscd
would
are
pretty
Technical
and
they
would
likely
want
to
see
just
the
script
straight
out
before
the
readme.
But
I
can't
you
know,
I,
don't
I,
don't
know,
maybe
something
we
should
look
into.
C
A
One
problem
validation,
research
that
Erica
and
I
plan
for
the
next
quarter.
That
includes
like
how
would
user
consume
the
information
in
this
page,
so
we
can
networkly
have
at
least
one
or
two
questions
regarding
that
and
then
based
upon
the
feedback
that
we
got
like
I
can
incorporate
those
feedback
into
my
design.
Okay,
like
I,
want
to
see
ABC
it's
important
for
many
different
reasons
and
I'll
share
with
you
all
the
insights
and
then
why
I
I
came
up
with
the
different,
probably
different,
type
of
design
due
to
that
research
inside.
B
Yeah
I
also
thought
about
you
know
this
is
essentially
a
different
View
of
a
project
page
without
the
source
code
right
yeah
so
and
something
that's
on
a
project
page
I
mean
this.
This
looks
quite
like
you
know.
In
the
heading
and
title
we
have
the
breadcrumbs
and
everything
just
slightly
different
one
thing
that
we
do
have
right
off
the
bat
in
a
project
page
after
you
scroll
past.
The
files
is
the
readme,
so
I
wonder
if
it
would
be
more
important
to
consume
the
Manifest
file.
A
I
think
that's
a
great
feedback,
so
I
think
in
the
next
situation
like
we
cannot
just
stop
like
just
fetching
the
readme
as
it
is
because
probably
you
might
be
redundant
or
like
oh
I,
can
just
go
to
the
project
by
just
clicking
this
button
and
then
just
see
whatever
I
like
to
see
in
there.
Probably
they
also
want
to
check
the
test.
Job
template.yamo
as
well,
so
I
think
in
the
very
future
iteration.
A
What
I
would
imagine
is
more
like
conversational
UI,
like
so
what
kind
of
components
that
you
like
to
contain
here
like
what
is
the
best
explanation
for
each
component
and
then
when
they
just
put
and
submit
in
the
form,
and
then
they
can
have
it
more
like
customized
instruction
and
I.
Think
it's
better
than
just
fetching
the
data
as
it
is
from
the
readme.md,
but
I
think
that's
a
great
feedback
like
maybe
we
should
combine
somehow
the
Manifest
information
with
the
readme.md,
but
that
also
needs
some
user
validation.
A
B
A
B
C
A
Sorry,
I
I,
just
I,
just
didn't,
like
put
it
the
whole
first
date,
but
like
this
behaved
like
as
what
what
we
already
do
in
the
markdown.
So
when
Mouse
in
here
then
there's
a
copy
and
paste
button
shows
up.
So
that's
our
pattern
that
we
use
in
the
markdown
at
gitlab,
so
I'll
I'll
create
a
whole
birth
date,
but
like
it'll
it'll,
definitely
be
here
because
that's
one
of
their
main
goal
to
consume
this
information
because
they
want
to
use
it
absolutely
cool.
That's
a
great
feedback.
Thank
you.
D
Like
a
plus
one
to
debris,
well
option
of
of
the
tabs,
because
we've
only
got
overview
and
changelog
here,
so
it
does
seem
like
there's
plenty
of
space
for
adding
a
tab
in
there
and
I'm
looking
at
another
component,
catalog
from
a
competitor
right
now
that
has
five
different
tabs
at
the
top
of
theirs,
including
like
dependencies
and
change
loads.
So
you
know
it's
it's
similar
to
dependencies,
so
it
does
make
sense
up
there
and
it
would
be
kind
of
front
and
center.
D
For
the
Manifest,
although
I
do
Wonder
like
maybe
it
shouldn't
be
called
manifest,
you
know
the
the
technical
writer
in
me
wonders
if,
if
it
like
over
you,
changelog
and
I'm
trying.
No,
no,
no
like
this
should
still
be
overview.
Oh
yeah,
but
if
we
add
details
from
the
Manifest
in
here,
it
shouldn't
necessarily
say
manifest,
because
that's
not
what
users
are
going
to
be
looking
for.
It
might
be
like
reference
or
keywords.
A
A
D
A
C
A
A
And
then
this
is
what
they
do
is
like
okay.
This
is
this
is
just
fetching
the
changelope.md
and
then
give
a
freedom
to
the
user,
the
okay.
So
whatever
you
put
it
here,
whatever
version
info
like
about
fix
and
then
I
think
the
benefit
of
having
this
approach
is
include
the
release
notes
within
this
just
without
any
click.
It's
just
stay
on
the
first
step.
I
think
that's
great,
but
at
the
same
time
probably
we're
providing
too
much
restriction
and
too
much
freedom.
B
A
B
C
A
So
I
have
one
idea,
so
we
can
just
put
this
version
drop
down
on
the
right
top
of
the
page,
but
I
think
this
model
would
work.
So
that's
my
assumption.
So
this
version
that
works
if
they
like
to
change
the
version
frequently.
So,
if
you're
going
forward
with
this
design,
that
means
user
probably
want
to
like
try
not
to
use
the
latest
version
because
it's
not
stable
in
in
their
opinions.
So.
A
B
Right
so
if,
if
so,
if
I
click
on
version
1.4.0,
for
example,
with
that
in
there
or
well,
so
if
you
do
it
here
right,
the
readme
will
update
to
whatever
commit.
Has
this
version
right?
Okay,
and
if
you
were
to
click
on
the
version
in
the
table,
does
this
navigate
to
the
repo
and
then
also
navigates
to
the
commit
hash.
A
A
B
D
A
B
A
D
D
It's
more
and
with
the
extra
labels,
and
it's
just
like
you,
diff
I
kind
of
feel,
like
the
feedback,
makes
sense
because,
like
when
you're
clicking
in
the
table
it
it
does
kind
of
give
a
feel
like.
Is
this
going
to
take
me
to
another
read
here:
yeah,
if
you
click
here,
is
this
going
to
take
me
to
another
read
me:
is
this
going
to
take
me
to
another
component.
C
A
B
C
D
But
now
that
you
say
it
and
I
think
about
it
a
little
bit
more.
That
probably
would
be
a
better
thing
to
show
the
full
change
log,
because
if
you're
using
an
old
one,
you
you
and
you're
kind
of
wondering,
oh
if
I
wanna,
maybe
I,
should
update
you,
don't
wanna!
You
don't
want
to
have
to
click
through
everyone,
I
suppose
just
go
to
latest
and
you
can
scroll
from
latest
I.
Suppose.
C
B
D
D
B
A
That
would
be
great
and
I
know
we're
out
of
time
but
like
since
we
only
touched
on
the
first
items
so
that
I
can
move
on
to
the
second
one.
So
this
is
more
like
FYI
that
the
catalog
navigation
research
issue
got
closed.
I
recommend
you
to
go
through
the
conversation
there
and
we
we
don't
want
to
like
block
the
implementation
plan.
A
So
we
we
made
a
decision
to
stop
running
a
research
here
and
then
we
just
move
on,
but
also
at
the
same
time,
the
foundation
team
is
the
dri
to
decide
like
okay,
you
can
put
your
new
feature
in
the
sidebar
navigation
or
not
so
we'll.
Let
them
decide
based
on
the
first
round
of
user
research
that
we
run
and
later
March.
A
A
And
then
we
just
gather
more
data
like
we
can
either
use
snowflow
I
think
it
depends
on
the
front-end
team's
decision
like
how
can
we
gather
metrics,
like
how
many
Creeks
like
are
happening
when
we
release
it
on
the
NBC
and
then,
if
we
get
more
metrics
and
data
and
then
like
well
like
the
discoverability,
is
a
problem
and
then
like?
What
do
you
rethink
about
this
decision
that
you
previously
made
Foundation
team
like
I?
Think
we
need
to
put
it
in
the
sidebar,
so
I
think
we
need
more
data
if
that's
happened.
A
That
they
want
to
see
this
feature
under
the
CI
CD
menu.
So
that's
good,
but
now
the
goal
is
on
the
foundation
team.
So
we
just
wait
and
then
we
move
on
based
on
their
feedback.
So
I
just
wanted
to
say
that
this
got
the
close
and
then
there
might
be
some
chance
that
we
need
to
gather
more
metrics
and
data.
D
D
We're
just
starting
to
document
the
very
first
ones,
so
there's
like
specs
that
you
would
put
at
the
top
of
the
pipeline
configuration
and
then
within
the
specs.
There
would
be
inputs
and
that's
basically
how
you're
going
to
fill
out.
So
if
you
want
to
use
a
component,
you
have
to
kind
of
tell
that
component.
D
All
of
your
you
know
the
details
that
you
need.
The
component
is
going
to
expect
certain
values,
and
so
they'll
have
a
header
where
you
define
all
the
values
that
the
component
is
going
to
use
and
then,
when
you
include
that
configuration
in
your,
let
me
just
open
my
own
merge,
request
and
and
I'll
show
you
what
I
mean
in
just
one
moment:
where
is
it.
D
D
So
what
you,
what
you
would
do
is
you
would
this
would
be
the
component,
but
you
can
actually
already
use
this
right
now.
It
doesn't
have
to
be
a
component.
It
can
just
be
anything
that
you
include
and
then
you
put
spec-
and
these
are
the
inputs
that
you
expect
and,
for
example,
it
would
just
be
environment,
and
then,
in
your
configuration
you
would
say
well
any
user
that
puts
an
environment
well,
we
would
feed
it
into
here.
We
would
feed
it
into
here.
C
D
Would
configure
it
but
then,
when
when
a
user
wants
to
use
it,
they
would
add
that
configuration
through
include
and
then
we
call
it
with
and
it
kind
of
makes
sense
when
you're
reading
it.
So
I
want
to
include
this
configuration
with
these
inputs.
But
while
while
I
was
writing
it
out
I
kind
of
got
confused
because
it's
like
that's
how
I
would
say
it
use.
D
This
but
then,
when
I'm
looking
at
it
like,
if
I'm
a
user,
not
a
component
creator,
that
might
not
necessarily
be
intuitive
to
me.
So
I'm
kind
of
wondering
if
this
should
be
something
like
just
inputs.
So
we
would
have
specs
that
would
have
inputs.
And
then
we
would
say
the
I
want
the
inputs
to
be
these
three.
For.
D
B
D
D
B
Like
anything
that
you
would
like,
basically
any
variables
that
you
want
to
include
or
any
anything
that
you'd
pass
into
a
function
like
if
this
is
we're
treating
this
like
a
I,
don't
know
it's
not
a
function.
Is
it
I,
don't
know
it's
an
interesting
one,
but
I've
I've
gravitate
towards
inputs
rather
than
with,
but.
D
I,
like
it
I
like
your
idea
of
parameters,
I
hadn't
thought
of
it
like
that,
even
though
I
wrote
it
in
as
parameters
I
wasn't.
That
was
just
kind
of
a
word
that
fell
out
while
I
was
typing
it
in
I
wasn't
really
thinking
of
it
in
the
in
the
concept
of
programming
parameters,
I
was
just
setting
parameters,
but
that
that
also
makes
a
lot
of
sense
very
clearly,
because
that's
that's
what
I
said
without
even
thinking
about
it,
Define
the
input
parameter.
B
B
D
D
But
as
far
as
pipelines
are
concerned,
we
don't
have
the
concept
of
parameters
anywhere
in
CI
CD,
so
that
that's
one
reason
that
I
really
like
it
with
is,
is
it's
like,
and
but
you
know
too
it
it
it's
like.
So
it's
too
simple.
It
doesn't
give
very
much
information,
but
yeah
inputs
make
sense
as
kind
of
for
lack
of
a
better
word
like
a
layman's
term,
just
like
a
simple
term,
but
parameters
might
might
be
a
good
middle
ground
of
something
that
the
authors
are
going
to
understand.
D
B
C
A
D
D
But
I
I
have
parameters,
I
think
is
still
probably
better,
but
you
know
you
can
say:
attributes
we've
got
type
and
we've
got
risk
required,
yes
or
no,
which
is
you
know,
same
thing
optional
or
mandatory.
But
if
we
lean
towards
kind
of
the
API
language,
people
can
do
this
kind
of
table
in
their
readme
file
and
I
mean
that
that's
probably
what
they
would
be
doing
anyways.
D
A
I,
like
this
session
I,
also
edit
one
link
that
Kasha
put
it
in
our
retrospective,
that
muscle
and
myself,
and
we
we
had
a
discussion
around
like
keywords:
syntax
like
how
how
would
user
use
it
like
is
our
Cur
is.
Are
we
using
the
correct
terminologies
at
the
moment?
Is
it
user
friendly?
So
we
have
a
lot
of
questions,
so
I
I
think
maybe
like
after
the
Runa
user
research.
A
Maybe
we
need
to
come
up
with
better
process
to
Define
this
internally
internal
process,
to
define
the
syntax
keyword
and
that
will
require
technical
writers
approval
also
from
all
of
the
team
members,
and
also
maybe
from
the
user.
Research
I
am
not
a
huge
fan
of
like
making
a
lot
of
like
approval
process,
but
of
course,
I
need
to
like
hear
from
like
what
users
think,
but
this
is
something
that
we
should
also
take.
More
care
about.
A
I
also
went
through
a
sus
verbatims
and
then
I
mean
they
love
our
features
but
still
like
there
are
some
improvement
and
opportunities
that
we
could
do
like
in.
Is
it
like
really
easy
to
understand
when
they
go
into
the
docs
page
and
then
like?
Is
it
really
easy
to
just
let
them
choose
at
once
or
or
not,
and
from
that
user
research
we
we
can
figure
this
out.
I
just
also
wanted
to
heads
up
to
all
of
the
front-end
Engineers,
because
I
think
we
need
to
be
involved
in
this
process
more.
A
Yes,
I
agree:
are
you
agreeing
and
I
I
feel
guilty
that,
like
I
I
haven't
like
really
directly
come
in
and
say
like?
Okay
like
this
is
what
we
should
do,
because
I
I
am
still
struggling
understanding
all
of
these
things
and
how
to
make
and
how
to
use
this
keyword
to
make
my
pipeline
runs.
But,
like
you
fly
like
get
to
know
more
about
the
user's
context
and
then
Behavior
do
this
research
and
then
I
I
probably
become
more
confident
to
say.
Okay,
let's
do
this.
A
Let's
do
other
thing,
probably
we're
doing
this
in
the
wrong
way.
So
this
is
my
forecast.
So
please
give
me
some
time
to
understand
the
user's
Behavior
through
this
user
research
in
the
next
quarter,
and
then
we
can
sit
down
and
then
maybe
revisit
a
couple
of
keywords
if
we
need
to
and
then,
if
you'd
like
to
introduce
a
new
keyword
and
then
what
could
be
the
right
process,
we
can
also
start
the
discussion
there.
D
Yeah
I
was
just
thinking
a
lot
about
sorry.
I,
keep
interrupting
you.
Probably
just
I
I,
just
helped
with
some
issues
in
Mrs
in
package
where
they
renamed
one
of
the
Registries.
So
they
had
a
registry
where
they
had
terraform
modules
which
are
used
for
infrastructure
and
they
call
it
the
infrastructure
registry
and
they're
like
let's
just
call
it
the
terraform
module
registry,
and
it's
like
okay
and
just
renamed
and
and
part
of
the
reason
is
because
it's
not
going
to
break
a
pipeline.
It's
not
going
to
break
a
workflow.
D
They
just
have
to
learn
a
new
term,
but
the
pipeline
authoring.
Well,
just
the
whole
verified
group
is
defining
like
a
new
language
and
new
keywords,
and
things
like
that.
So
if
you
get
something
wrong,
you
can't
really
fix
it,
because
we
have
not
really
fixed
any
keywords,
since
it
came
up
because
it's
so
hard
to
fix.
So
so
it's
just
kind
of
reinforcing
the
point
that
extra
special
care
needs
to
be
taken
when
we're
adding
new
new
keywords,
because
it's
it's
much
harder
to
fix
compared
to
other
ux
issues.
B
B
D
B
D
D
D
D
B
D
D
A
D
B
B
D
D
D
A
I
think
if
we
use
like
a
plug-in
integrated
like
with
whatever
like
ID,
that
we
use
like
there's
more
distinction
between
the
first
level.
So
let's
say
you're,
probably
just
writing
a
really
simple
python
code,
and
then
there
is
a
very
strong
distinction
between
the
the
function
definition
and
then
the
what
I
write.
So
maybe
we
can
do
similar
visual
distinction
here,
which
should
be
I.
I
can
try
to
think
about
it.
B
It's
in
my
editor:
it's
it's
not
in
my
editor
There's,
no
distinction
between
something
that
I've
named
and
a
git
lab
keyword,
but
I
don't
see
why
in
the
pipeline
editor,
we
can
itself.
We
can
put
an
algorithm
in
there
to
like
make
it
like
get
lab
orange
or
something
something
easier
or
make
it
like.