►
From YouTube: Unlocking InnerSource with Gitlab
Description
If you’re just getting started with InnerSource, or are looking for advice on how to improve your performance, this webinar is for you!
Benefits of InnerSource include:
- Faster, with quality: Unit tests, code coverage, and continuous integration help improve code earlier
- Documentation: Code is better documented, both in comments and less formally in discussions
- Code reuse: Code and architecture are discoverable and available across teams and the organization
- Collaboration: Friction reduced for code review, communication, and contributions in and between teams
- Culture: Silos broken down, happiness improved and with that, better retainment and recruitment
A
Hello,
everyone
and
welcome.
I
want
to
thank
you
for
joining
us
and
taking
time
out
of
your
day
today,
and
I
promise
you
this.
You
will
not
walk
away
here
without
picking
up
a
few
new
ideas,
and
I
know
that,
because
I'm
joined
by
a
couple
of
awesome
colleagues
of
mine
who
will
introduce
themselves
in
just
a
second,
this
is
a
pre-recorded
video.
So
please
feel
free
to
ask
questions
in
the
q.
A
A
section
of
the
chat
we'll
also
have
time
at
the
ends
of
the
webinar
to
do
some
live
q,
a
as
well
as
for
me,
my
name
is
conley
rogers,
I'm
a
technical
account
manager
at
gitlab.
Prior
to
joining.
I
worked
at
verizon,
a
leading
telecommunications
company
with
a
global
footprint
where
I
used
git
lab
to
build
an
inner
source
program.
Hence
today's
topic,
as
well
as
other
devops
and
ci
cd
analytics
programs.
B
C
I'm
carlos
bazan,
I'm
a
senior
technical
account
manager
at
get
lab
I'll,
be
moderating
the
webinar
today,
and
I
wanted
to
just
thank
you,
conley
and
david
for
for
joining
us
here.
I've
heard
a
lot
about
inner
source.
It's
a
topic
that
has
come
up
often
with
my
customers,
speaking
about
how
gitlab
can
facilitate
better
communication
through
merge,
requests,
issues
etc.
A
Yeah,
absolutely
it
is
important
to
kind
of
look
at
where
it
came
from.
Inner
source
is
a
clear
example
of
applying
open
source
to
the
enterprise,
so
hence
the
name.
It's
applying
the
best
and
breed
practices
that
you
follow
in
an
open
source
project
and
it
uses
the
same
types
of
collaboration
and
communication
that
open
source
projects
use
to
enhance
the
project
and
co
quality.
These
are
things
like
asynchronous
communication,
as
well
as
a
high
degree
of
ci,
cd
and
automation,
so
that
you
can
ultimately
trust
contributions
from
strangers.
A
This
is
a
common
practice
with
open
source
where
they're
they're
able
to
solicit
a
variety
of
ideas
from
different
time
zones.
It
allows
you
to
work
at
your
own
pace
asynchronously,
so
those
are
some
of
the
key
benefits
now.
Why
do
companies
consider
this
a
working
practice
to
bring
in
well
for
one
it
increases
operational
efficiency,
so
reusability
is
a
is
a
key
benefit
that
you
gain
by
sharing
your
code
within
the
enterprise.
A
A
It
also
leads
to
reductions
in
lead
time
for
change,
so
it's
been
proven
time
and
time
again
with
mature,
open
source
projects
that
they
have
a
quicker
lead
time
for
change,
because
they
incorporate
a
high
degree
of
automation
in
order
to
trust
any
contribution
that
comes
in
there
needs
to
be
checks
and
balances.
These
these
are
things
like
a
linting
tool,
code,
quality,
scans
and
security
tools
that
are
all
baked
into
a
ci
cd,
workflow
and
then
last
is
to
reduce
security
and
compliance
risk.
A
There's
many
types
of
security
scans,
but
a
secrets,
detection
scan,
is
one
that
I
call
it
here
and
that
we're
going
to
demo
and
talk
about
later,
because
if
you're
accidentally
checking
in
secrets
to
your
code
and
that's
internally
accessible
across
the
company,
then
that
can
really
be
an
issue.
This
is
just
a
bare
minimum
scan
and
it's
one
of
the
many
ways
that
having
an
inner
source
workflow
can
improve
the
security
posture
of
the
company.
C
A
Yeah,
absolutely
this
is
a
it's
good
to
have
a
good
working
example.
The
the
example
I'm
using
today
is
for
my
my
experience,
working
at
verizon
for
over
six
years,
and
I
think
it's
a
good
example
because
it
demonstrates
sort
of
the
hard
way
of
doing
this,
and
the
reason
I
hope
to
to
share
this
is
that
you
may
take
a
few
items
away
that
are
similar
to
your
workplace
culture.
Ours
was
very
risk-averse.
A
We
were
a
mature
telecommunications
company
trying
to
introduce
devops
ways
of
working
and
we
were
met
with
some
resistance.
So
I
think
it's
a
good
example
to
kind
of
go
through
how
to
get
started
with
the
program
of
your
own.
Our
journey
really
began
in
2017
when
we
were
trying
to
become
more
innovative.
We
had
a
desire
from
our
svp
to
become
more
of
an
investment
center.
A
We
needed
to
figure
out
ways
to
to
bring
in
new
ideas
of
fresh
ideas
across
I.t,
so
I
gave
an
internal
tech
talk
that
year,
really
talking
about
the
crowdsourcing
model
that
the
google
used
for
their
innovation
time
that
20
time
you
may
have
read
about.
They
had
really
awesome
results
from
this
when
they
allowed
their
employees
to
spend
x
amount
of
time,
some
percent
of
their
time
on
projects
that
interested
them
away
from
their
day
job.
A
They
sort
of
find
communities
of
interest
and
ideas
can
spark
from
this
innovation
time,
and
so
we
wanted
to
adopt
that.
But
we
also
wanted
to
look
at
beyond
just
the
peoples
and
the
processes
and
analyze.
What
tools
do
we
have?
Let's
do
an
assessment
to
make
sure
as
we
embark
on
this
and
try
to
get
the
most
from
our
rit
ideas
in
it
department
that
we
have
conducive
software.
So
one
of
those
was
the
way
that
we
write
and
ship
source
code.
A
What
we
landed
on
was
a
use
case,
a
business
case
for
using
git
labs
collaboration
aspects
like
the
merge
request,
where
you
can
communicate
with
any
kind
of
party
who
needs
to
weigh
in
and
you
can
iterate
on
an
idea
before
it's
pushed
all
the
way
to
the
end
and
waiting
on
review
and
then
from
there
once
we
kind
of
landed
on
a
tool
that
was
conducive
to
this
inner
source
workflow,
we
started
with
some
seed
projects.
We
called
them
five
smart
projects.
A
It
was
just
something
that
resonated
with
our
leadership,
but
these
were
projects
like
infrastructure
as
code
projects,
it
was
also
docs
as
code.
So
if
you
were
trying
to
stand
up
a
new
documentation
site
for
an
internal
product,
it
would
save
you
weeks
of
time
because
it
had
all
that
piping
scaffolded.
A
A
The
biggest
hurdle
we
had
was
that
risk
averse
and
even
some
internal
mandates
and
documentation,
saying
that
source
code
was
least
privileged.
So
it's
a
need
to
know
basis.
That
was
the
defective
standard.
When
you
may
not
know
who
needs
to
know,
you
may
not
know
who
is
interested
in
contributing
and
using
your
project.
A
So
once
we
formed
the
governance
to
enforce
that
and
to
kind
of
re-up
your
scan,
we
were
all
to
the
races
and
by
the
time
I
I
ended
my
tenure
there.
Over
the
summer
of
2021,
we
had
48
projects,
it
grown
significantly
and
we
were
able
to
tout
many
weeks
worth
of
time
savings
as
people
were
installing
forking
or
reusing
some
of
these
projects
that
we
had
created,
and
I
think
that
david,
you
had
a
similar
story
that
you
wanted
to
tell
about
a
different
customer
at
gitlab.
B
Yeah
great
question
carlos,
so
my
example
is
about
canada,
another
large
telecommunications
company.
They
were
a
company
that
worked
in
development
silos
and
wanted
a
way
that
they
would
be
able
to
break
down
those
silos
and
incentivize
collaboration
for
any
inner
sourcing
engagement.
I
like
to
focus
my
work
on
efficiency
code,
tracking
reusability
collaboration,
all
of
which
leads
to
employee
satisfaction,
also
for
intersourcing
to
be
successful.
An
organization
should
work
towards
open
collaboration,
bringing
in
leadership,
support,
best
practice
and
good
maturity
using
qualified
peer-reviewed
source
repositories
and
quality
assurance.
B
Last
communication
should
be
encouraged
open.
All
users
should
feel
comfortable,
expressing
thoughts,
ideas,
opinions
and
feedback
loops.
Effective.
All
communication
should
be
effective
and
actionable,
meaning
users
are
working
towards
the
same
outcome
or
action
positive,
always
assume
and
utilize
positive
intent.
All
parties
have
the
same
goal.
Collaborative
all.
B
Users
need
to
collaborate
together
and
find
the
best
course
of
action
to
ensure
a
better
final
product
and
for
the
final
part
of
your
question,
carlos
the
practical
steps
to
integrate
intersourcing
best
practices
would
just
be
starting
with
one
or
a
few
projects
or
services,
create
an
open
environment
and
invite
everybody
in
the
organization
to
contribute
include
all
the
best
practices
and
industry
standards
in
from
your
organization
and
abroad
into
those
projects.
Specifically.
C
C
A
A
couple
of
good
examples
that
worked
for
me
was
the
door
of
four
metrics.
These
are
devops
leading
metrics
on
they're
very
outcome
focused,
so
you
get
speed
and
quality
type
analytics
from
these,
and
so,
if
you
have
a
way
to
measure
your
door
for
metrics
with
the
inner
source
projects,
you
can
actually
prove
hey
my
way.
Time
for
change
is
half
that
of
non-inner
source
projects,
or
we
deploy
twice
as
frequent
as
those
who
don't
follow
this
working
model.
A
So
that's
a
really
good
way
to
to
get
the
visibility
attached
to
an
outcome
and
something
really
worthwhile
to
measure
a
couple.
Others
was
it
practically?
Are
you
getting
a
full
participation
with
your
secret
scanning,
so
this
is
sort
of
a
nuts
and
bolts
scan
that
anyone
should
do
not
just
inner
source
projects.
So
why
not
have
that
as
a
goal
to
get
some
percent
a
high
percent
of
your
projects,
passing
a
secrets,
detection
scan
and
then
last
is
transforming
I.t
into
an
innovation
center.
A
That
was
really
the
crux
of
what
what
kickstarted
our
program
was.
We
wanted
to
have
great
ideas
to
compete
with
our
competitors,
who
who
also
had
really
good
ideas.
We
needed
to
move
faster
and
come
up
with
better
ways
of
working,
so
these
are
a
couple
good
examples
of
north
star
goals.
So
once
you
lock
in
on
that,
it's
hey.
What's
a
good
project
to
start
with
I've
rattled
off
a
few,
the
handbook
that
gitlab
uses
this
is
the
most
perfect
inner
source
example.
A
A
I
think
another
one
is
infrastructure
is
code,
so
your
cloud
formation
templates,
your
terraform
templates,
affect
a
broad
range
of
your
your
developers,
so
exposing
that
as
an
inner
source
project,
you're
definitely
going
to
get
some
users
right
off
the
bat
which
may
funnel
into
contributors
as
well,
and
then
the
brand
compliant
ui
frameworks
just
about
every
company
has
one
of
these.
So
I
think
it's
also
sort
of
a
no-brainer
to
to
intersource
that
as
a
good
project,
once
you've
identified
that
it's
time
to
set
it
up
with
the
best
practices.
A
That's
well
documented
that
points
users
to
how
to
install
as
well
as
contribute
through
the
contributing
guide
and
then
finally,
once
you've
got
a
couple
good
projects
to
display
to
share
this
community
engagement
becomes
a
great
lever,
a
tool
in
your
toolkit
to
start
to
use,
and
then
last
company
we
had
a
call
every
friday
that
had
hundreds
of
people
on
it.
It
was
our
public
cloud
call,
and
so
we
would
talk
about
any
updates
to
the
governance
model.
A
For
for
the
public
cloud
we
were
using
if
we
unlocked
say
a
new
feature.
They
just
released
at
a
conference,
that's
where
it
would
be
announced,
get
on
the
agenda
for
for
a
call
like
this,
because
these
are
the
whole
gamut
of
it
users.
You
got
sysadmins
developers,
product
managers
that
join
these
calls.
So
getting
on
that
sharing
your
project
demoing,
it
starts
to
drum
up
some
engagement.
A
You
definitely
want
to
recognize
anyone
who
contributes
your
your
maintainers,
who
maintain
that
code
recognizing
them
through.
If
you
have
an
internal,
you
know
bonus
program,
putting
them
on.
You
know
some
kind
of
a
newsletter
getting
involved
in
inner
source
comments
that
could
just
be
consuming
the
patterns
or
looking
around
and
asking
questions
that
you
have
in
that
slack
channel
and
then.
Finally,
this
was
a
topic
I'm
really
pumped
about
that
was
released
in
14.5
of
git
lab
and
it's
it
goes.
A
A
What
it
does,
though,
is
we
found
ourselves
trying
to
create
custom
marketplaces
where
you
can
get
ideas
for
inner
source
projects
and
advertise
for
them,
so
this
kind
of
alleviates
the
need
to
maintain
a
separate
marketplace,
which
is
a
pretty
common
pattern
that
I
see
out
there.
So
I
wanted
to
call
that
out
as
well.
C
Gotcha
yeah,
that
makes
sense.
I
like
that.
You
also
called
out
the
the
recognition
component.
I
know
that
gitlab
we
have
our
gitlab
heroes
for
some
of
the
key
contributors
to
our
open
source
and
they
get
invited
to
special
events.
I
think
that's
a
huge
component,
so
I
appreciate
you
highlighting
on
that.
I
also
wanted
to
see
if
we
can
hit
on
some
of
the
high
notes
from
your
your
best
practices
list,
starting
with
the
building
block
to
any
good
inner
source
project,
the
readme
and
the
contributing
guides.
A
Let's
do
it
so
looking
at
some
good
readmes,
I
wanted
to
use
an
open
source
project
called
kicks,
because
it's
got
a
ton
of
support
around
it.
So
it's
about
as
mature
as
you'll
probably
see
out
there
right
off
the
bat.
You
can
see
all
these
nice
badges
that
tell
you
about
the
code.
Quality
tells
you
about
the
types
of
scans
and
the
thresholds
that
they've
set
for
quality
gates
the
license
so
that
you're,
aware
of
of
how
to
accredit
an
attribute.
A
So
many
ways
to
make
contributions
in
these
projects,
not
just
through
code
contributions,
but
it
could
be
identifying
a
bug
features
and
then
they
give
you
some
more
information
there.
So
that's
one
example
slightly
different
example
is
closer
to
an
inner
source
project.
This
is
actually
from
a
previous
team
that
I
was
on
where
we
had
this
internal
repo.
We
ended
up
open
sourcing
it,
which
is
why
I'm
able
to
share
this
with
you
but
similar
practices.
You
want
to
have
that
code.
Quality
badged
right
at
the
top
in
that
license.
A
A
couple
differences
here,
though,
is
the
focus
of
these
signatures
in
this
project.
Here
is
that
it
is
a
security
focus
project.
So
that's
what
they
put
right
there
at
the
top
was
securities
top
of
mind.
You
can
see
all
of
these
signature
files
that
we're
going
to
scan
for
if
you
use
this
project
as
a
dependency
in
your
code,
all
right,
so
that's
really
cool.
I
wanted
to
share
with
you
all.
A
A
Also
talks
about
how
to
contribute
it
can
come
in
a
variety
of
forms.
You
know
all
kind
of
contributions
are
welcome.
Even
triaging
issues
like
putting
badges
and
tags
and
soliciting
more
information
from
from
issues
is
a
way
to
contribute,
and
they
will
also
mention
how
their
get
strategy
their
branching
strategy
works.
How
to
create
issues
that
should
all
be
right
there
in
the
contributing
guide.
A
Back
to
that
other
project,
and
you
can
see
clear
documentation
around
the
the
branching
and
workflow
model,
this
is
really
nice
to
show
and
encourages
people
to
follow
this,
as
well
as
semantic
versioning
and
then
at
the
bottom.
I
wanted
to
just
point
out
one
thing:
all
the
different
scanners
that
you'll
have
to
go
through
and
pass
how
to
configure
your
local
dev
environment.
A
C
C
Perfect
yeah-
and
you
also
some
of
those
examples-
were
gitlab,
and
I
think
gitlab
really
makes
this
process
really
easy
for
for
developers
to
get
started.
Some
of
the
things
that
I
like
to
use
in
my
day-to-day-
and
I
encourage
my
customers
to
use,
is
project
templates
david.
Can
you
walk
us
through
what
project
templates
are
and
how
we
can
utilize
them.
B
Absolutely
so
great
question:
with
project
templates:
an
organization
can
create
at
either
the
instance
level
or
the
group
level.
They
can
build
a
fully
working
project
that
can
be
used
as
a
template
for
similar
projects
going
forward.
This
allows
an
organization
to
put
all
of
the
best
practices
and
organizations
specific
configurations
into
a
project
before
the
team
even
starts
working.
B
This
leads
to
many
benefits
that
are
typical
of
open
source
development,
but
mainly
it's
faster
with
quality
as
much
of
the
project
and
testing
can
be
pre-built.
Documentation
and
readme
can
be
templated
code
reused.
It's
distributed
consistently
across
an
organization
with
all
the
best
practices
built
in
in
collaboration.
C
Awesome,
thank
you.
So
much
for
that
and
calmly
you
mentioned
security
is
the
most
important.
It's
really
practicing
the
security
best
practices.
This
can
sometimes
be
a
a
day,
two
technical
debt
item
or
a
second
thought.
Can
you
explain
why
it's
you're
on
your
101
list
and
how
gitlab
actually
really
makes
it
easy
to
set
up.
A
Definitely
secrets
detection
is
one
of
the
handful
of
security
scanners.
You
get
out
of
the
box
by
using
gitlab
ci
secrets.
Detection
is
looking
for
sensitive
information
that
was
accidentally
pushed
to
your
repository,
the
br.
The
best
practices
is
to
store
things
like
api
tokens,
passwords
and
keys
in
a
secrets
manager
like
hashicorp
vault
or
the
gitlab
secrets
manager
in
in
the
project
itself.
A
Now
the
reason
that
this
is
a
101
for
an
inner
source
project
is
that
you're,
theoretically
sharing
this
code
with
any
authenticated
user
at
your
company,
so
the
stakes
are
a
little
higher
than
just
your
team.
From
my
experience,
I
can
also
tell
you
it's
the
use
case.
Risk
or
security
at
your
company
can
really
use
to
shut
down
initiatives
like
this,
so
considering
it
mandatory
and
being
conscious
day.
One
earns
their
support.
A
This
can
be
configured
to
run
whenever
you
push
changes
to
your
merge
request.
Gitlab
is
able
to
detect
secrets
and
credentials
unintentionally
pushed
to
your
repository,
for
example,
an
api
key
that
allows
right.
Access
to
third-party
deployment.
Environments
may
have
accidentally
been
been
checked
in
so
it
scrubs
it.
It
looks
for
those
flags
them
and
then
you're
able
to
address
it
before
it
lands
in
trunk.
C
Perfect
appreciate
you
going
over
that
definitely
want
the
securities
buying.
We
don't
want
this
getting
shut
down
shut
down
before
it
gets
off
the
ground.
So
I
appreciate
you
going
over
these
best
practices
in
your
in
your
101,
and
I
know
you
got
a
demo
tee'd
up
for
us
before
before
we
dive
into
that.
For
those
that
aren't
familiar,
can
we
go
over
the
git
lab
flow.
A
Yes,
the
gitlab
flow
is,
I
wanted
to
put
the
slide
up.
It's
a
little
different
than
the
the
other
ways
of
working
you
may
have
seen.
So
here
is
the
gitlab
flow
process
that
we
recommend
for
for
teams
to
follow
while
using
get
live
capabilities
within
a
concurrent
development
lifecycle,
it's
different
than
other
git
workflows,
where
you
create
bank
for
your
branch,
you
work
locally
with
small,
commits
push
to
remote
and
then
create
a
pull
request
in
the
get
lab
flow
described
here.
A
A
This
is
that
crux
of
shifting
left
that
everyone's
desiring
and
wants
to
do
is
getting
faster
feedback
loops,
as
well
as
enabling
a
conversation
while
making
the
changes,
instead
of
only
at
the
very
end
soliciting
that.
So,
as
you
finalize
those
changes,
you
invite
stakeholders
that
need
to
weigh
in
or
approve
that
change.
A
A
This
is,
as
a
side
note
a
really
awesome
way
to
organize
your
inner
source
projects
that
I've
seen
work
very
well,
where
you
have
a
group
and
everything
under
it
is
considered
the
inner
source
project
it's
useful
in
gitlab,
because
you
can
actually
enforce
compliance
frameworks.
So
if
you
need
to
enforce
secrets
detection,
this
would
be
one
way
of
going
about
that.
A
A
The
purpose
of
having
these
templates
is
so
that
I've
got
a
standard,
readme,
a
contributing
guide,
a
project
and
group
level.
Runners
runners
are
sort
of
the
core
piece
of
gitlab
ci
cd
and
are
definitely
prerequisite
it's
where
it's
the
infrastructure,
where
your
pipelines
are
actually
running.
So
it's
like
a
vm.
It
could
be
in
many
different
forms:
I'm
using
docker
today,
gitlab
ci,
yaml,
so
there's
some
example
snippets
in
here
the
secrets.
Detection
code
is
also
easily
referenced
and
then
how
to
add
topics
to
increase
discoverability
and
search
engine?
A
A
A
A
I'm
going
to
keep
it
keep
it
simple
here,
so
by
default,
you've
got
that
this
branch
main
is
my
default
branch
and
anyone
who
is
a
maintainer
level
and
above
like
owner
maintainer,
is
able
to
merge,
merge
requests
and
maintainers
are
also
allowed
to
push.
I
want
to
enable
or
disable
that
so
that
no
one
can
push
without
a
merge
request.
A
This
is
a
very
bare
bones,
one
that
russ
rutledge
was
working
on
in
the
slack
channel,
so
I
just
pulled
it
because
I
think
it's
nice
and
quick,
quick
and
easy,
nothing
crazy,
but
it
tells
you
the
purpose:
how
to
use
this
project,
how
to
get
help
and
contributing.
So
it
hits
all
the
the
high
notes
that
I
want.
A
So
I'm
going
to
go
ahead
and
copy
that
all
right-
and
in
doing
so,
I'm
going
to
create
a
new
branch
to
work
off
of
this
new
branch
is
going
to
be
sort
of
a
scaffolding
and
it's
going
to
include
all
those
nice
templates.
So
I'm
going
to
create
this
branch
here,
like
I
mentioned
before,
it's
encouraged
and
you
can
even
see
it
prompted
me
to
create
that
merge,
request
right
off
the
bat
drafts
is
great
because
it
means
no
one
can
merge.
My
changes
before
I'm
done
working
on
this.
A
A
A
A
And
then
the
last
thing
I
wanted
in
my
original
repo
to
set
it
up,
we've
got
our
contributing
guide.
I
went
ahead
and
set
up
a
runner
ahead
of
time
and
it's
what
we
call
a
group
runner,
there's
also
project
or
repo
specific
runners,
where
you
can
lock
it
down,
so
that
that
infrastructure
can
only
be
used
for
a
given
project
and
and
then
there's
shared
runners.
Shared
runners
are
really
clean
and
easy
because
you
can
use
them
across
the
whole
instance.
A
Today
I
went
with
a
group
runner
and
it's
running
locally,
so
there
are
some
prerequisites
and
docs
that
you'll
be
able
to
find
later
in
the
sites
and
if
you're,
using
a
mac,
you
can
use
these
instructions
here,
like
I
did,
and
so
let
me
just
add
the
gitlab
ci
yaml
and
then
we'll
almost
be
done
here.
So
back
to
my
snippets.
A
A
Gitlab
ci
yeah.
Well,
that's
that's
what
we
call
this
file
and
you'll
see
some
really
nice
settings
come
up
where
you
can
use
templates.
Any
gitlab
installation
comes
with
these.
I'm
not
going
to
take
these,
but
if
you
were
to
use
something
like
auto
devops,
it
throws
in
all
kinds
of
tests.
So
it's
kind
of
the
full
array
of
ci
cd,
including
canary
roll
outs,
that
you
can
use.
A
A
A
So
it
just
created
a
lot
of
overhead
for
us.
So
when
I
realized
that
I
could
get
this
out
of
the
box,
I
had
to
share
it.
That
was
really
the
impetus
behind
sharing
a
lot
of
what
we're
sharing
today,
all
right.
So,
let's,
let's
wait
for
that
to
run
it
won't
take
too
long,
and
hopefully
everything
looks
good
and
assuming
that
secrets
detection
scans
on
this,
mr
I'm
going
to
push
it
and
we'll
start
to
wrap
up.
A
So
topics
is
what
it
looks
like
on
your
home
page
of
gitlab.
You
can
you've
always
had
the
ability
to
explore
projects,
but
it
was
tough.
You
had
to
know
what
you're
looking
for
topics
being
right
here
on
the
home
page
means
I
can
just
search
by
inner
source.
I
can
search
by
a
language
and
all
of
those
android
projects
or
whatever.
That
topic
is
that
you
tagged
it
with
are
going
to
show
up
by
relevance
and
update.
A
So
this
is
really
key
to
setting
up
if
you're,
the
administrator
of
your
gitlab
instance-
and
this
is
how
you
would
do
it
so
administering
these
you
need
to
choose.
If
it's
a
self-managed
gitlab,
you
need
to
choose
what
those
topics
are,
so
you
can
be
strategic
about
this
and
do
it
not
just
for
inner
source,
but
for
for
other
initiatives
that
you
have
going
on,
and
so
that's
really
all
the
content
we
had
for
you
all
today.
I
wanted
to
thank
everyone
so
much
for
joining.