►
From YouTube: Iteration Office Hours with CEO and Marin
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
in
very
short,
the
reason
why
I'm
participating
with
sid
is:
I
won
the
values
awards,
gitla
values
awards
at
contribute,
2019
for
iteration
and
the
this
year's
winner,
so
2020
james
ramsey
is
in
australian
time
zone
which
makes
it
really
inconvenient
for
him
to
participate.
So
I'm
hoping
to
discuss
things
with
sid
and
with
all
of
you,
others
in
the
call
as
well,
and
make
this
yeah
useful
for
all
of
us.
A
I
I
hope
to
learn
more
as
well
about
iteration,
because
there
is
always
something
to
be
learned
lindsay.
Your
item
is
first.
B
So
my
topic
is
based
on
a
planning
breakdown
kind
of
question.
I've
had
in
my
head,
we've
been
working
on
a
big
set
of
epics
around
redesigning
the
three
levels
of
security
dashboards
that
we
support
within
the
threat
insights
group.
So
we
have
the
group
level,
the
project
level
and
the
instance
level,
and
we
received
three
design
issues
from
our
ux
counterpart
and
we
use
those
as
the
basis
for
our
epics
basically
and
then
within
each
of
those
epics.
B
The
team
broke
down
implementation
issues
based
on
that,
so
to
jump
right
into
sid's
questions,
because
everyone
can
read
what
I
I
wrote
here.
I
don't
understand
the
first
one
said.
C
So
do
you
know
that
we're
working
on
instance,
groups,
we've
incidence
groups,
are
kind
of
a
special
group
that
encompass
every
s
that
every
group
on
the
instance
every
root
namespace
on
the
instance
is
a
subgroup
of
the
instance
group.
So
it's
a
way
for
us
to
make
sure
that
we
don't
have
to
duplicate
functionality.
Now
a
lot
of
functionality
ends
up
in
the
administrator
instance
dashboard
and
at
the
group
level
we
have
an
instance
group.
B
That's
news
to
me:
I
wasn't
aware
of
all
that,
so
you
know
going
forward
that
could
change
how
we,
you
know
separate
our
dashboards,
and
you
know
how
we
offer
these
to
customers
right
now.
The
instance
level
is
available.
You
know
across
the
whole
set
of
projects
that
you
have
access
to
and
it's
up
at
the
top
menu.
B
B
You
know
your
report
card
those
types
of
things
so
to
give
that
sort
of
dashboard
experience,
so
our
work
has
really
been
around
the
navigational
changes
that
are
required
to
split
those
two
elements,
as
well
as
a
set
of
enhancements
to
the
vulnerability
list.
The
vulnerability
list
is
already
shared
across
all
three
of
these
dashboards.
So
we
didn't
want
to
recreate
that
work
under
each
epic.
So
part
of
the
challenge
was
you
know?
How
do
we
consolidate
those
implementation
issues
but
still
provide
visibility
into
them?
You
know
people
would
go
and
look
for.
B
C
Yeah
cool
yeah
and
I
think
if,
if
you
ask
like
hey,
which
which
one
should
go
first,
I
would
say
group
first,
we
have
too
much
on
the
project
already
so
dump
stuff
under
group
and
then
instance
would
be
last
because
we're
going
to
replace
that
with
a
group
instance-
and
I
I
like
to
see
that
sooner
rather
than
later,
I'm
pushing
in
the
project
the
product
scaling
call
like
hey,
we
say:
gitlab.com
is
enterprise
ready,
but
we
keep
releasing.
All
these
instance
features
first
without
having
it
on
the
group
level.
B
Quick
second
part:
question
of
you
know
when
we
are
being
successful
at
iteration
by
breaking
things
down
small,
I
do
we
do
run
into
challenges
both
with
how
we
announce
this
to
our
customers.
You
know
we
end
up
with
these
tiny
little
bits
and
the
release
posts
when
really
we're
working
towards
one
big,
larger
goal,
and
if
anyone
has
advice
to
that-
and
it
also
results
in
a
lot
of
additional
overhead
around
screenshot
updates,
because
we
are
making
a
lot
of
front-end
ui
changes.
So
any
advice
on
that
when
you're
really
embracing
iteration.
C
Yeah,
that's
a
good
question.
I
don't
I
don't
have
solutions.
One
suggestion
is
that
I'd
love
overview
posts.
So
if
you
have
a
clear
vision
at
the
start,
you
can
have
a
blog
post
that
you
reference
every
time
you
announce
something
you
can
refer
to
that
bigger
vision
from
the
release
post
and
then,
when
you're
done.
You
can
also
have
something
that
kind
of
on
our
blog
that
gets
promoted
separately
like
and
don't
be
afraid
to
say,
get
lab
releases,
even
though,
like
you've
already
released
it
over
over
many
small
releases.
C
The
best
example
I
have
I
used
to
build
submarines
and
we
had
the
front
page
of
the
national
newspaper
and
there
we
were
with
the
submarine
we're
like
this
is
never
going
to
happen
again,
but
guess
what?
If
it's
good
news
they'll
just
we
got
on
the
front
page
again,
the
next
year
and
again
the
next
year.
So
it
doesn't
matter
just
say
it's
new.
We
we
can.
We
don't
have
to
be
shy
about
that.
So
you
can
kind
of
kind
of
the
release
date
and
the
launch
date
can
be
different.
C
Nobody
particularly
cares
about
that
and
then
for
the
screenshots
big
problem
in
an
ideal
world
screenshots
would
self-update
in
the
documentation
that
is,
however,
tricky,
so
that
would
it
would
take
someone
to
to
get
very
excited
about
that
and
start
doing
that
and
we've
not
found
it
person
yet.
But
if
there's
a
there's
56
people
in
this
call
consider
this
a
solid
citation
for
that.
C
B
That's
a
very
recent
renaming
of
the
instance
level
security
dashboard
to
security
center.
So
I
I
misspoke
there
or
I
guess,
cast
my
my
verbiage
kind
of
broadly
but
yeah.
They
are
the
same
thing.
C
Okay,
I
it's
just
calling
them
the
same
thing.
I
think
it's
it's
confusing
to
the
end
user
to
have
the
same
functionality
with
different
names.
B
And
that's
a
that's
a
really
good
point.
I
think
that
is
the
plan,
but
matt
wilson
will
weigh
in
on
that.
D
C
B
Sure
so
the
list
is
really
just
a
standalone
vulnerability
list
today,
whereas
the
dashboard
is
a
page
that
just
shows
charts
and
overviews.
Today
you
can.
B
Up
on
the
instance
level,
dashboard
or
the
group
level
we're
still
working
on
the
project
level,
because
we
are
adding
a
new
chart
in
order
to
create
that
dashboard
experience
because
there
didn't
exist,
it's.
B
C
F
New
yeah,
I
was
just
curious
and
I'm
speaking
for
dylan
here,
who
is
fast
asleep
in
the
apac
time
zone.
So
what
are
your
thoughts
on
the
ongoing
discussion
in
the
mr,
where
dylan
had
pushed
forth
explaining
the
challenges
of
horizontal
slicing
of
mrs
and
how
to
ensure
context
is
included,
and
I've
added
some
more
detail
there
below.
If
you
hadn't
read
it
previously,
yeah.
C
I
I
might
misunderstand,
but
what
I
think
I'm
seeing
is
like
someone
says
hey,
I
got
a
lot
of
work
to
do
and
I'm
gonna
ship
iterations,
and
it's
there's
this
graph
in
our
or
this
comic
in
our
handbook,
like
the
way
to
split
things
up,
is
not
to
ship
first
the
wheels
and
then
the
doors
and
then
the
engine
and
then
the
rest
of
the
car.
C
The
way
is
first
ship
a
skateboard
and
then
a
bicycle,
etc,
and
the
point
of
that
is,
it
has
to
be
functional
in
every
iteration
and
I
think
the
slicing
that's
done
horizontally,
maybe
a
bit
crude,
but
it's
like
shipping,
a
human
horizon
in
horizontal
slices.
You
don't
get
something
functional.
So
let's
not
do
that.
C
I
think
if,
if
something
doesn't
add,
basically,
if
there's
no
docs
with
the
new
functionality
for
people,
then
we
should
decline
it.
So
every
mr
should
have
a
docs
update
with
it.
There's
no
docs.
Basically
it
shouldn't
get
merged.
It
doesn't
meet
our
definition
of
done
so
the
way
and
the
way
to
get
there
is
to
reduce
scope
and
that's
what
we
have.
This
call
for.
That's
super
hard,
so
be
happy
to
discuss
that.
C
But
there's
it's
it's
it's
it's
not
acceptable
to
ship,
something
that
doesn't
add
value
and
if
it
adds
value,
you
probably
want
to
communicate
that
it
should
probably
have
docs
as
a
part
of
that.
A
A
So
it's
really
hard
to
ship,
even
like
a
small
scope
feature
within
within
gitlab
with
so
many
participants
in
in
the
mr
and.
D
A
That
is
one
of
the
reasons
why
we
have
these
group
division
per
merge
request.
So
you
will
not
gonna
split
database
with
back-end
changes,
but
you
are
likely
to
separate
front-end
changes
from
back-end
changes
and
documentation
from
all
of
that
separately,
because
there
are
too
many
people
changing
too
many
things
at
the
same
time,
so
collaboration
becomes
really
difficult,
and
I
think
that
was
the
original
intention
of
these
smaller
merge
requests.
They
don't
necessarily
have
the
skateboard
in
them.
A
C
F
I
think
for
me
personally,
I
like
that
the
wording
has
changed
to
more
guidelines
and
ensuring
context.
It
was
a
little
more
prescriptive
previously
and
it
still
calls
out
that
these
are
guidelines.
There
are
going
to
be
some
real
world
cases
where
you
do
almost
need
to
split
them
up
horizontally.
The
partitioning
work
that
the
database
team
is
doing
right
now
is
the
case
that
comes
to
mind.
F
We
have
been
able
to
enable
partitioning
behind
the
scenes,
but
we're
waiting
for
the
functionality
on
the
front
end
to
be
able
to
actually
start
using
that
efficiently
within
our
products.
So
there
are-
and
the
wording
has
been
changed
to
reflect
this.
There
are
going
to
be
cases
where
horizontal
splitting
still
makes
sense,
but
this
just
encourages
folks
to
think
about
providing
all
of
the
context
available
in
the
mr,
so
that
the
reviewers
don't
have
to
bounce
around
and
they
only
have
a
small
piece
of
the
entire
change
in
the
sids
point,
it
adds
value.
C
You
shouldn't
hide
the
fact
that
it's
now
shipping
as
part
of
the
product,
so
I
think,
I
think
not
having
a
docs
update,
is
really
kind
of
a
a
red
signal
to
me
and
the
docs
update
can
be
like
look.
This
is
this
is
not
active,
yet
I'm
cool
with
that,
but
I
think
not
documenting
what
you
do.
Shipping
the
docs
separately
is
really
weird.
The
docs
describe
what
your
code
does
like.
C
F
Yeah,
so
in
the
example
that
I
used
it's
all
the
documentation
is
there
and
we're
pointing
to
it,
and
it's
all
publicly
available.
You
can
understand
and
read
what
we
did
to
enable
partitioning,
but
the
front
end
needs
to
actually
start
using
the
key
that
is
part
of
the
partitioning
for
it
to
work
properly
and
we're
just
waiting
to
connect
those.
Last
two
on
the
last
mrb.
C
C
A
C
Thanks
for
bringing
that
up-
and
I've
said
that
before
I
think
that
should
not
be
a
blocking
change,
we
can
only
have
a
few
blocking
changes
and
in
gitlab
there's
security
in
the
database,
and
they
should
never
be
docs
and
we
should.
We
should
stop
that
and
if
you
ship
docs
and
you
haven't
complied,
you
can
fix
that
later.
So
docs
would
be
a
fix
forward
and
if
people
don't
comply
with
that,
we
need
we
need
their
managers
to
tell
them,
but
docs
should
never
hold
up
the
merging
of
code.
C
C
So
it's
an
anti-pattern
we
should
think
of
docks
are
continuous
improvement.
The
docks
that
are
with
the
merch
request
already
improve
the
state
of
the
docks.
So,
instead
of
aiming
for
perfect,
it
should
be
like.
Does
it
make
the
docks
better?
Obviously
it
does
so.
Okay,
you
can
merge
it.
It's
not
making
anything
worse
and
then
it's
great
that
we
have
guidelines
for
the
docs
and
we
can
do
that
afterwards.
C
So
maybe
the
way
to
do
that
is
to
have
tag
it
with
docs
cleanup
and
you
need
to
fix
it
later,
but
don't
hold
up
the
merge
of
code
because
of
the
docs,
because
otherwise
we're
going
to
split
the
docs,
and
you
know
it's
very
predictable.
What
will
happen?
The
code
review
is
harder
because
there's
no
docs
to
compare
it
to
so.
We
ship
worse
code
plus
some
people
are
never
going
to
update
the
docs
because
we
can't
enforce
that.
E
If
I
may
vocalize
point
m,
I'm
fully
supportive
of
this
just
setting
expectations
that
this
will
affect
some
of
the
pipeline
costs,
because
we've
broken
out
back-end
pipelines
and
dog
pipelines.
So
if
we
do
this,
then
there
will
be
parallel
pipelines
for
both
for
docs
on
all
the
all
the
changes,
so
that
may
also
affect
the
measurements
of
cost
per.
Mr
that
we're
looking
at,
but
supportive
is
some
setting
execution
that
we
will
anticipate
is
happening
if
this
is
the
path
we're
moving
to
towards.
C
C
C
G
Is
this
probably
to
marin,
because
you
mentioned
the
collaboration
on
the
merge
request
when
you
have
several
threads
ongoing
overviews
and
being
in
source
code?
I'm
curious.
Is
there
any
particular
feature
that
the
group
thinks
that
could
be
useful
in
us
building
and
I'll
just
add
that
we're
currently
working
on
the
reviewers,
which
is
a
separate
entity
from
signes
that
we
can
start
building
more
directed
features
into
this
use
case?
So
if
you
have
any
ideas,
let
us
know.
A
A
Then
you
have
different
people
focusing
on
different
parts
of
the
code
and
that
all
is
like.
When
you
look
at
the
merge
request
top
down,
it's
a
timeline
right
like
it.
It
doesn't
really
show
you
what
is
currently
happening,
so
you
have
to
like,
sometimes
scroll,
quite
a
lot
further
down
to
actually
see
changes
and,
yes,
you
have
buttons
to
jump
to,
but
that
might
not
be
super
obvious.
A
There
are
like
many
things
that
I
think
we
get
as
a
benefit
from
from
google
docs,
with
the
real-time
changes
that
we
can't
really.
A
And
I
can't
think
of
a
feature
right
now,
but
there
is
it's
sufficient
to
go
through
some.
Let's
say
more
more
visited,
merge,
requests,
more
active,
merge,
requests
to
see
how
that
gets
challenging,
especially
when
you
have
different
topics
within
the
same
bridge
request,
meaning
database
changes,
back-end,
front-end
and
so
on,
where
you
as
a
let's
say,
front-ender
will
not
necessarily
care
about
all
of
the
changes
that
are
happening
on
the
database
review,
for
example.
So
that
makes
it
harder
over
time
like
when
things.
G
H
Cool,
I
have
the
next
point.
Sorry,
I
will
not
be
turning
my
video
on.
I
have
some
technical
difficulties.
Basically,
I
have
a
to
give
some
context.
I
am
working
in
the
security
center,
the
vulnerability
list
so
right
now,
if
one
goes
to
any
of
the
levels
to
the
vulnerability
list,
there
is
a
filter
by
scanner,
das,
sas
dependency
scanning,
etc.
So
and
you
can
filter
the
vulnerabilities
out
by
that.
My
the
issue
I
am
working
on
is
making
that
dynamic.
H
So
if
a
client
has
a
third
party
scanner
that
they
brought
in
now
the
you
know
white
source
sas
or
whatever-
and
they
can
filter
specifically
by
the
third
party
and
just
get
that
third
parties
sas
or
das
scanning
and
not
include
get
labs
vulnerabilities,
they're
found
by
get
lab
scanners,
and
so
I'm
having
a
little
bit
of
trouble
iterating
that
because
the
ui
is
not
changing
much
there,
it
was
a
little
bit,
but
it
is
basically
adding
a
header
and
separating
those
choices
out
in
the
drop
down
and
the
back
end
didn't
change
much
it's
sort
of
just
bringing
it.
H
Some
queries
got
updated
and
I'm
bringing
that
data,
but
the
bulk
of
the
change
was
sort
of
updating,
essentially
like
the
data
mile
in
the
front
end
and
like
making
the
flow
of
data
work
for
this
new
information
and
there's
some
additional
information.
And
so
it
was
hard
to
iterate
because
it
felt
like
everything
needed
to
change
at
the
same
time
and
it
felt
like
there's
many
ways
to
do
it.
H
And
so
I
was
like
iterating
with
another
engineer
on
sort
of
the
best
way
to
do
to
do
this
and
that
sort
of
led
to
many
iterations.
But
like
do
you
have
any
suggestions
for
scenarios
like
this,
where
it
feels
like
everything
needs
to
change
at
once,
where,
like
sort
of
the
entire
architecture
needs
to
change,
and
one
thing
won't
work
without
the
rest
of
it.
H
Yeah
great
question:
so
we
that
was
possible.
We
were
able
to
do
that
and
I
was
able
to
bring
the
graphql
queries
into
the
front
end
in
separate,
mr,
so
that
I
could
access
those
easily
so
yeah.
That
is
one
way
we
have
iterated
on
this.
Thus
far.
C
Okay,
so
you
first
changed
the
api
and
then
added
the
new
functionality
to
the
front
end
correct
cool.
I
don't
see
any
possibilities
to
split
it
up
even
further.
What
about
you?
Madden.
A
No,
I
was
looking
at
this
earlier.
I
cannot
see
anything
I
was
thinking,
possibly
reducing
the
the
the
the
number
of.
A
C
H
Yeah
there
are
some:
there
are
some
files
you're
seeing
some
graphql
files,
probably
on
the
left-hand
side,
I
had
made
some
spelling
errors
in
the
initial
merge,
where
I
wasn't
using
them.
I
was
just
preparing
to
use
them,
and
so
those
are
just
one-liners
to
update
them,
so
they
work
properly,
but
yeah.
C
Cool
well
thanks
for
that
and
pretty
cool
change
by
the
way
this
is.
This
is
driving
a
lot
of
value
for
gitlab,
like
security
by
itself,
is
selling
ultimate
and
that's
more
than
20
of
our
revenue.
So
thanks
for
this
greg,
you
have
that
next,
one.
I
I
know
we
do
have
upgrade
documentation
and
I
have
worked
on
improving
that
recently,
but
I
guess
my
primary
goal
would
just
be
making
updating,
gitlab
easier
and
smoother
for
those
who
can't
keep
up
with
our
our
release
schedule.
I
find
folks
who
have
a
gap
in
upgrades
for
whatever
reason,
especially
if
it
goes
across
a
major
version.
I
This
is
where
most
of
the
problems
pop
up
and
get
lab
support
provides
live,
upgrade
assistance
to
any
customer
who
has
this
problem?
Would
you
request
some
advanced
notice
and
an
upgrade
plan
that
they
provide
to
review
I'd
like
to
shorten
that
advance
notice,
time
frame
and
reduce
the
burden
of
like
providing
a
plan
that
will
work
on
our
customers,
and
I
also
think
this
would
help
open
source
software
and
education
program,
members
and
partners
as
they
don't
have
access
to
live,
upgrade
assistance,
but
they
will
be
upgrading
their
self-managed
gitlab
instances.
I
C
Yeah
thanks
for
asking
based
on
what
you
described,
I
I
think
that
you're
there's
three
elements
to
it.
One
of
it
is
more
safety
checks,
more
automated
safety
checks
before
the
upgrade
happens.
The
second
thing
is
shorter
notice
for
the
people
who
are
already
entitled
to
life
upgrade
assistance
and
the
third
is
expanding.
The
live
upgrade
assistance
to
open
source
projects.
C
I
think
all
three
are
great
proposals
and
I
encourage
you
to
submit
them
and
more
safety
checks
is
probably
an
epic.
In
whatever
does
our
upgrades,
probably
our
main
code
base,
shorter
notice
is
probably
customer
facing
documentation
upgrade
like
probably
we
specify
somewhere
how
how
far
in
advance
we
want
the
upgrade
and
the
open
source
projects
is
probably
some
somewhere
in
the
hand
and
customer
facing
where
we
specify
what
what
we
offer
the
open
source
projects.
C
So
that's
that
will
be
the
the
emrs
I'd
split
it
in
madden.
Any
suggestions.
A
There
is
some
some
requirements
that
people
need
to
go
through
to
actually
upgrade
as
well
organizational
or
time-wise,
but
I
would
be
curious
to
find
out
like
whether
there
is
just
the
point
of
them
not
taking
the
time
to
do
it
or
whether
something
is
preventing
them
from
our
side.
So
I
would
like
to
find
that
out
first
as
well
before
venturing
into
resolving
a
problem
that
I
don't
really
fully
understand.
A
A
Some
things
are
related
to
pro
product
marketing
and
so
on,
and
this
way
you
can
actually
work
on
figuring,
which
bucket
of
work
might
might
belong
to
you
specifically,
unless
I'm
misunderstanding
the
question
you're
asking
here,
but
that
that's
how
I
would
approach
it.
I
I
I
really
appreciate
the
feedback
from
both
of
you
and
speaking
to
marin.
I
think
yeah.
I
think
it's
a
good
idea
to
really
describe
the
problem
and
what
is
preventing
folks
from
upgrading
before
we
invest
too
much
time
into
it.
I
from
support,
I
would
say
the
number
one
thing
is
network
restrictions.
I
Another
would
be
that
companies
have
a
maintenance
time
frame
in
which
they
they
upgrade
their
get
lab
instance,
and
it's
not
during
business
hours.
They
have
to
schedule
that
in
advance-
and
it's
sometimes
one
monthly,
sometimes
less
than
monthly-
that
they
can
fit
that
into
their
schedule.
That
would
be
a
restriction
on
their
end
of
things.
I
Some
more
like
up
to
chancing.
If
they
get
lab
administrator
duty,
is
transferred
from
one
customer's
employee
to
another.
It
could
take
that
customer
some
time
to
get
their
new
admin
up
to
speed
and
updating
yeah.
So
I
think
I
think
I'd
like
to
discuss
this
further
capture
some
of
these
ideas.
What
would
an
mvc,
or
like
good,
first
step
to
do
that?
Look
like.
A
So,
if
I
think
about,
obviously
you
cannot
handle
the
the
situation
with
people
who
have
network
separation
right
like
they.
You
can't
resolve
that
immediately
and
the
scheduling
is
is
really
hard.
If
you
have
a
in
one
of
those
buckets
things
like
people
don't
upgrade
because
they
miss
the
date
right
like
they're,
not
looking
at
the
calendar
every
day
like
20
seconds
right,
you
would
want
to
focus
on
well.
How
can
we
give
them
a
notification
in
in
a
more
structured
way,
so
the
the
way
again
like
the
way?
A
I
would
start
this
work
is
with
interviews
interviewing
the
the
the
customers
collecting
that
data
and
just
based
on
that
figuring
out
where
you
can
start,
because
it
would
be
really
hard
for
you
to
resolve
this
problem
in
one
go
in
one
epic,
in
one
merge
request.
You
would
probably
want
to
describe
this
as
a
general
problem
that
more
than
one
customer
has
so
that
you
know
what
kind
of
value
you're
bringing
with
with
the
work
you're
gonna
do
right.
It's
probably
not
gonna,
be
one
merge
request
or
one
epic.
C
C
I
looked
at
our
offline
documentation
and
it
says
how
to
install
gitlab,
but
it
doesn't
say
how
to
up
update
gitlab.
You
can't
use
our
regular
package
server
for
that.
So
I
think
that
might
be
a
very
interesting
first
approach
to
add.
Like
hey,
how
do
I
update
my
offline
installation
to
better
documentation?
Maybe
we
have
it
and
we
just
need
to
link
it
from
this
page,
but
it
could
very
well
be.
C
A
You
can
also
there
is
something
that
just
popped
in
my
head.
The
omnibus
package
specifically
has
a
cron
inside
of
it.
There
is
no
reason
why
we
couldn't
ship
a
chrome
setting
that
will
automatically
throw
you
know
a
log
message
or
something
like
that
to
tell
you
like:
hey,
it's
22nd
of
the
month
check
out
the
new
release
and
that
doesn't
have
to
be
pointing
to
or
calling
home
because,
obviously
they
can't,
but
it
can
give
you
a
notice
hey.
You
should
do
something
about
this.
C
The
advantages
of
a
fixed
release
date
no
need
to
call
home
to
know
that
gitlab
is
released
crack.
You
also
have
point
seven.
This
is
this
is
fun.
That's
for
support,
support
for
a
day.
I
Oh
yeah,
so
this
is
actually
inspired
by
a
conversation
I
had
with
matt
mullenweg
of
automatic
at
contribute,
2019,
I
got
to
meet
him
and
we
talked
about
how
he
does
at
wordpress
every
everybody
who's
onboarded
does
their
first
two
weeks
in
support
and
there's
an
annual
expectation
that
they'll
also
work
in
support
somewhat.
After
that
I
was
thinking
well.
I
One
of
the
reasons
I
really
like
support
is
because
I
feel
like
it
gives
me
a
really
good
overall
understanding
I
get
to
understand
the
product.
I
get
to
understand
the
customers,
their
needs,
their
use,
cases
that
what's
important
to
them,
and
I
think
that
we
could
share
this
experience
with
others
outside
of
the
support
team.
C
Yeah,
I
think
that's
an
excellent
idea.
I
would
make
it
even
smaller,
because
a
day
long
zoom
call
is
draining,
so
I
would
say,
support
for
half
a
day
and
you
just
shadow
someone
you
don't
get
access
to
any
systems
you
just
the
support.
Engineer
agrees
to
screen
share
and
you,
if
you're
not
too
annoying,
you
get
to
ask
questions
at
certain
times,
and
that
will
be
the
simplest
thing.
I
don't
think
we
need
to
make
any
system
changes.
C
We
don't
have
fast
permissions,
it's
just
two
people
that
zoom
pole
for
for
a
couple
of
hours
and
by
the
way
it
sounds
great.
I'd
like
to
participate.
A
Then
dan
is
mentioning
also
an
sre
shadow
model,
the
the
item
that
we
have
in
infrastructure
already,
where
people
do
participate
in
infra-related
tasks.
A
So
we
have
something
like
this
thanks
dan
for
writing
it
down,
and
I
just
want
to
also
say
that
one
of
the
worst
and
best
experiences
I
had
at
gitlab
was
working
with
support
or
working
on
support,
which
allowed
me
to
understand
the
frustration
of
our
customers
and
make
things
better
for
them
once
I
stopped
doing
support.
So
I
would
absolutely
love
to
do
this
and
let
me
know
how
I
can
help
out
to
make
it
happen.
J
Yeah
show
and
tell
I
guess,
ask
for
your
feedback
on
this.
This
is
very
rough.
This
is
just
from
a
couple
days
of
conversations
in
terms
of
how
we're
looking
at
like
the
next
big
leap,
to
take
for
designs,
and
I
wanted
to
get
your
opinion
on
that.
C
Well,
let's
maybe
you
can
demonstrate
and
by
the
way
it
was
a
few
days
ago
that
for
the
first
time
I
clicked
on
a
design
or
an
image
upload,
and
I
could
go
to
the
next
one
without
closing
my
window
and
opening
the
next
one.
That
was
super
exciting.
J
Nice,
I
didn't
so
it
wasn't
working
for
you
before
the
the
left
right
arrows.
C
Good
tip,
maybe
yeah
I
can
maybe
show
to
make
this
come
alive
a
bit
more.
I
have
a
hard
time
wrapping
my
head
around.
It.
J
Yeah,
so
the
first
one
I
did
link
there's
a
link
there
to
wireframe,
where
this
is
sort
of
what
we're
talking
about.
When
we
rolled
out
designs,
we
actually
had
a
bug
where
all
attachments
were
becoming
designs
and
we
got
a
really
big
spike,
which
was
a
bug,
but
it
made
us
think
hey
what,
if
attachments
also
were
treated
this
way,
and
we
gave
you
kind
of
the
full
screen
view.
Maybe
you
posted
a
screenshot
in
a
comment.
J
J
This
would
get
more
of
the
personas
like
engineers.
Pms,
like
the
goal
would
be
just
everyone
who
uses
attachments
in
some
way
would
get
the
feature
set
that
come
with
designs,
so
yeah.
J
Okay,
I
think
the
trade-off
would
I
guess
the
major
trade-off
in
this
would
be.
Would
we
should
we
keep
iterating
on
in
the
smaller
market
of
a
git
lab
issue
and
growing
it
there
before
moving
this
out
onto
other
real
estate,.
J
C
Yeah,
I
think
I
think,
like
merchandise,
start
at
least
twice
as
heavily
used
as
issues
so
and
your
whole
thing
is
get
your
gmail
up
your
future
gmail
up,
so,
I
think,
makes
sen.
I
think
the
biggest
bang
for
the
buck
would
be
to
just
launch
what
you
have
today
on
merge
requests.
I
think
that
that
will
triple
your
usage
numbers.
Sorry,
I'd
go
for
that.
J
D
C
Yeah
yeah,
that's
super
exciting
and
I
wouldn't
call
it
an
integration
with
draw.io.
I
would
just
hey:
you
can
make
diagrams
in
gitlab
now
yeah
on
the
backend.
It
uses
the
draw.io
javascript,
but
it's
just
a
gitlab
diagram
and
I
don't.
I
don't
even
know
that
I'm
using
draw.io
libraries,
it's
just
native
gitlab
functionality,.
C
Yeah,
I
think
I
think
that
the
figma
integration
was
a
a
big
success,
but
I
think
something
like
diagrams
is
so
basic
that
I
think
it
should
be
an
18
gitlab
and
hey
actually,
look
if
you,
if
you
replicate
figma
and
just
make
it
part
of
gitlab,
I'm
not
complaining.
I
think,
however,
that
that
seems
like
a
lot
of
work,
so
it's
probably
not
in
scope
right
now,
so
that's
fine,
but
since
draw
I
always
just
just
embed
this
extra
javascript
framework,
it
seems
like
something
we
can
easily
do
basically
well.
C
J
J
C
A
Yeah
I
I
can
only
say
that
I
also
enjoy
it
a
lot.
I
learned
a
lot
as
well,
so
thanks
everyone
for
your
time
and
until
next
time.