►
From YouTube: Iteration Office Hours with CEO (Public Live Stream)
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
B
Thanks
ed
one
of
the
most
common
questions,
I
hear
from
sales
from
account
managers
and
from
our
prospects
is:
when
can
I
replace
my
existing
package
manager
vendor
with
get
labs
package,
offering
there's
a
lot
of
information
to
share
as
part
of
that,
because
there's
a
lot
of
issues,
there's
epics
I'm
wondering
what's
the
best
way
to
start
to
get
that
message
out
there.
So
it's
more
visible
and
so
that
I
could
keep
people
updated
on
the
progress
that
we're
making
over
time.
A
These
ones
are
already
in
programs,
so
you
can
kind
of
follow
along
how
they
do
it
and
we
even
ask
like
hey
these:
are
the
ones
we'd
really
really
like
to
see
so
that
wasn't
a
conversation
with
me
and
the
product
managers?
In
this
case
the
iteration
is,
let's
support
people
already,
adding
things
instead
of
spending
our
energy
and
in
packaging
formats,
ourselves
and
I.
Think
they're
still.
A
We
still
have
like
some
way
to
go
because
before
our
documentation
is
super
super
clear
how
to
do
this
and
we
make
it
as
easy
as
possible
to
do
this,
but
focusing
on
contribution
is
one
of
the
things.
The
other
thing
is.
We
have
an
awesome
dependency
proxy,
but
it
needs
to
pull
my
two
round,
so
we
need
Puma
to
run
or
get
Lancome,
so
we
can
start
dogfooding
that
ourselves
there's
a
whole
team
focusing
on
getting
Puma
to
run
and
I.
A
B
I
was
more
thinking
of
I,
think
I
have
clear
steps
and
highlights
of
how
we
get
there.
One
of
those
is
definitely
leveraging
the
community
but
I'm
wondering
the
message
of
letting
sales
and
our
customers
know
one
that
we
are
trying
to
replace
their
existing
package
manager
vendor
and
two.
We
can't
do
that
yet,
but
here's
what
has
to
be
true
for
you
to
be
able
to
do
that
and
then
three
giving
them.
Some
sort
of
you
know
update
of
our
progress
so
that
they
know
when
they
could
pull
that
switch.
B
I'm
wondering
for
more
of
like
a
communication
and
and
marketing
perspective.
If
they're,
like
iterative
steps,
I
could
take
to
get
there
yeah.
A
If
I
think,
what
we
can
do
is
try
to
get
to
a
single
source
of
truth,
because
we
have
a
list
here.
Then,
if
you
go
into
the
development
documentation,
there's
another
list,
then
there's
a
list
of
these
ones
are
in
progress
and
then
there's
a
list
of
these
ones.
We're
interested
in.
So
that's
for
four
separate
lists.
What
we
could
do.
Instead,
it
has
only
the
list
here
and
then
see
available
in
gitlab
version.
Now,
if
it's
planned,
then
we
link
to
the
merge
request
for
it.
A
If
it's
our
interest,
we
link
to
that
and
if
it's
not
there,
yet
we
just
invite
people
to
do
it
so
use
this
available
column
to
kind
of
demarcate
the
status
deprecated
this
list
and
deprecated
these
two
kind
of
sub
lists
I,
think
that
would
I
would
already
kind
of
help
to
give
an
overview.
And
then
hopefully
we
get
to
the
point
where
all
of
these
expertise
have
like
someone
starting
the
work,
so
you
can
share
like
okay,
we're
making
a
ton
of
progress,
and
this
is
probably
how
it
looks
this
is
planned
for
this.
B
B
Another
thing
I
was
planning,
is
I'm
updating,
just
the
features
page
with
a
more
like
robust
comparison,
so
we
have
like
if
sono
type
or
J
frogs
are
talking
about
features
in
a
given
way,
that
we
make
sure
that
we
have
that
information
there,
that
we
say
what's
available
and
what's
not
this
way,
customers
have
a
quick
view
of
seeing
okay.
Well,
how
do
you
compare?
How
do
you
compare
yourself
for.
A
C
So
we're
just
preparing
our
world
for
its
of
just
code
and
the
first
issue.
Electic
is
actually
to
come
up
with
a
big
lab
recommended
interests.
Interests
such
as
code
set
up.
That's
quite
a
few
asked
for,
and
that's
what
that
it's
quite
obvious
and
the
users
interviews
as
bad
there's,
always
this
question
of
Dwight.
Why
do
I?
Do
it
right
and
one
of
these
questions
that
we
have
the
gate
lab
get
flow?
So
how
do
you
merge?
What
was
the
iterative
process
in
that?
C
A
It's
like
if
you
were
gonna
automate
something
the
first
thing
you
do
is:
do
it
manually
a
few
times
and
make
sure
you're
automating
it
the
right
way
and
I
think
about
post
or
a
doc.
Changes
is
a
great
venue
for
that.
As
for
get
my
flow
I
think
we
called
it
his
lab
flow
instead
of
give
up
get
it
all.
A
We
I
made
up
most
of
that
and
what
I
was
seeing
around
the
internet
was.
There
was
github
flow,
but
it
wasn't
sufficient
for
all
the
different
scenarios.
For
example,
if
you
had
software
that
you
needed
to
maintain
with
packaged
with
certain
versions,
so
there
was
github
flow
and
it
was
get
flow,
get
float
a
very
complex
one,
getting
flowed
a
very
simple
one
and
with
get
live
flow
we
specifies
those
specified
those
two
but
also
all
kind
of
the
in-between
States.
So
we,
the
goal,
was
to
be
more
comprehensive.
C
Yeah,
thank
you.
My
next
question
still
waited
to.
This
is
how
to
come
up
with
this
fill,
because
what
I
say
is
that
this
is
obviously
a
non-coding
activity
and
and
I'm
thinking
lots.
How
could
I
get
still
developers
to
really
put
all
day
knowledge
and
experience
behind
this?
What
would
be
your
acquaintance?
They.
C
A
But
what
I
would
do
is
I
think
most
common
language
frame
for
searchers
code
is
terraform.
Give
me
a
way
to
kind
of
version
control
my
terraforming
give
lab
and
then,
instead
of
me
running,
terraform,
apply
or
whatever
it
is
from
my
comment
line,
the
command
line.
Have
it
happened
to
CD
and
I?
Think
then
the
next
thing
you'll
probably
hit
is
like
hey.
You
cannot
have
two
jobs
at
the
same
time.
A
C
Yeah
thanks.
My
question
here
is
differences.
It's
about
how
to
get
our
own
engineers
to
to
work
mostly
on
coding
activity,
because
this,
what
we
want
to
solve
here
is
actually
some
writers
documentation,
but
to
do
it
really
total
in
total
ways,
it's
really
production-ready
what
we
write
down
I
think.
A
The
way
to
get
to
production
ready
here
too,
is
to
first
have
some
documentation
and
then
improve
it
over
time.
So
don't
try
to
immediately
have
something.
That's
prediction
ready,
let's,
let's
start
somewhere,
because
it's
much
easier
to
have
something
and
validate
that
with
someone,
then
to
try
to
create
it
from
nothing
and
I
mean
the
ways
one
of
the
ways
to
do
it.
A
I
know
that
our
infrastructure
team
is
using
terraform,
so
write
that
first
tutorial
yourself
and
then
go
to
our
infrastructure
team
is
asked
like
hey
II,
start
doing
this
to
deploy
or
terraform,
and
they
will
say
no,
of
course,
not
because
you're
missing
this
I'm
missing
that
and
then
okay
can
we
do
half
an
hour
and
the
first.
The
first
objects
you
mentioned.
Can
we
add
that
to
it,
and
then
you
come
back
the
next
day
for,
for
the
second
part,
thank.
E
For
sure
so,
I
linked
an
issue
here
and
it's
a
pretty
straightforward
issue
about
redirecting
via
check
box
forget
lab
pages
domains.
The
the
heart
of
the
problem,
though,
is
that
I
have
some
natural
hesitation
in
the
engineering
team
side
that,
if
we
implement
an
incremental
change
to
help
satisfy
some
of
our
customers,
use
cases
around
redirects
and
get
webpages
that
it
might
cause
rework
in
the
future
for
another
solution,
where
we
want
to
support
different
kinds
of
domains
and
get
lab
on
the
roadmap.
A
So
and
that's
that's
an
invalid
argument,
you're
not
proposing
to
do
more.
Let's
discuss
it
when
I'm
proposing
to
do
more
I'm
just
proposing
this
today.
So
don't
don't
not
do
it
because
it
could
lead
to
more
requests.
We
have
to
then
look
at
those
requested,
so
that
would
be
yeah.
That
would
be
my
response.
Is
there.
E
Ever
a
time
where
it
would
be
appropriate
to
say
that
the
risk
is
too
high,
given
that
maybe
my
roadmap
in
three
to
four
months
suggests
that
we
want
to
do
something
completely
different.
How
do
I,
how
do
I
still
empower
the
engineers
to
confidently
push
back,
even
though
I
would
tell
them
in
this
case?
Yo?
No,
don't
worry
about
it.
I
think.
A
It's
really
about
okay,
if
we
do
it
now,
and
we
know
that
we
already
want
the
next
step
on
the
slippery
slope,
and
we
know
that
will
involve
a
refactor.
How
much
extra
work
is
it
to
kind
of
change
it
at
that
time
for
just
changing
it
now,
for
example,
if
you're
looking
at
a
database
schema,
it's
relatively
easy
to
create
a
new
database
table,
but
renaming
it
it's
much
more
work,
especially
if
there's
tons
of
data
in
it.
A
So
there
of
someone
could
say:
look
we
already
know
we're
gonna
need
this
three
months
down
the
road.
Let's
make
sure
this.
We
got
this
table
right
for
everything,
so
we're
not
stuck
with
a
migration
that
changes
a
database
schema
and
that
might
even
be
like
first
one
version.
We
migrated,
we
add
the
new
one
and
then
in
the
next
version.
Our
code
starts
writing
to
the
new
one,
and
then
we
have
a
background
chance
that
copies
it
like
my
name,
is
rather
hopefully
easier,
can-do,
non-blocking,
but
suppose
it's
it's
something
super
complex.
A
In
that
case,
you
could
say,
look
we'll
if
we
look
over
a
six
month
span.
We
know
that
doing
it
the
wrong
way.
Now
it's
gonna
cause
a
lot
more
work,
but
that's
the
thing
to
check
that.
That's
not
true
for
everything.
If
it's
just
about
well,
we
have
to
do
this
now
and
we
have
to
do
the
other
work
then,
but
there's
not
a
huge
interest
rate
you've
paid
for
changing
it.
That's
like
okay!
A
Well,
let's
at
least
create
some
value
now
we'll
learn
a
bunch
and
that
will
probably
inform
the
refactor
of
the
code.
So
big
difference
here
between
code
and
data
having
data
in
the
wrong
place
tend
to
be
much
harder
to
solve
than
having
the
wrong
code.
Because
the
code
you
can
kind
of
atomically
update.
That's.
E
A
E
I
have
a
second
issue:
I'm
and
I'll
go
ahead
and
cover
it
here.
So
in
evidence
collection,
we
have
a
really
great
traction
with
particular
regulated
segments.
They
love
this
feature,
but
something
that's
making
me
a
little
nervous
is
that
they
want
to
upload
a
bunch
of
stuff
to
this
artifact
of
the
release,
and
this
includes
things
like
tests,
data
from
external
test
systems.
E
What
I
want
to
avoid,
though,
is
uploading
or
creating
this
Avenue
by
which
they
can
upload
anything
to
this
to
this
artifact
in
releases
and
it
discourage
adoption
of
future
functionality
and
get
lab
because
anywhere
where
we
create
like
a
jumping-off
point,
it
could
dissuade
the
adoption
of
features,
so
I
wanted
to
kind
of
get
your
insight
on.
Is
this
a?
Is
this
a
normal,
worry
or
fear,
or
should
I
just
kind
of
push
that
a
way
to
address
the
customers,
needs
and
lots
of
supporting
everything
inside
releases.
A
My
this
is,
this
is
a
call
of
quick
takes
that
might
be
wrong,
but
I'm
gonna
do
my
quick.
Take
I
would
do
it.
I
would
allow
people
to
to
upload
those
things.
First
of
all,
I
get
lab.
We
want,
we
want
to
be
open.
We
want
to
be
open
to
other
systems.
We
don't
want
to
force
you
to
use,
get
lab
CI
for
anything
want
to
support
Jenkins.
A
A
Second,
I
totally
understand
the
requests
like
if
you're,
using
an
HB
test
center,
there's
things
in
there
that
manual
testing
provisions
or
things
that
we
can't
do
today,
so
it
makes
sense
as
well
and
then
the
third
thing
is
becoming
a
source
of
record
is
awesome,
so
if
they're
kind
of
using
us
to
become
the
source
of
drackett
like
is
this
release
good
and
get
and
they
go
to
get
lab
to
find
that
out.
That's
an
that's
an
amazing
position
to
be,
in
my
view
from
my
room
here,
is
to
the
Salesforce
tower
and
Salesforce.
A
You
could
view
it
as
a
CRM
freely.
It's
also
a
bit
of
a
low
code
solution
to
kind
of
build
your
own
CRM,
it's
very
customizable
and
through
all
those
customizations
that
people
do
it
becomes
very
hard
to
is
launch
because
you
kind
of
manure
dotted
it
to
what
you
want.
So
I'll
offer
give
lab
to
be
the
source
of
record
and
there's
love
for
people
to
customize
get
life
a
little
bit
to
fit
their
needs.
As
long
as
we
have
convention
over
configuration,
figuration
out-of-the-box,
there's
like
the
right
finger.
D
Said
it's
a
slightly
less
product,
a
more
tactical
tactical
question
here,
but
and
we're
using
we're
moving
towards
using
a
single
template
all
about
job
postings
across
engineering.
A
small
change
in
the
template
means
the
copy
of
this
we're
changing
the
copy
in
the
template
needs
to
be
reflected
in
both
the
hiring
process,
repo
and
in
greenhouse.
It's
pretty
time-consuming
and
efficient
to
do
this,
and
it
makes
it
hard
to
maintain
a
single
source
of
truth.
I
guess.
D
A
I
think
there's
two
things:
first
of
all
is
kind
of
the
job
families,
as
you
can
see
them.
You
know
on
our
static
website
and
that
we
definitely
can
use
templates.
We
can
easily
include
template.
So
if
you
did,
your
family
already
includes
a
couple
of
templates.
Then
the
problem
is
okay.
How
do
we
make
sure
in
green
house
they
reflect
our
job
family
and
the
two
things
I
would
look
into
like
do
we
need
the
job
family
in
green
house?
A
Or
can
we
just
put
you
out
there
that
will
point
back
to
our
static
website,
because
that
seems
preferable
and
people
understand
URLs
they
can
click
them.
They
can
just
view
the
job
family.
There
that's
not
possible.
Can
we
automate
it
so
that
every
time
every
24
hours,
older,
don't
families
in
green
house
are
populated
from
our
static
website?.
D
Cool,
that's
helpful,
I
guess.
The
only
difference
is
that
we
don't
have
a
job
because
it's
around
job
postings
and
we
have
stage
groups
specific
job
postings
and
we
have
a
job
family
for
product
designers.
But
then
we
have
different
job
posting
for
product
designers
have
been
a
secured
team
compared
to
product
designers
within
our
configure
team
and
I
guess
we
could
host
each
individual
job
advert
for
those
different
stage
route
roles
within
our
handbook,
but
that
would
be
a
change
that
we'd
need
to
make.
F
So
long
mix
so
I
wanted
to
talk
about
issue
that
we
have
coming
up.
It's
for
group
to
play
keys
and
the
idea
is
that
when
you
have
deployed
keys
that
our
joint
is
bringing
from
horse
who
want
to
join
them
together.
So
it's
easy
to
manage,
and
this
was
weighed
pretty
heavily
by
our
development
team
and
they
even
offered
a
way
to
split
this
up,
but
the
way
that
they
are
currently
that
we're
currently
thinking
about
splitting
up
the
issue
doesn't
give
any
customer
value
in
the
way
that
we're
splitting
it
up.
F
So
in
the
back
in
the
back
end,
what
we're
gonna
have
to
do
is
if
you
have
a
project,
and
now
we
had
a
new
token,
we're
gonna
need
to
add
it
to
where
the
group
tokens
are,
and
if
you
remove
it
again,
we
need
to
remove
all
this
excess
noise,
and
this
currently
doesn't
really.
This
is
not
the
way
that
it's
designed
at
the
moment,
so
we
need
to
create
this
kind
of
framework
even
before
we
even
start
applying
it
in
the
UI.
You
want
to
add
it
to
the
settings
page.
F
A
Can
we
just
automate
that
so
I
the
group
in
so
there's
two
options?
There's
like
hey?
Let's
add
real
group
deploy
keys
and
on
the
group
level
and
then
every
time
we
have
to
check
not
only
the
project
level
but
also
the
group
level,
there's
also
kind
of
a
hacky
way
which
is
hey
at
the
group
level.
I
can
upload
a
deploy
key,
and
the
only
thing
that
happens
is
that
it's
uploaded
to
every
project
plus
stored
at
the
group
level
and
every
time
you
create
a
new
project
here
that
he
gets
at
it.
I.
A
Think
the
hacky
way
it's
like
if
we
then
move
to
the
proper
way
later,
is
it
gonna
be
a
disadvantage
that
we
did
the
hacky
way
because
can
then,
if
you
kind
of
on
the,
if
you
also
start
checking
on
the
group
level,
you
have
to
keep
both
and
the
project
in
the
group
level.
Is
that
a
problem
I'm
not
able
to
oversee
whether
that's
a
problem
or
not?
It
seems
it's
very
dangerous
territory.
Yeah.
F
A
But
it
would
be
something
to
look
into
because
you'd
be
able
to
create
value
immediately,
and
you
can
even
you
can
even
split
it
up
even
further,
where
you
say
on
the
group
level,
you
say,
add,
deploy
key
to
all
current
projects.
It's
the
first
thing
at
least
I.
Don't
have
to
do
it
five
times,
then
you
change
that
in
the
next
release
and
say,
add,
deploy
key
to
all
projects
and
like
Oh,
current
and
new
projects.
So
now
you
also
store
it
on
the
group
level.
A
You
keep
adding
it
if
a
new
project
gets
created
and
then
the
third
release,
when
you
upload,
when
you
already
have
that
group
deploy
key
it
just
you
change
the
code
to
also
start
checking
that
key,
and
then
you
don't
have
to
like
push
it
to
all
the
projects
as
well.
That
would
be
a
way
to
kind
of
iterate
on
it.
It
would
accumulate
the
technical
data
of
having
like
multiple
copies
of
the
same
deploy
key,
which
would
make
rotation
pretty
annoying.
So
that's
like.
A
Is
it
worth
it
I
think
at
least
the
initial
one
is
certainly
worth
it
where
you
have
a
functionality
to
like
and
a
deployed
key
to
all
projects
in
this
all
current
projects
in
this
group.
That's
not
a
bad
one
and
then
I
think
I'm
a
bit
in
doubt
about
when
you
create
a
new
project.
Also
at
that
key
that
starts
feeling
a
bit
too
hacky
but
kind
of
automating.
What
people
are
currently
doing,
I
think
that's,
that
seems
simple
and
that
seems
like
it
adds
value
immediately.