►
From YouTube: CI contribution framework
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
So
maybe
before
we
start,
I
just
want
to
make
sure
we
all
understand
the
the
goal
of
this
meeting.
I
think,
first
and
foremost,
I
want
to
make
sure
everyone
understand
the
problem
that
we
want
to
that
we
want
to
solve
and
and
then
understand,
more
or
less.
What
is
the
solution
that
we
want
to
to
plan
now?
This
is
a
this
is
a
large
undertaking.
It's
big!
A
It's
a
big
feature,
it's
much
bigger
than
just
the
feature,
and
so
the
next
thing
for
me
would
ask
you
like
how
do
we
start?
How
can
we
get
going
and
how
can
we
do
something
and
work
in
iteration
and
not
like
go
into
and
develop
a
thing
for
like
the
next
six
months?
Okay,
in
the
next
six
months,
we're
going
to
have
like
the
first
iteration.
A
I
want
to
start
doing
something
in
some
way,
maybe
internally
within
gitlab
or
maybe
find
a
partner
or
a
customer
that
we
can
work
with
and
then
get
more
feedback
as
quickly
as
we
can
but
like
before.
We
even
start
and
of
course,
feel
free
to
ask
questions
in
the
middle,
because
this
is
a
big
subject
and
I'm
sure
that
I
don't
have
all
the
details,
and
but
I
want
to
make
sure
like
we
all
understand
the
the
problem
where
the,
where
did
this
problem
came
from.
A
I
think
the
number
one
problem
that
we've
seen
as
a
part
of
our
in
interviewing
customers.
There
is
a
problem
around
discoverability
and
of
what
is
out
there
like
every
developer
or
every
devops
engineers
start
writing
a
pipeline.
The
first
thing
that
he
or
she
are
asking
is:
what
is
it
that
is
available
that
I
can
use?
A
And
today
there
is
nothing
like
either
they
have
something
in
in
the
organization
that
they
build
with
time
or
maybe
they
just
like
go
in
the
google
go
into
google
and
start
looking
for
something
we
have.
Our
templates,
but,
like
most
users,
are
not
really
using
like
they're
using
our
template,
but
this
is
not
the
templating
experience
that
they
would
like
and-
and
the
problem
is
that,
like
we
are
like
every
organization
has
experienced
this
problem.
So
we
are
like
repeating
this
problem.
A
Over
and
over
again,
like
first
organization,
was
able
to
solve
this
problem
now
there
is
another
one
and
they
are
doing
the
exact
same
steps
that
the
the
similar
organization
already
done.
So
we
want
to
be
opinionated.
We
want
to
provide
our
user
with
some
sort
of
a
way
to
say
hey.
This
is
the
this
is
the
place
where
we
need
to
go
in
order
to
find
what
is
out
there
and
yes,
we
are.
A
A
You
know
that
is
something
that
you
can
use,
and
then
you
use
it.
Why
do
you
want
to
use
it?
Because
yaml
is
not
a
programming
language?
Nobody
wants
to
write
camels,
they
say
hey
like
if
I
have
like
an
aws
and
I
need
to
deploy
my
application
to
aws.
A
A
The
developers
want
to
use
an
existing
yamaha
configuration
at
least
look
at
existing
gaming
configuration
tweak
them
for
their
for
for
their
benefit
and
to
add
on
top
of
that,
like,
yes,
we
do
have
some
sort
of
a
templating
way
and
we
do
have
a
a
way
that
we
said.
Yes,
everyone
can
contribute,
but
in
reality
everyone
can't
contribute.
A
Unfortunately,
because
the
way
the
template
is
architect
today,
templates
are
a
part
of
our
rail
code
base
and
every
partner
and
every
customer
and
every
user
that
tries
to
contribute
their
templates
hit
so
many
challenges
and
the
the
pain
that
they
had
to
go
through
until
they
were
able
to
contribute
that
and
doesn't
end
there,
because
what
happened?
If
you
need
to
update
this
template
now,
who
is
going
to
update
it
is
it's
like
gitlab
needs
to
update
because
it's
a
part
of
our
code
base,
but
we
don't
know
anything
about
these
templates.
A
So
it's
not
it's
not
even
scalable.
So
at
least
I
assume
that,
like
so
many
people
were
able
to
contribute,
then
there
is
a
problem
of
maintainability,
so
there
are
like
many
many
problems
and
the
solution
that
we've
seen
in
the
market
today
and
is
basically
create
some
sort.
We
like
to
call
it
like
the
contribution
framework
we
want
to
avoid
using
the
term
marketplace,
because
the
idea
here
is
that
users
will
be
able
to
share
their
knowledge
without
any
cost
associated.
A
If
you've
seen
my
my
videos
walking
through
some
of
the
competitors
that
they
are
today
in
the
market,
what
I
would
envision
is
to
have
the
front
end
that
would
be
similar
to
github
marketplace,
which
looks,
in
my
opinion,
one
of
the
best
marketplace
in
terms
of
the
front-end
approach,
but
the
back
end
of
the
process
on
how
to
on
how
to
contribute
needs
to
be
maybe
a
bit
more
similar
to
circles.
Yeah
circle
ci
by
far,
is
doing
the
best
job
in
contributing
a
template.
They
were
able
to
automate.
A
It
is
in
a
really
really
good
way,
so
some
sort
of
hybrid,
but
but
I'm
I
think,
I'm
jumping
ahead
like
this-
is
like
my
vision
like
in
a
year
or
two
years.
This
is
what
I
would
like
to
achieve,
but
before
that
we
need
to
understand
okay.
Well,
where
can
we?
Where
should
we
start
now?
There
are
some
few
caveats
that
we
need
to
really
understand
and
we
need
to
make
sure
that
the
the
requirements
are
there
from
day
one.
A
We
are
building
a
public
catalog
that
everyone
can
contribute,
but
we
would
like
also
to
build
a
private
catalog
so
which
is
like
a
a
different
flavor
of
a
public
catalog,
but
think
about
as
an
organization
that
want
to
have
an
internal
catalog
for
their
templates.
Only
no
one
will
be
able
to
access
those
templates.
Besides
the
people
in
the
organization
think
about
a
dedicated
catalogue
for
good
stuff.
A
Okay,
this
is
not
something
that
we
are
going
to
do
today,
but
we
should
definitely
keep
this
in
the
back
of
our
mind
when
we
walk
towards
the
public
catalog,
because
the
idea
here
is
that
we
won't
be
a
lot
of
work
to
move
a
public
catalog
to
a
private
one.
So
once
we'll
have
like
the
public
one,
we
can
easily
quickly
iterate.
B
I'll
start
the
ball
rolling.
Just
by
saying
that
I
just
merged.
Well,
I
just
put
merchant
pipeline,
succeeds
for
the
second
partner
template
and
it
probably
took
about
a
month
and
a
half
to
get
it
in
so
so
so
just
to
kind
of
highlight
the
problem
that
was
for
a
single
template
and
it
took
a
bunch
of
engineers
and
a
bunch
of
people
to
review
it.
So
I'm
super
super
excited
for
this
and
can't
wait
to
to
look
for
it.
B
But
what
one
thing
that
came
to
mind
just
now
that
I
hadn't
thought
of
until
just
now
is
we
we
kind
of
talked
a
little
bit
before,
or
I
talked
a
little
bit
before
with
someone
else
about
how
this
will
be
kind
of
the
first
time
where
we
we
kind
of
bubble
up
public
contributions
into
the
ui
itself,
like
we
say
everyone
can
contribute,
but
they're
actually
contributing
code
and
back
end
things
and
a
little
bit
templates
and
things
like
that,
but
we're
not
really
putting
things
from
contributors
into
the
ui
of
gitlab.
B
So
that's
just
not
bad.
It's
just
something
new
to
consider,
because
it
might
mean
that
we
would
need
to
have
moderators.
For
example,
what
if
someone
puts
a
template
in
the
catalog?
That's
here's:
how
to
spin
up
a
hundred
runners
to
do
bitcoin
mining,
or
something
like
that
like
we'll,
we'll
have
to
to
consider
that
in
kind
of
the
legal
ramifications
and
things
like
that,
just
as
part
of
the
discussions
along
the
way.
Just
I
just
thought
that
we
should
probably
write
that
down
somewhere.
A
Yeah,
okay,
I
think
we'll
have
eventually
we'll
have
like
different
types
of
like
certification
for
for
catalog,
for
a
template
like
we'll,
have
we
have
the
gitlab
certified
template?
So
those
are
the
template
templates
that
we
already
provide
as
a
part
of
our
code
that
are
available
in
our
repository
then
we'll
have
like
the
the
partner
certified
template.
It
will
be
contributed
by
our
partners
to
our
channels
and
then
we'll
have
like
the
community
and
again
we
need
to
have
the
right.
A
A
Definitely
something
that
we
need
to.
We
need
to
think
too,
as
as
we
do
that,
and
but
I
think
this
is
a
part
of
like
the
streamline
process
of
contributing
a
template.
I
think
I
think
before
that
we
need
to
actually
like
build
the
actual
framework
and
then
start
building
the
processes
around
it
and
then
say:
okay,
this
process
can
be
automated,
and
this
process
needs
to
have
some
sort
of
a
manual
verification.
C
Are
we
gonna
deprecate?
The
include
template
option,
keyword.
A
A
C
Like
the
proposal,
you
know
where
we
like
slowly
start
doing
this
and
because
I
kind
of
like
what
fabio
had
done
where
it
was
like
project
version
etc.
But
then
I
was
like
I
guess,
because
I
got
pink
on
a
deprecation
issue.
I
was
like
oh
man
separating
this
one,
but
you.
A
I
think
I
think
that,
like
our
users
eventually,
will
I
mean
if
we
build
this
right,
users
will
eventually
move
away
from
like
the
include
template
and
just
do
like
a
regular
include
because,
like
there
will
be
like
added
value
to
that,
like
you
know
the
version
control
and
the
documentation
that
we
need
to
be
around
that
because,
like
you
know,
you're
doing
today
include
something
you
have
no
clue
what
this
something
is
doing.
Unless
you
know
exactly,
you
know
where
to
go,
what
to
what
to
find
and
everything.
A
So
I
hope
that,
like,
if
we'll
build
this
right,
then
users
would
actually
want
me
to
deprecate
they'll.
Actually,
you
know
move
it
and
when
we
will
start,
you
know
maybe
think
about
the
application
recently,
not
a
lot
of
users
actually
using
it
and
switching
that
from
something
else.
It's
it's
quite
easy
to
do.
A
E
I
think
the
main
aspect
of
this
initiative
is
how
can
we
make
templates
discoverable,
because
I
think
I
also
answered
that
to
myself
question
about.
You
know
legal.
I
think
today,
like
a
user,
I
could.
I
could
create
like
a
a
snippet
on
gitlab
and
then
tweet
to
say.
Okay,
if
you
want
to
use,
I
create
this
great
template.
E
You
can
include
from
my
project
and
you
can
use
this
whatever
magic
it
does
and
and
that
works
you
know
if,
as
long
as
they
the
public,
the
the
project
you're
targeting
is
public
or
you
have
access
to
and
then
you
can
include
it
and
that
runs
so
if
they
may
change
it
or
do
some
malicious
code
or
something
I
think,
there's
kind
of
some
legal
things
that
could
already.
You
know
we
might
be
covered
today,
since
these
are
use
cases
that
happen
already
today.
What
we
would
want
to
do
instead
is.
E
Can
I
discover
what
you
know
templates?
Are
there
available
so
rather
than
doing
this
kind
of
manual
process
or
googling
it
and
find?
What
kind
of
include
you
know
path,
I
I
have
to
add.
I
can
simply
look
at
the
one
of
the
pipeline
editor
side
panel,
where
it
tells
you
like
you
know
here
are
the
things
that
are
available.
You
can
use
and
here's
how
you
can
use
it,
so
you
directly
just
take
it
and
use
that
so
I
I
I'm
hoping
we
can.
E
You
know
just
by
thinking
this
way,
that
there
is
a
lot
of
functionality
already
like
include
from
a
project
that
already
exists.
We
could
build
on
top
of
that
and
and
what
we
might
need
to
focus
more
in
terms
of
ux
and
and
from
that
marketplace
and
building
that
marketplace
perspective
is
how
can
we
make
this
template
searchable,
and
so
you
can
find
and
include
and
display
the
readme
on
the
side
so
directly
know
how
to
use
this,
and
but
apart
from
that,
the
manual
process
should
already
be
you
know
in
place
today.
D
Yeah
and-
and
I
agree-
and
I
think
I
think
that
the
essential
part
for
discoverability
are
going
to
be
one
some
kind
of
tagging
mechanism,
whatever
that
is
so
right.
User
can
say
this
is
a
java
config,
and
this
is
like
a
2ws
and
you
could.
We
could
even
like
have
specific
kind
of
tag,
and
you
could
say
this
is
the
language.
This
is
the
deployment
environment.
D
This
is
the
framework
or
whatever,
and
then
you
have
these
and
that
will
help
tremendously,
and
then
you
need
to
have
some
kind
of
voting
system
right
like
you
need
people
to
be
able
to
like
to
be
like
this
is
this
is
right,
and
ideally,
on
top
of
that,
maybe
even
later-
or
maybe
we
don't
know
that,
but
even
having
like
comments,
people
could
go
and
say
I've
used
it.
D
It
worked
right
and
like
thank
you
for
this
all
right,
hey
this
doesn't
work
for
my
company
and
then
I
have
that
kind
of
interaction
as
if
it
was
a
repo
right
like
you
can
you
can
chat,
it's
public.
You
can
like
ask
the
the
person
who
wrote
it
and
then
it
evolves
over
time.
So
I
think
that's
going
to
be
very
important
and
just
to
come
back
also
on
the
the
compliance.
D
I
think
it
would
be
very
hard
to
have
some
kind
of
stamp
from
gitlab,
mostly
because
of
version
control,
and
so
you,
if
you
have
a
manual
stamp,
you
would
say
up
to
disk,
commit
someone
from
gitlab
saw
it.
But
then
you
need
someone
every
time
to
go
and
look
at
the
changes
right,
because
if
you
have
the
stamp
and
then
someone
in
the
the
code
becomes
malicious,
then
it's
even
worse,
because
the
stamps
is
still
there,
but
it
changed
and
so
like
that.
D
So
there
would
have
to
be
a
whole
like
a
bunch
of
people
who
constantly
look
at
all
the
comments
which
is
not
scalable
for
sure.
And
so
I
think,
if
we
have
like
official
templates
that
are
very
like,
like
they're
internally
maintained,
like
you
know
like
this,
is
the
core
aws
deployment
for
this
language
and
like
we
own
that
and
people
can
branch
it
off
and
do
what
they
want.
D
E
I
think
we
need
to
introduce
a
kind
of
a
paradigm
shift
there,
where,
whenever
we
tell
users
to
include
templates,
we
should
tell
them
what
tag,
for
example,
to
use
I'll,
always
lock.
That
version
I
never
use
like
they
give
me
the
latest
version,
because
that
could
be
also
dangerous
for
us.
Like
let's
say
we
have,
you
know
our
gitlab
maintain
templates
and
we
want
to
introduce
a
change
that
or
maybe
a
breaking
change.
You
know
so
we
could
target
you
know
if
we
have
a
version
1.5,
we
can
decide.
E
Okay,
let's
roll
on
version
2.0,
because
it's
a
breaking
change.
Anybody
who's
using
the
latest
version.
It's
like
a
you
know.
It
should
be
about
practice
and
you
know,
and
that
could
break
a
lot
of
pipelines
and
we
should
tell
user
always
lock.
Your
version
then
maybe
use
your
latest
version
and
try
a
new
pipeline
to
see
like
the
same
way.
We
do
upgrades
with
packages,
and
things
like
that.
So
I
think
it's
like
one
of
kind
of
best
practices.
We
should,
you
know
maybe
tell
users
or
put
in
readme
and
things
like
that.
D
D
B
The
initial
like
among
the
early
mvcs
with
an
s
because
there'll
be
lots
of
steps.
Would
it
make
sense
to
just
not
have
includes
and
or
anything
like
that
at
all,
just
have
like
a
way
to
bubble
up
templates
in
a
way
that
people
can
at
least
find
them
first
and
then
they'll
all
be
copy
and
paste
to
start
with,
and
then
you
don't.
We
don't
really
have
to
worry
about
breaking
changes
or
versioning,
or
things
like
that.
Just
thrown
the
idea
up.
There.
A
I
think
that
like,
if
we
want
to
make
sure
users
will
actually
or
not
not
actually,
but
would,
if
you
want
like
more
users
to
adopt
it
in
order
to
get
more
feedback,
we
should
go
with
the
most
common
usage.
The
most
common
usage
is
to
use
use,
it
would
include,
I
mean
we
already
have
included
today,
and
this
is
like
we
are
seeing
much
more
users
that
are
like,
including
templates
than
just
like
copy
pasting
templates.
A
Copy
pasting
is
not
it's
not
something
that
our
users
really
like,
because
when
you,
when
you
do
that,
you
are
you're
forced
to
be
to
use
the
basically
the
configuration
that
you
configured
and
if
you
want
to
tweak
it,
and
if
you
want
to,
you,
won't
be
able
to
reuse
it.
Basically,
you
just
need
to
copy
paste
it
over
and
over
again,
and
let's
assume
you
use
it
in,
like
I
don't
know,
100
different
pipelines
and
you
want
to
update
it.
Then
you
need
to
go
and
update
it
to
100
different
pipelines.
A
A
And
again,
if
you
ask
me
which
one
we
should
use,
we
should
use
the
the
smallest
one,
so
the
the
the
pipelines
that
are
actually
we
are.
Our
users
are
including
to
doing
to
do
a
specific
task
because
pipeline
that,
like
that,
have
like
a
full-blown
like
a
configuration
to
have
like
a
full-blown
pipeline
for
onboarding.
We
actually
have
it
today.
A
We
have
it
today
in
the
product,
even
and
when
you
start
your
and
uci
and
uci
configuration
you'll,
get
like
a
several
example
for
like
a
skeleton
template
when
you
click
it,
it
will
automatically
copy
paste
to
your
to
your
pipeline
today.
But
this
is
something
that
users,
if
they
will
do
it
they'll,
do
it
only
once
okay
and
when
they
will
realize
how
it
works,
they
will
stop
using
it
and
they
will
just
doing
the
include.
So
it's
like
one
time
doing
that
versus
many
times
they
are
doing
includes.
A
E
I
think
that
we
could
probably
do
both
at
the
same
time.
So
I
there
I
linked
there
like
a
comment.
You
know
from
a
different
issue
where
I
described.
We
have
two
different
types
like
that
I've
noticed
at
least
of
I
call
two
types
of
ux.
So
one
is
the
example,
like
you
say
like
it
is
like
a
skeleton
of
a
pipeline.
If
you
have
ruby
up
here's
the
jobs
you
could
run
then
it's
up
to
you
know
we,
we
add
a
lot
of
comments.
E
These
are
very
common
heavy
templates
where
you
can
decide
to
remove
some
jobs
or
tweak
it
if
you're,
using
postgres
or
using
my
sql.
You
might
need
to
kind
of
do
a
lot
of
not
tweaking
yourself,
and
this
will
be
the
one
that
you
you
copy
paste.
There
is
no
actual
configuration
there
to
link
to
it's
just
like
here's.
How
you
can
do
this
and
it
will
be
for
more
like
for
tutorial
purposes
and
another
one
is
the
it's
packaged
configurations
are
called,
but
it's
more
like
here's.
What
you
can
include.
E
You
don't
need
to
know
exactly
the
details
of
how
it
does
something
you
just
need
to
know
it
does
this
thing
and
that's
it
and
you
can
pass
in
some
variables
as
a
parameter
kind
of
to
tweak
the
behavior
a
little
bit,
but
you
take
as
a
function
like
a
github
action
and
I
think
the
depending
how
we
want
to
design
this.
The
difference
between
the
two
is
very
minimal.
E
We
need
to
have
always
a
readme
anyway,
so
so
you
can
tell
the
users
here's
how
you
can
do
this
thing
and
the
difference
is
like
you
can
either
include
this
file
and
and
just
copy
paste.
The
include
part-
and
that
is
how
you
can
reuse
many
templates
or
if
it's
the
case
of
a
skeleton
pipeline
like
a
ruby,
app
or
something
like
that,
and
it
will
be
you
just
copy
paste.
Whatever
is
in
the
rhythm,
there
is
no
yammer
configuration
in
the
template
kind
of
repository,
it's
just
the
rhythmic.
It's
like
a
tutorial
readme.
E
This
is
how
you
can
do
things,
but
if
there
is
something
you
want
to
include
to
make
it
not
reusable
and
abstract
that
way,
then
in
the
written
you
specify
this
is
you
can
use
it
by
including
this
file
and
then
the
file
that
we
point
to
within
the
the
repository
is
where
the
full
kind
of
configuration
is,
and
this
can
be
a
of
the
two
types
that
w
you
mentioned
before
that
could
be
like
they're.
E
A
A
This
is
why
I
want
to
be
very
focused
on
what
is
it
that
we
want
to
achieve
in
the
in
the
first
iteration,
and
this
leads
me
to
my
my
next
question
is
like
what
should
we
do
in
order
to
start
with
the
first
iteration
like,
for
instance,
do
we
want
to
start
doing
some
design
work
for
how
the
final
product
should
look
like?
Will
it
help
drive
the
some
of
the
architectural
discussion?
A
D
I
may
have
well,
I
have
an
opinion.
Not
surprisingly,
I
think
what
could
be
interesting
is
if,
instead
of
focusing
first
on
the
public
part
and
like
everyone
contributing
what,
if
instead
we
did
the
opposite,
then
we
said
right
now:
there
are
enterprises
that
cannot
reasonably
reused
jobs,
and
I
think
that
is
a
much
more
narrow
use
case.
D
That
would
benefit
a
lot
and
so
how
I
envision
this
is
you're
in
the
pipeline
editor
and
the
company
company
x
decides
that
they
have
a
couple
of
jobs
that
they
want
to
allow
developer
to
reuse
right
so
they're
already
in
their
own
repo
they're
in
a
folder
or
something
and
they're
all
in
there.
And
if
you
go
into
the
ui,
we
make
something
discoverable
literally
like
in
in
the
ui.
D
They
can
name
that
job
and
if
you
click
on
it,
it
just
snippets
the
yaml
inside
their
config
and
just
put
it
at
the
bottom.
Then
you
can
move
it
and
do
whatever
they
want.
You
can
configure
some
part
of
it,
but
they've
just
removed
the
manual
process
of
going
and
finding
the
job
bonus
points
if
we
could
make
it
so
that
they
can't
and
they
can't
edit
it
or
that
the
lentor
catches,
if
they
change
it,
and
it's
no
longer
valid.
That's
like
a
nice
nicer
way
right.
D
They
could
have
their
own
custom
rules
and
be
like.
Oh
you've
changed
the
syntax.
It
doesn't
work
but
like
I
think
that
first
step
of
like
you're
in
the
ui
and
you
can
click
on
the
button
and
it
pastes
the
job
inside
your
config
with
that
address
part
of
the
pain
point
of
like
reusing
or
would
it
be
like
just
an
include
even
like
I'm,
including
this
job?
I
clicked
on
this
button.
It
adds
the
write
includes
and
now
that
job
isn't
there
and
it.
A
Works,
probably
like
probably
using
the
includes
is,
is,
is
a
better
method.
Private
organization
would
like,
because
this
way
they
can
enforce
specific
standouts
on
on
pipeline.
So,
of
course,
both
approach
are
valid,
but
based
on
at
least
the
the
the
interviews
that
I've
done
with
organization.
This
is
what
they'd
like
they'd
like
to
have
like
include
they
like
to
have
include
even
for
the
latest,
and
they
are
in
charge
of
managing
like
and
maintaining
those
templates
and
but.
D
Then
that
makes
it
work
then
I
mean
that
that
would,
at
least
in
terms
of
complexity.
What
would
be
really
cool
about
this
is
that
you're
removing
even
variables
you're
removing
the
need
for
user
to
fill
anything
out
right,
they're,
not
customizing.
These
templates
they're,
not
they're,
just
including
them
and
so
yeah,
but
that
would
become
that
would
come
later.
A
Those
yeah
they
have
to
customize,
I
mean
they
have
to
do
something
like
simply,
including
templates,
almost
never
work,
and
you
always
want
to
customize
those
templates.
This
is
where
we
need
like
the
documentation.
This
is
where
documentation
is
super
important,
that
you
have
a
template,
and
you
say:
okay,
this
template
doing
this
kind
of
thing.
In
order
for
it
to
work,
you
need
to
populate
those
variables
with
your
cadential
or
whatever.
A
You
need
to
add
this
step.
If
you
wanted
to
work
with
a
you
need
to
add
that
step.
If
you
want
to
work
with
b,
you
can
override
rules.
You
cannot
write
different
things
that
you
can
do
with
templates,
even
with
include
templates,
because
it's
almost
will
never
work
if
you'll
just
include
it
as,
as
is.
D
With
it
and
then
follow-up
question,
then,
would
it
be
possible-
and
this
are
desirable
for
instead
of
like
then
getting
and
include
and
then
having
to
like
either
because
I
thought
maybe
that's
doable
right
now,
and
I
don't
know
so
sorry
if
that
exists,
but
like
when
you're
using
a
clue
is
there
a
week
currently
where
you
can
say
I
want
this
include,
and
here
I'm
I'm
just
passing
variables
so
like
under
includes
like
vars
or
something
and
then
you
go.
This
is
the
commit
branch.
D
This
is
the
name
of
the
repo
that
I
need
and
this
because
I'm
thinking
in
terms
of
like
abstraction
and
I
think
the
problem
we're
always
going
to
face
is,
if
you
have
to
copy
it,
then
you
can
change
it
and
then
the
rules
of
what
you
can
change
cannot
be
enforced
easily.
But
if
it's
like
it's
a
black
box,
you
include
this
and
you
get
the
documentation
you're
like
here's.
What
I
need
here
are
the
variables
that
I
need
you
to
give
me.
D
You
give
your
variable
in
the
list
and
then
that
gets
that
gets
like
once
the
include
runs.
It
gets
those
variables
and
then
it
generates
the
right
enamel
given
these
variables.
So,
instead
of
putting
the
work
on
the
person
who
includes,
we
put
the
work
on
the
the
template
maintainer,
they
they
can
understand
what
might
change
given
your
config
and
then,
if
the
changes
are
too
big,
then
you
need
a
different
include
right.
You
need
a
different
structure
because
then
it's
just
not
variable.
It's
like
it's.
It's
different.
E
Yeah
there
is,
you
know
some,
you
know
some
competitors
that
have
the
concept
of
parameters,
input
parameters
when
you
include
something
you
say:
okay,
I
want
to
use
whatever
here.
Is
that
the
list
of
parameters
that
we
take
in
and
in
our
case,
maybe
the
first
iteration
would
be
you
have
you
use
the
the
variables?
E
E
It
will
be
better
to
transform
into
some
kind
of
inputs
where
you
say
here,
the
inputs
we
do
the
replacement
before
we
include
the
the
the
the
configuration
and
it
could
be
an
iteration
where
eventually
we
look
into
okay.
Is
there
like
a
way?
We
could
extend
the
syntax
to
also
use
parameters,
and
so
these
parameters
will
be
expanded
or
treated
like
variables
could
be
treated
like
on
any
other
things
we
could
figure
out
and.
A
Yeah,
I
I
think
I
think
definitely
there
is
room
to
to
improving
like
the
way
we
are
doing
include,
and
you
know
one
idea
could
be
maybe
leveraging
parent
child
pipeline
instead.
But
I
think
that
what
we've
seen
today
is
that
our
syntax
today,
with
all
the
pros
and
cons
that
it
has
with
variables
and
and
the
inheritance
and
the
presidents
and
and
those
those
challenges
users
are
still
using
include
the
use
include
massively.
A
The
use
includes
with
variables
that
are,
as
I
mentioned,
like
organization,
are
building
some
sort
of
a
catalogue
by
themselves.
Okay,
everyone
is
doing
like
crazy
things,
but
they
are
able
to
overcome
most
of
the
problem
that
we
have
today,
and
it
is
good
enough
for
us
to
take
a
step
and
say:
okay.
A
This
is
where
we
want
the
product
to
to
go
into
like
we
want
to
create
some
sort
of
a.
A
We
need
to
have
a
place
for
all
of
our
users
to
say,
okay
for
this
great
work
that
you
are
doing
today
now
there
is
a
home
for
this
work
and
while,
as
you
contribute
to
the
work
that
you're
doing,
you
will
make
the
life
of
your
colleagues
in
different
organization
much
easier
so
like
yes,
definitely
we
we
have
rooms
to
work
on,
maybe
adding
steps
into
stages
and
an
input,
variables
and
and
and
parameters
and
more,
but
I
think
for
now
we
need
to
focus
on
what
we
have
today
and
how
can
we
improve
based
on
what
we
have
today
and
if
we
were
saying
hey,
it's
not
good
enough.
A
A
What
should
be
the
next
step
for
us
to
to
solve
this
problem?
There
is
by
the
way,
groups
in
gitlab
that
are
willing
to
to
help
us
with
that.
So
I
spoke
today
with
er
with
lemmy
from
the
infrastructure
team.
They
are
using,
I
think,
four
or
five
different
templates
in
the
pipeline
configuration
they
can.
Definitely.
You
know
they
can
definitely
help
us
build
that,
so
we
can
maybe
focus
on
on
those
templates
that
they
are,
including
today
in
their
pipelines.
Okay.
Now,
assuming
that
you
have
this,
I
know
this
ui.
A
A
The
second
thing
that
I
also
want
to
maybe
try
is:
we
do
have
a
a
a
way
to
tap
into
our
partners
and
channels,
so
maybe
even
before
making
it
like
a
public
catalog,
we
can
maybe
open
the
process
to
partners.
Only
so
we'll
have
like
a
catalog
that
only
partners
will
be
able
to
contribute,
because
with
partners
we
still
have
some
control
because
the
minute
we'll
open
it
for
for
community.
A
Yeah,
so
what
I
was
thinking:
okay,
let's
dog-food
it
first
with
our
engineers
internally
and
then,
like
the
first
release,
we
can
call
it
a
better
release:
google,
whatever
we
want,
it
will
be
with
partners
only,
and
we
ask
partners
to
contribute
those
templates
into
into
our
catalog
and
see
how
the
process
works.
And
how
can
we
automate
things
and
how
can
we
make
it
smoother
and
once
we
feel
comfortable
that
this
is
where
we
need
to
open
it
up
for
for,
for
everyone
to
contribute.
E
And
I'm
my
I'm
getting
a
little
bit
more
convinced
on
the
idea
that
we
could
start
with
private
catalog,
and
you
know
internal
catalog
first
and
then
the
public.
Even
if
we
deal
with
partners,
for
example,
I'm
not
sure
when
they
will,
they
all
will
be
willing
to
share
their
their
templates
like
within
a
catalog
that
is
shared
across
different
partners.
I'm
wondering
whether
it's
more
like
okay,
we
implement
an
organization
level
catalog
for
partner.
A
partner
b
also
have
their
own
organization
level.
E
They
don't
share
these
templates,
but
these
at
least
are
shared
across
their
organization.
Once
we
are
able
to
build
or
do
the
extra
mile
where
we
actually
do
the
public
catalogue,
it's
up
to
them
to
decide
in
the
same
way
it's
github
actions
are
done
to
them.
You
can
decide.
I
want
this
template
to
be.
You
know,
promoted
to
a
public
catalog
versus
my
organization,
catalog,
and
so
then
the
partners
can
decide
to
share
only
what
they
want.
E
Rather
than
being
forced
to
to
be.
You
know,
basically
put
all
their
templates
into
a
single
kind
of
catalog,
so.
A
E
A
Just
to
just
to
alleviate
this
this
this
problem
again,
I
have
no
problem
pivoting
to
public
or
private.
I
think
like
we
first
of
all
in
the
product
organization,
we
agreed
that
the
public
catalogue
should
be
like
the
first
like
official
release,
so
we
can
build
like
a
private
one
first,
but
the
real
catalog
should
be
like
a
public
one
in
terms
of
like
partners.
A
Partners
would
like
to
contribute
their
templates
for
everyone
to
use,
because
it's
their
interest
that
users
will
use
their
templates
because
it
means
that
they
are
using
their
product.
So
we
have
like
many
many.
I.
A
Today
that
they
have
integration
with
their
products-
and
they
say
we
want
gitlab
users
to
use
our
product,
how
can
we
do
that?
We'll
create
a
template?
We
let
everyone
to
use
it
to
get
the
best
template
in
the
world.
Okay,
we
make
it
like
super
light
with
all
the
documentation,
everything
it's
our
interest
to
make
it
accessible
as
as
much
as
we
can,
because
by
doing
that,
we'll
make
sure
that
those
users
that
are
using
the
template
are
using
our
product,
so
it's
their
interest.
E
Yes,
although
like
okay,
even
if
we
go
to
the
way
like
of
you,
know
opening
the
marketplace,
I
guess
it's
for
partners
to
publish
only
right,
only
partners
can
publish,
can
can
write,
but
then,
who
can
read
these.
E
Then,
like
as
a
first
iteration,
my
concern
is
that
what
if
we
decide?
Oh,
we
took
a
wrong
turn
in
the
design.
We
need
to
actually
make
some
small
adjustments.
Now
we
have,
maybe
thousands
of
you
know
100
000
of
users
using
this
type
of
these
templates
in
specific
or
the
specific
structure
like
including
a
specific
way.
Maybe
we
realize
or
there's
like
a
ux
issue
here
we
wanted
to
fix,
and
this
is
why
it's
like
the
reach
is
still
very
high.
E
You
know,
even
though
we
only
you
know,
publish
a
couple
of
templates
yeah,
but
the
reach
might
be
very
high
because
of
the
number
of
people
that
can
read
these
pipelines.
If
we
start
with
like
an
organization
level,
then
the
reach
is
only.
We
can
work
with
some
organizations
that
are
willing
to
try
this
feature.
E
We
can
even
enable
the
feature
flag
only
for
that
organization
and
say
you
can
only
you
know,
see
this
and
use
this
template,
and
if
we
realize
that
there
is
something
we
want
to
tweak
just
because
we
are
like
a
still
iterating,
we,
you
know,
we
don't
have
to.
You
know
introduce
huge
breaking
changes.
We
can
work
with
the
partners
said
it
might
be.
Like
you
know
we,
this
is
that
we
want
to
introduce
like
a
breaking
change.
This
is
the
way
you
know
we
can.
E
You
know,
support
you
to
move,
but
there
are
like
customers
that
are
willing
to
to
take
breaking
changes,
because
it's
like
a
feature
that
they're
interested
in
and
maybe
before
that
we
could
even
look
if
there
is
opportunity
to
dock
food
that
so
maybe
we
can
talk
to
productivity
group
to
see
that
they
are
our
pipeline
authors
to
say:
okay,
are
there
any
templates
that
we
reuse
across
different
products
within
gitlab
and
things?
You
know
we
could
actually
create
a
gitlab.org
catalogue
and
we.
E
As
we
want
there
like,
because
you
know
we
can
iterate
as
fast
as
we
can
even
breaking
things,
because
we
know
how
to
move,
you
know
how
to
overcome
breaking
changes.
It's
like
we
are
dog
food
in
this,
and
so
my
suggestion
would
be
to
look
if
there
are
any
opportunities
to
talk.
Food
first,
as
first
layer
of
of
implementation,
then
work
with
some
customers
that
are
willing
to
collaborate
with
that
and
then
eventually
maybe
open
to
all
organizations
first
and
then
publicly.
B
B
A
Yeah,
so
I
think
I
think
whether
we
will
introduce
like
a
public
or
private.
I
think
we
are
agree
that
we
need
to
talk
for
this
first
I
mean
this
is
also
one
of
our
principal
core
here
in
gitlab,
especially
when
we
are
building
something
and
something
new,
as
as
a
catalog
dog
fooding
it
first.
B
You
can
do
it
on
the
docs
project
too,
if
you
want
something
with
that.
That's
not
so
impactful,
because
you
know
if
we
cause
trouble
to
to
them
to
the
gitlab
project
pipeline.
That
would
be
a
pretty
big
problem,
but
we
were
using
two
templates
right
now
in
the
doctor,
probably
like
just
we've
got
dependency
scanning
and
sas
scanning
we're
just
just
using
the
straight
templates
for
that,
so
that
there's
probably
multiple
smaller
projects
that
that
you
could
even
start
with,
but
yeah
a
hundred.
A
Yeah,
even
better
I
mean,
if
we
will
have
you,
I
mean
you're
part
of
this
team,
so
it's
even
easier
to
at
least
to
at
least
as
a
poc.
This
is
something
to
get
get
us
started.
So,
let's
assume
that
we
are
okay,
we
are,
we
are
settled.
We
want
to
start
something
on
the
docks
like
what
is
it
that
we
can
do?
I
don't
know
next
week,
next
iteration.
What
is
it
that
we
all
need
in
order
to
kick
start
this?
This
project.
E
I
I
I
think
the
first
thing
we
could
do,
I'm
assuming
that
you
know
we
kind
of
are
settling
on
the
idea
of
having
one
template
per
project.
E
E
We
convert
into
a
project,
you
know
using
the
you
know,
the
project
templates
kind
of
that
we
had
defined
like
how
the
structure
should
be
for
each
project
and
convert
them
into
a
project
with
a
readme
and
how
to
use
this
and
see,
first
of
all,
that
what
they
look
like
and-
and
then
eventually
I
have
read
them-
do
include
the
play
templates.
We
do
include
project
whatever
gitlab
is
secret
detection,
and
then
we
include
that
directly.
E
From
now
on
and
bear
in
mind
that
you
know
if
we
decide
to
rename
this
to,
you
know
rebrand,
and
we
want
to
rename
it
it
might
have
breaking
changes
unless
we,
I
don't
know
if
we
can
do
some
redirections
automatically,
I'm
not
sure
but
like
because
these
paths
will
be
hardcoded
in
every
everywhere,
where
we
use
it.
This
is
another
case
where
I
was
saying.
We
need
to
be
careful
who
reads
these
templates,
because
we
might
introduce
breaking
changes
if
I
simply
decide
to
move
all
our
templates
from
one
group
to
another
one.
E
E
Well,
I
was
just
I'm
saying
like:
do
you
want
to
have
them
within
gitlab.org
or
want
to
have
like
another
top
level
group
specifically,
that
is
more
even
more
generic
can
be
reused
by
gitlab.com
and
any
other
customer,
or
we
want
that
to
be
within
gitlab.org
and
group.
I'm
not
sure
these
are
kind
of
decisions
we
we
might
need
to
make
again
it
might.
E
We
might
be
willing
to
deal
with
breaking
changes
just
like,
let's
create
a
group
subgroup
of
gitlab
org
and
put
the
projects
in
there,
and
whenever
we
come
up
with
a
better
decision,
we
can
move
this
project
and
deal
with
the
tracking
changes
or
like
when
we
move
one
project
at
a
time
and
things
like
that,
but,
like
the
smaller,
the
subset
of
you
know,
users
that
are
that
is
using
this.
The
easiest
for
us
to
you
know,
change
our
mind
and
move
this
around.
D
We
all
want
to
speak,
so
maybe
maybe
an
option
also
would
be
to,
and
maybe
it's
like-
I
don't
know
if
it's
shorter
term
long
term
whatever,
but
like
at
some
point.
We
should
aim
that
when
people
write
their
yaml,
they
don't
have
to
hardcode
the
group,
so
they
just
do
like
slash
template
their
templates
and
we
on
the
api
side,
understand
that
this
keyword,
we
we
populate
the
group
where
they
live,
so
we
we
have
one
place
where
that
lives
and
we
maintain
that.
D
B
I
was
just
wondering
if
it
would
be
possible
to
have
like
a
proof
of
concept
of
this,
such
that
the
project
that
we
use
isn't
really
important.
Just
just
have
a
random
project
really
anywhere.
It
could
be
someone's
personal
name
space,
but
such
that
the
code
people
can
start
working
on
it.
Basically
and
not
really
worry
exactly
about
the
final
destination
so
that
you
know
designers
and
things
like
that
can
work
in
parallel,
because
it's
going
to
take
a
long
time
and
then
people
can
start
working
on
it
and
people
can
start.
B
A
E
B
Project
really
and
then
iteration
one
would
actually
be
a
production,
a
real
production
project
that
has
deployments,
and
it
has
security
scanning
and
things
like
that.
E
We
can
create
a
group
put
these
templates
into
the
group,
each
each
template
per
one,
each
for
on
each
project,
and
eventually
you
know
if
they
are
stable
after
the
plc,
we
can
directly
move
to
a
different
project,
just
like
an
internal
group
and
create
some
projects
that
use
these
templates
and
we
could
work
eventually.
E
That
is
a
good
point
that
we
just
discovered
here
that,
rather
than
using
include
project
where
there
is
like
a
path,
name,
project
path,
kind
of
hardcoded,
we
could
use
like
a
maybe
even
we'll
see
if
we
can
reuse
the
include
template
keyword,
maybe
a
different
keyword
that
will
automatically
expand
the
path
based
on
the
name
of
the
template.
E
A
digital
action
has
like
the
template
name
is,
must
be
unique
so
that
for
this
purpose,
so
we
could
even
check
all
these
things
like
where
you
know
the.
As
you
publish
a
template,
you
know
the
publishing
might
fail,
say:
okay,
this
is
another
template
with
the
same
name
docker
for
example.
Right
you
know
you
can't
publish
another
one
and.
E
C
B
Just
wanted
to
say
that
what
you
did
in
the
issue
is
an
issue
in
an
epic
in
the
epic
was
really
really
good,
because
you
already
had
you
had
your
your
fabio
group
and
your
get
labs.
Yeah
instance
template
slash
code
quality.
You
had
ruby,
it's
like
that's
that's
I
already.
B
Yeah,
but
the
poc
it
to
me
is
it's
already
started.
It's
already
like
all
you
have
to
do
is
take
that,
like
you,
you've
taken,
the
first
steps
is
like
take
what
you've
done
there
and
just
put
it
into
a
group
under
dot.
You
know
org,
and
it's
like
we're.
We've
already
got
the
ball
rolling
in
my
mind,
with
what
you've
done
in
that
epic
is
great.
A
Okay,
so
we
can
start
this
as
a
as
our
basis
for
for
poc
and
then
like
we
can.
We
can
create
an
issue
for
a
poc
based
on
the
initial
work
that
fabio
was
doing
and
see
if
we
can
quickly
test
it
and
see
if
it's
not
we're
not
seeing
any
thing
funky
there
and
then
maybe
afterward,
we
can
move
to
some
a
clear
project,
as
I
mentioned
doc's
project.
A
Is
I
really
like
this
sorry
myself
for
speaking
on
you,
but
I
really
think
that
this
is
a
good,
a
good,
a
good
approach,
especially
since
you're
one
of
our
teams.
It
could
be
easier
to
get
feedback
in
and
out.