►
Description
This virtual meetup from 2020/08/05 features a panel of four GitLab engineers who frequently review community contributions. Note: the recording is audio-only with a static background starting near the 9:37 mark and lasting for about a minute.
They share insights on:
- How community members benefit from feedback & collaboration on MRs
- How panelists approach reviews for community contributions
- Allocating bandwidth for community contribution reviews
- Tips (for community members) on writing good MRs
- Learnings from working with wider community members
https://bit.ly/2CYrnbc
You can learn more about contributing to GitLab via https://about.gitlab.com/community/contribute/.
A
So
you
just
click
the
carrot
next
to
everyone
scroll
to
find
my
name,
and
you
can
send
me
a
dm
and
we
can
make
sure
that
we
resolve
any
concerns
that
you
have
yeah.
So
with
that
said
thanks,
everyone
for
joining
us
really
excited
to
be
here
with
you
today
for
folks
that
are
new
to
git
lab
I'll.
Just
give
a
quick
overview.
Gitlab
is
a
complete
devops
platform
delivered
as
a
single
application.
So
there's
lots
of
great
benefits.
A
We
have
one
interface,
everything
happens
in
one
conversation,
there's
one
permission
model
and
included
in
that
kind
of
platform.
We
have
thousands
of
features
we
release
every
month
on
the
22nd,
so
the
product
is
always
improving,
gitlab's,
an
open
core
company.
So
we
have
a
you
know:
free
open
source
version
that
everyone
can
use
and
everyone
can
contribute
to
and
then
there's
also
kind
of
enterprise.
A
You
know
levels
that
that
people
who
need
more
functionality
can
use
git
labs,
the
largest
all-remote
company
in
the
world,
which
is
really
cool,
or
at
least
we
were
until
you
know,
covet
started.
There
may
be
more
larger,
all
remote
companies
right
now,
but
but
we've
been
the
the
largest
all-remote
company
for
a
while
and
it's
part
of
our
dna
and
it's
something
that's
really
interesting
about
us
and
another
thing:
that's
cool
about
gitlab.
A
I
love
to
talk
about
our
handbook
and
transparency,
so
gitlab,
one
of
our
values
is
transparency.
That
includes
publishing
our
handbook,
which
is
kind
of
like
everything
that
we
use
to
run
our
business,
and
so
you
can
search
google
for
gitlab
handbook
and
kind
of
read
about
everything
that
everybody
on
this
call
does,
because
we
all
you,
know
kind
of
keep
the
handbook
up
to
date
and
share.
You
know
how
we
work
and
what
we
work
on.
A
So,
if
you're
interested
in
learning
more
about
git
lab,
I
think
that's
a
great
place
to
start
so
with
all
that
said,
really
excited
to
have
this
group
here
today.
This
is
a
panel
discussion.
That's
gonna
be
facilitated
by
ray
and
I'll.
Let
him
do
introductions
of
all
of
our
speakers
so
ray.
Why
don't
you
take
it
away.
B
B
Give
me
a
thumbs
up
cool
all
right.
So
yeah
again
my
name
is
ray
pake.
I
work
with
the
code
contributor
community.
I've
been
at
gitlab
for
the
past
two
years
and
it's
I've
been
wanting
to
do
this.
I've
been
working
with
a
great
group
of
people
at
gate
level,
engineering
team
that
actually
made
community
contribution
possible.
I
mean
we
celebrate
a
couple
of
milestones
in
the
past
few
months
we
surpassed
3
000
contributors
in
the
history
of
the
company
a
few
months
ago
and
then
for
13.1
release.
B
We
actually
have
over
300
mrs
merged
and
it's
not
possible.
If
we
don't
have
people
like
like
the
panelists
here
that
aren't
you
know
reviewing
and
working
with
the
community
members
and
the
other
thing
I
wanted
to
add
likely
just
six
wise
like.
I
definitely
want
to
hear
like
a
question
from
the
participants.
B
So
if
you
want
to
like
I
type
in
any
questions
from
on
the
zoom
chat,
like
we'll,
monitor
that
and
like
hopefully,
we'll
have
some
time
towards
the
end
to
answer
answer
some
of
your
questions
in
terms
of
introduction,
I'm
gonna
turn
things
over
to
the
panelists,
so
we'll
we'll
go
according
to
the
order
of
the
people
listed
on
the
slides,
like
carrie.
If
you
wanna,
like
briefly,
introduce
this
app
and
we'll
go
we'll
end
it
with
steve
and
then
I'll
share
a
couple
more
slides,
carrie.
C
F
B
Well,
thanks
everyone,
so
just
couple
more
slides.
Hopefully
I
won't
board
people
too
much,
but
just
want
to
set
some
context.
I
mean
this
slide.
You'll
see
you'll,
find
on
the
main
contribute
page
that
we
have
over
the
past
few
years,
we've
seen
both
number
of
contributors
and
the
number
of
mrs
getting
merged.
B
I
think
the
number
of
engineers
probably
like
triple
over
the
past
few
years
and
as
new
people
come
on
board.
It
takes
a
little
while
for
people
to
get
going
and
get
familiar
with
the
workflow,
and
I
wasn't
sure
how
that
on-ramp
was
going
to
happen
in
terms
of
community
contributions,
but
we
done
like
quite
well
as
you
can
see
on
the
in
the
next
slide
like
this
is
one
of
the
metrics
that
I
look
at
from
time
to
time.
B
Why
we
like
it,
like
even
things
like
the
coding
style.
While
we
do
at
gitlab
the
things
we
do,
if
you,
if
you're
lucky
enough
to
have
your
mrs
review
by
paul
slaughter,
you'll
get
once
when
you're
mrs
merged,
you
get
a
lot
nice
celebratory
like
animated
gifs,
and
the
question
I
want
to
ask
you
paul
was
that:
where
do
you
find
these
gifts?
Because
I
I
don't
think
you
recycle
any
of
them
at
all?.
E
Yeah,
I
have
a,
I
have
a
bookmark
folder,
titled,
gifs
and
okay.
If,
if
anyone
ever
has
cool,
looks
good
to
me,
gifs
send
it
my
way
cause
I
feel
like
I
am
running
out
of
them.
I
have
20
that
I
try
to
shuffle
to
make
it
look
like.
I
don't
recycle
them,
but
yeah.
No,
that's
something
I've!
I
pick
up
some
habits.
I
see
other
people
do
in
code,
reviews
on
other
projects
and
that
kind
of
personal
touch
has
meant
a
lot
to
me,
receiving
it
and
yeah.
D
D
Yeah,
so
I
did
not.
I
was
already.
I
was
always
like
pretty
intimidated
by
contributing
you
know
to
open
source,
especially
because
the
first
project
someone
suggested
I
contribute
to
was
rails.
So
I
thought
you
had
to
be
like
a
super
expert.
You
know
just
like
everyone
I
suffered
from
imposter
syndrome,
but
ever
since
joining
gitlab,
I
realized
that
it
was
all
in
my
head.
D
B
Cool
thing
so,
what's
been
like
as
a
re
reviewer,
like
I
mean
you're,
I
mean
you
didn't
necessarily
have
a
lot
of
experience
like
contributing
to
other
projects.
But
how
did
you
sort
of
come
up
to
speed
in
terms
of
you
know,
working
with
community
members
and
providing
feedback
when
people
submit
their
mrs.
D
B
F
I
have
more
empathy
to
maintainers
and
I
also
understand
more
the
effort
that
goes
into
and
like
even
if
I
see
something
that
I
felt
oh,
this
was
a
really
nice
experience
from
my
end,
like
I
try
to
understand
why
it
was
a
nice
experience,
because
I
always
wanted
to
feel
other
community
contributors
and
catalan
to
feel
the
same
way.
I
did
at
other
projects
so
yeah.
B
B
F
So
I
do
luckily,
we
have
an
agreement
with
my
manager,
like
the
whole
team,
has
to
have
20
percent
of
our
time
working
on
community
contributions,
and
that
means
20
percent
is
like
a
whole
day
right.
So
I
made
it
as
a
routine
for
myself,
because
I
love
routines
to
friday
be
community
contribution
days.
So
every
friday
I
just
spent
all
day
reviewing
community
contribution,
codes,
proposals
and
so
on
and
so
forth,
and
that
gives
me
like
a
nice
cadence
and
something
that
community
contributors
gets
used
to
right.
F
B
Well,
yeah,
I
mean
that's
a
I
thought
that
was
like
a
pretty
ambitious
goal.
I
I
mean
I
definitely
see
a
lot
more
emails
from
you
steve
with
commenting
on
mrs
and
I
mean
not
just
you
but
other
college.
You
know,
colleagues
have
set
a
pretty
high
bar
in
terms
of
allocating
time
time
for
this
that
I've
been
impressed
with
so
carrie.
What
about
you?
How
do
you
like
organize
your
day
or
or
your
week,
so
that
you
you
have
bandwidth
to
to
look
at
contributions
from
the
wider
community.
C
I'd
probably
just
sort
of
echo
with
these
comments
there
and
that
it's
for
me
it's.
I
don't
have
as
much
throughput
on
those
that
come
in
to
me,
but
they
I
generally
tend
to
prioritize
them.
They
take
a
little
bit
longer
because
there's
more
to
talk
about-
and
I
have
to
do
a
bit
more
communicating
around
again
around
teaching
what
what
what
our
concerns
are
and
explaining
them
and
communicating
those
sorts
of
things.
C
C
They
have
deadlines,
somebody
who
coming
into
the
community
who
knows
when
they're
working
on
that,
if
it's
like
during
their
work
day
or
their
evenings
or
their
weekends,
I
want
to
be
as
responsive
so
that
they're
able
to
then
whenever
they
have
that
time
that
they're
taking
for
participating
in
our
community.
I
want
them
to
see
that
it's
priority
for
us,
so
I
tend
to
prioritize
those
that
come
in
and
try
to
get
them
as
quickly
as
can.
B
Cool
awesome
yeah.
I
think
I
I
remember,
like
you
know
not
long
after
you
joined,
I
think,
carrie.
You
ping
me
and
you're
impressed
with
like
the
quality
of
the
work
that
we're
getting
from
the
community
members.
So
I
appreciate
you
like
reaching
out
to
me
so
that
was
it
was
pretty
cool,
and
then
I
mean
you're
relatively
new
to
gitlab
and
you're
already
reviewing
community
contribution,
which
is
awesome,
and
I
mean
you,
you
brought
up
something
that
I
wanted
to
ask
I'll
start
with
you
paul
in
in
terms
of
reviewing.
B
E
E
E
I
may
test
things
manually
more
often
because
I
know
that
they
may
not
have
the
same
like
gdk
setup
that
that
we
do
and
we
have
some
more
support
there,
but
yeah
for
me
when
I,
when
I
look
back
at
some
of
the
community
contribution
to
mars,
comparing
it
to
team
member.
Mrs
we're
all
contributors.
So
it's
it's
very
much
the
same.
B
D
D
B
Yeah,
I
think
that's
one
of
the
feedback
I
got
from
one
of
the
contributors.
I
think
one
of
the
mrs
didn't
end
up
getting
merged
for
for
one
reason
or
another.
I
can't
remember
the
details,
but
what
he
told
me
was
that
he
still
learned
a
lot
like
you
know.
It's
I
mean
he
didn't
really
care
what
the
mri
was
merged
enough,
but
you
learned
about
how
you
know
he
needs
to
write
better
code.
You
know
if
something
they
used
to
get
persian
mri.
B
B
It's
a
proof,
point
of
of
that
person's
testimony
and
steve
I'll
I'll
next
question
is
for
you
I
mean
I,
I
think
like
what
what
I've
learned
like
working
with
the
runner
team
is
that
I
I
think
for
a
runner,
particularly
it
I
mean.
Sometimes
it
takes
like
a
really
long
time
for
you
to
even
like
review
an
mr,
because
you
need
to
understand
the
context
better.
B
I
think
you
told
me
that
you
one
of
the
mrs
it
took
you
like
a
six
hours
to
like
provide
detailed
feedback
on
what
are
some
of
the
tips
that
you
want
to
provide
to
why
the
community
members
on
writing.
Good.
Mrs,
I
mean
what
are
what
are
some
of
the
things
that
you
want
to
suggest
so
that
it
sort
of
not
only
increases
the
likelihood
of
that
getting
merged,
but
also
expedites
the
review
process.
F
F
So
I
think
the
biggest
thing
that
people
can
help
us
with
like
for
a
quick
merger
first
is
either
like
some
test
scripts
that
we
can
run
to
reproduce
the
fix
and
reproduce
the
issue
or
like
hey,
just
copy
paste.
This
gitlab
cima
file
and
run
it
and
it
should
work
before
it
didn't
like
provides
kind
of
an
instruction
manual
on
how
to
run
it
and
that's
because
sometimes
like,
for
example,
it's
very
a
weird
edge
case
like
that
six
hour.
F
One,
for
example,
is
regarding
uploading
artifacts
on
a
windows
machine
that
had
japanese
characters
turned
on
like
like.
I
do
not
know
that,
like
I
have,
I
had
to
set
up
a
windows
machine
to
actually
understand.
Okay,
is
this
fetch
actually
fixing
things,
and
is
this
breaking
things
or
is
there
a
better
way
to
fix
it,
because
sometimes
it's
not
the
contributor's
fault
at
all,
sometimes
they're,
just
their
main
goal
is
to
fix
an
issue.
F
F
B
D
Yeah,
I
guess
you
mentioned
you
know
the
description,
sorry,
but
I
guess
I
can
think
of
like
three
things.
One
is
even
though
it
might
sound
trivial.
A
good
description
is
always
really
important,
like
you
say
why
this
mrs
necessary
how
to
test
it,
especially
how
to
test
it,
because
you
know
I'm
in
the
verified
team
and
if
I
get
an
mr
from
another
team,
it's
just
easier
for
me
to
know
exactly
where
to
go.
D
Second,
one
is
always
include
tests,
we
like
it
and
we
like
our
code
tested
and
the
third
one
is
just
don't
be
shy
about
asking
questions.
You
know
we
always
review
things
with.
You
know
no
judgment
and
assumptions
that
everyone's
trying
to
their
best-
and
you
know
contributing
to
gitlab
is
a
great
way
to
get
some
mentorship.
So
you
know
why
not
ask
questions.
We
have
some
awesome
engineers,
so
it's
a
great
chance
to
you
know.
B
Yeah,
that
was
not
that's
a
great
reminder.
I
mean
I
actually
talked
to
like
a
few
students
that
are
still
in
in
universities
in
couple
of
countries
and
they
weren't
sure
whether
it's
okay
to
like
ping,
somebody
at
gitlab,
I
said
sure
I
mean
if,
if
somebody
like
opened
an
issue,
if
you
want
to
ask
about
that,
it's
a
completely
fair
game.
It's
a
reminder
that
I
like
to
give
like.
B
B
The
next
question
I
mean
I
think
I
mentioned
this
early
on
when
I
was
sharing
the
slides,
how
our
engineering
teams
have
grown,
particularly
over
the
past
few
years,
and
especially
with
the
new
engineers
I
sometimes
they.
I
get
a
ping
on
slack
and
and
ask
about
guidance
in
terms
of
you
know,
working
with
community
members,
which
is
which
is
great
to
see
because
they
they're
eager
to
work
with
community
members
they're.
Looking
for
guidance,
I
mean
kerry
I'll
start
with
you.
B
C
Yeah,
I
think
that
the
biggest
one
for
me
whenever
I've
been
working
with
community
members.
I
I
have
a
lot
of
experience
working
on
open
source
projects.
It's
it's
always
to
come
back
to
the
idea
that
people
are
contributing,
and
so
we
want
to
encourage
their
enthusiasm
and
their
participation
right
so
like
if
you
get
an
especially
large,
mr
for
example,
and
there's
a
lot
of
like
we
could
be
nitpicky,
sometimes
around
our
code
style.
But
it's
very
important
because
of
the
demands
of
our
product.
So
how
do
we?
C
So
it's
you
know
just
trying
to
continue
to
foster
that
sense
of
participation
and
enthusiasm
that
propelled
this
person
to
scratch
that
itch
and
make
that
feature
that
they
wanted
to
see
or
fix
that
bug
that
they
found.
How
do
we
encourage
that
so
staying
positive
and
and
on
that
contributors,
side.
B
Well,
paul
I
wanted
to
ask
like,
if
you
have
anything
to
add,
I
mean
the
partic
one
popular
question
I
get
is
like
the
the
mr.
It
just
isn't
in
a
good
shape,
so
they
want
to
like
a
close
emr
and
they're
really
reluctant
to
do
it
because
they
don't
want
to
discourage
the
contributors
but
paul.
I
don't
know
if
you
have
any
thoughts
there
or
any
other
tips
that
you
want
to
share
with
with
other
gitlab
team
members.
E
No
carrie
is
100
on
point
of,
I
think
all
of
the
conversation
we
give
to
community
members
is
peppered
with
so
much
gratitude
for
because
we
realize
they're
contributing-
and
this
is
part
of
what
makes
kid
lab
really
special
and
that's
just
so
valuable
yeah.
I
would
there's
there's
definitely
some
cases
where
someone's
worked
hard
on
something
we
end
up
having
to
close
it
and
the
only
time
I've
seen.
That
is
less
because
the
code
is
in
a
bad
shape.
That's
almost
should
almost
never
be
a
reason.
E
I
think
I
think,
there's
a
lot
of
power,
though
in
the
way
you
ask
it.
If
I
just
say
hey
this,
this
class
doesn't
look
good
change.
It
that's
going
to
be
like
the
most
discouraging,
like
I'm,
not
going
to
expect
a
lot
of
feedback
on
that,
mr,
but
if
I
can
take
this
as
maybe
a
mentorship
opportunity,
I
can
explain:
hey
here's.
Why
and
then
I
try
to
communicate
a
lot
with
patches,
because
every
comment
I
leave
to
community
contributor,
I
want
it
to
get
merged
as
soon
as
possible.
E
So
I
even
show
here's
the
code
that
how
I
would
do
it
but
feel
free
to
change
it.
However,
you
want
to
so
leaving
really
actionable
comments
is
huge
where
here's
a
patch
or
even
I
like
to
ask
them
questions
and
say
because
I
feel
like
we're
all
contributors.
So,
even
though
I'm
like
a
live
team
member
there's
a
lot
of
co-ownership
here.
So
how
would
you
approach
this
problem?
Because
this
does
have
issues
so
leaving
actionable
comments
rather
than
just
this?
Isn't
right
change
it?
That's
that's
trying
to
perceive
what
is
the?
E
What
is
the
reader?
What
is
a
reader
going
to
do
when
they
read
this,
and
or
do
they
have
enough
information
to
go
forward?
That's
been
huge
yeah,
so
I
would.
I
would
encourage
reviewers
not
to
be
courageous
asking
for
changes,
but
also
be
make
sure
that
every
request
has
a
clear
action
to
it,
and
sometimes
you
gotta
just
get
your
hands
in
the
code
and
start
collaborating
on
it,
which
is
really
cool.
F
F
One
thing
that
I
found
really
worked
well
for
me
on
with
my
big
merch,
addresses
to
actually
open
up
a
merge
request
to
this
merchant
to
their
merch
request
like
if
it's
just
a
bunch
of
nitpicking
code,
styling
issues
just
open
a
merge
request
to
theirs
and
they
can
like
either
apply
the
changes
themselves
or
just
merge
it
right
them
like
that.
You
provide.
Oh
okay,
just
click
the
merge
button,
and
it's
done
and
works
really
well
with
what
what
paul
said
with
actually
the
comments.
B
They
just
want
to
learn
like
if
there's
a
good
reason
for
this
not
to
be
merged.
They
just
want
to
know
the
reason,
and
you
know
if
you
close
it
without
without
any
explanation,
then
they
have
right
to
get
upset.
But
if
you
have
a
good
rationale,
then
I
think
that
just
goes
a
long
way.
In
terms
of
I
mean
they'll,
you
know
that's
an
opportunity
to
learn
for
the
for
the
next
time,
so
cool
yeah.
B
F
I
take
it.
Every
contribution
makes
me
learn.
I
I
learn
a
lot
from
it
and
not
from
like
from
a
technical
perspective
as
well
like
some
pers,
some
people.
It
was
like
very
knee
deep
into
docker
and
turner's,
for
example
right
and
like
they're,
doing
a
feature
on
docker
and
they
propose
a
way
hey.
We
should
do
it
this
way
and,
like
I
have
never
heard
of
it
like
one
like
two
things.
F
I
always
keep
in
mind
as
when
we
were
working
on
the
network
purpose
right,
so
we
create
a
docker
network
for
every
job
that
we
run.
There
were
some
really
technical
details
that
like,
for
example,
two
community
contributors
like
actually
explain
to
me
how
they
work
and
like
how
they
should
be
set
up
and,
like
I
learned
a
lot,
even
how
kubernetes
networking
works
and
that
and
some
people
are
super
technical
on
specific
things,
and
because
the
runner
touches
a
lot
of
different
technologies
that
it's
for
me
it's.
F
I
find
it
quite
hard
to
be
super
technical
on
every
one
of
them
so
like
when
someone
explains
to
me
hey,
for
example,
this
artifacting.
I
had
to
learn
about
zip,
headers
and
things
like
that,
and
they
spent
the
time
explaining
what
the
patterns
are
and
things
like
that.
So,
like
I
learned
a
ton
and
every
day
I
learned
something
new
from
the
community
contributions.
So
yes,
I
really
really
appreciate
it's
not
just
me.
Mentoring,
damage
done.
Mentoring
me
as
one
at
the
end
of
the
day.
D
D
I
mean
yeah.
I
also
learned
something
from
every
contribution
and
I
guess
it
was
like
a
little
bit
of
a
lucky
thing
that
just
as
I
switched
teams,
I
got
to
review
a
community
contribution
for
for
this,
the
team
I'm
currently
on,
and
just
through
that
I
you
know
I
was
like
well.
I
have
to
like
really
go
deep
into
this,
so
I
learned
a
lot
which
was
really
helpful
for
my
current
role.
D
The
mr
actually
ended
up
being
closed,
but
just
like
paul
said
it's
because
we
were
you
know
solving
the
problem
in
it
was
just
a
different.
It
was.
It
was
actually
a
little
bit
of
a
misunderstanding
in
the
documentation,
so
we
actually
ended
up
making
some
documentation
changes
instead
to
you
know,
make
things
more
clear,
but
yeah
I
mean
I
learned
a
ton
from
that,
and
thanks
to
that
now
I
am
training
to
be
a
maintainer
for
the
ci
templates,
so
that
was
really
great
cool.
E
E
B
C
Adding
x,
509
commit
signing
to
to
commits
which
I
don't
even
use
gpg
commit
signing,
so
it
was
like
it
was
a
deep
dive
into
you,
know,
encryption
and
and
signing
things
as
well
as
having
to
learn
a
code
base
from
somebody
who
is
clearly
very
deep,
deep
knowledge
in
that
area.
But
but
it's
really
wonderful,
it's
you
know
the
community
is
part
of
our
product
in
a
way
right.
B
Yeah
I
mean
this
reminds
me:
I
was
having
a
conversation
with
tonkwa
who's,
another
back-end
engineer.
He
says
that
he
appreciates
hmr
because
he
gets
insight
into
how
people
are
using
our
product
like
they
the
way
that
you
didn't
even
think
about.
So
that
was
very
interesting
because
he
because
he's
also
very
active
in
being
responsive
and
responding
to
community
of
ours,
and
he
said
it's
been
a
really
eye-opener
in
a
lot
of
cases
on
how
customers
and
users
are
are
using
gitlab.
So
so
I
mean
last
question
for
panel
members.
B
Is
you
know
I
I
think
you
know.
Obviously,
over
the
past
couple
of
years
since
I've
been
here,
we've
done
a
great
job
in
being
responsive
and
growing
the
community.
But
what
else
should
we
be
doing
to
to
make
it
easier?
I
think
paul,
like
I'll
start
with
you,
because
you
provided
a
comment.
I
it
was
bad
on
my
part,
I
scheduled
the
last
hackathon
during
the
last
week
of
leading
up
to
the
release,
which
is
crunch
time
for
a
lot
of
you
guys,
and
you
rightfully
called
me
out
in
a
positive
way.
B
E
E
Do
this
really
well
and
one
one
area
of
our
code
base,
I
think,
could
use
a
lot
of
love
that
I
think
anybody
could
just
get
started.
Working
on
are
a
lot
of
our
tests
like
our
unit
tests,
especially
in
the
front
end,
are
using
like
an
old
pattern
or
could
be
rewritten,
and
you
don't
need
the
gdk
set
up
for
this.
E
So
it's
it's
very
doable,
but
I
think
it's
not
visible
that
that's
a
problem
and
just
increasing
the
visibility
and
awareness
of
here's
some
problems
in
our
code
base
at
specifically
these
files.
Here's
how
we
can
approach
that!
That's
something
that
I
personally
want
to
deal
with:
epics
and
issues.
I
open
up
emphasis
on
the
one
two
and
I
need
to
do
better
at
it.
B
B
I
mean,
basically,
all
the
issues
are
just
low
hanging
fruits,
because
the
way
it
was
organized
and
broken
down-
and
I
think
the
last
one
like
within
a
day
all
the
epics
were
all
the
issues
in
the
epics
were
closed,
so
kudos
to
the
front-end
team
and
want
to
replicate
that
with
the
with
the
back
end
as
well,
to
make
it
easy.
So
what
about
rest
of
you,
steve,
laura
or
carrie?
Anything
else
that
you
can
think
of
that
we
can
do
better
going
forward.
F
I
one
thing
that
I'm
still
struggling
with
when
I
review
a
community
contribution
and
it's
like
how
much
to
comment
on
the
code
quality
and
how
much
dependence
on
that
right
and
I've.
I've
been
doing
some
research
on
other
community
contributions
on
other
projects.
Like
one
thing
that
really
struck
me
is
the
web
back
project.
Basically,
the
maintainers
of
the
webpack
team
work
back
project.
F
That
is
good
and
bad,
because
sometimes
a
community
contributor
wants
to
learn
the
coding
standards
and
wants
to
learn
stuff
so,
like
I
think,
having
a
way
to
tell
the
user
that
hey
the
contribution
hey.
Do
you
want
to
like
continue
contributing
to
this
like
fixing
it
up
properly
and
things
like
that?
Or
is
it
okay?
If
we
just
merge
it
and
we
fix
it
on
our
own
time,
it's
a
give
or
take.
Sometimes
you
end
up
incurring
technical
depth
without
realizing
this
time.
F
F
I
ripped
off
from
the
kubernetes
community.
Basically,
when
I
opened
up
a
merge
request,
they
gave
like
there
was
a
bot
that
just
posted
a
bunch
of
links.
I
know
it
was
a
bot,
but
it
was
still
very
helpful
for
me,
like
hey,
it
was
acknowledged
in
a
way,
and
I
started
reading
up
on
more
of
the
processes
about
kubernetes
community
I
like,
if
we
have
that,
but
maybe
meaning
we
can
encourage
this
like
hey.
F
Do
you
want
to
continue
improving
the
code
on
this
one
or
do
you
just
want
it
merged
and
fixed
and
then
we'll
handle
the
code
quality
in
our
wrong
time?
So
those
are
the
two
ideas
that
I
can
think
of
at
the
moment,
but
yeah
like
trying
to
communicate
more
with
the
contributor
what
their
end
goal
is
is
very,
very
beneficial.
D
D
E
D
C
C
Discoverable
to
people
who
are
looking
for
things
to
do
as
well
as
making
sure
that
you
know
people
understand
the
process
and
what
to
expect,
and
I
I
really
like
that
idea
of
having
a
bot
that
says:
here's
some
really
important,
interesting
docs
to
read.
That's
that's
a
really
interesting
idea:
cool.
B
All
right
so
and
thanks
steve
for
linking
the
issue
on
the
chat,
so
those
are
all
the
questions
I
had
like.
I
don't
know
if
the
audience
members
have
any
questions
like
I
haven't
seen
anything
on
chat
like
I
mean
john,
I'm
not
sure
if
we
want
to
open
up.
Like
I
mean
I
actually,
I
need
to
thank
everybody
for
staying
with
us.
We
had
some
zumba
incidents
earlier
and
thanks
john
for
blocking
those
people
and
and
people
for
staying
around.
A
Yeah,
let
me
reiterate
what
ray
said:
thank
you
to
our
presenters
and
ray
for
keeping
your
cool
through
those
disruptions,
and
thank
you,
everyone
for
staying
with
us
through
that
definitely
never
googled.
So
fast.
How
to
you
know,
react
to
zoom
bombing,
so
we're
we'll
make
sure
to
kind
of
address
some
of
those
security
gaps
in
the
future
to
try
and
avoid
future
disruptions.
But
I
do
think
that
we
were
able
to
remove
most
of
the
bad
actors.
B
So
one
question
from
geelong
and
any
one
of
the
panelists
can
take
this:
how
does
a
community
contributor
get
involved
in
important
features?
It's
a
test,
planning
live
stream
publicly
or
recorded,
and
we
have
lots
of
video
on
like
especially
on
filter
channel.
A
lot
of
team
meetings
and
office
hours
are
posted,
but
I
don't
know,
like
other
panelists,
want
to
add
anything
there,
but.
F
I've
been
paint
on
multiple,
like
directional
feature
issues
like
hey,
I'm
really
interested
in
picking
this
up.
Like
can
I
pick
this
up
like
if
you
just
ask
if
you
want
to,
if
you
can
pick
it
up
and
like
you
want
to
pick
it
up
like
I
would
say,
99.9
would
be
yes,
the
other
way
to
figure
out
like
to
discuss
something
as
multiple
teams
from
office
hours.
So,
for
example,
my
team
are
on
office
hours
per
week
per
month,
sorry
hour.
F
Anyone
in
the
community
can
join
in
to
zoom
and
we'll
discuss
any
community
contribution,
and
things
like
that
and
like
if
you
want
to
join
there
and
discuss
a
specific
feature,
even
if
you're,
just
thinking
of
started
working
on
it.
That
would
be
really
real,
because
then
you
can
get
a
lot
of
context
from
us.
Having
like
a
one-to-one
synchronous,
communication.
B
Well
and
then
I'll
take
the
question
from
jeremy:
do
you
think,
having
more
north
star,
epics
or
directional
docs
would
help
community
contributions
align
with
direction
and
contribution
resources
yeah?
I
think
this
is
similar
to
like
paul
that
what
you
talked
about
when
you
do
a
better
job
with
sort
of
surfacing
and
laura
you
too,
like
surfacing
or
highlighting
some
of
the
issues
or
epics,
that's
actually
something
that
I
want
to
work
with
with
some
of
the
teams
this
quarter
to
especially
before
hackathon
just
do
a
better
job
of
like
highlighting
these.
E
E
E
We
internal
to
the
gitlab
team
are
aware
of
like
oh,
this
is
in
this
slice
of
the
product,
and
so
we
label
our
issues.
That
way,
but
that's
another
thing
is
probably
a
little
mysterious
to
the
outside
community.
Is
I'm
interested
in
these
kind
of
features?
What
how
do
I
find
that
and
that
that's
there
it's
labeled
in
a
certain
stage,
but
it's
that
that
information
might
not
be
as
visible,
but
looking
at
backlog
based
on
the
milestone
is
great.
E
E
B
Yeah,
I
think,
there's
a
question
from
justin
that
we
probably
won't
have
time
to
address
regarding
epics
or
milestones,
but
since
we're
out
of
time.
But
if
you
want
to
follow
more
more
questions,
I
piece
a
link
to
the
getter
channel.
I
mean
I'm
usually
there
most
of
the
time,
while
working
so
just
post
your
questions
there
and
apologies
for
not
getting
to
them,
but
yeah
and
thanks
paul,
steve,
laura
and
carrie
for
being
an
awesome,
awesome
panelist.
A
Yep
thanks
everyone.
Once
we
got
past
the
the
bumpy
start,
I
think
it
wound
up
being
a
great
descript
discussion.
So
I
really
appreciate
all
your
time
and
thanks
to
you,
know
the
folks
who
kind
of
came
and
and
listened
and
asked
questions,
and
I
you
know,
I
think
we
all
can
everyone
from
the
gitlab
team
looks
forward
to
seeing
contributions
from
from
many
of
you
in
the
future
and
collaborating
with
you
on
issues
and
merge
requests,
and
you
know
on
gitter.