►
From YouTube: GitLab Docs Offline - R&D Requirements Discussion
Description
Discussion to get the context around the requirement for offline docs and which direction we should go in with R&D.
A
Right,
hello,
everybody!
So
this
is
a
quick
synchronous
discussion
to
have
a
look
at
the
need
to
or
the
desire
to
provide
the
offline,
docs
version,
and
so
we're
just
going
to
brainstorm
a
few
ideas
and
determine
the
next
steps
on
what
we
want
to
do.
With
regards
to
an
r
d
spike
to
see
what
the
best
solution
you
would
be
going
forward,
jog
for
over
to
you
to
give
us
some
context.
C
B
B
B
And
then
the
documentation
for
all
the
gitlab
ins
applications
gets
hosted
on
the
gitlab.uh
docs
docs.hitler.com
project,
so
this
includes
git,
lab
runner,
omnibus
charts
and
all
of
the
other
applications,
and
it
also
supports
multiple
versions.
So,
on
the
docs.gitlab.com
project,
there's
just
drop
down,
we
can
choose
different
versions.
B
It's
also
feature
rich
and
well
maintained
for
the
most
part
and
then
looking
over
at
the
gitlab.com
forward,
slash
help
section
that
contains
all
of
the
help,
all
of
the
markdown
content
that
you
find
in
here.
For
that
specific
instance,
the
problem
is
that
it
lacks
the
features
of
darkstarkgitlab.com.
B
B
B
A
B
A
B
C
B
B
The
other
solution
is
to
update
the
methods
for
building
the
help
section
to
more
closely
in
line
with
that
of
the
dark
side
kit
lab
project,
so
that
there's
more
features
between
the
two,
for
instance.
We
we
can,
for
instance,
pull
master
of
gitlab
docs
into
gitlab
and
serve
it
in
a
different
port.
A
Yeah,
just
so,
essentially,
the
the
problem
is
we're
maintaining
two
different
trying
to
maintain
two
different
things,
but
the
main.
The
main
intention
of
this
is
to
provide
the
documentation
in
an
offline
environment
where,
in
an
air
gap
solution
where
there's
no
access
to
the
to
the
internet,
and
they
can't
access
docs.github.com
that
they
can
at
least
access
a
version
of
the
documentation
on
their
network.
That
is
fully
featured.
B
That's
right,
that's
right,
so
there's
also
so
that
that
is
a
big
concern,
but
looking
at
the
issue,
we've
also
got
some
concerns
of
our
own.
For
instance,
currently
the
forward
slash
help
section
doesn't
give
us
the
ability
to,
for
instance,
do
includes
redirect
and
search,
whereas
the
docs.gitlab.com
project
gives
us
those
abilities.
B
C
B
B
A
A
B
A
A
So
the
search
part
is
potentially
a
big
deal
breaker
from
just
in
terms
of
the
way,
the
docs
that
gitlab.com
works
right
now,
which
is
a
static
site
that
gets
generated
and
then
having
that
in
offline
environment
and
providing
search
will
be
really
tricky.
Which
is
why
I
guess
the
the
concept
of
expanding
help
hasn't
been
taken
off
of
the
table,
because
that
gives
you
a
back-end
run
time,
at
least
that
you
can
use
for
dynamic
features.
B
Yeah
yeah,
that's
right,
and
one
of
the
outcomes
from
this
r
d
session
is
to
obviously
expose
things
like
this
and
to
break
it
down
into
into
deliverable
chunks.
So
I
would
imagine
that
search
would
be
one
of
the
things
that
we
need
to
split
out
into
separate
issues
that
we
can
properly
investigate
that
and
possibly
do
some
spikes
around
it.
B
A
A
I
feel
like
the
non-negotiables
are
almost
the
thing
that
needs
to
be
defined
to
to
be
able
to
to
know
which
direction
to
look
into
if,
for
instance,
search
is
a
non-negotiable
thing,
and
also
if
we,
if
we
do
go
down
the
road
of
making
help
more
feature
rich
and
stuff,
you
know
like
how
do
we?
How
do
we
share
the
effort
across
the
two
projects
so
that
we
don't
end
up
having
to
maintain
two
separate
systems
as
much
as
possible?
A
C
So
yeah,
I
actually
agree
with
the
that,
having
like
two
separate
projects,
it's
not
a
great
idea
because,
like
right
now
we
have
one
which
is
actively
developed,
another
one
which
is
maintained
on
real
low
level,
and
we
have
this
difference
between
the
features
and
even
if
we
fix
the
gitlab.com
help
and
provide
some
extra
features
to
eat,
it
will
be
still
a
problem.
You'll
need
to
constantly
maintain
return
back
and
update
it.
So
I
guess
the
right
approach
would
be
to
aim
for
one
single
project
that
we
can
share.
C
We
can
probably
use
to
have
like
dogs
only
or
to
have
a
dogs
included
into
the
gitlab,
like,
I
think
it's
up
to
us
to
decide,
but
for
that
I
think
we
need
to
figure
out
like
how
much
effort
we
need
to
do
to
achieve
like.
I
guess
our
goal
is
to
have
dogs
that
users
can
use
off
the
line
without
internet
connection
and
the
docs
that
have
like
lots
of
features
that
we
want
to
provide
as
well.
B
Yeah
and
obviously
yeah
sorry
go
for
it
all
right.
I
just
want
to
say
obviously
having
having
to
maintain
just
one
code
base
could
be
the
ideal
outcome
yeah,
because
it's
getting
it's
getting
more
and
more
complicated
to
try
and
maintain
these
two
different
versions
of
our
docs
or
docs
ui.
So
I
think
the
ideal
outcome
would
have
whether
we
include
it
in
the
gitlab
project
or
still
have
it
as
a
separate
project
and
then
package
it
within
the
gitlab
project.
C
So
what
if
we,
for
example,
take
the
docs
gitlab
as
a
example
as
a
base
and
you'll
try
to
add
this
offline
search
to
it
and
somehow
ship
it
together
with
the
gitlab
product
too.
So
we'll
use
the
most
modern
version
of
our
docs
one
side,
so
we
don't
need
to
implement
it.
We
just
need
to
add
the
features
that
it's
missing
right
now.
B
A
A
Far
as
as
far
as
I
know,
they're
only
indexing
groups
and
projects
and
stuff
in
in
the
elasticsearch
database
so
we'd
have
to
work
with
the
search
team
to
to
see
if
it's
possible
to
to
index
the
documentation
as
well,
because
yeah.
If
we
have,
I
mean,
we've
got
a
search
functionality
in
gitlab
and
and
so
if
we
can
include
the
documentation
as
part
of
the
search
results.
That
would
be
really
useful.
C
B
A
And
then
also,
I
would
imagine
that
the
aversion
drop
down
wouldn't
be
necessarily
appropriate,
because
you'd
want
the
documentation
relevant
to
to
to
the
version
that
you're
running
on
that
instance.
So
it's
not
as
simple
as
just
I
guess,
replicating
what
what's
in
docs
on
docs.gitlab.com
and
putting
it
in
the
in
the
help
site.
A
Finding
some
sort
of
mechanism
to
share
resources
between
the
two
like
layouts
and
styling
and
stuff
might
might
be
another
approach
that
we
that
we
that
we
look
at
you
know.
Maybe
we
could
have
a
package
that
that
has
the
shared
common
common
things
between
the
two.
You
know,
I'm
not
sure
you
know
yeah,
because
it's
not
a
it's
not
as
clean
cut,
as
just
you
know,
replicate
gitlab.com.github.com
functionality
to
help.
There
is
some
tweaks
that
would
need
to
be
made.
B
B
A
C
B
A
So,
for
me,
what
it
feels
like
is
the
first
step
is
just
to
clarify
on
the
exact
requirements,
because
the
requirements
might
short
circuit
some
of
the
effort
we
might
need
to
put
into
to
see.
You
know
how
do
we
share
layouts
and
styling
between
help
and
docs.google.com
and
all
those
things,
because
if
the
requirements
become
clear
enough,
we
had
said
you
know.
Actually
we
need
a
full
featured
docs
thing
available
offline.
B
C
C
B
B
A
Was
on
it,
what
might
be
helpful
is
if
you
we,
you
know
if
you
follow,
if
you
check
out
the
docs.gitlab.com
project
and
you
follow
the
installation
instructions
to
get
it
running
locally,
you
get
a
really
good
feel
for
how
it
works,
to
get
it
going
where
it
literally
all
the
repos.
It
pulls
the
various
docs
sections
of
those
repos
in
and
then
at
both
times.
It
uses
that.