►
From YouTube: 2019-07-10:: Ceph DocUBetter meeting
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
A
A
A
A
I
did
have
a
chart
with
lens
who
started
this
ether
pad
on
onboarding
experience
in
the
first
place
and
he
said
he'd
be
willing
to
help
us
with
that
and
just
that
he's
got
to
be
on
pto
for
the
next
few
weeks.
So
in
the
meantime,
we
can
probably
start
working
on
some
bits
pieces
of
what
we
discussed.
B
A
B
B
Python
binding
for
that
documentation
that
seems
to
take
a
really
long
time
and
I
think
that'll
be
sort
of
maybe
the
first
PR
that
I'm
gonna
be
producing,
but
it's
still
not
ideal.
Like
I
mean
it
would
be
really
nice
to
use
some
of
these
more
modern
documentation
frameworks
where
you
can
have
like
like
real
time
editing.
B
A
Yeah,
okay
cool
so,
but
the
other
thing
that
I
think
I
can
start
looking
at
is
from
the
docks
Sarah
yeah.
From
from
the
docks
perspective,
the
docks,
that's
f,
comm,
where
we
want.
We
said
that
we
want
it
to
me,
be
the
super
set
of
everything
it
should
have
it
ready
everything
and
some
parts
of
it
should
go
to
the
website.
A
The
website
bit
I,
believe,
can
be
handled
by
Mike,
but
I
can
start
working
on
getting
docks,
safecom
up-to-date
with
all
the
information
that
it's
missing
right
now.
So
that
would
include,
like
you
know,
adding
maybe
a
new
page
or
like
editing
your
original
page
that
we
have
for
beginners
or
whatever.
That
is
called
to
include
all
the
information
that
we
have
talked
about
in
that
onboarding
talk.
A
A
Junior
and
Gabriella,
so
if
any
of
this
doesn't
make
sense
to
you
of
these
feel
free
to
ask
questions,
but
the
whole
idea
is
that
this
meeting
is
supposed
to
be
a
forum
for
us
to
discuss
documentation
improvements
which
includes
things
like
actually
improving
the
content
of
the
talks
and
also
the
experience
of
the
dock.
Some
things
are
maybe
like
outdated
and
don't
need
to
be
there
or
some
things
are
just
missing,
making
them
up-to-date
and
making
them
more
user
friendly.
A
The
goal
of
this
meeting,
and
so
last
time
we
discussed
as
I
pasted
in
the
in
the
chat
there
is
a
there
is
this
etherpad,
which
is
called
improve,
onboarding
experience.
That
was
something
that
came
up
in
cephalic
on
where
we
felt
that
we
are
lacking
in
a
way
that
are
on
boring.
Docks
for
new
users
or
new
contributors
are
not
very
user-friendly,
and
you
want
to
make
it
as
easy
as
possible
for
them
to
just
look
at
something
and
start
working
on
something.
So
in
line
with
that,
we
discussed
a
few
things.
A
So
we
want
to
structure
the
website
in
in
that
way,
so
that
it's
easier
and
also
we
want
to
improve
our
dock.
So
in
the
Ceph
repository
you
have
a
Doc's
directory
which
has
pretty
much
everything
that
every
component
of
Ceph,
including
things
like
how
you
should
start
and
get
started
and
stuff
which
is
not
up-to-date.
So
we
want
all
the
information
to
go
in
there
as
well
and
also
quite
a
structure.
The
third
part
is
about
the
doc
build
times.
A
So
if
you
look
at
it
at
current
pull
request,
there
is
you'll
see
that
there
is
a
doc
build
that
gets
fired
with
every
pull
request
that
currently
takes
a
lot
of
time.
So
what
Noah
was
talking
about
is
to
reduce
those
build
time
so
that
it's
easier
to
just
you
know,
make
changes
in
get
PR,
smashed
and
stuff
like
that.
A
And
like
what
we
also
are
trying
to
enforce
is
anybody
who's?
Creating
a
PR
will
support
us
if
it's
adding
a
new
feature
of
its
making
a
change
to
a
configuration
value.
Those
PR
should
definitely
have
a
talk
change
as
well
to
update
the
docs.
If
there
is
a
configuration
value
which
is
no
more
going
to
be
true,
you
have
to
go
and
change
it,
along
with
the
PR
that
you
are
creating.
Also,
if
you're
adding
a
new
feature
like,
for
example,
two
here
you're
adding
stuff
to
the
propolis
module
right.
A
We
want
people
to
be
able
to
at
least
know
what
the
propolis
module
is
now
looking
like.
What's
the
difference
with
your
PR,
if
you
have
like
a
small
doc
change
which
will
update
all
the
new
changes
in
the
docs,
it
just
becomes
easier
for
users
to
know
what
you've
done,
rather
than
having
to
like
dig
through
all
the
pull
requests
and
find
out
what
should
what
it
should
be
doing.
So
that's
the
whole
idea.