►
From YouTube: CI component catalog - meeting 2
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
Okay,
so,
as
I
mentioned,
the
song
you
just
joined,
there
are
some
open
threads
on
the
issue
that
we
are
all
collaborating
on
and
I
propose.
We
will
go
over
those
open
threads
and
things
that
we
did
not
come
to
an
agreement
or
consensus
or
decision
has
made,
so
we
can
go
over
them
one
by
one.
A
Good,
okay,
I'll
start
with
the
top
level
keywords
like
variables
stage
workflow,
and
there
is
like
a
there's,
a
long
discussion,
but
basically
I
think
the
the
main
I
would
say
problem
problems
that
I'm,
seeing
we
have
seen
is
that
if
we
will
allow
a
component
to
use
a
top
level
keyword,
it
will
affect
practically
all
the
pipelines,
all
the
components,
even
components
that
were
not
nothing
was
defined.
A
There
is
part
of
like
the
top
level
keywords
and
will
be
affected,
and
so
I
guess
the
like
trades
trade-off
of
blocking
versus
allowing
users
to
use
the
keywords
and
and
like
let's
I
mean
let's
discuss
that
I
mean
let's
think
about
what
what
are
the
opinion
here,
like
obviously
blocking
you
blocking
users,
I
would
say
would
would
allow
the
component
to
be
may
be
well
defined.
A
What
structure
everyone
will
know
what
this
component
is
doing,
and
it
will
not
affect
anything
else,
but
in
terms
of
like,
if
we
will
allow
it
and
then,
as
I
mentioned
it
will,
it
will
affect
it
and
Camille.
You
mentioned
that
that
if
we
block
a
top
level
keyword,
it
will
not
make
an
existing
template
to
be
able
to
use
the
catalog
and
so
I
think
that
the
the
overall
idea
it's.
B
It's
great
like
if
we
can
block
like
the
top
level,
it
actually
makes
it
easier
because,
like
we
can
offer
them
like
them,
so
I
think
starting
more
restrictive
is
always
better
I
mean
for
us,
because
it
allow
us
to
learn
and
kind
of
offer
more
features
over
time,
but
then
I
think
it's
like
for
me.
It's
like
the
question
to
you
essentially
like
what
you
want
to
achieve
in
the
CI
catalog
first
iteration.
B
That
would
make
our
customers
happy
because,
like
if
we
block
these
top
level
keywords
to
existing
templates
that
people
may
be
using,
they
will
not
be
able
to
use
them
unless
they
kind
of
rewrite
them.
With
the
cycle
topic
and
I.
Remember
that
one
of
the
design
goals
that
you
mentioned
was
that
like
people
should
use
the
existing
templates
with
the
minimal
efforts,
so
I
think
like
I,
would
love
to
hear
from
you,
like
the
clarification.
B
Do
you
kind
of
are
fine
with
just
saying
that,
like
okay,
we
block
this
for
the
sake
of
the
future,
let's
say
better
design
of
the
catalog,
but
it
may
put
a
little
more
effort
on
existing
customers.
B
That
would
like
to
use
catalog
because
I
think,
like
this
kind
of
there's
like
two
structural
aspects,
that
we
discussed
blocking
top
level
keywords
like
a
default
variables,
also
I,
think
image
services,
which
is
like
one
of
the
aspects
and
the
second
aspect
of
the
what
we
would
blog
for
the
component
initially
cycle
include
keyword
that
we
discussed
I
think
the
last
time.
So
this
would
be
like
the
like
two
forbidden
types
of
the
syntaxes
in
the
in
the
CI
catalog
templates.
B
So
I
think
it's
really
like
essential
like
to
figure
out
if
this
is
like
acceptable
to
block
it
initially
to
better,
maybe
hamper
maybe
kind
of
break
this
rule
of
that
we
allow
all
of
existing
templates
to
just
be
use
catalog
out
of
the
box,
but
kind
of
looking
over
like
a
longer
term.
Maintainability
of
the
template
count
dialog.
A
Ue
yeah
I
mean
quite
honest.
It's
hard
it's
hard
to
tell
now,
and
you
probably
need
to
do
some
validation.
So
maybe
this
is
a
point
that
we
can
decide
later.
If
we
want
to
block
or
not
block,
and
if
we
we
probably
need
to
think
about
okay,
if
we
are
not
blocking
what
are
we
going
to
do?
Are
we
going
to
tell
the
user
hey?
A
This
is
not
the
recommended
way
we're
going
to
use
something
like
the
prefix
that
Gregor
suggested
to
me,
I
feel
like
I
mean
as
long
as
since
we
evolved
these
discussions
from
from
several
months
weeks
ago,
I
would
say:
I
do
see
the
component
as
like.
Probably
something
like
new,
that
we
are
going
to
to
introduce
to
users
and
I
mean
templates
will
always
be
there.
So
it's
not
that
we
are
telling
the
customer
hey.
A
B
A
B
Like
a
feedback
from
the
user,
I'm
kind
of
primarily
asking
like
about
like
the
the
the
the
guideline
from
you
like
I
I,
think
like
Fabio,
correcting
me
if
I'm
wrong,
but
we
would
love
to
actually
block
them
right.
We
have
the
desire
to
maybe
figure
out
if,
if
there
are
like
a
valid
use
cases
to
unblock
them
later
so
I
I
I
think
this
probably
would
be
our
recommendation.
B
We
just
block
them
for
now,
because
it
makes
it
easier
to
unblock
them
later
than
allow
everything,
because
it
makes
it
really
hard
to
block
them
later,
because
it
will
be
breaking
change.
So
this
is
I'm
kind
of
my
way
of
thinking
that
if
we
can
block
that-
and
you
are
fine
with
that-
I
think
we'll
actually
prefer
to
block
them.
C
I
think
the
initial
feedback,
I
think
from
from
users
will
be
like.
Oh
I,
now
have
to
rewrite
my
template
I,
but
I
I.
Don't
think
we
should
expect
that
that
kind
of
bit
of
pushback
but
I
think
we
need
to
really
understand
them.
But
this
is
why
I
think
the
dog
fooding
phase
with
the
engineering
productivity
is
important
because
it
allows
us
to
discuss
with
them.
C
Like?
Are
you
writing?
Are
we
writing
the
the
templates?
You
know
not
following
the
right
standards
or
why
do
we
need
to
include
use
the
include
within
a
component
or
why
do
we
need
to
Define
top
level
keywords
and
have
this
kind
of
discussion
for
us
to
understand
what
are
the
real
requirements
there?
C
What
are
the
real
problems
to
solve,
and
so
this
way
I
think
if
we
block
them
initially
and
then
during
the
duck
fooding
phase,
you
know
which
we
have
more
information,
whether
we
want
we
need
really
to
add
top-level
keywords
or
just
simply
a
way
of
for
the
user
to
think
differently
on
how
they
can
design
the
components.
Even
if
some
that
means
sometimes
you
need
to
duplicate
things
which
might
be
just
fine
and
not
necessarily,
you
know,
a
decouple
like
dry
everything
and
just
and
use
include
all
the
stuff
I'm.
B
I'm,
like
I'm
like
one
of
these
persons
using
different
CI
systems
and
I
love
the
application.
It's
just
way
easier
to
manage
stuff
drying.
Stuff
is
like
something
that
you
may
be
doing
over
time,
but
probably
at
least
like
in
the
cases
that
I
use
like
I
very
rarely
do
spend
time
on
the
drying
stuff.
B
If
something
works,
as
long
as
it
was,
then
I
can
update
that
so
I
I
was
kind
of
say
that
in
case
of
the
CI
system,
the
application
is
like
a
userably,
a
way
of
like
how
you
like
implement
the
system,
because
how
CI
systems
are
complex,
I.
D
D
This
allows
the
usage
of
workflow
like
it
means
that
the
template
won't
be
cohesive
in
some
way,
because
they
would
need
to
duplicate
some
core
ideas
from
the
template
or
just
Implement
them
separately,
and
the
template
that
they
are
working
on
won't
be
like
a
whole.
It
will
be
divided
into
different
parts
that
they
will
need
to
actually
Implement
on
on
their
site.
In
some
way,
I
mean
the
workflow.
D
The
workflow
keyword
describes
how
you
can
run
pipelines,
for
example,
that
all
the
jobs
inside
your
pipeline
will
only
work
from
for
merge,
request
pipelines
and
then,
if
we
disallow
the
usage
of
workflow,
it
means
that,
if
someone
designs
their
template
in
a
way
that
it's
only
valid
for
merge,
request
pipelines,
they
can
encode
that
knowledge
in
inside
their
template,
and
it
makes
me
think
that
we
are
actually
trying
to
fix
templates
in
a
similar
way.
D
We
would
like
to
fix
like
inheritance
in
a
programming
language,
I
I,
see
many
parallels
between
what
templates
are
how
we
compose
our
configuration.
Ci
configuration
many
parallels
between
this
and
software
engineering
and,
like
object,
oriented
programming,
we
are
trying
to
move
away
from
The
Inheritance
model
to
the
composition
model.
Yet
I
don't
know
really.
If
we
can
do
that
with
templates
without
completely
breaking
compatibility,
I
think
it's
a
flowed
as
an
assumption.
We
just
can't
fix
templates
without
breaking
compatibility.
D
So
what
I'm
trying
to
say
here
is
that
I
I
did
explore
this
idea
of
prefix
I
did
explore
a
bunch
of
other
ideas
to
move
us
towards
more
like
the
composition
model
and
composibility,
but
it
with
templates.
D
It
might
be
really
possibly
well
significantly
changing
the
you
know,
Paradigm
of
how
we
like
use
them
and
how
to
configure
them.
So
I
think
that's
what
what
I'm
trying
to
say
is
that
we
can
probably
improve
templates,
but
we
won't
be
able
to
fix
templates
and
that's
that's.
What
I'm
worried
about
and
I
definitely
believe
that
interpolation
in
a
way
that
you
are
suggesting
it
will,
will
improve
templates,
but
it's
not
going
to
fix
templates
and
I'm
slowly
losing
hope
that
we
won't
be
able
that
we
will
be
able
to
fix
them.
D
B
I
think
the
problem
that
you
are
describing
is
Way
Beyond
templates,
it's
like
a
problem
of
figuring
contract
includes
better
infrastructure
for
dependent
pipelines,
dependent
workflows,
many
workflows,
extends
keyword,
yaml,
syntax
and
I
I.
Think
it's
not
really
like
a
component
thing
like
we're
kind
of
working
with
the
constraints
and
like
designs
of
the
current
system,
and
until
you
start
something
new
complete
besides,
it
may
be
impossible
to
change
the
behavior
of
the
current
system,
because
you're
gonna
inadvertently
break
like
a
lot
of
people
workflows
how
they
are
running
a
bit
today.
B
I
I,
don't
agree
like
about
the
the
the
comment
about
the
workflow,
but
some
components
may
require
the
same
magic
password
for
and
we
don't
have
like
a
solution
to
ensure
that
but
I
also
kind
of
want
the
I
don't
know
how
he
would
like
want
to
like
in
like
support
that
like
what
would
be
like
the
the
pattern,
because
we
are
still
very
early
like
in
the
component
design,
so
I
think
it
may
be
kind
of
like
pre-optimization,
similar
to
what
we
discussed
with
this
top
level.
B
Other
things
that
we
discussed
like
how
we
support
many
workflows
that
are
concurrent
that
maybe
they
are
executed
on
on
the
different
conditions.
We
also
don't
know
that
yet
so
I
I'm
kind
of
like
I
I'm
hearing
that
problem
and
I
see
this
also
as
a
problem,
but
I
think
we
don't
have
like
even
like
a
good
idea.
What
we
want
to
achieve
and
like
how
we
would
want
to
this
kind
of
filtering
in
this
type
of
the
problem,
because
I
think
we
should
kind
of
also
think
better.
B
How
and
when
are
maybe
pipelines
like
created
if
you
would
start
to
have
more
event
types
because
I
think
like
the
primary
use
of
at
least,
let's
say
this
rule
that
you
mentioned
for
the
match,
request
I!
Think
it's
not
really
merge.
Requests
I.
Think
like
it's
more
expected
that
we're
gonna
have
a
component
that
let's
say
it
closes
the
issues
automatically
after
30
days
of
no
activity,
I.
B
Think
it's
like
more
disruptive
between
the
current,
a
CI
type
of
the
workflow
versus
a
general
type
of
the
workflow,
and
but
then
it's
also
probably
tricky
case,
because
maybe
it's
something
to
be
executed
as
part
of
the
CI
workflow.
We
just
kind
of
do
it
with
some
specific
tasks.
Just
close
this
issue
somehow
automatically
or
like
post
a
comment
when
this
pipeline
passed
pushing
notifications,
I
don't
know
there
is
too
many
I
like
things
here,
I
don't
know.
D
When
I
understand
what
you're
saying
but
I
I
now,
what
I
would
say
is
that
I
I
believe
that
what
we
need
right
now
is
to
make
some
decisions
that
will
keep
the
highest
amount
of
doors
open
and
won't.
Actually,
then,
will
allow
us
to.
You
know,
increase
the
amount
of
choices
we
will
have,
rather
than
decreasing
the
amount
of
choices
that
we
will
be
able
to
make
after
we
move
towards
like
subsequent
iterations.
D
So
how
I'm,
seeing
that
I
think
that
there
are
two
things
that
we
we
need
a
few
things
that
we
need
to
make
a
decision
on
soon
if
we
want
to
actually
move
forward
toward
with
the
implementation-
and
that's
the,
in
my
opinion,
the
magic
files
decision
where
and
how
do
we
store
metadata
and
then
decide?
What
do
we
want
to
do
with
the
templates
and
I?
D
Think
that
probably
the
most
reasonable
solution
is
to
reduce
the
interpolation,
because
it
greatly
can
improve
templates
for
people
that
want
more
compatibility
and
more
same
behavior,
yeah
and
then
and
then
I
would
like
completely
prohibit
the
possibility
to
use
include
outside
of
the
Sha
of
a
given
component.
So
you
can
include
files
from
within
the
git
repository,
but
you
can
do
that
from
different
components
or
different,
like
files
like
remote
files.
D
Project,
no,
you
know
same
project
it's
in
the
within
within
the
same
gitsha,
so
you
you
can
definitely
include
a
component
from
the
same
gitsha,
but
you
should
not
do
that
in
this
iteration
from
a
different
repository
or
from
what
is
even
worse,
like
remote
file.
That
can
change
at
any
time
without
any.
You
know
worrying,
so
so.
I
I
think
that
and
and
like
that's,
also
an
important
decision
that
we
want
to
include
workflow
and
and
variables
at
top
level.
I
think
that
I
would
probably
still
allow
doing
that.
D
I
don't
see
like
I,
see
more
problems
with
not
allowing
that
than
with
allowing
that
probably,
but
it's
something
I,
perhaps
I,
don't
have
really
a
strong
opinion
about,
but
I
I
I
would
like
us
to
focus
on
the
magic
file,
names
and
the
metadata
location
and
how
we
actually
include
component,
how
we
solve
which
component
needs
to
be
included,
and
then
that's
probably
the
most
important
one.
Okay,.
A
It
yeah
we
can
think
about
it
if
we
want
to
include
like
the
top
level
keyword
and
okay,
let's,
let's,
let's
move
on
with
the
magic
file
name,
who
wants
to
go
first.
D
I
started
that
I
I
think
that
the
it's
it's
additional
coupling
that
we
would
introduce
into
the
system,
it's
coupling
with
a
magic
file,
location,
magic
file,
name
and
now
I
do
see
things
that
it's
changing,
but
I
believe
that
we
can
actually
reduce
this
coupling
by,
for
example,
using
the
top
level
metadata
file,
that
is,
configuring
all
the
locations
of
other
metadata
files
in
the
in
the
in
the
catalog
or
just
templates
on
in
the
in
the
Repository
there
are.
C
A
C
Things
that
I,
when
I,
wanted
to
downside,
I
think
of
the
top
level
metadata
well
I,
do
like
the
idea
of
some
kind
of
routing
system
that
tells
you
okay,
this
is
the
component,
so
you
see,
these
are
some
of
the
components
we
have
in
this
project
and
here's
where
you
can
find
them.
C
The
problem
is
sometimes
it
could
be
that
if
you're
using
a
component,
it
just
points
to
a
specific
directory
directly
in
order
to
use
it,
we
might
need
to
first
read
the
routine
table
or
the
rooting
metadata
file
or
whatever
it
is,
and
then
from
there
read
the
actual
file
that
we
for
of
the
components.
So
it
means
every
time
we
use
a
component.
We
might
need
to
read.
You
know
twice
two
files,
something
like
that.
What's
these
two
locations
we
need
to
read,
this
is
one
of
the
downside.
C
In
my
opinion,
I
do
like
I,
wouldn't
consider
those
like
magic
file,
names
but
more
conventions,
but
it's
it's.
It
depends
like
how
complex
they
come.
We
want
their
inventions
to
be.
You
know
anything
is
a
convention.
Even
the
fact
that
we
say
component
needs
to
be
placed
you
know
in
the
directory
and
that
director
there
has
to
be
like
a
readme
readme
markdown
file.
This
is
a
convention,
but
like
it's
more
can
we
use
you
know?
What's
the
simplest
type
of
convention,
maybe
we
can
have.
C
I,
don't
know
so
so
I
I
think
the
kind
of
the
discussion
primarily
is
more
like.
Do
we
like
the
git
lab
Dash
type,
yaml
file
that
where
we
impair
the
type
of
the
component
from
the
file
name
or
we
want
to
use
something
like
a
you
know
like
a
generic
component
yaml
and-
and
you
always
read
that
file
and
inside
that
file.
There
is
everything
we
need
to
to
process
that
component
from
the
metadata
to
the
input
to
to
the
actual
content.
C
In
my
opinion,
the
the
more
components
ourselves
defined
rather
than
depending
on
another
thing
or
the
sits
somewhere
under
the
top
level
directory
of
the
project,
the
better
yeah.
So
that's
my
in
my
opinion,
so
we
should
be
able
to
read
the
specific
components
without
knowing
what
else
to
to
get
information
from.
B
I
would
probably
say
that,
like
convention
is
a
convention
and
with
the
version
you
can
break
conventional
because
you
follow
the
convention
and
Convention
can
change
because
you
have
different
passion.
You
just
follow
different
conventions,
so
we
can
start
with
gitlab
Dash
template
yml
and
per
component
component
per
directory,
readme
MD,
being
very
opinionated,
How,
We,
Do,
It
and
like
being
very
expensive.
This
is
how
you
do
it.
This
is
our
prescribed
way,
but.
B
You
kind
of
do
something
different,
but
I
think
like
in
other
case,
you
have
everything
all
over
the
place
so
like
it's
much
better
on
top
of
existing
convention
to
add,
maybe
some
additional
ways
how
it's
being
used.
D
Yeah,
but
the
problem
is
here,
is
that
that's
the
file
in
which
you
define
the
version,
so
you
can't
decide
what
version
to
use
when
you
don't
know
what
the
version
is,
because
it
might
be
defined
on
that
file.
But
perhaps
in
this
strategy
we
don't
really
read
that
file.
So
if
we
can,
if
you
know
design
a
system
in
which
we
know
which
version
to
apply
for
a
given
project,
then
we
can
change
those
strategies.
Probably.
B
Yes,
so
maybe
I
guess,
like
I,
think
there
are
like
two
aspects
really
like
metadata
to
describe
a
publishable
components.
This
is
something
that
we
want
to
do
is
attract
top
level.
I
mean
sorry.
There
are
like
three
ways
like
no.
It's
like
okay,
three
ways
like
first
way
metadata
at
the
top
level
describing
all
export
table
templates
with
a
path
whatever.
This
is
like
a
yamun
path
or
a
directory
path.
This
is
one
thing.
B
This
metadata
has
a
version
and
it
references
a
very
specific
yamul
or,
like
a
director
version,
number
two:
you
have
you
don't
have
top
level
metadata.
You
have
metadata
pair
component
directory,
that
is
alongside
the
template,
but
template
itself.
Okay,
sorry,
one
smartphone
get
back
to
the
first
one.
First,
one
you
have
metadata
at
the
top
level
and
this
metadata
lists
all
export
table
templates
within
this
project.
Now,
in
this
case,
does
it
is
this?
Template
defines
specification
of
inputs,
outputs
name,
description,
everything
in
a
header.
B
This
is
version
number
one
version
number
two.
You
don't
have
metadata
volume,
another
top
level
you
have
metadata
alongside
the
specific
component.
Your
template
describes
only
specifies
inputs
so
basically,
like
I,
say
function
header
with
arguments
that
is
allowed
and
but
alongside
you
have
metadata
ymr
that
specifies
maybe
version
maybe
specifies
metadata
that
are
not
template
specific,
but
more
like
an
auto
license.
B
Person
number
three:
you
have
you
don't
have
metadata
at
any
level.
You
just
have
a
single
template,
yml
file
that
specifies
let's
say
the
specification
of
inputs,
name
out
or
whatever.
B
So
this
is
about
like
metadata,
then
the
second
thing
is
about
what
type
of
the
convention
you
use,
because
you
can
actually
use
convention
in
case
number,
one
which
is
like
top
level
metadata.
You
have
to
use
convention
in
case
number
two
you
have
to
have
convention
for
the
metadata
file.
You
have
this
convention
in
number
three.
B
If
you
don't
use
convention
in
number
one,
then
you
kind
of
have
to
specify
each
individual
file
explicitly,
but
then
I'm
gonna
ask
we
list
in
the
metadata
or
export
table
components.
We
also
talked
about
using
internal
components
in
the
specific
product.
How
we
want
to
achieve
that,
or
this
is
no
longer
a
feature
like
do.
We
also
have
to
list
all
internal
components.
Maybe
we
have
GitHub
repository
that
just
implements
components
for
their
own,
because
it's
like
a
convenient
way
to
do
it.
It's
like
very
prescriptive.
B
So
now.
This
GitHub
repository
should
also
contain
githra
Dash
components
to
expose
these
internal
component,
because
you
have
to
go
through
this
routing
file
to
find
this
internal
component
or
it
kind
of
follows.
The
convention
of
two
or
three.
B
D
But
I
think
we
think
we're
somewhere,
but
I
have
one
one
crazy
proposal.
I
actually
talked
about
that
already,
but
I
I
kind
of
you
know
it
kind
of
takes
with
me.
I
know
it
might
not
be
valid.
So
how?
Because
the
reason
why
I
one
of
many
reasons
why
I
don't
like
those
magic
file
names?
Is
that
I
remember
what
happened
when
we,
when
we
had
a
very
valid
use
case
from
Debian
project,
to
change
the
location
of
gitlab
Cima
and
we
had
to
add
configuration
that
now
allows
you
to
point
different
directory.
D
It's
usually
usually
a
Debian
subdirectory
in
a
project,
because
that's
where,
when
I
used
to
be
a
Debian
developer,
we
use
that
directory
to
put
all
the
metadata
about
a
component,
a
Debian
package
inside
like
it's
Debian
directory
and
it
described
everywhere
what
what
is
inside
the
project
very
similar
to
The,
Dot
gitlab
directly.
Actually
so
I
remember
that
we
had
had
to
do
that.
D
So
my
idea-
and
now
we
have
the
whole
infrastructure
to
point
GitHub
to
that
GitHub
cim
file,
wherever
it
might
be,
it
might
be
in
the
top
level
in
a
sub-level
somewhere.
So
my
crazy
idea
here
is
why
we
can't
just
add
the
components
keyword
to
GitHub
crown
that
will
specify
an
array
of
subdirectories
in
this
project
and
then
in
every
subdirectory.
D
You
would
have
a
yam
file.
That
is
a
complete
metadata
for
this,
given
template
with
all
the
inputs
and
all
the
stuff
name
description.
Yet
in
this
top
level,
gitlab
CI
yaml
file,
we
would
have
just
components
and
the
version
convention
invention
number
right,
so
it
would
be
version
one
how
we
store
components,
how
we
resolve
metadata.
D
Now
we
have
the
entire
infrastructure
in
place
to
know
where
this
like
file
is
going
to
be,
and
then
in
this
gitlab
CM
yaml
file.
We
will
simply
have
the
list
of
paths
to
the
metadata
yamus
for
every
given
component
in
this
project.
C
C
So,
ideally,
I
would
like
to
go
straight
to
that
location
or
even
a
specific
file,
even
without
even
knowing
the
type
or
anything
just
read
one
time
ideally,
and
we
have
a
path-
and
we
just
do
one
gitile
request,
read
that
file
or
all
request
or
get
a
request
or
whatever
we
could
decide
to
do.
Object
Store,
whatever
we
decide
to
yeah
one
gitly
request
to
whatever
so
and
just
to
have.
This
is
the
ideal
scenario:
I
don't
need
to
go
to
the
project.
C
C
But
we
are
talking
about
different
use
cases
I'm
talking
about
the
from
the
point
of
view
of
consuming
a
specific
component.
D
Yeah,
so
you
include
the
whole
project,
you
you
read,
the
you
read
the
GitHub
yaml
and
one
of
the
entries
will
describe
the
top
level
component.
There.
D
D
With
the
includes
so
the
component
is
just
metadata
description.
It
will
make
it
easier
for
you
to
consume
the
list
of
those
components.
So
I
can
imagine
that
having
components
keyword
in
the
GitHub
Cil
will
give
you
some
additional
features
to
test
them
more
easy
in
a
bit
more
easy
way.
But
it's
like
decoupled
from
the
processing
of
that
young
file.
How.
B
D
So
it's
like
you
already
know
where
to
look
for
that
version
and
that
that's
I
believe
the
missing
piece
of
the
puzzle
where
to
specify
the
version
of
this
convention
where
the
thing
things
are,
what
are
the
names
of
the
components
of
the
magic
file
names?
You
know
what
kind
of
strategy
we
use
to
actually
build
a
component
in
the
catalog.
B
I
I
think
it's
I
think
that
design,
where
you
kind
of
put
something
of
different
purpose
in
the
GitHub
serial
of
different
purpose,
I
think
it's
much
better
just
to
have
a
top
level
metadata.
That
has
a
very
specific
purpose
and
is
simple,
and
it's
like
it's
like
it's.
It's
like
not
conflicting.
What
is
that,
because,
like
components,
keyword
means
like
like
windows
are
applies
very
special
parsing
to
the
components
that
is
different
to
other
parts.
B
If
we
simply
discount
everything,
look
only
at
the
components
we
discard
includes
and
then
like
we're,
gonna
have
customer
coming
to
us.
Hey
I.
Have
this
very
prescriptive
way?
How
I
use
components
can
I
use
inputs
for
that
and
then
I
click
on
and
say
no,
but
why
I
cannot
do
it,
because
this
is
our
design
like
I,
don't
know.
D
D
Then
you
can
probably
consume
them
easily
in
your
GitHub,
because
you
want
to
test
them
anyway.
So
if
you
specify
components
in
your
GitHub
CRM,
you
can
easily
you
know
test
them
because
you
already
know
where
they
are,
and
you
can
have
means
of
you
know
Arch,
including
them
into
your
top
level.
Gigasm.
D
C
C
D
There
are
like
the
the
main
problem
here
is
that
we
want
to
be
able
to
change
the
like
conventions
right,
so
the
convention
might
be
what
what?
What's
the
name
of
the
yaml
file
inside
a
catalog?
The
convention
might
be
the
keywords
being
used
to
describe
metadata
right
so
in
in
order
to
change
this
convention.
We
need
to
specify
somewhere
a
version
of
this
convention.
Now
we
need
to
know
the
version
before
we
start
looking
for
the
files,
because,
in
between
different
conventions,
the
locations
of
the
magic
field,
high
names
can
be
different.
C
Because
I
I
understand,
but
the
way
I'm
wondering
whether
we
are
adding
a
an
unnecessary
level
of
configuration
and
because
this
will
change
basically
what
we're
saying
if
we
want
to
change
the
convention,
you
know
we
can
bump
the
version,
and
now
you
have
a
completely
different
set
of
conventions.
Why.
D
D
B
D
So
I
think
we
are
talking
about
slightly
different
things
here,
because
again,
what
are
what
I'm
talking
about
is
the
version
of
the
convention
of
naming
stuff
like
whether
it's
gitlab
Dash
template.yaml,
whether
it
is
a
directory,
is
it
or
total
level
or
or
not.
It's
like
it's
some
kind
of
a
convention
right.
So
whenever
we
publish
a
component,
we
need
to
know
this
conversion
because
we
need
to
know
which
files
to
read,
because
we
don't
want
to
read
every
file
in
the
project.
D
We
don't
want
to
find
all
the
young
files
parse
them
and
see
whether
there
is
some
kind
of
header
that
we
are
looking
for,
because
it
would
be
inefficient.
So
when
we
publish
a
component,
we
need
to
know
which
version
of
a
convention
to
apply
to
parsing
this
component
and
exposing
that
in
the
CI
catalog.
So
there
are
two
ways
whether
to
have
a
a
single
place
to
store
that
inside
the
component
or
by
passing
this
very
convention
version
to
the
CI
catalog
endpoint.
That
will
make
that
we
publish
this
component.
I.
D
Think
that
if
we
want
to
have
any
kind
of
convention,
then
passing
the
version
of
the
convention
to
the
API
that
that's
probably
the
most
decoupled
way
I
can
think
of.
But
it
adds
additional
responsibility
to
the
user
that
they
need
to
know
which
version
of
the
component
they
are
trying
to
deploy
and
they
need
to
pass.
This
version
number
to
the
API.
D
Like
this
is
so
drastically
that
it
would
be
extremely
expensive
to
figure
it
out,
because
in
the
the
worst
case
scenario
is
that
you
would
need
to
read
every
young
file
in
the
repository
and
if
there
are
thousands
of
them,
this
can
be
extremely
expensive
operation
to
actually
publish
a
component.
That's.
D
B
But
like
then,
in
this
model,
like
you
have
convention
that
says
V1,
but
then
you
probably
apply
convention
V2
that
says
I'm
gonna,
first
reach
top
level
metadata
to
look
well.
But
how.
D
Does
gitlab
know
which
version
which
version
of
the
convention
you
need
to
apply
when
someone
deploys
or
publishes
the
company
the
catalog?
We
can't
read
that
from
repository,
because
if
the
convention
changes,
we
don't
know
which
file
to
read
and
if
you
either
make
this
an
immutable
file
somewhere.
D
C
Can
we
think
can
can
we
think
of
this
problem
kind
of
what
are
the
variables
we
can
remove
or
reduce
in
order
to
have,
you
know
to
can
reduce
the
chances
of
changing
convention
in
the
future?
So,
for
example,
if
we
are
currently
saying
a
file
needs
to
be
called
component
Dash
step
and
then
one
day
we
say
actually
step
should
not
be
supported
anymore.
It
may
be
remove
this
from
the
equation.
C
Maybe
let's
just
agree
on
that
name,
but
it's
just
always
the
same
and
like
reduce
the
chances
of
things
changing
in
the
future,
and
this
way
we
don't
need
to
discuss
about
like
having
a
way
to
process
like
because
then
we
have
a
version
for
the
convention
and
probably
a
version
for
the
syntax
and
and
then
the
version
of
the
component,
which
is
like
you
know
the
target
version
which
things
could
be
extremely
confusing
for
for
the
user,
yeah.
D
B
Responsibilities
and
making
things
like
even
more
conclusive.
Now,
like
let's
say
you
put
guitar
and
you
don't
want
to
run
any
pipeline
this
project
and
you
put
components
at
the
top
how
you
interpret
that
is
it
only
like
for
the
purpose
of
the
components,
but
it's
something
that
you
should
run
yeah.
D
I
agree
that
this
is
slightly
different
concert,
and
that
is
why
I
had
this
idea
to
do
that
differently
by
optionally
passing
the
version
of
the
convention
to
the
API
when
we
are
deploying
a
component
right
in
the
first
version.
We
want
me
to
do
that
because
there
is
just
one
way
to
read
files
Define
files,
but
in
the
second
version
we
might
add
a
version.
D
You
know
component
version
attribute
to
the
API
in
which
you
use
to
deploy
this
component,
the
CI
catalog,
and
then
you
know,
if
it's
not
the
previous
scheme,
if
it's
something
different,
then
you
will
need
to
provide
the
version
of
the
components
you
have
in
the
API,
and
this
way
it's
completely
coupled
from
files
that
are
anywhere
the
deployed
component
will
have
the
version.
C
Can
we
think
about
how
we
can
make
the
ux
instead
think
about
a
stable
ux?
So
what
are
the
things
we
know?
We
don't
want
to
change
in
the
future
instead
like
something
that
might
not
really
need
to
change
in
the
future
is
like
I
like,
for
example,
the
concept
of
how
silicon
CI
orbs
are
using
conventions,
which
is
you
specify
you.
You
have
like
a
directory
called
jobs.
For
example,
in
there
you
put
all
your
jobs,
type
of
components.
You
have
a
director
called,
maybe
workflows
in
there.
C
You
can
put
all
the
work
for
all
the
steps
to
go
into
a
specific
directory,
and
if
you
want
to
use
internal
components,
you
don't
need
to
even
specify
anywhere
else.
It
just
can
be
any
directory
in
the
inside
the
the
repository,
because
those
are
like
internal
preferences
and
then
inside
each
directory.
Let's
say
we
have
thus
slash
jobs
inside
there
there
will
be
like
a
directory
containing
the
components
that
we
we
want
and
inside
each
directory
there
is
like
a
a
simple
file,
even
called
whatever
component.yaml
and
inside
the
component.yaml.
C
We
have
everything
we
need,
so
we
just
need
to
read
one
file
based
on
a
single
convention
in
the
future.
We
decide
we
don't
want
to
support
templates
anymore.
We
simply
don't
read
from
the
template
directory
for
existing
components
for
new
components.
We
simply
put
like
a
new
rule.
Where
you
know
you
can't
publish
a
component
containing
that
directory.
C
D
Every
immutable
convention
is
a
tight
coupling
that
can
One
Day,
become
a
big
trouble
and
I
think
that,
for
example,
right
now,
we
do
have
this
big
trouble
with
gitlab
ciao
and
not
being
not
being
a
file
that
is
being
versioned.
That's
my
personal
opinion
I
think
that
what
Circle
CI
is
doing
with
their
SRC
directory.
D
It's
also
a
tight
coupling
a
convention
that
can
become
problematic,
so
one
there
are
like
one
solution
is
to
decouple
what
you
deploy
to
the
catalog
from
the
repository
in
some
way
or
from
the
files
for
location
of
them
in
the
repository
so
I
like,
for
example,
what
you
can
do
with
kubernetes.
You
have
a
deployment
manifest
that
can
be
stored
in
the
same
project,
but
it
can
be
stored
differently.
Why
can't
we,
for
example,
design
a
deployment
manifest
for
the
catalog
and
this
deployment
manifest
is
going
to
be
passed
to
the
API.
D
Whenever
the
deployment
happens,
then
someone
can
decide
to
read
that
from
the
current
project,
but
it
can
be
stored
separately,
perhaps
or
like
you
know,
I
don't
know
in
in
different
code
hosts
or
who
knows
so.
There
are
so
I
know
that
we
are
I'm
pushing
us
a
little
bit
here,
but
I
think
it's
very
important
to
think
about.
D
How
can
we
decouple
The,
Core
Concepts
and
not
to
get
locked
in
into
immutable
conventions
that
then,
can
completely
hamper
our
progress
and
velocity
at
some
point
and
become
huge
pain
in
the
ass,
and
that's
that's
what
I'm
trying
to
do
and
I'm
I'm
I,
don't
want
to
be
stubborn
or
something
I
just
want
to
explain
my
opinion
about
this
coupling
and
immutable
conventions
that
can
achieve
a
problematic
and
we
are.
We
do
experience
those
problems
already
with
many
different
parts
of
GitHub,
for
example,
I'm
kind
of
like
thinking.
B
B
I
I
did
not
see
that
here
today
they
would
change
convention,
so
I
think
like
whatever
we
like.
If
we
follow
the
conventional,
it's
not
that
like.
We
cannot
change
that,
but
on
the
other
hand,
if
we
make
people
to
configure
too
much
stuff,
it's
also
not
good
either.
It
actually
makes
it
harder
I
and
like
I,
still
go
back
to
these
magic.
Find
names
like
I
I,
have
very
valid
reasons
why
we
should
use
a
very
opinionated
names,
which
is
like
Way
Beyond.
B
What
system
can
do
I
mean
like
system
can
do
everything
like
if
we
have
to
pass
the
armor
files?
It's
definitely
the
way,
but
it's
more
like
engineering
at
all
and
we
could
figure
out
and
like
let's
say
we
follow
the
convention
that
uses
github.com.
We
figure
out.
Okay,
this
convention
is
not
good.
We
should
now
turn
the
convention
and
introduce
a
top-level
metadata
with
the
version
number,
and
this
defines
like
that.
This
is
different
conventions
simply,
and
it's
still
durable.
We
can
still
do
it.
Nothing
could
use.
D
D
B
D
D
B
B
C
Like
we
shouldn't
change
the
expectations
because
that
will
affect
the
user
is
a
lot
more.
It's
not
always
complex
for
us
to
maintain
different
conventions,
but
especially
costly
for
the
user,
because
they
have
they
need
to
learn
a
new
convention
and
they
need
to
probably
now
write
components
in
a
different
convention,
and
this
is
very
expensive,
in
my
opinion,
as
well.
As
you
know,
in
the
long
term
could
be
a
bad.
C
You
know
user
experience,
but
if
we
have
conventions
as
defaults
like
okay,
if
we
don't
configure
anything,
this
is
the
convention
just
put
a
stop
here
and
everything
works,
but
then
there
could
be
a
way
to
have
customization.
So
if
something
doesn't
work
for
you,
so
I
think
that
this
is
like,
in
my
opinion,
the
the
main
point
like
rather
than
thinking.
If
we
should
change
conventions
in
the
future.
B
I
think
that
that's
the
tricky
part
of
that
is
like
it's
gonna
work
in
the
case
of
the
actual
version
component,
but
our
well-being
says
that
we
can
be
friends
and
Char
and
any
branch,
and
it
can,
you
can
be
referencing
very
old
version
of
your
component
that
is
kind
of
following
completely
different
convention.
How
you
would
know
actually
that
this
is
what
is
the
convention
of
them
to
use?
If
you
base
your
like
decision
on
what
is
published
and
publish.
D
Means
it's
like
a
snapshot
at
the
given
moment,
so
does
it
mean
that
we
won't
be
able
to
Define
any
kind
of
like
processing
version
or
convention
version
in
the
database,
because
you
can
still
deploy
a
component
that
have
as
many
versions
as
you
have
shots
or
tags?
D
So
the
question
here
is
rather:
do
we
want
to
constrain
what
you
can
deploy
or
not,
and
perhaps
only
allow
access
through
a
tag
like
you,
you
can't
like
you
can
include
a
gem
from
a
ruby
gem
from
a
branch,
but
it
won't
be
done
through
a
group
gems,
probably
directly.
If
it
will,
like
you,
know,
use
the
different
different
conventions
to
actually
include
something.
So
I
think
that
that's
a
completely
different
question.
D
Yeah,
so
is
that
actually
a
good
design?
I
think
this
is
interesting,
because
with
one
entry
you
allow
people
to
access
your
their
component.
This
published
component
through
this
one
entry
in
the
CI
catalog
in,
like
probably
many
different
ways
that
can
result
in
a
completely
different
Behavior.
The
entry
in
the
catalog
won't
be
describing
the
single
behavior.
That
is
what
I'm
trying
to
say.
B
I
immediately
depends
like
how
you
access
your
component
because,
like
for
example,
what
five
yourself
like,
we
don't
access
components
directly,
maybe
via
catalog
we
access
component
information
directly.
We
are
Repository
so
now,
in
your
case,
what
you
are
describing
I'm
gonna
access
component
via
RP
that
is
published,
which
is
very
different
access
pattern
between
you
and
Fabio
and.
D
This
is
also
different
how
our
two
devops
did
that
they
had
this
actually
decoupled
storage
for
every
component,
and
only
single
version
for
for
for
a
component
that
they
would
include
them.
D
D
D
A
D
Yeah,
so
the
difference
would
be
that
having
a
convention,
the
way
that
Camille
and
Fabio
are
describing
would
specify
the
version
of
the
component
or
or
the
version
of
the
repository
of
the
components
in
the
file
inside
the
Repository,
and
that
we
wouldn't
be
able
to
easily
change
the
location
of
that
file.
That
describes
the
version,
because
then
you
know
if
that
changes.
D
We
don't
really
know
the
next
time
someone
publishes
a
component
from
which
directory
to
read
it
from
and
in
in
case
of
my
proposal,
is
to
add
an
optional
version,
keyword,
meaning
that
you
tell
gitlab,
which
version
of
the
Repository
components
repository
you
are
trying
to
publish
and
with
this
change,
GitHub
would
know
exactly
where
to
look
for.
D
D
D
Yeah,
so
in
that
case
we
probably
need
the
convention,
and
we
can't
rely
on
the
action
of
publishing
the
component
to
provide
any
kind
of
information
about
the
component
itself.
So
that's
kind
of
in
my
opinion,
problematically,
because
we
won't
be
able
to
change
the
convention
easily
and
it
makes
this
decision
about
what
the
magic
file
names
are
going
to
be
and
what
is
going
to
be
their
location
kind
of
immutable,
because
we
won't
be
able
to
easily
move
away
from
it.
C
Okay,
my
only
worry
that
I
just
put
in
the
chat
so
can
we
is
there
any
decision
we
need
to
make
in
this
call
at
the
moment
and-
and
we
make
sure
now
we
open
threads
or
specific
issues
or
anything
that
you
know
requires
more
discussion,
because
I
feel
there's
a
lot
of
interesting
ideas
and
probably
for
Anybody
Everybody
requires
more
time
to
digest
the
ideas
and
think
through
them
and
so
I
think
they
think
might
be
more
suitable
way.
D
I'm
in
a
different
call,
since
two
minutes
so
but
I
think
we
should
move,
discuss
a
little
bit
more
I
think
and
then
schedule
another
meeting
as
soon
as
possible,
because
all
the
conversations
that
we
are
having
are,
in
my
opinion,
just
essential
and
not
having
them
before
designing
music.
I
catalog
probably
would
make
all
the
decision.
Accidental
and,
like
you
know,
implicit
so.
C
I
want
I
think
it's
also.
You
know
important
to
kind
of
to
consider
the
fact
that
we
can.
We
are
going
to
have
dog
pudding
and
even
if
we
decide
to
start
without
version,
for
example,
and
then
say
Oh
actually
during
the
dog
Pudding,
we
require
Direction
and
we
need
to
change
and
make
Backward
Compatible
changes.
The
dog
pudding
phase
is
made
on
purpose.
C
For
that,
so
you
know
we
can
discuss
with
the
stakeholders
and
make
even
Backward
Compatible,
even
not
on
Backward
Compatible
changes
and
and
because
I
think
it's
important
that
we
can
start
to
think
about
something
and
test
it
real
life
component
and
not
try
to
think
up
front
of
all
the
possible
things
in
my
opinion,
because
otherwise
we
might,
it
would
they're
all
useful
aspects
to
be
considered.
So
I'm
wondering
whether
some
of
the
things
we
can
actually
have
the
benefit
of
discovering
the
real
needs
of
those
by
saying.
C
B
I
think
it
makes
sense,
I
I
think
like
what
I
would
like
to
learn.
I
wanted
to
learn
this
meeting
like
what
is
actually
MVC
and
the
iterations
that
we
want
to
achieve
in
the
three
Milestones
we've
described
the
goals
for
each
Milestone,
because
I
think
like
we
can
do
everything.
B
Every
idea
is
probably
like
to
Able,
but,
like
I,
think
it's
essential
for
us
like
to
limit
ourselves
and,
like
let's
say
getting
to
the
ca
catalog,
for
example,
in
the
free
milestones,
it's
actually
quite
a
quite
a
challenging
task,
because
yeah
catalog
is
also
like
a
front-end
that
user
and
can
discover
stuff.
It's
not
only
like
getting,
let's
say,
templating
syntax
components,
somehow
working,
but
also
like
publishing
and
presenting
that
and
I
I.
Think,
like
we
decided
for
that.
This
is
like
the
project.
B
It's
gonna
take
three
months,
so
I
think
we
should
figure
out
what
is
like
the
minimal
steps
that
provide
the
value,
give
like
the
iteration
that
we
can
get
that
to
yourself
get
like
a
feedback
either
marking
that
this
is
like.
Non-Final
is
a
better
it's
subject
to
change,
to
get
this
feedback
early
and
adapt
designed
based
on
the
feedback,
so
I
think
Fabio
I
completely
agree
with
you,
but
being
more
I
guess
doing
stuff
even
doing
wrong.
It's
probably
I.
B
A
B
D
B
C
Propose
a
syntax
that
we
can
Implement
based
on
the
feedback
we
have
provided
so
far.
There's
a
lot
of
conversion
points
in
the
syntax,
I
think
there's
a
lot
of
us,
but
we
I
do
agree
on.
So,
let's
pick
that,
let's
keep
outside
out
of
scope.
Anything
we
currently
don't
agree
on
yeah
and
and
let's
Implement
that
and
see
if
there
is
aspect
that
are
missing
for
for
this
to
work,
yeah
and
it
doesn't
need
to
be,
you
know
anything
released,
it
can
be
something
we
implemented
with
behind
a
feature
flag.
C
A
Mine
by
the
way,
a
random
thought
that
I
just
had
at
most
makes
sense.
Camille,
you
mentioned
that,
like
inputs
need
to
be
available
for
any
include
so
I
wonder
if,
like
maybe
like,
an
MVC
could
be
like
adding
includes
to
a
template
just
so.
D
B
B
B
B
A
C
Syntax
and
Implement
that
I
think
it
will
probably
be
the
the
biggest
value
we
can
get
like
with
an
embassy,
because
that
can
ex
we
can
be
used
with
includes
in
general.
We
can
build
include
component
very
easily
on
that
and
as
soon
as
we
grow
the
component
to
automatically
get
the
the
inputs
as
well,
and
we
can
even
think
about
the
spec
input
for
prefilled
variables
and
think
about
that,
and
we
could
even
start
thinking
of
yeah
of
of
releasing
that.
So
there's
like
basically
I
improvements
and
benefits
and
resides
so.
C
But
we
need
to
agree
that
specs
include
this.
Spec
inputs
is
a
syntax
that
we
can
move
forward
eventually
with
components,
because
if
this
is
something
we
include,
income
in
New
includes,
with
templates
and
your
users
start
to
use
that.
This,
then,
is
a
thing
that
we
cannot
change
in
the
future.
So
how.
B
About
how
about
we
simply
focus
on
like
it's,
like
writing:
iteration
iteration
One,
spec
inputs.
This
is
what
we
actually
want
to
implement
iteration
to
include
component
and
like
this,
let's
say,
convention
iteration
free.
We
make
a
component
publishable
into
catalog,
and
this
is
like
how
we,
what
you
have
to
add
to
your
project.
Maybe
this
is
I,
think
your
idea
that
you
have
like
with
the
top
level
metadata.
This
is
what
describes
what
is
publishable.
B
B
Maybe
with
this
restricted
keywords,
iteration
three
slash
four
is:
when
you
kind
of
see
like
I,
see
a
catalog
that
you
have
as
part
of
the
interface
that
you
can
see.
Everything
that
was
published,
I
would
I
would
kind
of
think
about
along
these
times,
like
after
each
iteration,
we
should
provide
us
something
that
can
be
used.
B
C
So
I
think
we
can
need
to
first
of
all
make
an
update
on
the
blueprint
with
the
syntax
proposed
and
then
choose
the
MVC,
which
is
likely
spec
inputs,
but
so
so
that
we,
we
are
sure
that
spec
inputs
fits
in
the
long
term
path
of
everything
else
of
all
the
conventions
that
we
want
to
think
about.
C
I
know
it's
not
something
that
then
we
will
need
to
change,
because
it's
probably
it
gives
a
lot
of
benefit,
but
also
there
is
some
risk
in
doing
a
the
inputs
first,
because
we
will
expose
them
to
end
user
directory
without
even
looking
at
the
iteration
on
components,
and
it
means
it's
going
to
be
hard
to
change
later.
So
that's
probably
the
main
downside
I
would
I.
B
B
Maybe
we
translate
that
this
is
not
like
a
like
a
square
bracket,
but
a
query
bracket,
I
think
as
long
as
we
not
make
it
like
in
junior
generally
available,
which
can
happen
right
after
his
publish
a
catalog
I
I
would
be
like
a
safeguard
that
we
can
still
translate
because,
like
it's
part
of
the
bigger
work
stream
that
we
are
adopting,
I
I
would
be
more
like
prepared
that,
like
in
the
process
that,
like
whatever
we
ship
in
the
iteration,
is
not
set
in
the
stone,
rather
something
that
can
be
changed
where
to
adapt
to
whatever
we
learned
next
and
kind
of
I.
B
Put
these
expectations
up
front.
It's
very
likely
that
a
lot
of
people
want
to
be
just
passionate
about
a
new
construct
that
can
use,
and
it's
just
gonna
be
fine
like
with
adapt
and
follow
with
the
way
with
us
and
even
like
contribute
to
us
like
hey,
but
you
didn't
think
about
this
very
specific
use
of
the
in
the
armor.
Can
you
think
about
that?
I
think
this
is
what
I'll
be
looking
for?
Don't
don't
try
to
figure
out
that
ahead.
I
think
figure
out
that
this
is
something
to
change.
A
B
B
Fabio
I'm,
actually
kind
of
wondering
like
would
you
like,
take
a
bite
on
this
syntax
stuff
and
try
to
maybe
describe
Maybe?
These
iterations
I
can
describe
my
iterations
because
then
I
think
like
based
on
your
availability,
when
you
could
do
it.
Maybe
this
is
when
we
should
schedule
like
a
next
meeting.