►
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
Hi
everyone-
these
are
gitlab
iteration
office
hours.
Iteration
is
our
hardest
value,
we're
full
of
ambitious
people
who
think
big,
but
we
force
ourselves
to
execute
small
and
fast
and
get
something
out
the
door
quickly.
So
we
get
feedback
from
people
andrew.
You
have
the
first
item.
Thanks
for
putting
something
on,
you
want
to
verbalize.
It.
B
I'm
not
sure
he's
here,
sid
victor
is
here,
though,
if
you
want
to
skip
to
three
cool.
A
C
Sure
lately,
I
watched
quite
a
few
iteration
videos
from
you
and
one
topic
that
came
to
my
mind
watching
those
was
that
how
would
you
relate
solution,
validation
and
basic
discovery
to
iteration
like
where
would
it
stop,
and
what
can
it
add
because
often
what
I
hear
is
more
that,
let's,
let's
aim
smaller
in
terms
of
delivery,
but
but
how
can
we
win
even
before
that
that
would
be
the
question
or
how
do
you
see
that.
A
I'm
not
sure
I
completely
understand
the
question.
Let
me
have
a
stab
and
an
answer
and
then
please
follow
up,
but
I
think
there's
a
place
for
solution.
Validation,
first
of
all,
kind
of
asking
customers
and
working
through
kind
of
an
idea.
Maze
is
faster
and
more
efficient
than
actually
writing
something.
A
But
then,
as
soon
as
you're
writing
something
the
you.
You
want
to
keep
validating
that
you're
on
the
right
path
and
the
way
to
do
that
is
to
ship
it
to
customers
and
get
their
feedback.
So
there's
just
two
ways
of
solution:
validation,
the
talking
part,
the
idea,
maze,
part
they're,
getting
feedback
on
an
idea.
Super
efficient
totally,
do
it,
but
there's
a
much
higher
fidelity
to
giving
something
that
people
actually
use.
A
They'll
suddenly
change
a
lot
of
their
opinions,
and
it's
frequently
when
we
ship
the
first
iteration
and
people
shift
what
they
want
in
two
three
and
four
to
something
very
different
than
they
expected
earlier.
Either
they
don't
need
those
things
or
they
need
different
things.
B
D
B
If
I
could
weigh
in,
I
think,
there's
sort
of
a
sweet
spot
when
you're
trying
to
validate
something.
B
D
A
Yeah,
and
and
using
like
validation
in
the
strict
sense
of
kind
of
discussing
an
idea
with
a
customer.
I
totally
agree-
and
I
think
probably
frequently
the
the
thing
you're
validating
with
a
customer
is
going
to
be
bigger
than
the
first
iteration
you
can
ship,
because
you
you
do
have
the
the
confusing
thing
about
iteration
is
you
do
have
a
vision
about
the
future
and
it's
pretty
well
articulated
it's
just
something
to
you
can
quickly
move
like
we
can
change
the
direction
page
of
of
of
of
something
we
have
at
the
lab.
A
We
can
change
it
in
an
hour
just
rewrite
it,
so
super
cheap
to
move
well
if
we
ship
the
code
or
that
that's
really
hard
to
change.
So,
if
you
don't
ship
iteratively,
you
don't
have
a
chance
to
move
when
you're
you're,
you
end
up
being
here.
Well,
you
should
have
been
here.
Well,
if
you
take
small
steps,
you
can
amend
your
path
and
go
to
the
optimal
location.
Victor.
C
Yeah
thanks
actually
the
two
together
kind
of
answered
the
question,
because
really
what
I
had
in
mind
as
well
is
that
we
validate
something
much
bigger
and,
and
it
seems
to
be
kind
of
fine,
that
it's
much
bigger
than
a
small
thing,
and
but
once
we
move
it
to
delivery,
we
then,
then
we
aim
to
the
smallest
possible
thing.
There
thanks.
I
would
recommend
moving
on
to
the
other
topics,
because
I
saw
when
we
failed.
The
docs
and
actually
justin
was
before
me.
A
Cool,
I
want
to
add
one
thing,
and
that
is
it's
tricky
to
have
to
do
both
to
do
both
validation
and
iteration,
because
if
you
validate
a
solution
with
customers,
it's
easy
to
hang
on
to
that
idea
and
not
be
open
to
to
iteration
and
not
be
open
to
the
feedback.
That
iteration
provides,
and
I
think
both
have
their
both
have
their
place.
But
it's
important
that
we
don't
get
wetted.
A
We
make
a
big
plan
or
we
we
validate
a
bigger
plan.
But
we
don't
get
wedded
to
that
idea.
We
keep
an
open
mind,
and
that
is
that
is
very
hard
and
that's
something
we
we
need
to
do
because
there's
there's,
there's
a
it's
very
efficient
to
do
solution,
validation
as
well
as
long
as
you're,
not
doing
code.
E
Sure,
sorry,
I
was
late,
so
this
came
up
in
a
call
yesterday
where
we
were
prioritizing
based
on
a
incident
that
happened
last
week
and
a
new
suggested
that
I
bring
it
up
in
the
iteration
office
house.
So
basically,
we
have
dozens
of
different
bots
and
they're
all
kind
of
built.
E
In
the
same
way,
they
normally
run
in
ci
on
a
schedule
and
they
use
our
api
and
they
will
read
a
whole
bunch
of
of
issues
and
then
they
will
write,
notes
to
issues
or
open,
merge,
requests
or
do
something
like
that
and
and
they
all
kind
of
run,
every
10
minutes
or
20
minutes
or
whatever,
and
it
works,
but
they're
problems
with
the
way
that
we
do
it
and
there
might
be
better
ways
that
we
can
do
it.
And
how
can
we
start
thinking
about
iterating
on
that?
E
I
think
is
the
is
the
ask.
A
Yeah
thanks
for
that,
so
I
read
here
that
the
downside
so
I'll
read
some
of
them.
That
is
that
the
gitlab
bot
account
is
used
for
many
things
and
it
makes
a
lot
of
api
calls.
So
it
has
a
rate
limit
exception.
E
E
But
it's
still,
I
I
think
that
there's
a
there's
a
possibly
better
way
to
do
it
right,
which
is
that,
if
we're
looking
for
new
issues
being
created
like
can't,
we
have
an
event
that
we
get
told
an
issue
is
being
created,
go
off
and
and
run
this
piece
of
code
on
issue
creation
or,
on
you
know,
issue
being
closed
or
whatever
and
allow
customers
a
way
of
kind
of
automating.
Some
of
those
tasks
without
bots,
or
at
least
not
the
kind
of
traditional
bot.
A
Yeah,
well,
I
think
this
is
iteration
office
hours,
so
we
we
for
for
the
rate
limit
problem,
there's
a
there's,
a
simple
solution
that
we
know
will
work.
So
we
should.
We
should
probably
have
multiple
accounts
and
have
the
gitlab
bots
and
then
underscore
that
the
name
of
whatever
that
that
specific
bot
does
in
a
way
that
allows
you
to
find
its
code
and
allows
everyone
to
contribute
what
you
just
proposed
kind
of
having
not
just
a
kind
of
we
almost
call
it
a
lambda
web
hook
like
have.
A
We
already
have
web
hooks
for
events,
but
in
addition
to
that,
we
can
also
allow
you
to
run
some
code.
It
would
be
in
the
webhook
page.
You
could
almost
imagine
like
a
field.
Here's
the
here's,
the
code
you're
going
to
run.
I
think
it
starts
sounding
a
bit
similar
to
github
actions,
which
is
not
a
bad
thing
that
that
might
be
a
good
idea.
E
I
I
look
briefly
at
the
github
actions,
documentation
and
I
don't
know
if
they
they
support.
I
think
it's
a
really
great
thing,
but
I
don't
know
if
they
support
running
on
on
non-git
events
like
as
far
as
I
can
tell
they
still
have
a
schedule
and
the
and
the
schedule
runs
so
sort
of
integrating
with
with
web
hooks
and
fast
or
something
like
that
might
be
like
a
really
interesting
way
of
doing
it.
Yeah.
A
I'm
now
going
to
propose
something
we
might
not
technically
do
because
it's
a
bad
idea,
but
just
this
is
iteration
office
hours.
I
get
to
have
some
fun
every
now
and
then
what
about
in
the
web
hook?
We
allow
you
to
paste
some
code
below
it
and
then,
when
you
paste
that
code,
the
web
hook
address
becomes
becomes
fixed
and
it
becomes
a
fixed
endpoint
and
we
and
that
fixed
endpoint
is,
I
don't
know
a
lambda
endpoint
we're
going
to
use
gcp.
A
I
think
there's
all
kinds
of
problems
with
this
approach,
because
now
you
don't
have
to
you
also
have
to
send
a
longer
but
a
bunch
of
contacts,
and
you
have
to
send
a
long
credentials
like
who
do
you
run
as
and
things
like
that,
but,
but
something
to
to
that
effect
I
can
see-
I
can
see-
is
building
something
like
that
within
a
day
it
just
wouldn't
have
all
the
contacts,
and
it
wouldn't
run
with
the
permissions
of
that
user.
E
Yeah,
potentially
I
mean
I
was
wondering
about
the
security
implications
of,
but
I
guess
you
control
both
ends,
so
that
probably
isn't
an
issue
yeah
that
that
that
could
be
an
option
I
mean
another
option
could
be
if
you
had
a
way
of
automatically
deploying
the
you
know
if
there
was
a
certain
script
in
the
dot
gitlab
directory,
which
is
something
like
webhook
receiver
and
that
automatically
got
deployed
to
open
files.
E
If
you
had
that
connected
to
your
gitlab
instance
and
then
automatically
got
wired
into
your
web
hooks,
so
you
know
you
could
have
whatever
script
you
wanted
there
and
if
it
was
there,
we
would
just
start
sending
webhooks.
You
know
we'd
deploy
that
code
and
whenever
it
changed,
we'd
deploy
those
changes
and
then
any
webhooks
that
fired
for
that
project
would
automatically
get
targeted.
There,
cool
yeah.
A
Well,
that's
a
great
idea
nope,
so
your
your
point
would
be
instead
of
a
it's
kind
of
like
if
in
the
url,
the
webhook
url
the
webhook
url
fields,
you
paste
the
snippet
that
is
hosted
on
that
gitlab
instance.
It
will
just
run
that
code
kind
of
you
send
the
web
hook
to
the
to
the
snippet,
and
it
will
just
execute
that.
I
think
that's
that's
really
elegant.
A
D
Yeah,
I
just
wanted
to
jump
in
and
say
that
this
is
also
something
I've
heard
from
customers
very
similar
problems.
That's
what
we're
experiencing
solved
in
similar
ways
that
they
don't
consider
optimal,
so
there's
potential
for
customer
interest
and
whatever
solution,
we
come
up
one
here
and
jamie's
on
the
call.
I
see
him
he's
familiar
with
the
exact
use
case
and
I
see
him
adding
some
notes.
G
Thanks,
melissa,
yeah
I'll
just
add
some
some
size
here
I
was
talking
to
an
engineer
on
your
former
team
manage
access
and
they
had
shared
kind
of
an
unusual
usage
pattern
with
this
customer,
where
the
number
of
automated
api
actions
that
this
customer
takes
on
a
daily
basis
is
many
multiples.
I'll
say
something
like
5x.
The
number
of
user
initiated
hits
that
we
see
on
gitlab.com,
so
the
volume
of
api
traffic
that
we're
seeing
as
a
result
of
some
of
the
downsides
that
andrew
mentioned
at
the
genesis
of
this
conversation
is,
is
definitely
like.
G
A
Yeah,
if,
if
we'd
allow
people
to
use
the
to
in
the
webhook
url
field,
just
fill
out
a
gist,
it
would
mean
there's
no
polling
going
on
because
it's
initiated
by
a
webhook,
but
also
you
don't
have
to
send
up
kind
of
a
bot
account
per
thing,
because
it's
totally
within
kind
of
the
gitlab
installation
control.
So
you're
not
going
to
hit
all
the
rate
limits
and
everything
else.
E
One
thing
that
I
that
I
mentioned
in
in
the
in
the
documents
as
well
was
you
know:
perhaps
we
could,
because
all
of
these
scripts
need
a
github
token,
and
so
perhaps
we
could
create
a
github
token.
That
is
single
use
and
you
can
use
it
for
the
execution
of
that
script
and
it
sort
of
disappears
afterwards,
and
then
it
gets
added
to
the
environments.
And
it's
just
you
don't
have
to
worry
about
github
tokens
for
those
for
those
tasks.
E
E
Did
I
say
github
I
was
busy
reading
the
documentation
that
that
camille
pointed
me
to
because
github
actions
does
do
events
as
camille
pointed
out.
So
I
was
busy
reading
that
when
I
said
that
whoops.
A
I
think
they
do
do
events,
I
think
it's
pretty
cool
and
I
I
think
we
should
look
for
a
lightweight
way
to
to
add
that
to
gitlab
and
I
think
ephemeral
tokens
are
an
interesting
idea.
I
think,
should
have
a
look
at
the
might
bloat
some
databases,
but
I
think
that's
fine.
H
They
they
also
have
like
very
useful,
like
image
that
you
can
use
that
has
javascript
node.js,
that
you
can
really
like
access
all
the
app
with
the
programming
interface
and
perform
actions.
For
example,
what
like
one
of
these
patterns
could
be
like
you,
either
on
the
schedule
or
like
when
someone
comments,
do
some
sanity
checks
or
close
issues
without
that
doesn't
follow
like
some
kind
of
template,
you
can
actually
pretty
easily
model
that,
with
a
few
javascript
lines
that
are
in
your
yml.
D
File,
do
we
have
any
other
public
questions
that
anybody
would
like
to
ask.