►
From YouTube: TT310: Demoing GitLab
Description
This is a Tanuki Tech session on 10/13/2020.
For more on Tanuki Tech, see here: https://about.gitlab.com/handbook/marketing/revenue-marketing/sdr/tanuki-tech/
For more on the speaker, see here: https://www.linkedin.com/in/christopher-wang-0835b226/
B
B
B
B
I
think
I'm
the
only
pubsec
person
here
so
if
anything
sounds
a
little
bit
off.
Just
let
me
know-
and
I
might
be
using
some
pubsec
lingo-
that's
not
used
in
other
areas
of
gitlab.
So
just
let
me
know
okay,
so
for
version
control.
Basically,
here
we
have,
we
have
git
lab
and
within
within
git
lab.
This
is
your
normal
fcm
you've
probably
seen
a
setup
like
this
many
many
times
you
can
see
all
the
all
of
the
files
here.
B
B
You
can
see
the
history
behind
all
of
these
files,
so
these
are
people
who
are
you
know
putting
in
changes
to
these
files,
then
you,
I
also
wanted
to
open
up
what
we
have
as
web
ide,
which
makes
which
makes
development
a
lot
easier
for
for
non-developers.
So
so
this
this.
This
helps
with
the
the
value
of
collaboration
and
whatnot
that
that
git
lab
espouses
so
so.
B
B
So
what
we
can
see
is
we
actually
have
this
this
built
into
to
gitlab.
So,
as
everything
is
put
in
in
as
a
merge
request,
it
can
go
through
all
the
stages
of
a
of
a
normal
of
a
normal
pipeline.
You
can
build
that
out.
So,
for
example,
here
are
some
some
merger
quests
that
are
coming
in
and
you
can
actually
see
in
this
merger
quest.
There's
some
collaboration
happening
around
the
the
pipeline.
B
A
B
E
A
Yeah,
let's
keep
going.
This
is
something
that
will
happen
in
your
live
demos,
which
I
think
is
actually
something
that's
important
to
to
I
mean
you
will
have
technical
difficulties
in
the
demos
that
you
deliver,
so
it's
important
to
know
how
to
like
segue,
give
proper
expectations
which
you're
doing
right
now
to
just
push
through
like
beyond
the
awkwardness,
so
I'm
just
gonna
go
back
into
like
customer
mode,
so
josh
thanks
for
showing
me
your
ci
cd.
A
A
Yeah
exactly
so
one
of
the
things
that
I
see
over
here
is:
we
generally
have
a
lot
of
different
tools
that
do
a
lot
of
this
stuff,
so
building
images
we
use
docker
for
that
code
quality
we
use
pi
test
and
something
else
for
javascript,
but
is
so
I'm
just
curious
as
to
like
how
this
ci
cd
integrates
with
our
current
stuff?
Is
that
like
a
all
or
nothing
approach,
or
can
we
keep
some
of
our
own
tooling
and,
if
so
like?
How
would
we
go
about
doing
that.
B
That's
a
really
really
good
question.
Chris,
I
one
of
the
one
of
the
cool
things
about
git
lab
is
it
it
is
an
all-encompassing
solution,
if
you're
ready
for
that,
but
we
also
don't
expect
for
every
company
to
rip
and
replace
so
we
build
gitlab
in
a
manner
that
it
can.
It
can
integrate
with
pretty
much
any
any
tool
available,
so
whatever,
whatever
you're
using
in
your
development
process.
B
If
you
want
to
use
gitlab
ci
cd
with
you
know,
whatever
scm
version
control
you're
using
or
security
whatnot,
we
make
that
we
make
that
possible
and
easy
for
you.
I
will
say,
though,
that
the
one
of
the
larger
benefits
and
what
we
want
to
push
everybody
towards
eventually
to
is
adapting
gitlab
as
a
total
devsecops
solution,
because
it
does
exist
within
one
one
interface,
one
application.
B
B
A
B
Cool
well
we'll
go
ahead
and
move
real
quickly
over
to
dev
secops.
So
I
kind
of
mentioned
this
briefly
a
moment
ago
about
how
how
security
is
embedded
within
within
gitlab.
So
again,
here
we've
got
some
merge
requests
and
what
we're
actually
going
to
do
is
we're
going
to
pull
up
this
pipeline
here
and
around
the
test
section
you
can
see
you
can
see
sas
testing
we've
got
dast
and
sas
we've
actually
also
within
our
within
our
roadmap.
C
B
Security,
tooling
into
the
devs
about
sec,
ops
framing
because
it's
already
right
here,
so
I
actually
wanted
to
show
you
this
too,
within
the
maturity
of
the
security
product.
So
this
shows
you
kind
of
where
we
are
and
how
how
developed
it
all
is
right
now,
so
secret
detection
license
compliance
container
scanning
dependency,
scanning
and
fuzz
testing
and
then
in
the
in
the
future,
and
this
is
actually
something
you
can
see
for.
B
A
C
B
Sure,
here,
I'll
I'll
show
you
this
real
quickly.
There
are
different
different
tiers
of
of
pricing
with
git
lab,
so
we
have
right
now
a
free
version
called
called
core.
We
also
have
bronze
and
starter
silver
premium
and
gold
and
ultimate
and
the
difference
between
those
all
of
all
of
like
the
the
slashes,
the
silver
premium
gold
ultimate,
it's
just
self-hosted
versus
hosted
mechanisms.
So
if
you're
in
the
public
sector,
like
I
am
most
of
everything,
is
self-hosted,
so
you'd
be
looking
at
an
ultimate
or
premium
product.
B
So,
as
you
can,
you
know
one
of
the
one
of
the
benefits
to
the
ultimate
tier
kind
of
coming
into
what
you
just
said,
chris,
is
that
security
really
does
come
into
the
forefront
fully
during
or
in
the
ultimate
tier.
So
we
can
talk
a
little
bit
more
about
that
that
structure,
if
you
want,
but
does
that
that
kind
of
answer,
your
question.
A
Yeah,
absolutely
I'm
curious
if
we
can
hook
in
like
our
existing
security
things
as
well,
so
we
already
have
all
these
license
subscriptions
for
you
know
like
nexus
and
a
lot
of
different
other
scanning
tools,
there's
another
team
that
does
all
that
stuff
and
they
so
like
they
already
have
a
multi-year
contract.
So
I'm
curious
as
to.
I
think
this
might
be
just
asking
the
same
question
again,
but
does
get
lab
work
with
these
other
things
like.
B
Yes,
absolutely
we
totally
understand
that
you
might
have
contracts
existing
for
multiple
years.
So
again
you
know
we're
not
trying
to
you
know
you
know,
get
everybody
to
just
rip
and
replace
everything.
So
if
you
all
are
using
nexus
and
that's
that's
working
for
you
we'd,
you
know
like
that.
We
can
absolutely
make
that
work
within
the
gitlab
frame.
B
I
will
say
if,
if
there's,
if
there's
an
interest
in
the
future,
we'd
be
happy
to
demo
out
the
the
full
capabilities
of
security,
so
you
can
understand
once
that
contract
with
nexus
is
ending.
You
know,
we'd
be
able
to
just
show
you
what
git
lab
could
accomplish
within
the
security
phase.
So
thank
you.
Yeah
you're
welcome,
okay
and
now
I
just
kind
of
wanted
to
to
finish
up
by
showing
you
all
a
little
bit
of
the
agile
planning.
B
So
as
as
you
know,
this
is
a
very
important
space
within
within
devops.
Right
now
is
agile
planning,
so
gitlab
actually
allows
a
very
robust
issue
system.
Where
here
here
you
can
see
all
the
issues
that
are
coming
into
to
gitlab.
You've
got
all
the
tags
that
are
associated.
For
example.
Here's
here's
one
issue,
that's
open
and
you
kind
of
you
can
kind
of
see.
B
Here's
some
some
burn
down,
burn
up,
charts
we'll
get
to
in
a
little
bit,
but
it
outlines
exactly
what
needs
to
happen
for
for
this
to
be
accomplished,
so
you
can
see
down
towards
the
bottom
the
collaboration
between
all
of
the
all
the
developers
and
non-developers
too.
So,
and
you
can
it's
just
it's
a
robust
bus
system
where
you
can.
You
know
reference
other
other
issues
and
other
areas
of
get
lab
so
wanted
to
go
from
there
and
show
you
some
of
milestones
and
ethics.
B
These
are
just
ways
to
organize
some
of
of
the
issues,
so
issues
or
epics
would
surround
like
a
very
particular
topic.
So
then,
from
from
here
for
for
the
management,
as
as
management's
taking
a
look
at
everything
within
within
gitlab
or
I'm
sorry,
everything,
that's
that's
happening
with
agile
planning.
You
can
see
how
things
are
coming
along.
You
can
see
you
know.
Perhaps
there
are
some
bottlenecks
that
are
developing
in
the
process.
B
Just
by
you
know,
for
example,
here's
the
you
know
the
issue
dashboard
then
wanted
to
kind
of
show.
You
the
burn
down,
charts
and
burn
up
charts,
which
is
something
that
can
be
used
to
again
identify
if
there
are
bottlenecks.
So,
for
example,
with
this
you
know
there
are
there's
a
significant
amount
of
work
that
still
needs
to
be
done
in
this.
B
A
B
Oh
okay,
that
sounds
good
yeah.
Sorry
this
is
this.
Is
this?
Is
the
road
map
the
epic
road
map?
So
basically
this
allows
you
to
visualize
all
of
the
all
of
the
epics
and
how
how
they're
progressing,
if
they're
being
accomplished
on
time,
just
kind
of
give
you
a
visual
visualization
into
the
overarching
progress
of
the
of
the
company
and
the
projects
surrounding
it.
So.
C
B
D
B
B
D
B
A
C
A
I'm
still
drinking
my
coffee
first,
so
yeah.
I
think
that
you
did
a
great
job
overall
and
here's
the
format
of
how
we're
gonna
give
feedback.
So
the
first
thing
that
we're
gonna
do
is
just
go
around,
give
mostly
the
positive
things.
First,
impressions,
specific
things
that
you
liked
after
we
had
a
round
of
going
around
after
we
had
a
round
of
going
around
the
table
and
talking
about
like
the
positive,
we'll
give
specific
things
to
improve
and
work
on.
A
I
wrote
my
things
down
the
google
doc
just
so
that
josh
had
a
list
of
things
that
he
could.
You
know
reference
in
the
future,
so
I'll
go
first,
just
to
kick
things
off
josh.
I
think
you
did
a
great
job
for
for
your
first
like
demo.
I
think
that
this
was
solid,
so,
like
keep
in
mind
like
I've,
seen
hundreds
and
hundreds
of
people,
new
hires
new
essays,
give
demos,
and
I
think
that
your
demo
is
good,
specific
things
that
I
liked
about
it
is
that
I
liked
your
energy.
A
A
I
really
liked
how
specifically
how
you
handled
the
technical
question
that
you
didn't
know
so
like
once
again,
y'all
aren't
essays
and
it's
very
like
I
thought
that
I
really
liked
how
you
handled
like
hey.
I
don't
know
the
answer
to
this
right
now,
but
let
me
get
back
to
you
so
when
I
was
a
new
essay
at
red
hat,
we
had
25
different
products
and
a
lot
of
people
that
we
talked
to
are
more
technical
than
we
are
right.
A
It's
just
a
fact,
and
in
my
career
I've
used
that
exact
line,
maybe
50
to
100
times.
I've
never
had
someone
kick
back
and
like
call
me
out
on
not
knowing
something
people
understand,
if
you
don't
that
you're
not
going
to
know
every
single
like
thing
about
your
product,
so
I
really
really
liked
how
you
did
that.
D
I
agree
with
the
same
I
liked
the
enthusiasm
and
he
went
into
explaining
things
also
when
there
was
a
you
know,
maybe
a
little
bit
of
a
an
issue
with
an
answer.
If
you
didn't
know
it
at
the
moment
right
away
to
answer,
you
gave
a
good
guidelines
like
I
will
send
you
a
proper
documentation
or
you
know
we
can
have
a
next
call
to
discuss
more
around
it.
So
I
think
it
went
pretty
well
good
job.
F
I
totally
agree
josh.
I
also
think
that
something
I
really
enjoyed
was
there's
a
few
slides
there,
which
I
personally
have
not
seen
in
a
demo
and
like
I
like
how
you
kind
of
went
into
detail
on
the
road
maps
and
the
burn
down
charts.
I
like
how
you
kind
of
made
it
really
individual.
You
know
following
the
steps
and
seeing
what's
happening,
what's
up
to
date,
what's
lagging
and
from
my
side
I
was
at
least
quite
new
and
actually
was
kind
of
like.
F
C
E
G
Yeah,
you
clearly
see
that
you're
not
afraid
to
talk
and
you
you
have
a
very
good
expression,
everything
you
feel
comfortable.
It
feels
comfortable
to
listen
to
you
and
you're,
not
boring
or
anything,
and
you
know
you
have
a
very
nice
voice
and
everything
to
it.
So
it
felt
really
like
a
private
nice
conversation
and
you
were
trying
to
show
certain
aspects
of
gitlab
how
they
can
be
beneficial,
but
in
a
very
friendly
manner
and
not
nosey
or
anything.
So
I
liked
your
tone
a
lot.
B
F
F
We
could
have
said
like
hey,
we
lost
you
there
for
like
10
15
seconds,
but
I
mean,
as
chris
said,
you
know
these
technical
things
generally
happen
and
again
you
were
like.
What's
up,
do
you
have
any
questions,
so
I
don't
really
have
any
negatives
that
are
from
your
side
just
for
the
technical
side,
but
yeah.
D
I
think
we
in
in
sales
or
inside
sales,
more
or
less
since
we
don't
we're,
not
technical.
Of
course,
we
don't
understand
the
products
in
details.
We
can
go
very
into
like
deep
dive
sessions.
We
try
to
explain
things
or
over
explain
things.
Sometimes,
I'm
not
sure
if,
if
you
know
anyone
notice
that,
but
but
sometimes
I
do
also
that
on
the
calls
you
know
like
I
already
made
my
point
that
I'm
like
going
continuing
explaining
it's
like
okay,
it's
enough!
Stop
it!
It's
all
right!
You
know
you
already
did
it
as.
D
C
G
Yeah
from
my
side,
the
only
thing
that
I
would
have
done
a
little
bit
differently,
but
I
don't
know
if
this
was
your
plan
or
anything
to
start
from
a
to
z,
but
to
at
the
beginning
ask
the
person.
What
do
you
want
to
see?
What
are
you
most
curious
and
then
they
say,
for
example,
I
want
to
know
about
burn
down
charts,
because
maybe
they
know
all
about
this
and
this
and
that
what
you
showed
them
just
ask
them.
G
A
A
A
A
C
A
I
thought
it
was
a
great
job
overall.
I
think
that
one
of
the
things
that
I
point
out
is.
I
know
that
when
we're
talking
about
our
technical
capabilities
and
stuff,
it's
really
I
I
feel
like
it's
really
important
to
know
that
most
people
don't
know
what
does
fuzz
testing
and
maybe
even
burn
down
charts
are
in
a
specific
sense
that,
like
unless
you're
a
security
person,
you
don't
know
what
like
a
lot
of
the
security
things.
A
Are
you
probably
know
what
like
things
like
dependency
scanning
are,
but
I
wouldn't
assume
that
it's
almost
like.
So
I
guess
like.
Let
me
rephrase
if
you
go
to
a
hardware
store
and
you're
looking
at
something
like
a
lawnmower,
then
saying
like.
Oh,
it's
got
xyz
super
technical
things
like
if
it's
just
an
average
person
who's
like
a
homeowner,
then
it
might
be
too
technical
for
them
and
it
could
just
be
saying,
like
we
have
state-of-the-art
security
things.
A
So
let
me
explain
what
these
things
are
now
you
seem
like
a
trusted
advisor,
so
most
engineers
just
like
do
not
know
what
dast
is,
and
they
also
don't
really
know
what
things
like,
like.
A
burn
down
chart
most
people
don't
have
burn
down
charts.
So
I
I
wouldn't
introduce
some
of
these
things
as
like
as
like,
potentially
like
a
new
topic
as
as
opposed
to
assuming
that
the
audience
knows
what
they
are,
but
it
depends
on
the
audience
too.
A
A
Okay
and
the
other
thing
is
so
we
didn't
do
this
the
first
time,
but
once
we
go
in
the
presentation
mode
like
I'm,
I'm
no
longer
like
we
are
no
longer
sdrs
at
gitlab.
We
are,
we
are
prospects
so,
like
I
I'm
just
gonna.
If
you
ask
me
like
a
question
like
hey
chris,
you
know
it
can
house,
ask
me
to
explain
something
or
whatever
I'm
gonna
be
like
hey,
I'm
I'm
not
chris
the
essay
from
get
lab.
A
C
E
So
hi
everyone
again
based
on
the
conversation
we
had
up
until
now.
I
think
it
would
might
make
sense
to
give
you
a
better
visual
of
gitlab
so
just
to
set
expectations
right
here.
I
don't
have
any
engineering
background,
but
I'm
happy
to
show
you
what
I
know.
So,
if
you
would
like
to
see
just
yeah
the
real
basic
developer
flow,
I'm
happy
to
show
you
something
right
now.
Would
that
be
of
interest?
C
C
E
What
you
see
here
is
the
basic
gitlab
sas
and
specifically
source
code
management
here
in
this
top.
So
this
is
our
versioning
software
and
it
is
basically
a
complete
solution
if
you
have
ever
used
github
bitbucket
something
like
this.
This
is
very
similar
to
what
we
have
and
we
have
even
more
to
offer
in
some
some
aspects.
E
So
here
you
can
see
all
the
different
files
that
are
in
my
project.
This
is
the
gitlab
project
and,
as
I
said,
we
have
a
complete
versioning
solution.
So
what
we
mean
by
that
is
that
we
can
go
to
the
history
view
here,
let's
open
it,
and
we
see
what
has
been
done
here
in
the
last
couple
of
minutes
by
whom
and
when.
E
E
So
here
we
are
back.
So
if
I
go
here
into
a
file-
and
I
click
on
history,
I
can
see
even
the
changes
that
have
or
have
not
been
done
within
a
specific
file
and
again
by
whom
and
when
great.
So
this
is
a
bit
more.
This
was
a
bit
about
source
code
management.
I
can
show
you
when
it
comes
to
a
specific
issue,
so
here
we
are
in
a
specific
issue.
E
E
This
is
just
an
example
of
one
issue
and
you
can
see
what
what
has
been
done
in
each
issue.
First
of
all,
you
see
the
description
by
the
engineer,
what
he's
trying
to
achieve
the
proposal,
and
then
you
see
collaboration
from
different
stakeholders
within
the
issue,
but
let's
take
also
a
look
at
the
right
hand
side.
E
E
E
If
you
want
to
use
that,
you
can
add
a
due
date
here
and
make
use
of
labels,
labels
could
be
either,
for
example,
specific
engineering
and
departments
or
units
of
your
organization,
and
last
but
not
least,
I
mean
there
are
more
things,
of
course,
to
add,
but
is
weight,
so
it
could
be
a
really
important
item,
a
very
big
work
item
that
you've
been
working
on
and
you
can
give
more
weight
then
to
some
smaller
issues.
For
example,
that
was
just
about
changing
a
quick
button
on
on
your
website.
E
So
yes,
this
was
an
issue
and
after
an
issue
has
been
solved
and
discussed
thoroughly
and
the
engineer
feels
like
okay,
it's
ready,
he
would
create
a
merge
request.
Here's
an
example
of
a
merge
request
in
order
to
have
the
code
actually
changed
so
over
here
in
the
merch
request.
Again,
you
see,
I
just
give
you
a
general
overview
of
all
the
merch
requests.
E
This
is
how
it
looks
and
again
you
have
a
very
good
overview
about
the
labels
that
are
involved
here,
so
the
departments
that
might
be
working
on
or
the
engineering
departments
plus
when
it
has
been
worked
on
last,
but
going
into
a
specific
merge
request
is
here,
for
example,
you
see
again
what
let's
say
the
definition.
So
what
this
merge
request
is
supposed
to
do
what
the
engineer
tries
to
achieve
with
that,
and
then
you
would
see
again
collaboration
on
the
issue
here
by
different
stakeholders.
A
Yeah,
so
we
have
a
lot
of
open
source
projects
that
we
work
on,
and
our
business
is
that
we
basically
sell
services
on
the
open
source
projects
project
and
because
of
that
we
get
a
lot
of
community
contributions.
So
can
you
walk
me
through
what
sort
of
approval
mechanisms
you
have
for
merge,
requests.
E
E
E
So
if
we
go
into
the
changes
here
in
in
emergency
quest,
you
see
with
everything
that
is
marked
green
here.
The
changes
that
should
actually
happen
opposed
to
the
the
red
lines
here
that
yeah
should
be
replaced
or
taken
out.
So
the
code
changes
that
are
supposed
to
happen
here
and
also
very
important.
You
can
have
a
look
into
the
pipeline
directly,
so
you
can
see
what
happened
in
your
pipeline.
E
So
talking
about
pipelines
here
is
an
idea
about
the
ci
in
the
background
right,
so,
as
you
can
see,
there
are
very
different
stages
to
it.
The
first
stage
is
to
prepare
our
environment.
The
second
is
to
build
build
images,
and
what
is
very
important
here
is
the
testing
stage
just
scroll
a
bit
down,
because
there's
plenty
of
tests
that
are
happening
here
so
over
here.
A
Hey,
hey,
christina,
I
got
a
question
about
this
screen,
so
is
this
something
that's
customizable
or
like
how
it
seems
like
there's
a
lot
of
stuff
here
and
we
have
a
bunch
of
really
weird
security
requirements
in
our
environment.
So
I
imagine
that
some
of
the
things
that
we
have
are
gonna
be
kind
of
non-traditional.
We
have
like
a
disconnected
environment.
C
E
Yeah,
that's
a
great
question,
and
this
is
what
I
wanted
to
show
you
next.
So
thanks
for
leading
me
there
chris,
so
this
is
completely
configurable
in
our
dot.
Gitlab
ci
dot,
yaml
file
here.
So
basically,
all
the
stages
that
I
just
showed
here
are
completely
customizable.
So
you
have
your
configuration
file
here
and
yeah.
It's
up
to
you.
What
would
you
like
to
build
and
how
you
would
like
your
stages
and
pipelines
to
run.
A
E
E
Yeah,
okay,
perfect,
so
you
asked
me
already
so
this
was
the
our
yaml
file,
how
you
can
configure
all
your
different
stages,
yeah,
there's
really
nothing
to
add,
but
that
file
also
lives
in
our
repo
itself,
so
making
things
version
controlled
and
really
easy
to
see
from
accountability
perspective
yeah.
I
think
that's
all.
I
can
show
you
for
now,
but
please
let
me
know
if
you
have
any
questions
for
me.
A
E
A
Yeah,
that's
great.
I
remember
that,
like
sometimes
when
we
have
these
new
essays
come
on
board
these
people,
who
have
like
two
to
four
years
of
experience
like
they,
they
start
sweating
too
a
matter
of
fact.
I
think
I
did
the
first
time
I
went
through
this
as
well,
so
it's
totally
normal
who
wants
to
kick
off
positive
feedback.
G
B
Okay,
I
thought
overall,
like
it
was
it
felt
super
natural
and
it
felt
like
especially
like
right
from
the
beginning
like
where
you
were
setting
expectations
right
up
front.
I
thought
that
was
really
really
really
positive,
so
I've
I
felt
like
the
flow
it
felt
like
it
felt
like
you
knew
what
you
were
talking
about.
You
were
confident
it
made
it
made
me
and
I
think
everybody
else
feel
very
comfortable.
D
E
F
Chris,
I
was
curious
to
the
questions
that
you
were
asking
there.
Is
there
I'll
be
curious
to
hear
what
you
would
see
as
an
ideal
answer
to
like
some
of
those,
because
obviously,
of
course
you
know,
there's
obviously
the
one
where
it's
you
know
we'll
revert
back
with
some
technical
stuff,
but
I'm
curious
like
from
your
side,
you
know
you
being
the
one
asking
in
a
prospect's
point
of
view,
what
kind
of
answer
again
not
going
to
technical.
Would
you
like
to
hear?
A
Yeah,
I
think
that
the
ones
that
I
get
asked
the
most
when
I
go
on
calls
is
how
does
our
stuff
integrate
with
other
things
jenkins
jira,
whether
or
not
we
need
to
replace
everything
else
and
then
some
specific
questions
about
like
ci,
so
when's
it
triggered
what
controls
it.
I
have
a
special
environment,
you
know
what
determines
it
and
I
think
that
christina
you
handled
all
those
questions
perfectly.
A
The
answer
was:
get
lab,
ci
dot,
yaml
file
and
for
some
of
the
more
technical
things
you
just
redirect,
so
I
actually
think
that
some
of
the
questions
that
I
asked,
like
you
clearly
explained
in
the
beginning
that
you
don't
have
a
technical
background,
so
I
should
like
me
as
the
audience
like
I
I'm
not.
I
have
proper
expectations
right
and
I
think
that
you
did
a
really
great
job
of
that.
G
Well,
the
only
thing
that
I
came
to
mind
is
that
you
very
often
you
pause
and
you
your
own
or
something
because
I
think
you're
looking
for
the
next
word
and
everything
don't
be
shy
to
pause,
just
pause
and
ask.
Is
everything
clear
that
I
said
so
far?
Do
you
need
more
references
to
this?
Do
you
have
any
questions
and
while
you
ask
this
think
of
what
you
do
next
just
ask:
if
everything
is
clear
and
this
time
think
about
what
you
want
to
do
next
to
not
have
those
pauses
other
than
that.
G
To
be
honest,
it
was
well
structured
and
everything,
and
if
you
have
all
your
tabs
hope
and
everything-
and
you
know
what
you
want
to
show-
this
is
most
important
and
just
figure
out
in
between
the
pulses.
How
to
fill
the
silence-
and
I
think
by
asking,
is
everything
clear
and
asking
questions
that
could
be
beneficial.
E
A
A
So
we
talked
about
issues
and
how
issues
are
a
discrete
unit
of
work.
You
did
a
really
great
job
explaining
that,
and
so
I
I
talked
about
in
my
tutorials
that
issues
are
for
like
buttons
and
if
hey
you
have
to
go,
make
a
chart,
you
have
to
make
a
shopping
cart
thing
in
a
website,
so
I
use
those
examples
because
they're
easy
to
understand.
A
The
vast
majority
of
issues
are
not
for
like
things
like
buttons.
The
vast
majority
of
issue
work
is
like
for
something
that's
like
hard
to
explain.
So
it's
like.
I
need
to
update
this
script.
I
use
like
ansible
version
2.7.1,
and
I
have
to
update
like
this
very
specific
technical
thing
with
this
parameter
so
like
when
talking
about
issues,
I,
wouldn't
I
wouldn't
reference
websites.
Well,
actually
let
me
take
that
back.
A
I
wouldn't
talk
about
specifically
like
buttons
and
charts,
because
I
think
that
maybe
issues
are
five
percent
of
all
issues
out
for
customers
are
actually
like.
Parts
of
websites
like
that
are
graphical
elements,
and
any
other
thing
regarding
phrasing
is
like
with
pipelines.
Pipeline
is
a
very
specific
thing
per
a
tool,
so
a
pipeline
for
a
git
lab
is
different
than
a
jenkins
pipeline,
which
is
different
than
like
azure
devops
pipeline.
So
I
think
that,
like
it
would
be
good
to
explain
a
little
bit
more.
Hey
gitlab
has
this
concept
of
pipelines.
A
What
pipelines
is?
Is
it's
an
automated
job,
saving
you
time
money
and
allowing
you
to
focus
on
your
business
drivers?
So-
and
this
is
what
a
pipeline
is,
do
you
have
people
who
do
all
this
stuff
manually?
Well,
they
don't
have
to
do
that
anymore.
They
can
go,
do
something
else
right.
So
that's
what
a
pipeline
is,
but
overall
I
thought
it
was
a
really
great
job
and
I
could
definitely
tell
that
you
practiced.
So
thanks
for
doing
that,.
G
Hey
chris
is
alexander
from
gitlab
nice
to
meet
you.
It
would
be
great
to
we're
here
now
to
like
show
a
little
bit
off
of
gitlab
like
we
talked
about,
and
if
you
would
walk
me
through
a
little
bit
your
process
and
tell
me
what
kind
of
functionality
you're
most
interested
in,
let's
see
if
we
can
walk
through
them
from
the
basic
side.
As
you
know,
I'm
working
as
a
business
developer.
So
I'm
not
an
engineer
but
well.
G
I
will
try
my
best
to
answer
your
questions
and
show
you
a
basic
overview
of
what
we
do
and
should
we
go
into
more
detail
or
you
need
more
detailed
information.
I
can
send
you
over
lots
of
information
on
our
documentation
site
and,
if
needed,
maybe
later
on.
Have
a
solution.
Architect
assist
you
so
from
my
side,
what
you
want
to
see
and
what
you're
most
interested
in
and
let's
try
to
do
this
this
way.
A
A
I
think
that
my
organization,
we
just
run
into
bottlenecks,
a
lot
of
the
time
and
we're
just
trying
to
speed
up
our
development
processes
in
general,
so
specific
things
that
I'm
working
on
is
introducing
more
automation
into
our
environment
and
also
making
sure
that
we
have
metrics
so
that
we
know
when
we
are
coming
up
with
organizational
wins
but
josh
and
goran.
If
you
all
have
any
additional
things
that
you
want
to
see.
I'd
love
to
hear
from
your
perspective
as
well.
B
D
All
right
thanks!
Well
yeah,
I
mean
just
to
to
add
on
on
on
christopher
I'd,
like
also
to
see
a
how
gitlab
can,
for
example,
help
us
with
auto
devops
as
well
as
testing
in
general,
and
then
we
as
project
managers
would
like
to
see
the
efficiency
of
the
different
teams
and
how
they
work.
So
that
dashboard
that
the
christopher
mentioned
on
the
kpis
and
metrics
would
be
relevant
thanks.
C
G
C
A
C
G
Well,
then,
let
me
try
from
the
start
and
then
maybe
dig
deeper
when
you
see
something
you
want
to
know
more
about,
but
this
is
basically
gitlab
where
you
see
from
the
start,
where
you
see
our
source
code
management
and
everything,
and
you
see
all
our
files
and
you
can
dig
deeper
in
every
file
and
see
files
histories
and
what
we
do
in
our
source
code
management.
If
you
working
with
github
or
bitbucket,
it's
very
familiar
to
yours.
G
Is
is
many
issues
combined
together
to
one
big
thing
where
you
see
step
by
step?
What
needs
to
be
done
in
what
kind
of
order
and
everything
and
is
this
something
your
project
management
people
are
looking
into-
is
to
something
that
you
you're
interested
in?
Or
is
this
something?
That's
because
you
have
a
small
team
right
now
is
not
big
on
your
agenda.
A
G
G
You
can
fully
replace
it
in
time
if
you
wish
to,
but
you
can
also
work
with
it
side
by
side
and
keep
using
eugene,
especially
because
of
all
the
history
that
you
probably
have
established
over
the
years,
which
is
understandable
that
it's
not
that
easy
to
replace
but
gitlab
integrates
it
completely.
So
you
then
not
have
to
switch
between
two
programs
and
two
tools.
You
will
have
everything
running
within
gitlab
and
you
can
see
everything
side
by
side
other
than
that.
G
You
want
to
save
on
costs,
you
might
be
able
to
replace
it,
but
I
will
send
you
this
documentation
about
this,
and
if
we
need
a
deeper
discussion
about
how
to
maybe
integrate
or
replace
jira,
we
can
set
up
another
call
or
if
the
documentation
is
is
enough.
You
can
ask
me
some
questions.
Maybe
later.
A
G
I
think
that
is
possible.
To
be
honest,
I
will
look
deeper
into
this,
but
it
makes
total
sense
that
it
is
possible.
It
depends,
obviously
how
much
time
this
would
need,
but
I'm
pretty
sure
that
it
is
possible.
It's
probably
made
of
time
and
money
how
long
it
will
take.
We
have
lots
of
different
clients
who
work
with
jira
side
by
side.
C
A
G
Yeah
that
makes
total
sense.
I
will
write
this
down
and
send
you
a
little
bit
of
documentation
over
where
you
can
see
how
you
can
replace
it,
how
you
can
integrate
it,
where
the
benefits,
how
much
time
it
would
need.
We
have
lots
of
documentation
about
this
and,
if
needed,
I
will
obviously
inform
one
of
our
solution.
Architects,
to
take
a
look
at
this
in
particular
and
then
maybe
set
up.
Another
call
with
you
sounds
great:
where
are
we
now?
G
If
I
jump
to
the
next
slide,
this
is
basically
a
merch
request.
I'm
pretty
sure
you
know
what
a
merge
request
is,
but
it's
basically
when
you,
when
your
developers
are
working
on
an
issue
and
they
didn't
want
to
make
the
change.
It
triggers
a
merge
request,
and
you
can
see
here
what
were
the
changes
in
red
and
green
and
if
you
jump
to
the
next
c,
you
see
the
pipeline.
G
The
pipeline
is
basically
the
automated
job
that
runs
in
the
background
when
you
want
to
change
something,
and
you
can
then
see
what
you
have
configured
in
your
yaml
file.
What
you
want
to
run
in
this
merge
request
what
you
want
to
run
and
everything-
and
this
can
be
lots
of
different
things.
The
big
benefit
within
gitlab
is
that
many
security
tests
are
implemented
from
the
start.
G
To
not
have
you
bother
at
the
end
that
maybe
something
is
not
working
or
something
has
a
security
issue
or
anything,
and
this
is
very
beneficial
to
many
in
the
business
to
just
save
on
costs,
but
it
obviously
depends
on
which
tier
you
want
to
use
and
and
if
you
want
to
learn
a
little
bit
about
the
different
tiers
and
about
the
different
functionalities.
We
can
talk
about
this
also
because
it
really
depends
if
you
wanna,
take
everything
in
from
the
gitlab
side
or
if
you
wanna
start
with
the
basics.
G
Like
you
said,
I
think
before
you
want
to
reduce
some
kind
of
tools.
So
it
would
be
interesting
for
me
to
know
what
other
tools
you're
using
besides
jira,
what
you're
using
right
now
for
source
code
management
or
do
you
have
a
dedicated
ci
tool
or
if
you
use
any
anything
for
security
testing,
and
then
we
can
see
if
we
can
leverage
in
a
another
call
if
it
might
be
useful
for
you
from
a
financial
point
of
view
or
from
a
technical
side
how
to
replace
it
or
how
to
integrate
with
it.
A
Yeah,
this
is
kind
of
an
embarrassing
answer,
but
we
because
we
are
primarily
open
source
and
we're
just
getting
started.
So
we
just
got
to
be
around
of
funding,
so
security
isn't
something
that
we
are
super
focusing
on
we're
still
trying
to
come
up
with
a
mvp
for
our
product,
that
we
can
show
investors
and
eventually
become
cash
flow.
Positive.
That's
our
first
goal
for
our
business.
A
So
what
we
do
primarily
for
security
right
now
is
just
what's
built
into
github,
so
we
have
dependency
scanning
and
some
other
things
that
are
built
out.
We
use
some
of
github
actions
for
very
basic
things
like
container
scanning,
but
we
don't
have
things
like
sas
and
vest
built
in
what
type
of
applications
work
for
assassin
das.
Is
it
just
web
applications,
or
is
it
like
what?
A
G
To
be
honest,
I
don't
know
because
this
is
a
little
bit
too
deep
dive,
but
I
will
look
it
up.
I
made
a
note
right
now
that
you're
interested
in
this
and
I
will
send
documentation
over
what
we
can
look
up.
If
is,
if
you
want,
because
you
mentioned
github
and
github
actions
and
everything
I
know,
gitlab
has
also
security
dependencies
getting
and
everything
included.
G
We
can
look
up
what
are
the
difference
between
the
packages,
because
you
just
said
that
you're
looking
for
funding,
I
guess
your
startup
and
everything.
So
the
question
is:
how
beneficially
is
it
to
just
start
with
our
free
tier?
Or
what
will
you
gain
if
you
upgrade
to,
for
example,
our
bronze
tier,
the
starter
tier,
which
will
give
you
a
certain
extra
functionality
that
you
might
need,
for
example,
technical
support
not
from
a
lay
person
like
me
that
just
working
business
development,
but
you
have
a
technical
team
that
stands
behind
it.
G
B
I
I
can
I
pop
in
here
too.
I
I
think
that
it
would
be
very
helpful
to
look
through
kind
of
the
pricing
that
you
were
just
talking
about,
but
as
as
chris
was
saying,
we
are
trying
to
become
cash
flow,
positive
and
I
know
there's
going
to
be
a
cost
to
any
level.
So
if
you
could,
you
could
show
us
a
little
bit
about.
G
B
G
Yeah,
if
you
self-host
them,
they're
called
starter
premium
ultimate,
the
functionalities
are
very,
very
similar
and
the
prices,
as
you
can
see,
are
exactly
the
same
and
to
quickly
tell
you
about
differences.
Basically,
when
you
on
our
bronze
plan,
it's
for
single
project
management,
not
for
multi-project
management,
so
on
the
premium
tube,
you
gain
lots
of
agile
management
and
lots
of
project
management
tools
and
under
starter
plan,
you
gain
lots
of
source
code
management
and
issue
benefits
to
the
free
plan.
G
All
of
the
issues
and
everything
and
the
gold
ultimate
plan
basically
focuses
a
lot
on
security
and,
as
you
just
said,
security
is
not
that
much
on
your
radar.
I
would
take
a
quick
look
at
it,
but
probably
not
for
you
interesting
at
the
start,
so
I
would
say
just
look
into
the
difference
between
start
and
premium
and
see
what
kind
of
functionality
you
see
is
are
a
must
and
what
kind
of
function
that
you
would
like
to
have.
G
Then
we
can
maybe
establish
another
call
with
one
of
our
account
executives
to
maybe
help
you
from
a
financial
side
of
you
making
a
point
if
it's
beneficial
to
your
organization
and
other
than
that
see
where
you
can
start.
You
can
always
start,
for
example,
on
the
bronze
plan
and
then
upgrade
to
a
silver
plan
or
start
a
plan
and
premium
plan.
So
upgrading
and
going
up
the
ladder
is
always
possible
which
many
of
our
customers
do
in
time.
G
Is
there
any
certain
functionality,
while
I'm
scrolling
through
here,
that
you
see
that
peaks?
Your
eye,
for
example,
burn
down
charts.
You
gain,
obviously
on
the
starter
package
and
more
issue
board
configuration
very
important
required,
merge,
request
approval,
so
not
everybody
can
so
you
really
know
who
approves
your
merch
requests
and
everything,
and
you
can
have
it
even
multiple
approvals
for
your
code
and
everything
so
like.
G
And
if
we
scroll
down
and
go
a
little
bit
then
into
the
next
plan
you
can
see
when
it
comes
to
labels
epics,
you
can
have
multiple
issue
boards
because
they
said
one
is
a
single
project
management.
The
other
one
is
for
multiple
projects,
so
you
gain
lots
of
functionality.
If
you
have
many
different
projects
running
and
everything
if
epics
become
interesting,
roadmaps
becomes
interesting.
G
Is
there
anything
you
want
to
see
while
I
was
scrolling
through
here
where
you
can,
where
you
think,
like
okay,
road
maps
is
very
interesting
to
me.
I
want
to
see
how
you
do
this
or
is
there
anything
you
want
me
to
show
regarding
specifics
to
plans,
or
do
you
have
an
overview
right
now
that
you
think,
okay,
that
piqued
my
interest?
I
will
send
you
more
information
over
and
then
we
can
collaborate
on.
A
G
Okay,
so
so
I
will
just
to
recap
everything
I
will
send
you
over
to
documentation
about
our
dashboards.
I
will
send
you
documentation
over
about,
I
think,
security
and
application
testing
you
mentioned,
and
the
jira
integration,
everything
regarding
jira
and
gitlab,
and
about
the
benefits
about
our
starter
and
our
premium
plan.
And
what
are
the
differences?
Did
I
miss
anything
or
does
that
sound?
Okay,.
G
Wonderful,
then,
thank
you
so
much
for
this
short
demonstration
getting
to
know
your
business
a
little
bit
better.
I
will
send
a
follow-up
email
right
after
this
call
and
with
documentations
and
everything,
if
you
have
any
kind
of
questions,
feel
free
to
reach
out
to
me
directly
or
if
you
want
to
set
up
another
call,
we
can
establish
this.
A
Cool
you
came
in,
you
are
over
time.
You
came
in
at
21
minutes
and
40
seconds,
which
is
fine,
sometimes
calls
go
along.
We
all
know
how
that
works.
So
first
put
the
mic
in
your
hand.
What
do
you
think
about
it
and
how
did
you
feel
yeah
if
you
could
do
it
over
again?
What
do
you
think,
like
I'm
just
curious
as
to
what
you
thought
about
it.
G
I
would
need
to
look
at
that
because
I
just
opened
the
slides
before
the
before
I
started
and
everything
because
I
didn't
prepare
that
I
will
do
a
demo
right
now,
so
I
will
need
to
look
into
the
the
tabs
and
everything
and
materials
I
really
know.
Where
is
what
for
me
just
to
have
it
better
open
than
anything
other
than
that
yeah?
I
have
a
little
better
structure,
I
would
say,
would
be
nice,
but
other
than
that.
I
think
I
winked
it
pretty.
G
Okay
and
yeah,
I'm
thinking,
sometimes
of
maybe
showing
them
a
different
kind
of
documentation
right
away,
because
I
mean
I
saw
that
this
happens
many
times
when
I'm
on
the
call
with
a
prospect,
and
they
have
questions,
and
I
share
my
screen
and
I
show
them
directly
our
documentation
page
and
go
through
with
them
through
some
kind
of
answers.
Well,
I
see
the
ease
also,
do
it
many
many
times
just
quickly
show
them,
because
our
documentation
is
enormous.
G
It's
huge
and
there's
basically
an
answer
for
everything
and
also
I
forgot
to
show
the
maturity
page,
which
is
always
interesting
to
see
where
we
can,
where
we
are
leading
and
where
we
are
improving.
But
what
we
can
do
and
what
is
the
difference
between
many
tools,
because
you
mentioned
your
startup.
G
So
I
should
have
probably
showed
you
this
to
see
that,
yes,
where
you
can
save
because
we're
a
single
application
from
a
to
z
and
implementing
different
tools,
costs
money
and
when
you're
just
about
to
start
your
business
and
maybe
think
about
having
one
tool
to
save
on
costs
and
have
better
collaboration.
Everything
push
a
little
bit
more
on
those
value
drivers,
but
other
than
that.
I
think
it
was
okay.
A
B
One
thing
that
I
I
noticed
was,
I
thought
you
asked
really
really
good
questions
throughout
the
whole
process.
It
seemed
like
you,
understood,
kind
of
the
pain
points
that
everyone
was
experiencing,
and
so
I
really
appreciated
that
it
was
like
it
was
like
kind
of
like
a
constant
probing
into
the
psychology
behind
all
of
this.
So
I
don't
know
if
anybody
else
noticed
that,
but
that
was
just
something
that
stood
out
to
me.
F
G
Yeah,
I
think
it
makes
it
easier
if
you
have
a
conversation
going
and
not
just
demoing
everything,
because
it
is
hard
for
us
to
just
name
everything,
because
we
don't
know
what
the
customer
wants
and
b.
If
you
just
have
open
communication,
you
also
learn
about
the
customer,
which
is
important
information
for
us.
G
So
it's
easier
if
you
have
an
open
dialogue
and
just
show
them
some
things
step
by
step
and
on
the
basic
side,
and
I
think
if
we
do
it
more
and
more
often
it
will
come
more
natural
and
we
will
know
exactly
where
to
look
where
to
click
where
to
show
what
and
anticipate
already
okay.
It
now
will
come
the
question
of
this
and
then
boom
open.
Maybe
some
documentation
show
them.
So
that's
the.
C
A
Yeah
I
had
a
lot
of
good
things
written
down
for
you,
the
main
thing
that
I
really
really
liked
is
I
really
loved
how
you
remembered
all
of
your
individual
action
points
so
that
that's
like
one
of
the
keys
that
I
had
when
I
was
doing
direct
to
business
sales
at
red
hat.
I
remembered
every
single
thing
that
I
wrote
down,
wrote
it
in
this
notepad
and
then
that's
how
I
built
credibility
with
the
customer.
A
So
it's
like
these
long
dual
cycles,
maybe
five
to
ten
different
meetings,
remembering
every
single
thing
that
the
customer
ever
asked
in
delivering
it
in
like
24
to
48
hours,
and
so
now
the
customer
trusts
you
and
it
sees
you
as
a
consistent
value.
Add
and
now
just
wants
to
have
more
meetings
with
you.
So
there
are
five
different
things
that
you
said
that
you
do
and
you
remembered
them,
and
I
think
that's
something
that
like
is
very,
very
powerful,
so
I
loved
how
you
did
that.
A
I
also
really
liked
asking
how
you
pulled
us
for
what
we
wanted
in
the
beginning.
I
think
that
that's
something
that's
really
really
good.
I
wouldn't
directly.
I
think
that
there's
pros
and
cons
for
doing
this.
The
pro
is
that
now
your
conversations
tailored
the
con
is
that
the
vast
majority
of
our
customers
do
not
know
about
the
vast
majority
of
the
things
that
we
do.
So
we
can
sort
of
pigeonhole
ourselves
into
this
conversation.
So
it's
like
customer
wants
to
know
about
ci.
A
You
explain
rci
great,
but
there's
also
like
80
percent,
more
value
for
gitlab
outside
of
that
so
sort
of
like
pivoting
from
that
and
saying
yeah
I'd
love
to
share
you
some
of
these
things.
Just
so
you
know,
gitlab
truly,
is
one
tool
for
the
entire
devops
life
cycle
show
the
maturity
page.
Like
you
already
said,
we
literally
have
10
product
stages.
How
many
tools
do
you
use
for
this?
You
use
15.,
well
great!
You
can
consolidate
down
to
one
right,
so
that's
the
pros
and
cons
of
having
a
tailored
approach.
A
I
think
that
both
are
important
where
you
do
take
the
customer
feedback
into
consideration,
but
you
build
off
of
that
and
you
take
that
trusted
advisor
approach
where
it's
like
literally,
we
do
everything
else.
So
I
thought
that
that
was
all
really
good.
I
think
that
your
strength
out
of
all
the
conversations
that
we
had
today,
is
that
you're,
obviously
very
technical.
You
understand
the
customer
journey.
You
understand
the
product,
you
understand
the
space
that
comes
across
very
clearly,
and
I
think
that
yeah.
So
that's
that's!
That's
something!
That's
very
good,
great!
Okay.
A
A
I
don't
have
an
engineering
background,
but
for
you
in
particular,
like
your
strength,
is
that
you
know
the
space
and
the
product
really
well.
So,
like
I
wouldn't
be
shy
about
that
and
yeah
I
mean
the
questions
that
you
asked
are
very
insightful.
So
it's,
like
you,
add
value
in
terms
of
the
questions
and
the
insight
that
you
bring.
A
So
that's
one
thing
that
I'd
say
the
other
thing
that
I'd
say
is
I'd:
throw
in
more
breaks
into
the
presentation
itself.
So
it's
like
my
background's
music
and
it's
like
here's.
This
music
idea
now
throw
in
four
measures
of
just
like
pause
and
that's
super
dramatic,
and
it's
super
like
powerful
right,
and
I
think
that
you
did
do
a
good
job
of
asking
us
like
hey.
What
do
you
think
about
this?
Is
there
anything
else
that
you'd
like
to
see
but
just
sort
of
like
changing
your
vocal
inflection,
see
what.
A
Threw
in
a
pause
right,
so
it's
like
you
can
pause
for
dramatic
effect.
You
can
pause
to
make
them
think
in
terms
of
just
the
presentation
when
you
speak,
it's
sort
of
like
the
same
just
like
keeps
on
chugging
along.
So
I
think
that
if
you
throw
in
some
pauses
mix
things
up,
I
think
that
it
it
would
make
it
could
have
definitely
helped
so
yeah.
A
G
Yeah
I
heard
this
many
times
it's
very
when
I'm
sometimes
in
the
flow
I
stop
breathing
and
I
keep
talking.
Then
I
go
faster
and
faster
and
faster,
and
I
need
to
establish
the
positive
for
myself
and
b
also
when
you
say
something
interesting.
When
you
see
something
good
about
the
product
pause
a
little
bit,
let
it
sink
in
then.
Maybe
a
question
comes
of
it
or
the
people
take
it
more
serious
and-
and
it's
like
a
wow
effect.
So
I'm
working
on
this
very
good
catch
on
this
and
thank
you.
A
Yeah-
and
I
think
that
I
I
get
nervous
when
I
present
too
sometimes
and
then
so
it's
just
sort
of
like
I
actually
pause,
sometimes
to
settle
my
emotions
and
then
so
it's
serving
a
bunch
of
different
pause
like
functions.
One
is
creating
effect,
two
letting
them
think.
But
three
now
like
I
can
just
sort
of
like
take
a
bunch
of
breaths
real,
quick.
So
there's
a
lot
of
functions
for
it.
Great.
G
A
D
Yeah,
I
I
agree
with
christopher,
I
think
you
know
like,
since
you
know
more
around
the
product
and
you're
trying
to
cover
as
much
as
possible.
I
think
sometimes
you
know
and
yeah
having
that
break
is
is
is
important
just
to
see
because
sometimes
you
know
we
can
say
a
lot,
but
maybe
the
audience
maybe
doesn't
doesn't
know
exactly
you
know
if
they,
if
it's,
if
they
understood
it
well
or
not.
Something
like
that.
So,
yes.
D
Yeah,
it
depends
on
the
audience,
but
like
yeah,
I
think
you
have
a
lot
of
knowledge
and
you
know
like
you,
try
to
cover
everything
and
going
go
as
fast
as
possible,
but
I
guess,
as
sometimes
you
know,
establishing
that
slower,
slower
module
and
maybe
saying
less
but
for
fewer
things,
I'm
not
sure
in
20
minutes.
You
know
what
how
much
you
can
do
for
a
demo
gitlab.
It's
also
kind
of
a
tricky
tricky
timeline.
A
D
A
Okay,
yeah
I'll
just
think
I'll
I'll
follow
up
with
that
with
you
in
terms
of
that
async
just
be
mindful
of
everyone's
time.
All
right,
so
to
recap,
did
y'all
feel
like
this
was
a
helpful
experience.
I'm
curious
as
to
what
you
know.
So
it's
like
everyone
went.
What
do
you
all
think
like
did
you
feel
like
you
learned
something?
What
do
you
all
think.
F
A
F
I
mean,
I
think
it's
really
interesting
hearing
everyone's,
let's
say
unique
point
of
view
and
how
they
tailor
it.
You
know
which
unique
style
they
use
and,
as
alex
said,
or
as
everyone
agreed,
I
mean
these
things
just
take
practice
and
you
get
more
into
it.
You
get
more
in
the
flow
as
time
goes,
and
you
kind
of
get
used
to
the
questions
that
are
asked
and
you'll
say
what
questions
should
be
asked.
So
I
think
this
is
a
typical
standard.