►
From YouTube: CI component discussion
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
B
So
I
think
so
far
and
so
reading
what
we
have
so
far
in
the
issue.
There
is
a
like
a
safe
level
of
agreement
which,
which
is
good
on
the
syntax.
There
is
a
few
updates
last
minute
from
the
mail
yeah.
Do
you
want
to
discuss
your
points
since
maybe
kind
of
our
last
minute?
So
maybe
not
everyone
had
the
chance
to
read
them.
B
C
Would
propose
that,
like
with
this
kind
discuss
like
the
the
design
goals,
that
we
agree
open
and
then
basically
together,
write
an
example?
Syntax
because,
like
you
may
be
looking
at
this
issue
and
have
some
other
ideas
but
I
think
like
the
there
are
two
important
things
like
that
that
we
have
the
same
design
goals
and
then
we
I
finally
write
together,
something
that
resembles
what
we
want
to
do
so.
A
I
think
that
Wu
link,
like
the
problem
statement,
like
you
list
like
four
four
bullets
and
problem.
B
D
B
Think
these
are
okay
there's
the
bullet
points
are
more
they're,
not
the
things
we
have
to
solve,
primarily
as
part
of
the
problem
statement.
I
think
I
added
there
as
things
to
keep
in
consideration
as
we
make
decisions
since
I
want
to
link
discussions
with
other
things
happening
outside
of
the
component
catalog,
so
in
a
way
that
we
can
design,
also
the
syntax,
possibly
to
taking
consideration
of
certain
things
happening
like
outside.
B
So
one
of
the
things
was
the
recent
introduction
of
workflow
name,
the
the
discussion
we
are
having
around
the
refilling
variables,
and
so,
if
we
keep
this
kind
of
aspects
in
consideration,
maybe
it
could
help
us
to
combine
the
effort
in,
for
example,
redesigning
pre-filling
variables,
for
example,
using
inputs
or
to
Leverage
The
workflow,
name
that
you
can
Define
and
also
that
could
be
reused
similarly
to
like
a
workflow
name
within
the
the
component
or
template
or
these
kind
of
things.
B
So
in
a
way
we
can
we
have
like
a
coherent
syntax
with
with
the
features
we
currently
have
today
and
the
the
CIA
component
syntax.
So
these
are
kind
of
some
of
the
things
to
give
more
context
on
related
stuff,
but
they're,
not
the
primary
things
we
have
to
solve
and
the
primary
things
was
were
Pro,
where
the
inputs
and
and
basically
what
kind
of
yaml
structure
we
could
have
for
defining
make
sure
that
we
have
a
type
for
component.
B
We
specify
name
description
and
inputs
as
as
the
minimum,
then
there
is
also
things
like
outputs,
which
we
haven't
fully
covered
in
our
examples
and
discussions,
and
this
could
be
primarily
I
think
an
aspect
of
steps.
But
you
know,
arguably
there
might
be
other
kind
of
components.
I
don't
know
if
we
want
to
consider
artifacts
as
output
for
like
a
workflows,
type
style
components
but
yeah.
These
are
the
kind
of
the
primary
things
we
need
to.
A
A
About
what
you
mentioned
about
about
variables
that
we
don't
need
to
solve
that
problem,
but
we
do
need
to
acknowledge
that
we've
come
to
a
like
some
sort
of
a
dead
end
with
templates
and
variables
and
pre-filled
variables
and
would
like
to
hopefully
avoid
getting
into
the
same
situation.
So,
as
you
mentioned,
we
need
to
keep
this
in
mind
and
think
like
as
we
develop
the
the
syntax
that
we
want
to
agree
that
we
can
also
take
it
to
the
next
level
and
say:
okay
fall
the
prefilled
variable
and
the
variable.
C
This
is
actually
like
a
very
simple
example
how
we
can
make
templates
to
some
extent
composite,
but
if
you
follow
that
pattern
today,
for
example,
with
inputs,
you
actually
can
design
a
component
template
that
can
actually
be
included.
Many
times
like
a
Docker,
build
type
of
template
can
actually
be
included
many
times
as
long
as
you
specify
like
some
kind
of
let's
say
context,
prefix
whatever
you
name
it.
C
So
this
is,
like
example,
of
let's
say
a
Docker
build
type
of
the
template
that
you
have
built
who's,
maybe
some
kind
of
tests,
and
if
we
have
inputs,
you
can
actually
include
that
many
times
as
long
as
you
follow
some
some
design
principles
of
the
of
the
component.
So
this
is
what
I
kind
of
think
like
why
inputs
are
important
because
they
improve
composability
of
the
templates,
we're
not
going
to
solve
all
problems
of
the
templates
that
they
have
today.
C
But
when
things
are
by
by
definition,
more
explicit
with
the
inputs,
it
actually
makes
it
easier
to
move
away
from
from
variables
into
much
better.
Let's
say
handling
of
the
variables
in
the
future.
How
we,
how
we
pass
them
and
like
how
we
pass
them
to
actual
job,
because
I
I
feel
like
the
variables
think
like
how
how
they
are
being
evaluated,
is
one
of
the
things
of
how
job
processes
variables
and
like
to
what
variables
it
has
access.
E
The
the
one
caveat
here
is
that
how
I
understand
that
is
that
this
isolation
here
would
be
optional,
meaning
that
you
can
choose
to
add
a
prefix
for
a
job.
You
can
choose
to
isolate
your
template
using
the
inputs
like
right
now,
you
don't
have
a
way
to
do
that
with
the
syntax.
You
can
actually
do
that
and
that
that's
great.
E
The
question
is
whether
we
actually
want
to
make
it
optional,
or
do
we
want
to
make
this
isolation
required,
meaning
that,
with
with
the
new
kind
of
template
that
is
using
inputs,
you
will
the
the
isolation
would
be
fairly
guaranteed.
For
example,
whenever
there
is
a
job
we
always
append
the
prefix
Auto
generate
it,
perhaps
in
a
way
that
you
can't
really
mix
things
up,
even
if
you
wanted
to
so.
E
If
we
think
that
this
is
not
required
in
the
first
iteration,
I
can
probably
live
through
that,
and
this
this
syntax
with
the
square
brackets.
It's
it's
like
perfect.
C
Decision
I
would
probably
think
about
like
because,
like
I
think
like
the
way
how
you're
gonna
write
templates
in
the
new
model,
it's
gonna
evolve.
So
maybe
it's
more
of
the
thing
like
for
the
catalog
to
perform
a
validation
of
your
template.
If
it's
a
kind
of
fulfilling
the
rules
that
we're
gonna
be
refining
over.
E
Time
so
one
thing
that
is
missing
is
a
version
header
in
the
template
file,
because
if
we
want
ever
to
actually
make
the
prefix,
perhaps
a
required
required
input
for
every
template
yeah,
and
we
want
to
introduce
that
later.
You
would
need
to
make
it
like.
We
need
a
way
to
break
backwards.
Compatibility
at
some
point,
so
I
I
think
that
what
we
are
suggesting
companies
is
great,
but
I
would
still
somehow
introduce
version
of
those
like
inputs
or
template
mechanisms.
E
B
Opinion
but
I
think
it's
a
it's
great
to
at
least
have
like
a
version
with
it's
one
like
no
version
one
starts
with,
and
then,
if
we
at
least
we
we
have
the
option
of
changing
it.
If,
if
we
want
to
yeah
I
think
we
could
make
a
decision
on
this
like
racing
on
the
on
the
issue,
yeah
I
I
agree
with
the
starting
with
inputs,
as
also
like
you
know,
connecting
with
the
things
to
keep
in
consideration
that
are
mentioned
in
the
issue.
B
If
we
implement
the
workflow
input
that
we
already
have
workflow
keyword
that
we
use
on
top
of
the
pipeline,
if
we
Implement
inputs
as
as
as
part
of
workflow,
we
could
just
even
have
like
a
placeholder
where
we
can
start
building
creatures
like
a
peripheral
variables
using
workflow
inputs,
because
it
will
be
the
input
of
a
pipeline
in
that
case,
so
yeah
I
think
we'll
kind
of
open
the
door
for
multiple
things,
and
we
can
start
with
the
with
the
things
that
might
have
that.
Most
of
the
value.
C
I
I'm
not
really
at
short
on
the
need
for
having
four
different
types
of
the
components,
because
I
heard
about
the
component
for
the
workflow
template,
includable
top
extension
and
a
step,
but
I
think
we
have
enough
information
to
say.
The
template
and
step
is
a
minimal
amount
of
the
stuff
that
we
have
to
do
on
this
moment.
E
So
so
no
job,
because
this
is
right
now
being
used
like
there
are
many
cases
in
which
customers
and
users
are
defining
templates,
only
containing
hidden
jobs
with
the
dot
prefix
and
they
are
using
them
to
just
extend
their
concrete
jobs
with
the
hidden
jobs
from
the
template
and
I.
Think
that's
actually
a
very
good
use
case
and
that's
actually
quite
a
good
pattern,
because,
with
this
pattern,
customers
and
users
can
build
fairly
reusable
templates,
and
it's
like
you
know
them
doing
something
better
than
we
actually
offer
right
now.
E
So,
probably
with
the
existing
with
the
idea,
around
templates
with
with
inputs
and
string
interpolation,
we
can
use
the
same
technique,
but
it
should
be
fairly
simple
to
extend
that.
The
Syntax
for
including
component
to
just
include
a
single
job
from
the
from
the
template.
C
I
I
actually
wrote
this,
like
also
like
example,
but
if
I
think
it's
still
like
double
table.
This
is
like
a
good
because,
technically
like
we
could
change
excellent
syntax
to
include
a
single
drop
from
an
existing
template
that
is
published
and
also
passing
Leaf,
which
is
like
inputs
to
that
I
mean
questionable
is
like
how
you
want.
Actually
people
to
publish
this
kind
of
templates.
You
can
template,
have
many
jobs,
and
do
you
pick
like
how
how
how
are
all
other
rules?
You
find
that
so
I
think
this
is
possibility.
C
Another
possibilities
I
think,
because
what
you
propose
that
we
have
GitHub
I
mean
job
specific
component,
that
it's
by
definition,
allows
you
to
have
only
a
single
top
defined.
B
Or
it
could
be
a
combination
of
both
or
like
it
could
be
a
kind
of
composite
type
of
job
where
you
can
include
a
job,
because
you
can
define
a
component
that,
like
a
job
that
you
include
in
your
pipeline
and
that
could
run
a
single
job
or
could
be
a
composite
and
sort
of
job,
which
is
the
workflow
right.
Whether
you
say
include
this
job,
but
this
job
actually
attaches
you
know
it
runs
a
child
Pipeline
with
a
bunch
of
things
in
it.
B
C
I
I
I,
don't
know
if
we
need
like
a
job,
so
I
think
I
would
think
more
about
steps
because
maybe
like,
if
you
would
have
composite
steps,
the
stuff
can
be
a
place
that
we
use
extents,
so
basically,
I
I
would
maybe
consider
that,
like
just
cut
a
middle
and
if
we
have
like
a
step
that
can
be
composite
that
can
serve
like
a
like
a
job.
Basically,
then
it
can
be
actually
a
better
design.
That
is
that's
confusing,
like.
Let's
consider
that,
like
we
have
a
strap.
C
That
is
composite
that
allow
us
to
have
my
step
that
allows
you
to
use
that,
like
in
two
type
of
the
syntaxes.
C
So
basically,
like
this
syntax
can
be
just
a
simpler
one
that
is
equivalent
to
this
one
or
maybe
like
I,
don't
know,
maybe
something
along
these
lines
that
like
instead
of
like,
because
like
one
way,
there
are
probably
like
a
three
ways
of
doing
that,
get
like
a
job
from
a
template
containing
many
jobs,
but
then
how
this
templates
is
actually
written.
Is
it
written
that
it
can
actually
use
as
a
template
still
or
can
only
be
used
as
a
jobs?
I
think
it's
kind
of
confusing.
C
Sometimes
a
second
example
is
like
I,
think
about
circus
propose.
We
have
separate
components
which
is
like
a
job
that
you
extend
and
the
third
possible
ideas
like
basically
step
is
composite
and
you
can
use
that
as
your
definition
of
a
job.
E
A
I
would
agree
and
I
would
say,
like
most
of
our
users
like
they're,
building
the
building,
the
templates
for
single
purpose.
So,
let's
not
think
about
like
a
big
workflow
and
how
we
can
like
add
jobs.
Let's,
let's
make
a
component
and
say:
okay,
this
is
the
component
that
our
user
will
need
will
use
in
the
first
iteration,
and
then
we
can
we
can.
We
can
ask
for
feedback.
We
can
do
some
more
validation
and
see.
What
is
the
next
thing?
Do
we
want
to
prioritize
steps?
A
C
E
The
first
one
is
whether
we
want
to
keep
the
component
metadata
in
the
same
file
as
the
component
itself
with
all
the
inputs,
because
it
kind
of
depends
on
how
we
want
to
evolve
that
if
you
want
to
skip
more
files
in
the
directory
with
a
template,
or
do
you
want
to
have
multiple
templates
or
actually
a
directory,
so
this
is
this
is
one
one
question
I
I
don't
have
like
you
know,
a
ready
answer
for
and
the
second
one
is
actually
how
include
component
I
know
that
very
basically
there's
a
consensus
that
we
could
just
include
component
there
and
the
path
and
I
think
it
would
work
for
me.
E
I
I
I
just
wanted
to
make
like
to
share
my
idea
about
how
I
believe
it
could
work.
It's.
It's
not
like
I
feel
that
what
you
Camille
and
have
you
are
proposing
is
invalid.
I
just
think
that
there
are
some
aspects
of
using
the
import
keyword
or
import
keyword.
That
I
would
like
to
mention,
and
then
you
know
whatever
decision
we
are
going
to
make
here,
I
will
like
comply
with
it,
but
I
think
there
there's
some
there's
some
there
are
a
few
opportunities
I
believe
we
could
explore.
E
Let
me
share
my
screen,
see
I.
E
So
I
I
think
what
what's
being
proposed
right
now
is
this,
for
example,
include
component
or
do
something
like
that
later,
and
it
means
that
every
time
we
do
that
we
need
to
reference
the
complement
component
using
a
full
path,
and
here
I
also
see
that
we
are
using
fully
qualified
domain
name,
which
I
believe
is
good,
because
it
makes
it
easier
for
users
to
copy
paste,
like
the
paths,
the
components
from
the
catalog
ous.
C
Maybe
one
mode
I
think
like
we.
We
want
to
do
full
qualified
path,
because
it
opened
us
quite
easily
to
support
public
catalog
on
github.com
that
you
could
use
for
on-premise.
So,
with
this
design
we
actually
fight.
Zone
can
have
also
have
the
catalog
not
only
private
one
and
also
make
it
work,
a
close
GitHub
instances
so
kind
of
Federated,
at
least
for
the
public
software.
E
For
example,
so
let's
let's
say
that
security
is
just
a
component
and
we
can
include
scans
and
here
perhaps
it
would
be
securely
discounts
job
name.
So
this
is
what
I
proposed
some
time
ago,
but
I
know
it's
not
perfect,
but
I
just
wanted
to
clearly
voice
and
like
articulate
my
idea
about
why
this
could
be
a
good
syntax,
perhaps
not
now
perhaps
in
the
next
right
in
the
next
iteration,
but
I
think
it's
important
to
note
and
that
we
could
do
things
like
that.
For
example,
gitlab.
D
D
I
can
perhaps
we
could
also
do
something
like
that
import,
another
component,
something
in
here
and
then
a
very
high.
D
E
I
I
mean
that
there
are
some
operations
that
we
might
want
to
do
on.
A
group
of
components
like,
for
example,
I
can
imagine
that
some
of
the
components
may
be
stored
on
GitHub
right,
so
we
can
actually
pass
a
token.
Perhaps
it
could
be
done
actually
on
the
like
top
level
like
the
syntax.
Here
is,
of
course,
like
broken
right
now,
but
this
is
what
I
believe
we
could
do.
E
Then
we
could
build
a
service
that
allows
customers
to
generate
checksums
for
the
components
they
can
use,
something
like
latest
here,
but
still
have
an
external
and
trusted
service
that
calculates
all
the
checksums
for
all
the
components
used
to
comply
with
some.
You
know,
policies
and
stuff
like
that,
so
I
think
there's
some
value
in
aggregating.
All
the
Imports
of
all
the
components
like
in
a
single
block.
I
I,
do
understand
that
it.
E
It
will
make
it
more
difficult
to
copy
paste
components
from
CI
catalog,
because,
instead
of
just
doing
it
once,
you
would
need
to
do
the
twice
one
for
import
and
then
to
actually
use
it
some
somewhere
and
having
both
ways
will
make
the
copy
paste.
Even
more
difficult
but
I
think
in
the
future
there
might
be
some
value
in
actually
having
an
aggregated
import
for
all
the
components:
yeah,
that's
it
and
I.
E
C
I
I
have
a
few
thoughts.
Maybe
someone
else
as
well.
B
E
I
think
and
that
I
just
think
that
it
might
make
backend
code
design
a
little
bit
more
difficult,
because
we
would
need
to
support
both
ways
of
finding
components.
Checking
I,
don't
know
circular
dependencies
if
we
even
allow
them
to
actually
happen
and
with
one
way
this
will
simplify.
The
Code
by
having
two
strategies
is
also
a
little
bit
more
complex
but
yeah,
something
that
can
be
done
later.
B
The
other
aspect
was
I
think
we
touched
like
in
the
past.
Probably
my
kind
of
main
concern
would
be.
How
would
we
use
this
with
something
like
steps
that
is
evaluated
on
the
runner,
so
it
means
then
we
somehow
need
to
expand
like
a
saved
an
expanded
version
of
that
path
or
something.
E
But
I
think
that
anyways
we
will
need
to
maintain
some
kind
of
Global
state
for
a
config
to
enumerate
all
the
components
being
used.
I
don't
think
this
is
something
that
we
will
avoid.
It
will
probably
require
some
magic
on
in
the
sky.
Config
module
to
have
some
kind
of
a
list
of
components
available
when
actually
parsing
happens,
but
I
think
it's
like
more
like
yeah.
B
E
Yeah
speaking
of
that,
actually
there
was
related
concept.
I
I
talked
with
coming
some
time
ago
on
slack
I,
don't
remember
actually
whether
it
was
in
columns
like,
but
do
we
want
to
make
it
possible
for
components
for
templates
to
use
the
include
keyword
and
I
think
this
is
a
very
important
decision
we
need
to
make,
and
my
opinion
is
that
in
the
first
iteration
we
should
not
make
it
possible
to
use
an
include
in
a
template
that
is
a
component
using
new
inputs,
because
this
completely
breaks
determinism.
E
We
don't
have
good
ways
to
manage,
like
dozens
of
layers
of
templates
and
I
think
this
is
very
important
discussion.
We
also
should
have
today.
A
So
what
diffusers
have
like
the
same?
They
need
to
like
do
the
same
steps
over
and
over
again
should
they
include
or
include
the
component
with
different
different
inputs
and
every
time
they
need
to
do
it.
They
just
need
to
include
it
with
like
include
component
with
this
one
and
then
include
component
with
another
another
input.
E
So,
basically,
if
we
want
to
prevent
having
multiple
layers
of
components
where
one
com,
like
there's
many
levels
of
nesting
within
them,
I
think
the
only
way
to
work
around
that
is
to
make
it
possible
to
include
component
multiple
times
instead
of
having
them
all
like
overwriting
each
other.
So
it
doesn't
answer
a
question,
though,
because
I'm
not
entirely
sure
yeah.
A
C
I
think
the
idea
is
like
that
we
can
forbid
includes
today
because
then
like.
If
you
go
to
the
catalog,
you
have
a
single
yam
that
is
inspectable
by
your
eyes,
because
there
is
no
level
of
there
is
not
many
levels.
There
is
no
any
lasting.
Something
that
we
may
kind
of.
Consider
in
a
situation
is
like
to
to
to
make
it
so
like
to
aloe
Moro,
so
maybe
another
iteration
could
be
gradually
like.
We
could
make
a
decision
to.
Allow
includes
only
coming
from
that
single
project,
even
even
if
this
is
like.
C
Let's
start
so,
you
could
have
like
more
composability,
but
this
is
also
something
that
we
can
parse
efficiently
and
present
to
you
like
in
the
contest
form
that
is
still
like
inspectable,
probably
by
your
eyes,
I.
Think,
like
the
thing
that
we
like,
we
are
worried
that
like,
if
we
all
know
in
the
components
published
to
the
catalog,
for
example,
a
refer
to
a
private
project.
C
It's
simply
not
gonna
work,
sometimes
because
people
are
gonna
refer
to
some
of
their
projects
refer
to
some
remote
dependencies
and
it
will
be
not
deterministic
in
the
behavior.
So
if
we
publish
like
a
whole
project
into
a
catalog
before
the
components
that
were
there,
if
we
initially
like
skip
it
completely
includes
it
makes
it
like
pretty
deterministic,
we
can
download
like
say,
includes
from
that
project.
It's
also
deterministic,
because
it's
tied
to
the
very
specific,
a
version,
but.
C
So
so,
like
yes,
like,
like
it
kind
of,
includes
exactly
this,
like
the
version
that
you
post
within
that
project,
so
so
so
I
think
this
is
what
we
were
thinking
about,
like
the
imitation
of
what
is
pushable
to
the
catalog,
to
actually
make
things
possible
to
the
catalog
that
to
be
deterministic
always
and
do
not
change
over
time
and
like
this,
this
like
charcoal
currency
or
like
limiting,
includes
in
the
backing.
It
actually
would
allow
us
to
achieve
that.
If.
A
A
So
what
they'll
do
they
look
at
the
component?
The
way
it
is
composed
and
they'll
try
to
basically
copy
it
and
maybe
like
straight
out
the
variables
and
use
inputs,
but
then
many
many
examples
users
are
doing
include
within
includes
within
includes
within
includes
many
times
like.
If
we're
saying
the
same
project,
then
it's
okay,
but
if
we
are
like
forbidding
the
usage
of
includes,
then
we
are
causing
our
customers
a
big
big
problem
in
like
migrating
from
templates
to
the.
E
Components,
I
think
this
is
something
that
they
understand,
but
I
think
that
the
customer
customers
should
still
be
able
to
use
the
Legacy
templates,
but
with
the
the
new
new
features
like
interpolation,
with
the
square
brackets
explicit
in
inputs
and
all
the
stuff.
This,
if
you
want
to
use
these
features,
you
need
to
comply
with
the
new
principles
and
you
won't
be
able
to
use,
including
the
first
iteration.
E
If
you
still
want
to
use
Legacy
templates
that
are
non-deterministic
and
basically
you
know
A
bit
chaotic
you
can
still
do
that,
and
those
templates
pressing
could
be
also
somehow
visible,
somewhat
visible
in
the
CI
catalog.
But
if
you
want
to
use
the
new
version
of
of
templates
with
this
more
reasonable
interpolation
or
or
configuration
and
composibility,
you
would
need
to
like
gradually
move
towards
the
new
design.
A
Yes,
yes,
definitely
because,
like
that's
what
they
do,
they
go.
Sometimes
they
go
all
the
templates
in
the
same
project,
sometimes
they're
separated
based
on
like
technology
languages
and
so
on.
So
if,
if
we
do
that,
it
will
definitely
I
have
another
questions
about
inputs
is
the
suggestion
that
you
have
today
will
allow
us
to
support
like
dynamic
inputs,
because,
like
there
are
like
a
lot
of
ask
about
okay
now,
I
need
to
explicitly
mention
what
what
are
the
inputs
that
I
know
to
use.
A
But
there
are
many
cases
where
the
inputs
are
dynamics
and
dynamic,
and
it's
based
on
different
parameters,
and
could
we
like
point
the
inputs
or
the
width
to
a
specific
interface
or
an
endpoint?
That
will
tell
them
like
the
way
it
needs
to
be
structured.
They
say:
okay,
we'll
structure
it
the
way
it
is,
but
we
need
this
with
something
to
hit
an
end
point
that
will
be
dynamically
generated.
A
B
A
A
There
will
be
like
different
input
that
will
be
generated
based
on
specific
conditions
such
as
like
the
infrastruct
available
infrastructure
and
the
technology
that
is
being
used
in
the
environment
that
they
want
to
to
deploy
or
to
use
this
pipeline
against,
and
sometimes
they
don't
know
what
are
the
variables
and
then
they
need
to
go
and
manually
enter
the
variables,
and
this
is
why
they
use
like
the
pre-filled
valuable,
but
political
variable
also
have
problems
that
you
need
like.
A
B
A
E
So
I
I
don't
see
a
use
case
here
if,
if
they
right
now
are
using
variables
and
generate
the
names
or
variables
in
a
dynamic
way,
how
the
back
end
like
how
the
template
can
actually
know
what
are
the
names
like
those
need
to
be
hard-coded
in
there.
So
I'm
missing
something
in
here.
I.
B
Think
it's
yeah
I
think
so
the
the
inputs
are.
What
is
the
data
required
for
this
template
to
work?
So,
if
you
can
specify
you
know,
this
is
required
and
it
should
always
be
required.
You
know,
regardless
of
whatever
condition
is
being
currently
evaluated,
and
so
I
think
those
should
be
should
be
applied
regardless
of
the
context,
because
they
are
specifically
related
to
that
component
that
you're
trying
to
use.
But
what
it
sounds
like.
B
What
you're
saying
is
more
about
pipeline
profiles,
something
like
okay,
I
I
could
run
this
pipeline
in
the
we're
using
different
combinations
of
inputs
and
whatever
it
is,
is
like
it
depends
on
on
whatever
condition,
or
it
depends
on
whether
I'm
running
a
deployment
on
AWS
or
whatever,
and
my
if
I
want
to
deploy
on
AWS.
This
is
my
pipeline.
I
need
to
provide
this
set
of
inputs,
otherwise
I
need
to
provide
another
set
of
inputs,
depending
what
you're
trying
to
do
so.
B
I
think
this
seems
more
to
be
more
a
problem
of
pipeline
profiles,
but
for
the
component
itself,
there's
like
what
are
the
requirements
for
this
component
to
run?
Oh,
what
are
the
things
I?
You
could
customize
about
this
component,
so
we
provide
you
some
inputs
with
maybe
defaults,
and
so
you
could
customize
if
you
want,
and
so
I
think
those
should
be
shouldn't
like
it
should
be
able
to
exist,
regardless
of
whether
we
want
to
do
Dynamic
inputs,
because
that
defines
the
schema
of
the
parameters,
the
D1,
that
this
component
can
accept.
A
Okay,
what
about
what
about
play
field
variables,
which
is
like
a
very
common
scenario
that
our
users
are
using
and
do
we
see
a
way
to
support
it
using
the
using
the
include
the
inputs
so.
C
I
I
think
like
there
is
a
few
things
to
consider
like
weave
as
an
input
can
also
accept,
let's
say
Json,
and
you
can
then
probably
refresh
that
in
your
template
to
assign
the
value
of
the
input
to
a
variable
that
is
then
passed
to
a
runner.
This
is
one
thing
and
now,
like
I,
think
the
question
is
like
what
place
is
going
to
be
executed.
I
think
like
in
the
compounds.
C
We
would
never
allow
like
a
dynamic
evaluation,
but
if
a
pipeline,
let's
say,
for
example,
I
think
what
Fabio
said
in
that
pipeline,
maybe
we
can
Define
like
some
kind
of
syntax,
to
allow
you
to
fetch
an
external
configuration
in
kind
of
Json
form
that
would
be
applied,
maybe
as
an
input
somewhere,
but
I
think
it
will
be
have
to
be
done
in
the
context
of
the
pipeline,
and
a
component
would
just
receive
that
as
an
input
and
component
could
assign
any
of
these
inputs.
C
That
would
be,
let's
say,
a
Json
key
to
a
variable
to
use
that,
maybe,
as
a
staff
name
version
of
the
step,
whatever
you
really
wants
to
do
there
so
I
I
think
this
is
what
we
can
actually
do,
and
this
is
like
inputs,
I.
Think
the
templating
syntax
allow
us
to
be
to
have
a
Syntax
for
the
templating
that
can
be
evaluated
dynamically,
but
I
think
I
would
probably
make
a
distinction
between
at
what
level
you
can
make.
C
Let's
say
this
Dynamic
call
because
it's
expensive
and
this
level
it
will
have
to
be
a
pipeline
created
on
a
git
push
in
the
component.
You
can
only
parse
or
like
use
what
was
like
passed
to
you,
but
maybe
there
is
some
I
don't
know.
There
is
like
a
ton
of
improvements
that
we
can
do
like
with
the
templating
and
actually
be
like
a
complete
templating
system
like
if
you
have
inputs
that
says,
like
first
one
I,
don't
know,
project.
C
Maybe
maybe
there
is
some
syntax
that
we're
gonna
do
that
with
I.
Don't
know
it
probably
would
write
inputs
project
and
then
probably
like
that
version,
but
maybe
like
us
in
other
templating
systems,
or
maybe
there
are
like
some
transformation
allowed
like
float,
that
you
pass
that
as
a
float
value
or
like
a
Boolean
value.
This
is
like
a
like
a
syntax
from
Ginger,
so
we're
actually
gonna
introduce
like
a
templating
syntax.
That
initial
will
simply
support
that,
but
whatever
we
can
support
later.
C
As
for
the
transformation
of
the
of
that,
it
will
be
up
to
us
and
I.
Think,
like
you,
you
mentioned
somewhere
that
you
mentioned
I,
think
that
we
could
use
go
blank
templating
and
they
go
like
templating,
for
example,
maybe
not
go
around
templating
to
use,
but
some
constructs
allowed
in
the
gun
like
templating
and
the
government
templating,
for
example,
allows
you
like
F4
loops
to
automatically
generate
jobs
so
so,
like
with
the
templating.
We
can
actually
have
a
lot
of
possibilities.
C
How
you
can
transform
that
that,
but
I
think
like
you,
would
probably
require
that
all
Dynamic
and
expensive
costs
would
be
coming
from
from
the
create
Pipeline
and
a
component
would,
as
published,
would
have
like
a
very
deterministic
Behavior.
So
it
could
not
rely
on
anything
that
is
external
to
a
given
project.
C
This
would
be
I
think
my
my
perception
so
because
I
think
this
is
probably
one
part
where,
like
a
templating,
could
read
also
a
file
from
the
Adias
and
file
to
the
template
because,
for
example,
a
templating
mechanist
could
actually
read
some
kind
of
Json
file
with
the
with
the
predefined
variables,
like
a
version
or
whatever
that
could
be
reused
between
different
templates
and
like
the
templating
system,
can
actually
do
that.
E
Now,
speaking
of
these
additional
files,
my
my
idea
was
not
really
to
use
them
to
generate
configuration
but
to
pass
them
to
a
runner
so
that
it
can
execute
them.
So
I
think
it
is
a
slightly
different
use
case
here
and
you
making
it
possible
to
use
additional
files
to
evaluate
like
to
expand
the
configuration
using
some
kind
of
a
templating-
that's
definitely
about
use
case,
but
then
referencing
a
component
and
then
passing
additional
files
to
the
runner
that,
like,
depending
on
what
the
component
has
been
referenced.
E
That's
probably
a
slightly
different
use
case,
probably
more
valid
in
case
of
steps
than
in
case
of
templates.
So
perhaps
in
templates
this
will
not
ever
happen,
but
with
the
out
devops.
It's
clear
that
this
could
be
useful
for
our
customers
and
users,
because
right
now,
in
order
to
add
files,
you
just
need
to
create
a
Docker
like
merge
them
like
include
them
in
a
Docker
image
right,
which
sometimes
is
just
overkill
for
something
very
simple.
B
I
also
I
would
like
to
discuss
a
couple
of
questions
before
we
run
out
of
time,
and
so
one
of
them
is,
should
we
allow
or
forbid
top
level
keywords
in
template
components?
So
if
I
say
I'm
defining
include
component
blah
blah,
will
that
yaml
file
that
is
included
can
can
it
contain
default
image?
Can
it
contain
top
level
variables?
Can
it
contain
other
things
that
could
you
know
be
then
merged
and
override
is
going
to
be
able
to
all
the
jobs
so.
E
That's
a
good
question
and
I
I
think
it
depends
on
when
the
evaluation
of
those
default
values
will
happen.
So
if
we
actually
evaluate
them
at
the
same
time
as
we
like
process
the
template,
then
it
could
be
useful,
but
when
we,
when
we
merge
those
default
configurations
into
the
configuration
that
we
are
including
from
this
might
not
be
a
desirable
outcome,
so
it's
probably
probably
depends
on
the
timing
and
when
we,
when
we
use
those
keywords,
yeah.
B
Well,
one
of
the
idea
was
to
and
either
strip
out
any
top
level
keywords
maybe
raise
a
warning
or
something
like
this
is
not
allowed
or
whatever,
like
you
know
like,
if
you
you
could
use
a
component
that
will
currently
you
know,
depends
on
top
level
keywords,
and
is
that
those?
Let's
say
you
define
variables
that
level
inside
the
component?
Those
variables
will
be
applied
to
the
component
only
and
then
we
strip
out
the
top
level
variables
when
we
merge
the
diamo.
B
C
C
How
composable
is
your
component
if
you
status
it's
kind
of
it's
not
composable
but
like
there
are
all
other
things
like
if
the
syntax-
and
this
can
actually
like
because,
like
a
lot
of
people,
gonna
be
fine
with
using
stages
and
variables,
because
this
is
how
they
want
these
things
to
do
and
I
I
think
like.
We
can
actually
like
for
things
that
are
published
in
the
catalog.
C
C
And
make
me
like
a
decision
to
the
user
if
it's
fine
with
this
imitation
or
not,
and
we
don't
like
I,
think
I
would
be
surprised
if
things
are
stripped.
I
would
rather
things
to
error
out,
but
since
we
want
people
to
use
CR
catalog
as
a
drop
in
replacement,
we
cannot
error
out,
but
I
think
we
should
give
people
a
tool
to
allow
them
error
out
and
give
them
like
indicator
like
how
compostable
is
that
if
it's
public
I'm.
A
Saying
maybe
we
can
improve
a
little
bit
like
the
the
syntax
specifically
about
variables,
because
we
know
that
there
is
a
lot
of
confusion
when
using
the
top
level
variable,
because
user
thinks
that
it's
applied
to
a
to
a
workflow,
and
then
it
get
copied
to
a
job.
And
so
maybe
maybe
there
is
a
way
here
to
maybe
introduce
like
a
different
syntax.
I
know
we
discuss
of
nesting
like
variables
on
the
underneath
the
default
keyword.
A
So
let's
not
allow
like
a
top
level
keyword,
as
is,
let's
make
sure
it
is
like
nested,
underneath
like
a
workflow
or
a
default
and
not
just
like
variables,
column
and
then
just
double
the
variables,
because
this
this
was
one
of
the
main
confusing
parts.
So
maybe
maybe
there
is
some
slight
changes
that
we
can
do
in
order
to
avoid
this
confusion
with
users,
so
don't
strip
out.
C
I
would
say,
don't
introduce
any
syntax
I
think
we
should
be
at
LinkedIn
tool
outside
of
GitHub,
that
everyone
could
use
for
validating,
just
any
GitHub
ciamo
that
they
have
based
on
our
rules.
I.
Think
like
right
now,
it's
like
a
missing
piece,
because
right
now,
like
you
have
errors
that
are
hard.
C
We
have
I'm,
not
sure
if
you
have
pipeline
warnings
that
would
kind
of
show
you
what
syntax
is
deprecated
or
not,
but
if
you
would
have
like
a
separate
time
that
you
can
slap
into
your
projects
that
would
be
executed
when
you
modify
guitar
serial
to
give
you
like.
All
of
these
things,
hey,
you
are
using
variables
in
the
context
of
the
include
it's
gonna
override
things
in
the
global
I.
I.
C
Think
that's
how
you
should
encourage
people,
and
this
is
something
that
people
could
also
use
outside
of
the
gitlab
to
validate
stuff,
because
otherwise
people
are
today
simply
okay.
It's
breaking
I'm
just
gonna
push
that
together
to
test
if
it's
actually
working,
but
a
lot
of
these
things
can
actually
be
caught
ahead
of
the
time.
C
So
I
would
rather
go
in
the
direction
of
better
to
link
than
more
complex
syntax,
simply
because
this
better
touring
would
help
everyone,
including
us
how
people
write
GitHub
cimor,
how
people
design
components,
how
composable
they
are
and
that
the
fact
that
all
of
the
parsing
is
part
of
the
gitlab
and
our
reading
is
part
of
the
git
Club.
C
E
I'm
still
not
convinced
like
there
are
a
few
things
to
unpack
here.
There's
this.
Like
recently,
a
new
configuration
language
has
been
built,
it's
called
q
and
it's
solving
this
problem
exactly
to
define
a
syntax,
the
the
the
schema
and
and
the
values
in
a
single
file
so
that
it's
actually
all
together
like
you,
can't
build
an
invalid
queue
file,
because
the
the
schema
definition
and
the
the
data
are
actually
connected
together.
So
I
think
that's
actually
a
very
great
system.
E
The
second
thing
to
unpack
here
is
that
I
believe
still
that
we
should
not
really
make
the
catalog
backwards
compatible
with
the
templates
in
a
way
that
templates
and
components
are
mixed
together.
I
still
think
that
we
should
use
include
template
and
include
component,
and
we
should
still
version
files
that
are
inside
the
CI
catalog,
meaning
that
you
can
have
a
definition
of
a
template
in
the
CI
catalog.
E
A
Okay,
so
with
the
interest
of
time,
I
think
we're
always
at
time
a
I
would
say
what
are
they
all
open,
open
questions
that
we
still
need
to
discuss
like
we
thought
about
like
taking
like
looking
at
the
syntax
and
like
Community
proposal,
syntax
that
I
think
we
most
of
us
agree
on.
We
can
continue
the
discussion
on
the
on
the
issue.
What
are
the
other
questions
that
we
need
to?
We
need
to
address.
E
So
I
I
think
that
what
what
keywords
will
work
with
the
components?
Do
we
want
to
version
like
the
syntax
used
in
in
the
component
template?
E
So
these
are
two
from
the
top
of
my
head
and
yeah
and
then
how
to
pass
variables
to
the
components?
Do
we
want
to
explicitly
reassign
them
to
inputs
like
there's
an
input,
and
someone
needs
to
explicitly
use
a
variable
there
to
pass
that
propaganda
to
the
component,
or
do
we
want
to
make
it
possible
out
of
the
box
to
just
pass
all
the
variables
into
the
component?
C
B
B
Oh
you
mean
like,
instead
of
using
directly
the
the
viable
name
for
the
dollar,
sign
you
access
through
amp
dot,
whatever.
E
Yeah,
probably
or
and
then
yeah,
and
it
makes
it
make
it
a
part
of
the
input
syntax
whether
you
want
to
pass
variables
and
from
which
scope
do
you
want
to
pass
them?
It's
a
bit
more
complex
than
that,
because
it's.
C
The
second
question.
I
think
this
is
what
Fabio
you
asked
and
real
like.
If
you
include
a
component,
though
this
component
has
access
to
all
variables
that
were
defined
in
that
context,
or
rather
you
have
to
actually
specify
all
variables
in
that
component,
which
I
think
like
there
are
two
different
questions
that
that
I
think
you
asked
because
about
the
first
fun
fact
we
ask
about
the
second
one.
B
But
then
you
can
still
customize
those.
So
if
you
want
to
check
out
a
different
project,
you
pass
the
project
path
and
as
input
and
you
check
out
the
different
project,
but
by
default
it
will
be
the
current
Project
based
on
the
context.
E
B
Oh
yeah,
this
is
another
thing,
but
I.
B
I,
don't
think
we
should
do
that,
because
that
completely
changes
the
way
we
we
evaluate
variables,
I
think
variables
you
always.
We
should
always
evaluate
the
variables
from
the
project
that
is
running
the
pipeline,
but
somebody
might
you
know
in
the
I
can
play
project.
You
can
Define
like
a
project
variable
that
kind
of
overrides
everything
and
you
don't
have
control
to
decide.
C
B
So
the
the
using
the
top
level
variable
keywords
somehow
affects
whether
the
component
will
use
you
know
as
access
to
variables
or
not
because
it
doesn't
have
access
to
the
variables
action.
Sorry,
yes,.
B
C
I
well,
I
I
I
have
a
very
strong
opinion
on
that.
If
our
design
got
is
like
my
catalog
dropping
replacement,
we
have
only
one
way
to
do
it
with
a
path
to
Simply
4-bit
users
of
the
variables,
in
the
way
that
we
block,
let's
say
top
level
second
thing
because
like
it
opens
another
can
of
the
worms.
If
we,
if
we
let's
say
block
variables,
make
a
components
like
work
in
the
bubble,
how
then,
actually
accidents
work?
How
how
like
a
deep
match
of
the
job
works?
C
It
does
like
this
component,
like
this
job,
defining
a
component
that
is
running
in
the
bubble.
It's
going
out
of
the
bubble,
this
one
on
your
in
the
top
level,
GitHub
serum
right
aspect,
colon
like
it.
It's
like.
It's
opens
like
like
a
kind
of
the
problems
that
really
hard
I,
think
to
to
to
figure
out
how
it
should
behave,
but.
E
I
think
we
should
explicitly
State
like
the
goal,
I
think
and
that
you
may
disagree,
that
our
goal
is
to
move
away
from
The
Inheritance
model
to
composition,
model
and,
with
all
the
implications
of
doing
that,
I
think
it
will
be
very
difficult
to
make
it
a
complete
drop-in
replacement
the
new.
If
we
want
to
move
more
to
composition,
model
from
The
Inheritance
like
in
in
the
context
of
object,
oriented
programming
right,
then
the
implications
of
making
that
move
will
make
it
almost
impossible
for
us
to
build
a
completely
backwards.
E
Convertibly
compatible,
drop-in
replacement
because
the
the
the
this
principle
change
like
this,
like
you
know,
Paradigm
change,
is
going
to
be
too
significant
for
us
to
make
everything
backwards
compatible.
So
if
you
want
to
make
this
decision
that
we
are
moving
towards
the
moving
away
from
inheritance
to
composition,
there
will
trade-offs.
We
will
need
to
make.
B
If
we
were
making
our
predefined
variables
like
immutable,
then
we
pretty
much
could
say:
okay,
these
are
safe
variables
that
are
built
by
gitlab
that
you
can
use
them
like
as
a
context,
and
you
can
probably
access
them
through,
maybe
maybe
even
context,
Dot
and
variable
name.
You
can
only
access
predefined
variables,
you
wouldn't
have
any
other
sort
of
variables
and
this
might
be
already
kind
of
more
okay,
safer
and
and
for
from
a
composibility
perspective,
because
there
is
no
things
like
overriding
each
other.
B
It's
just
the
context
is
always
created
by
gitlab,
but
the
the
problem
is
more
like.
If
then
I
specify
a
variable
in
the
pipeline
in
the
main
pipeline,
the
main
gitlabsia
yaml
I
specify
a
variable
there.
Can
that
be
also
used
by
the
component.
That
is
is
being
evaluated
or
like.
Should
we
just
limit
to
predefined
variables
in
a
way
just
to
have
access.
E
And
what
about
this?
Like
simple
solution
like
use
Imports
with
the
Alias
like
Docker,
and
then
all
the
entities
and
resources
from
the
component
will
get
prefix
all
the
variables
defined.
There
will
get
the
prefix
all
the
global
keywords.
Perhaps
all
the
jobs
will
get
the
prefix.
You
will
still
be
able
to
use
the
component
as
a
regular
template,
but
you
will
have
an
explicitly
defined
prefix
for
all
the
resources
that
were
defined
there.
B
B
B
B
And
yeah,
but
what
I'm
wondering
is
that
maybe
it's
a
different
type
of
component,
it's
more
like
you,
want
to
include
jobs
rather
than
a
template.
Template
is
too
generic
and
so
like.
If
you
want
to
include
some
jobs,
it
makes
sense
to
somehow
have
a
prefix
or
something
that
doesn't
overlap.
B
B
So
to
move
on
with
the
you
know,
with
some
some
decisions.
What
so
do
we
agree
that
for
now
we
just
allow
variables
to
be
accessed
and
whatever
happens
in
the
in
in
the
presidents
of
the
variables
in
the
context
of
evaluation
context,
just
works,
as
is
with
with
templates
and
as
we
build
the
main
PC,
we
can
still
re-evaluate
that
to
say:
okay,
maybe
this
coin
goes
too
much
confusion
or
could
also
too
much
too
many
problems
with
inheritance.
B
So
you
can
decide
to
maybe
introduce
some
sort
of
context
object
instead
and
still
using
variables.
E
So
I
think
that
making
it
possible
to
evaluate
variables
when,
whenever
we
include
a
template
or
a
component,
is
bypassing
the
input
system.
It's
it's
just
a
different
way
to
pass
data
into
the
template
without
using
the
input
system.
So
if
you
want
to
actually
untangle
something,
then
I
think
it
would
be
reasonable
direction
to
require
users
to
use
input,
a
keyword
to
actually
access
variables
from
the
in
from
the
project.
That
is
including
the
template.
A
E
A
Need
to
have
access
to
those
to
those
variables.
Okay,
they
are
like
the
the
variables
that
we
Define
in
the
in
the
UI
to
project
settings
the
variables
that
we've
defined
in
like
the
global
Global
variables
and
templates
or
components,
will
need
to
have
access
for
that.
So,
if
doing
that,
using
like
the
inputs
makes
sense
this
way
we
we
have,
the
user
will
have
a
way
to
block
that
if
they
don't
want
to,
and
they
will
have
a
way
to
to
access
those
templates.
B
I
I
think
there
is
something
that
more
like
a
middle
ground,
because
even
if
like,
if
everything
needs
to
be
required
to
be
passed
as
input,
there
could
be
scenarios
like
where,
like
like
the
context
variables
the
predefined
variables.
Why
do
I
need
to
pass
in
something
where
I
should
be
able
to
access
CI
project
paths,
because
this
is
going
to
be
evaluated
in
that
project
right?
B
And
so
the
scenario
of
the
actions
check
out
GitHub
action
like
why
do
I
have
to
provide
what
to
repository
to
check
out
if,
by
implicitly
it
could
take
it
from
the
context
and
say:
okay,
if
I
don't
specify,
you
can
check
out
another
project,
but
if
I
don't
specify
it
just
check
out
the
current
project
and
kind
of
provides
like
a
safer
like
a
handier
way
of
having
the
the
component
to
get
what
you
need
from
a
from
from
a
list
of
safe
values.
B
So
that's
really
what
what
the
difference
is
so
maybe,
rather
than
having
access
to
all
variables,
there
could
be
access
to
some
gitlab
defined
variables
that
we
can
guarantee
them
to
be
mutable,
so
I
think
maybe
something
I.
Don't
know
I'm
not
sure,
but
like
it's
something
we
could
explore
is.
Could
we
create
something
similar
to
the
GitHub
context
where
we,
as
we
build
the
predefined
variables,
rather
than
defining
them
as
environment
variables?
We
Define,
we
Define
a
context,
data
context
and
those
will
can
be
accessed
from
there.
B
So
then,
if
you
create
like
an
environment
variable
that,
can
you
try
to
override
predefined
variables,
it
wouldn't
work
because
those
you
cannot
override
the
context.
You
know
you
can
specify
an
environment
variable,
but
if
you
then
access
that
variable
from
gitlab
dot,
whatever
variable
name
you're
not
accessing
through
the
dollar
sign
variable
name.
E
This
this
is
actually
something
that
cami
suggested
how
we
could
solve
like.
On
the
Ruby
side,
we
would
only
use
the
square
brackets
in
on
the
on
the
runner
side.
We
would
only
use
the
curly
brackets,
and
this
is
a
very
good
solution.
I
think
that
this,
what
that
is
what
the
GitHub
is
doing
as
well,
so.
B
Yeah,
what
I'm
saying
is
that
if
we
had
a
way
to
to
have
immutable
variables,
like
the
the
context
where
we
all
our
predefined
variables,
are
actually
mutable
and
being
generated
by
the
by
git
lab
and
not
being
generated
as
independent
environment
variables
will
be
like
an
object
that
you
can
access
like
the
way.
We
say
you
know:
gitlab,
dot,
CI,
project
path,
gitlab
dot,
you
know
current
user
name
and
and
you
where
you
cannot
really
override
those
and
those
are
safe.
B
Then
you
should
be
fine
for
the
con
for
the
component
to
access
those
but
I.
Think
it's
where
we
don't
want
to
blur.
The
lines
is:
can
we
access
environment
variables
and
I?
Think
environment
variables
shouldn't
be
accessed?
We
could
probably
access
a
context
and
the
inputs
and
everything
should
be
passed
through
either.
The
context
is
predefined
there
for
you
to
use
or
the
inputs
that
are
being
passed
from
for
extra
customization
yeah.
E
I
I
think
that
the
discussion
has
gotten
a
bit
too
complex
and
I'm
losing
track
of
all
the
threats
already
so
I
suggest
that
we
actually
document
the
questions
that
still
need
answers
somewhere
and
try
to
actually
make
some
progress,
I
think
and
schedule.
Another
meeting
like
that,
because
my
like
writing
is
already
like
overloaded
with
ideas
and
data
here.
So.
C
I
I
was
proposed
that,
like
we
take
syntax
provide
example
and
describe
in
detail
how
it's
gonna
behave.
Just
just
do
it
like
describe
in
detail
how
it's
going
to
behave?
How
like
variable
is
going
to
be
it's
much
easier
to
talk
about
like
the
specific
behavior
and
then
you
can
point
out
behavior
that
we
don't
like
and
figure
out
how
it
should
behave
differently.
C
C
So
I
I
think
like
I.
The
best
would
be
like
we
write.
Example.
We
describe
exactly
user
flow,
how
user,
like
does
everything
and
how
it's
actually
executed?
What
is
like,
what
are
the
variables
available?
How
you
pass
these
inputs,
like
example,
like
with
the
things
that
we
want
to
implement
for
MVC,
then
we
can
talk
about
this
specific
workflow,
including
the
syntax.
A
A
B
Yeah
I
would
say,
like
let's
schedule,
a
call
when
we
know
we
are
stalling
the
discussion
on
something,
because
if
there
is
like
a
good
discussion
flow
in
the
issue,
we're
seeing
with
a
lot
of
ideas,
I
I
think
it
might
be
more
beneficial
to
have
you
think
discussions,
but
that's
my
take.
But
then,
if
you,
if
you
see,
we
are
stalling
on
certain
things
that
require
this
discussion,
we
can
have
a
simple
on.
E
On
the
other
hand,
having
a
meeting
approaching
is
a
good
motivation
to
actually
make
better
progress
with
us
in
conversations.
So
for
me,
usually
it
works
better
to
have
a
meeting
schedule
so
that
I
know
that
I
don't
have
much
time
to
actually
bike
it,
and
you
know
just
okay,
it's
time
to
make
some
progress.
C
B
C
E
I
can
write
my
examples
in
the
like
a
couple
of
them
actually
I
think
anyone.
E
A
B
I
think
in
the
issue
we
have
different
threads,
that
we
can
continue
discussion
in
and
if
there
is
any
other
aspects
like
you
know,
should
we
you
should
we
allow
variables
or
other
things
we
can
create
new
threads
and
in
this
course
there
for
specific,
you
know
topics,
and
then
we
can
consolidate
decisions
into
the
example
that
drivers
is
going
to
create.
So
we
kind
of
have
like
a
a
source
of
Truth
or
that
we
are
going
to
implement
and
as
we
come
up
with
certification
or
changes,
we
update
that
to
say
okay.