►
Description
GitLab team discussion on MECC (Managing so Everyone Can Contribute): https://about.gitlab.com/handbook/mecc/
A
Thanks
everyone
for
joining
mech
office
hours,
scott
thanks
for
having
the
first
question
or
suggestion
you
want
to
verbalize.
It.
B
Sure,
thanks
sid
reading,
through
this
and
taking
the
training
I
found,
I
thought
there
should
be
explicit
reference
made
to
inform
decision
the
context
of
a
shared
set
of
values.
So
we
make
reference
to
the
shared
set
of
values
and
the
prerequisites
for
mac,
and
we
describe
mac
externally.
We
refer
to
it
as
being
driven
from
our
values
at
get
lab,
but
the
management
philosophy
itself
barely
talks
about
values
and
making
decisions
based
on
our
core
values.
B
A
Yeah
thanks
for
that
that
makes
a
ton
of
sense.
I
I
think
that
a
mech
should
be
something
that
transcends
fitlab,
so
I
don't
think
you
have
to
need
to
have
the
same
set
of
values
as
gitlab
sure.
B
A
C
C
It's
if
you
go
to
our
values
page
and
look
at
transparency,
that's
a
way
to
practice
transparency,
but
I
agree
that
there
could
be
more
explicit
call
outs
in
in
connecting
those
two
I'll
reemphasize
sid's
point
that
we
we
do
want
to
at
least
be
mindful
of
I'll
stop
short
of
saying,
avoid,
but
be
mindful
of
painting
this
picture
externally
that
you
have
to
adhere
to
get
labs
values
for
this
to
be
relevant
or
useful
to
you,
and
also
we
want
to
make
sure
that
it's
not
seen
as
an
all
or
nothing
proposition.
C
C
Yeah,
I
can
do
that
so
seth
thanks
for
the
question
and
not
on
the
call
so
I'll
verbalize
for
seth.
It
feels
like
a
low
level
of
shame.
Low
level
of
shame
is
one
of
our
operating
principles
within
the
values
page.
It
feels
like
a
low
level
of
shame
gets
harder
to
have.
C
As
the
company
scales
there
are
more
co-workers
and
customers
to
impress
the
quality
of
our
software
videos,
graphic
content,
communications,
etc
keeps
getting
better
and
better
because
of
the
amount
of
resources
each
of
them
get
and
the
grooming
they
go
through
in
that
environment,
it
seems
harder
to
show
up
with
a
low
level
of
shame.
Do
you
view
scaling
as
a
challenge
to
keeping
a
low
level
of
shame.
A
I
think
it's
a
it's
an
articular
point.
I
agree,
it
gets
harder.
People
expect
a
higher
uptime
of
galen.com.
Today
people
expect
fewer
fewer
showstopping
bugs
and
people
expected
a
better
designed
website
and
a
more
beautiful
looking
website.
A
A
Kind
of
if,
if
you
on
one
hand,
iteration
is
not
like
making
a
new
draft,
but
there
there
can
be
maybe
a
status
that
you
apply
to
something
where
you
say
hey.
This
is
an
alpha
version
of
something
or
this
is
something
we're
working
on
and
it's
it's
not
up
to
x
level.
Yet
if
we
make
a
change
to
our
merge
request
functionality,
it
should
be
really
good
because
that's
used
a
lot.
A
A
A
So
it's
about
making
sure
that
you
tune
it
to
what
the
usage
is,
and
I
think,
as
a
company,
we
should
get
better
at
that,
like
there's
a
there's,
a
big
difference,
depending
on
how
many
people
are
visiting
something,
how
many
people
are
using
something,
how
many
people
are
doing
a
course
and
we
can
allocate
our
effort
and
the
bar
that
we
have
accordingly.
C
I
would
what
what
I
found
useful
in
this
is
just
being
explicit
about
it
saying
from
the
top:
hey
I'm
going
into
this,
not
knowing
everything,
I'm
attempting
to
operate
with
a
low
level
of
shame
and
that
relieves
a
lot
of
tension
in
the
room
when
you
just
come
out
and
and
say
something
like
that.
C
I'll
also
point
out
that
a
piece
of
evidence
that
you're,
not
operating
with
a
low
level
of
shame,
is
concealing
work
until
it's
perfect
and
I
think
we
can,
even
as
we
scale,
I
think
we
should
still
try
to
maintain
that
familia
familiarity
with
the
feeling
of
not
concealing,
sharing
things
early
and
often,
although
the
bar
may
get
higher
and
higher
it
gets
that
way
because
of
smaller
iterations
along
the
way.
C
D
Yes,
thank
you.
I
just
wanted
to
call
out
that
I
love
the
clarification
that
we
made
to
iteration
and
the
mrs
available
in
the
agenda.
Thank
you
for
that.
I
think
it's
really
important
for
us
to
remember
that
quality
of
what
we
deliver
to
users
matters
so
somewhat
related
to.
I
think,
the
the
previous
agenda
item
we
find
we
have
to
find
the
appropriate
balance
between
getting
something
out
quickly,
while
also
still
having
it
provide
value
to
our
users.
A
A
I
do
think
that
we
we
should
get
better
at
making
sure
that
gitlab
is
a
more
is
a
better
product
and-
and
the
phrase
I
use
for
that
is.
It
should
feel
like
a
curated
experience.
Where
someone
cares
about
the
experience
in
the
product.
We
have
too
many
pop-ups
too
many
options
too
many
interruptions
too
many
things
that
distract
and
take
away
from
the
experience,
and
maybe
someone
can
link
the
curated
experience
doc.
A
So
it's
really
important
to
make
that
distinction
and
yeah.
We
now
have
parts
of
gitlab
that
are
very
heavily
used.
We
didn't
have
that
in
the
past,
so
we
didn't
have
to
account
for
that
now
we
have
that
we
need
to
do
that.
It's
a
great
thing,
but
it
only
means
that
there's
more
areas
as
we
see
gitlab
as
a
kind
of
a
a
big
sphere
with
something
in
the
center.
A
E
Thank
you
sid.
I,
as
I
went
through
the
training
I
found
it
really
helpful
just
to
to
kind
of
remind
myself
of
of
what
we
we
stand
on
and
one
of
the
you
know.
Some
of
the
reasons
I
joined
gitlab
and
one
of
the
questions
that
came
out
of
it
for
me,
was
just
as
the
company
has
grown
and
we
seek
for
more
community
contributions
and
decisions
that
impact
the
user
interface
they
they
incur
more.
A
Yeah
thanks
to
that,
it's
a
bit
repetitive
but
all
repeated,
and
hopefully
it
adds
something.
I
think
it's
really
important-
that
ui
ux
wise
we're
proactive
in
that
we
fix
things.
We
make
things
better
that
are
heavily
used,
even
if
we're
maybe
not
adding
functionality
to
that
part
of
the
application
at
the
moment
so
like
I
could
see
a
contribution
coming
in
and
get
landing
in
the
product
and
the
ui
ux
improving
later,
not
at
the
same
time,
but
that
improvement
being
made
later
right
now.
A
I
think
a
lot
of
the
time
of
ui
ux
is
scheduled
only
when
kind
of
the
the
the
product
manager
decides
that
there's
a
feature
coming
there
or
something
like
that,
and
while
that
that
it
is
also
many
times
an
appropriate
time
to
have
a
look
at
things
and
most
of
the
features
we're
adding
are
on
the
surface
of
the
product.
These
lightly
used
things
where
we're
adding
a
ton
of
features,
and
it's
so
important
to
improve
kind
of
the
core
user
experience.
The
things
that
are
very
heavily
used.
D
So
if
you
add
a
new
feature
to
the
heavily
used
area
of
our
product,
it
can
distract
from
the
main
purpose
of
that
view.
I
think
oftentimes
we
think
more
about.
I
need
to
add
this
feature
in.
We
know
that
it's
going
to
be
a
value
to
our
users,
so
let's
get
it
in,
but
it
could
take
away
from
maybe
the
the
premise
or
the
the
priority
of
another
persona.
Within
that
same
view,.
A
Yep,
I
think
you're
spot
on
and
there's
no
easy
answers
there.
I
do
feel
in
general
we
we've
gone
kind
of
as
a
product
from
phase
one
to
phase
two
naive
simplicity
to
sophisticated
complexity,
but
we
need
to
go
one
level
further,
which
is
sophisticated
simplicity
and
that's
going
to
take
some
hard
decisions,
including
deprecating
functionality,
that
people
contributed
in
the
past
things
like
that.
A
A
F
I
jump
in.
I
just
want
to
say
that
the
level
up
content
and
the
way
that
the
information
was
curated
was
really
well
done.
So
kudos
to
do
question
here
is
there's
reference
to
the
parent
workplace.
Os,
which
is
defined
as
an
organizational
framework
question
here,
is,
is
naecp
a
subcategory
of
workplace
os
and
if
so,
what
do
the
future
iterations
of
workplace
os?
Look
like.
C
Yeah
joe
thanks
for
that,
we
are
currently
working
with
a
category
design
agency
to
more
formally
figure
out
what
this
should
look
like.
The
current
view
of
this
is
that
workplace
os
is
going
to
be.
C
Let's
call
it
an
umbrella
where
certain
modules
of
building
a
modern
workplace
can
live
under
mac
being
one
of
those
what
we've
built
within
all
remote
being
maybe
an
infrastructure
component
of
those
that
may
change
depending
on
what
they
find
from
a
competitive
audit,
but
as
of
now
that's
what
we're
hoping
hoping
to
build
so
we're
working
on
more
of
an
umbrella
where
mech
and
all
remote
are
what
we
currently
have,
but
I
feel
like
we
can
scale
it
and
there's
some
other
elements
that
will
certainly
be
useful
to
building
a
modern
workplace
that
we
want
to
home.
C
For
so
I'm
trying
to
build
the
home
for
it
now
then,
and
then
fill
it
as
we
go.
I
do
want
to
take
this
opportunity
to
point
out
when
I
say
modern
workplace,
it's
a
very
intentional
term.
We
are.
We
want
to
speak
to
every
workplace,
not
just
fully
remote
workplace
workplaces,
not
just
hybrid
workplaces.
C
Sid
has
long
pointed
out
that
much
of
what
we
do,
90
percent
of
it
are
just
great
business
practices
that
we
had
to
do
earlier
and
with
more
intentionality,
because
all
remote
forced
us
to
do
that-
and
this
is
a
great
opportunity
as
much
of
the
world
figure
out
figures
out
what
their
physical
strategy
is
fully
co-located,
some
form
of
hybrid,
all
remote.
We
can
still
meet
them
where
they
are
and
we
are
attempting
to
share
as
much
of
this
through
a
we'll
call.
It
location,
agnostic,
lens
as
possible.
A
Thanks
darren
and
to
indicate
how
much
of
a
work
in
progress
this
is,
I
I
think
my
we're
working
with
the
brand
agency,
but
my
current
opinion
is
that
we
should
not
try
to
bring
two
words
into
the
world.
That
would,
I
think,
one
is
hard
enough.
I
don't
see
mac
as
part
of
being
remote.
I
think
only
very
few
companies
are
going
to
be
all
remote
in
the
foreseeable
future,
especially
among
our
customers.
G
Yeah
thanks
for
the
opportunity,
but
this
is
actually,
I
think,
a
great
follow-up
to
the
question
or
to
the
previous
question,
into
darren's
explanation
of
sort
of
the
the
sort
of
architecture
conceptual
architecture
under
which
this
lives.
You
know
the
last
several
years
have
seen
a
real
global,
an
uptick
in
the
global
conversation
about
the
ways
that
open
principles
like
the
ones
that
animate
gitlab's
operating
principles
and
practices
are
impacting
organizational
culture
and
design
regardless
of
industry,
regardless
of
organizational
structure.
G
You
know
in
in
a
sort
of
vertical
agnostic
way,
if
you
will
so
I'm
wondering
you
know
to
what
extent
the
mech
team
and
others
have.
You
know
thought
about
how
we
plug
into
that
conversation,
how
we
become
part
of
that
global
project
to
really
better
understand
those
connections
and
and
what
we
contribute
and
how
we
contribute.
For
example,
are
we
going
to
open
source
our
materials?
Do
we
offer
openly
licensed
training
modules?
Do
we
create
definitions
that
others
can
fork
and
modify
and
set,
etc?
A
Yeah
I'll
take
a
first
step
and
then
jessica,
I
think,
first
of
all,
the
materials
we
have
are
creative
commons
by
attribution,
so
they're
already
open
source
in.
In
that
regard,
I
think
transparency
is
super
important,
it's
important
when
getting
the
right
data
to
to
make
decisions.
The
first
part
of
mac.
A
I
do
think
that
just
talking
about
transparency
doesn't
talk
about
making
decisions
fast
and
taking
many
of
them,
and
you
see
a
lot
of
organizations
that
only
have
transparency
and
openness.
Actually
they
slow
down.
They
be.
They
become
very
similar
to
consensus-based
organizations
they're
not
able
to
make
fast
decisions,
they're
not
able
to
take
make
many
of
them.
So
I
do
think
that
openness
is
only
one
part
of
it
and
you
need.
H
Yeah
so,
first
of
all
I'll
say:
brian
you're,
relatively
new
to
gitlab,
I
believe,
you're,
a
huge
part
of
the
open
organization,
team
and
community.
So
shout
out
to
you
for
all
the
work
that
you
do
there,
I'm
a
big
fan.
H
I
do
believe
that
openness
is
something
that
drives
things
forward
and
I
think
it's
very
valuable.
How
that
works
with
you
know,
get
labs
plans
and
model,
that's
really
a
decision
that
is
out
of
my
hands
to
make,
but
I
will
say
that
I
personally
believe
that
there's
value
in
being
transparent
and
sharing
as
much
openly
as
possible
and
sharing
lessons
and
learnings
with
other
organizations
and
that's
sort
of
the
goal
where,
where
it
ends
up
falling
on
that,
I
can't
say
for
sure,
but
certainly
influenced
by
your
work
with
open
organization.
I
A
It's
a
happy
coincidence,
and
you
see
it's
new
for
darren
too,
so
I
think
darren
will
check
it
out
and
darren.
Please,
please
keep
me
and
jessica
abreast
of
what
you
find.
I
do
think,
maybe
not
knowing
the
materials.
Maybe
it
is
a
bit
like
openness
that
it's
you
need
not
just
trust.
I
frequently
hear
people
say:
oh
gitlab
is
a
very
trusting
organization
and
I
think
we
are
working
in
a
high
trust
environment,
but
there's
also
a
lot
of
accountability
at
gitlab.
A
So
I
think
that
the
two
kind
of
come
hand
in
hand
and
if
you
only
do
trust
you'll
lose
on
the
the
other
parts.
If
you
only
do
account,
you
need
all
of
them
and
I
think
that's
what
we're
trying
to
do
with
mac
both
have
decisions
out
in
the
open
and
the
ability
to
make
them
fast,
both
making
many
decisions
and
being
able
to
execute
on
them,
and
I,
I
think,
there's
a
lot
of
powerful
oversimplifications.
A
There's
there's
even
more
nuance
to
it,
but
at
least
hopefully
we
we
add
a
a
little
bit
more
than
than
some
of
the
other
frameworks
without
ever
having
seen
speed
of
trust,
and
maybe
it's
a
lot
more
balanced
than
I
give
it
credit
for
right
now.
A
Well,
this
was
really
great
and
thanks
everyone
for
doing
certifications,
we've
seen
hundreds
of
certifications
already
thanks
for
doing
that
and
looking
forward
to
merger
crafts,
but
because
I'm
sure
we
got
some
things
wrong,
I'm
sure
some
examples
could
be
better.
So
if
you
have
a
better
example,
please
feel
free
to
ask
us
to
change
it
out
or
send
a
merge
request,
looking
forward
to
making
the
materials
better
together.
Thank
you.
So
much.