►
From YouTube: Create - FY21Q1 OKR - Competitor Walkthrough
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
I'm
James
Ramsay
group
product
manager
here
at
gitlab,
and
this
is
a
competitive
walkthrough
of
the
github
product,
particularly
I'll,
be
focusing
on
areas
of
the
github
product
that
are
similar
to
the
areas
of
the
gitlab
product
with
regards
to
the
create
stage
of
the
develops
lifecycle,
so
that's
particularly
source
code
management
at
the
repository
and
code
review,
approval
rules
and
permissions,
and
things
like
that.
So
this
is
a
project
that
I
have
variously
maintained
over
the
years.
I
created
that
maybe
eight
years
ago,
and
it's
quite
a
long
way
out
of
date.
A
A
Report,
which
is
notifying
me
as
the
maintainer
that
there
are
some
vulnerabilities
that
I
need
to
address
and
then
the
classical
file
list
and
rendered
readme
preview,
and
so
this
one
looks
pretty
familiar.
So
if
you
get
lab
pretty
similar,
you've
got
an
icon
descriptions
and
information
repository
details
and
rendered
readme,
so
pretty
similar.
So.
A
That's
nice
and
fast
one
of
the
nice
features
of
github,
which
we
recently
added
as
well.
Here's
a
very
quick
file,
browsing
so
you'll
notice.
The
whole
page
is
not
really
loading.
It's
just
deep
and
these
little
aspects,
it's
being
done.
As
a
single
page
application,
we've
made
a
similar
improvement
to
Gil
out
as
well,
so
that
it's
fast
to
the
browser
repository.
B
A
A
B
A
We'll
see
similar
results
in
the
code
no
use
know
merge
request
because
it's
the
code
only
import
so
similar
capabilities
between
the
two
in
this
regard,
so
dean,
further
I
guess,
there's
another
nice
little
thing.
We
both
both
github
and
geared
lab
and
had
this
feature
for
a
long
time
being
able
to
search
with
the
fuzzy
file
finder
and
quickly
open
any
file
in
your
lab.
The
shortcut
for
this
is
T,
so
pretty.
A
Let's
then,
take
a
look
at
pull
requests
so
pull
requests
the
equivalent
feature
in
github
to
what
we
call
merge
requests
in
get
lab
here.
You'll
see
a
list
of
all
the
merge
requests
and
I
use
greenkeeper
to
help
me
keep
this
project
up
to
date
and
you'll
notice
I'm,
not
very
good.
At
that
you
can
see
that
there's
CI
pipeline
statuses.
They
call
these
checks
and
also
interestingly,
and
they
designate
this
greenkeeper
account
as
a
bot
account.
So
I
can
tell
the
difference
between
human-created.
A
A
A
Okay,
so
we
can
see
similar
information
here
and
we've
got
the
title
and
the
issue
or
the
merge
request,
pull
request,
number
sorry
and
a
difference
between
Gil,
lab
and
github
is
having
a
dedicated
description
field.
The
first
comment
in
a
pull
request:
sort
of
special
like
it's.
The
first
thing
you
see,
but
in
you
know
in
all
other
respects,
just
a
comment.
A
So
that's
a
little
interesting
and
you
can
see
that
the
navigation
is
kind
of
similar
and
we've
got
conversation
commits
checks.
We
call
those
pipelines
and
files
changed
so
easy
access
to
this
information.
Some
of
this
information
is
shown
in
slightly
different
places
in
kit
lab,
but
it's
much
the
same
over
here.
We've
also
got
a
left
hand
right
hand,
side
bar
with
the
signees,
so
I
could
assign
myself
to
this.
A
B
A
Repository
name
I
can
designate
this
a
template
and
get
lab.
Has
a
repository
templates
feature
where
you
can
create
a
group
and
in
that
create
lots
of
different
projects
that
will
be
used,
as
templates
for
your
instance?
I'm?
Sorry,
that's
a
similar
feature,
social
previews.
So
this
will
be
an
image
that
you
can
upload
and
when
you
share
your
project
on
a
social
network,
you
will
include
this
little
preview
so
similar
and
if
you've
got
blog
posts
and
they
have
those
little
images.
Some
of
that.
A
So
these
are
from
features
of
my
project
and
wiki's.
Just
great
get
labs
had
wiki's
for
a
long
time
to
restrict
editing
to
collaborators
only
so
this
appears
to
be
a
permission
setting
for
the
wiki,
but
it's
it
doesn't
appear
to
have
any
distinction
between
a
hierarchy
that
probably
should
be
indented
or
something
it's
a
bit
confusing
that
those
two
are
related
because
okay.
A
A
B
A
A
So,
interestingly,
security
alerts
are
enabled
by
default.
We
saw
that
on
the
landing
page
and
although
that
sort
of
verges
into
some
of
get
labs
capabilities
being
similar
to
a
defend
and
secure
stage,
I
think
it's
relevant
to
the
create
stage
that
these
are
highlighted
and
can
be
actioned.
So
we'll
take
a
look
at
those
later
on
on
a
merge
request.
We've
got
a
couple
of
different
merge
options,
so
merge
commits
squash
squash
and
merge
and
also
rebase
and
merge.
A
Fast-Forward
semi
linear,
so
fast
forward
with
emerged
commits.
So
all
the
merger
request
has
to
be
fast
forward,
but
then
we
still
create
a
merge
commit
anyway
and
then.
Finally,
a
completely
fast
forward
strategy
where
no
merge
commit
is
created,
and
so
squash
can
be
enabled,
independently
of
that.
A
So
they're
orthogonal
in
the
collab
system
and
there's
a
little
bit
more
control
for
project
administrators,
perhaps
to
specify
what
their
preference
and
style
is
and
although
I
guess
some
configurations
in
the
gitlab
matrix
of
options
can
be
a
little
bit
more
confusing
and
not
necessarily
what
end
users
would
expect
if
they're
trying
to
do
a
fast-forward
squash
and
they
might
still
end
up
with
a
merge,
commit
where,
if
you're
approaching
it
from
a
gimmick,
get
to
command
line
expected,
get
command
line
perspective.
That
might
be
unexpected.
A
So
let's
look
at
access
management,
which
is
directly
related
to
source
code
management.
So
this
is
currently
a
public
project
can
manage
this
and
I
could
make
it
a
private
project
if
I
want
so
get
lab
has
similar
options.
We
have
public
projects,
we
have
private
projects
and
you
can
also
have
internal
projects.
A
A
So
we've
got
branch
protection
rules
which
prevent
false
bushes.
They
prevent
the
branch
being
deleted
and
we
can
specify
and
the
different
checks
that
are
required.
So,
if
we're
looking
at
the
master
branch,
this
is
quite
nice.
Actually,
the
fact
that
you
just
go
to
branches,
you
specify
a
pattern
and
then
you
have
all
these
options
so.
A
Any
branch
named
example
with
anything
following
we
can
require
pull
requests,
so
someone
has
to
review
the
change
dismiss.
So
this
would
reset
approvals
when
new
changes
are
pushed.
We
can
also
require
review
from
code
owners,
so
your
lab
is
very
similar
options.
So
we
can.
We
have
approval
rules
where
you
can
specify
who
needs
to
approve
and
there's
actually
and
I.
Think
quite
a
lot
of
configuration
capabilities
inside
gitlab
can
in
comparison
to
this.
B
B
A
B
A
Administrators
can
or
cannot
and
bypass
these
restrictions
and
being
explicit
there
and
then
allowing
force
pushes
so
those
are
just
for
these
reviews
and
checks
allowing
administrators
to
pass
them.
But
then
these
would
have
replied.
It
apply
everyone
around
and
deleting
the
branch
and
force
pushing
to
the
branch.
A
A
You
can
change
the
default
branch.
Of
course
you
do
the
same
thing.
The
default,
the
default
default
branch
and
github
is
master,
as
is
the
same
in
github,
and
it
would
be
common
for
certain
workloads
to
change
this
to
develop
web
books
are
another
useful
feature
in
both
github
and
get
lab.
You
configure
a
URL
and
set
a
secret,
and
basically
and
github
will
send
you
a
JSON
payload
to
the
endpoint
that
you
specified
and
every
time
a
certain
event
happens.
A
B
A
Great,
so,
let's
go
back
to
some
poor
requests.
Take
a
look
at
this
one
that
I'd
started
to
assign
myself
on,
and
here
we
can
see
the
reviewers.
So
this
is
similar
to
approvals
inside
of
get
lat,
and
here
we're
saying
that
one
person
is
required
to
approve,
and
so
let's,
let's
request
a
review
from
James
myself,
and
so
we
can
now
see
that
it's
awaiting
my
review.
A
So
this
is
really
nice
actually,
and
this
is
a
feature
we've
been
researching
a
similar
feature
which
we
haven't
built
yet
but
I'm
having
a
first-class
workflow,
where
you
can
request,
reviews
from
specific
people
and
designate
James
or
Jane
or
Michelle
is
the
person
who
is
going
to
review
my
merge
request
and
even
if
I'm
not
reviewing
it
right
now,
you
can
denote
that
and
have
it
as
like,
a
clearly
marked
role
associated
with
the
merge
request.
It
prevents
confusion
which
sometimes
occurs
in
your
lab.
A
Where
you
can
see
the
developer,
who
is
the
author,
is
also
the
assignee?
And
so
it's
not
explicit
who
the
reviewers
are
so
when
I'm
done
with
my
change,
I
have
to
remember
who
I
asked
review
scroll
through
my
comments,
be
like
okay,
I'm,
going
to
ask
John
or
Michelle
to
review
my
changes,
and
this
makes
it
really
easy.
A
A
And
here
we
can
see
the
defuse.
Oh,
this
is
a
little
different
to
the
get
loud.
If
you
in
get
lab,
we
have
a
file
tree,
so
they
have
a
I
think
a
file
filter
which
allows
some
sort
of
an
filtering,
but
that
ever
they
have
a
tree
a
chopper
to
it.
That's
what
I
was
looking
for,
so
I
can
search
this
get
lab.
A
We
used
to
have
a
similar
interface
to
this,
but
we
decided
to
split
it
out
into
its
own
tree,
which
we
found
provides
faster,
easy
access
to
all
the
files
and
it's
easier
to
scan
through
and
get
a
sense
of
what
changed
other
than
that
I
can
compare
different
revisions.
Look
at
individual
commits
it's
really
nice
that
I
can
just
jump
to
one
commit
directly
from
this
view.
A
In
get
lab,
we
have
to
go
to
the
commits
tab
and
then
select
a
committee
which
then
takes
me
to
this
files
changed
and
there's
an
easy
way
to
get
back
by
just
doing
everything
from
this
drop-down.
So
that's
really
nicely
done.
There's
a
really
nice
UX
there
I
can
also
see
here,
0
of
top
two
files
viewed
and-
and
this
is
a
new
improvement
to
get
hug-
that
I
really
like
and
I.
B
A
A
Many
many
months
and
we'll
be
adding
multi-line
comments
to
make
it
easier
to
have
multi-line
suggestions,
hopefully
starting
next
month.
So
this
is
a
great
feature
and
great
improvement
makes
it
much
easier
to
use
other
than
that.
Let's
review
the
changes
and
see
what
happens
here
so
in
gitlab,
we
have
something
similar.
We
have
note
request
reviews
when
you
leave
a
comment.
A
It's
easy
when
you've
left
a
whole
lot
of
nitpicks
on
a
review
and
to
feel
like
you've,
given
them
overwhelmingly
negative
feedback,
except
that
the
most
important
part
of
the
work
is
actually
great.
You've
just
left
a
few
nitpicks,
and
so
it's
nice.
We
had
to
summarize
and
say
great
work
well
done,
put
a
gif
there
so
emoji
and
also
give
like
a
more
structured
signal.
This
is
common,
so
I
want
to
leave
feedback
without
actually
requesting
changes,
because
I
think
that's
one
of
the
ambiguous
things.
A
If
someone
leaves
a
comment
on
your
merge
request,
do
I
need
to
action.
That
is
it
like
a
negative
sign
that
needs
to
be
addressed
before
my
merge
requests
can
merge
or
is
a
simply
a
common,
and
particularly
myself
as
a
product
manager.
I
leave
comments
on
node
requests
at
the
time,
but
I
am
NOT
an
engineer
and
if
I
leave
a
comment,
asking
question
about
some
piece
of
code
that
I've
seen
and
I'm
confused
about
there
shouldn't
be
a
signal
or
a
flag
that
oh,
this
line
of
code
is
wrong.
A
This
the
discussion
needs
to
be
resolved.
It
might
just
be
a
throwaway
comment
being
like
this
looks
nice
or
I'm
confused.
Maybe
we
can
discuss
this.
Could
you
explain
this,
but
doesn't
actually
have
to
be
taken
as
criticism,
so
I
think
being
able
to
just
leave
a
comment.
Is
a
very
nice
feature,
whereas
that's
a
little
bit
more
ambiguous,
you
can't
lab
today,
it's
very
nice
field
to
approve
at
the
same
time,
so
you
can
leave
comments
and
approve
and
similar
to
the
comments.
I've
just
made
feedback
doesn't
necessarily
mean
negative
feedback.
A
I
should
be
able
to
leave
positive
comments
and
complete
my
review
and
saying
great
job.
All
of
these
things
are
complements
and,
of
course,
and
most
importantly,
you
do
need
to
be
able
to
leave
criticism
and
feedback
that
needs
to
be
addressed
and
so
be
able
to
request
changes
and
with
a
click
of
a
button.
It's
nice.
A
B
B
Interesting,
marriage,
fast
foot
and
the
upstream
and
then
add
your
okay.
A
This
takes
so
this
is
making
it
easy
for
me
to
do
the
review
locally
and
then
leave
my
feedback.
I
actually
need
to
go
back
to
the
conversation,
and
this
should
block
review
required.
So
we
have
a
similar
merge
widget.
We
call
it
that
this
block,
which
provides
a
summary
of
reviews,
required
and
easy
to
prove
it.
B
A
B
B
B
B
B
B
B
B
B
B
A
A
As
we
define
it,
get
lab
there's
a
lot
of
things
that
github
does
well,
and
there
are
some
areas,
particularly
that
I
think
gitlab
has
I,
think
more
control
and
capability
that
will
be
useful
for
particularly
larger
organizations.
Around
access
control,
get
lab,
provides
great
granularity
and
configuration
in
that
regard,
but
I
think
my
general
takeaway
would
be
that
github
does
a
really
nice
job
of
being
explicit
in
the
interface
around.
A
Who
has
permission
to
do
what
at
certain
points
in
time
and
I
think
this
interface
that
they've
built
for
resolving
confidential
security
issues
is,
is
really
well
geared
to
that
application,
but
get
like
get
label
point
out.
It
has
a
similar
feature
allowing
you
to
create
from
a
confidential
issue
a
confidential
merge
request
where
you
would
create
a
private
fork
and
then
resolve
it.
Similarly,
doesn't
quite
have
the
same
CDE
capabilities,
the
quests
in
one
and.