►
From YouTube: Docs SIG 2021 01 22
Description
Jenkins Docs SIG Jan 22, 2021
A
Let's
review
the
agenda.
We've
got
first
item
a
report
on
previous
action
items
oleg's
not
available
today,
so
we'll
skip
that
documentation.
Planning
is
one
topic
that
we'll
touch
on
and
then
latest
data
on
contributors
and
contributions
with
the
addition
of
a
new
component
into
the
the
data
that
we're
collecting
so
first
topic.
A
So
zenob
and
kristin
have
already
agreed
to
assist
and
we'll
ask
our
monday
office
hours,
participants,
vlad
silverman
and
meg
rob
mcroberts
to
assist
as
well.
The
idea
is
this,
so
what
we'll
do
is
we'll
identify
candidate
content
first
by
creating
an
outline
of
the
current
jenkins.io
documentation.
The
headings
of
the
of
the
chapters,
sections
and
pages
that
are
part
of
jenkins.io,
then
create
a
list
of
existing
wiki
content
by
frequency
of
use.
A
That
list
we've
been
amassing
over
time
by
collecting
the
wiki
access
data
logs
every
day
for
the
last
about
12
months.
So
we've
got
a
pretty
good
sample,
of
which
wiki
pages
are
being
read
and
which
are
not
then
outline
a
map
of
the
content
into
www.jenkins.io,
and
that
means
mapping
the
most
frequently
used
wiki
content
into
the
handbook.
This
is
a
technique
that
jonathan
morise
had
done
had
done
this
exact
technique
for
us
on
a
number
of
jonathan.
A
She
had
done
this
technique
for
us
on
a
number
of
cases,
and
it
worked
quite
well
for
us.
It
allows
us
to
create
individual
tickets.
Once
we've
completed
this
review
process
we'll
be
able
to
create
individual
tickets
for
each
page
that
needs
to
map
and
be
able
to
identify
the
kinds
of
changes
that
may
be
needed
in
that
page.
Now
it's
a
lot
of
work.
A
Jonathan
spent
many
many
hours
doing
that
work,
but
the
result
was
we
have
the
result.
Is
we
have
a
better
definition
of
what
should
the
structure
the
documentation
be?
How
should
it?
How
should
it
look
to
users
and
what
content
should
be
placed
in
which
places
that
way?
We
don't
sacrifice
the
content
we
have
available
in
the
jenkins
wiki
as
concepts
and
as
ideas
and
before
it
gets
put
into
www.jenkins.io
in
the
final
destination.
A
The
other
part
of
that
is
to
map
the
existing
content
on
www.jenkins.io.
That
needs
to
move
location,
because
there
are
some
things
that
are
are
not
well
placed
in
the
in
the
current
documentation,
and
we
have.
We
now
have
a
technique
to
preserve
the
identifiers
of
those
pages,
even
when
we
move
them
and-
and
that
means
navigator
navigation
that
previously
had
recorded
the
url
of
a
an
identifier
inside
a
page,
will
still
work.
A
We'll
use
that
information,
this
new
map
of
the
candidate
content,
to
revise
the
jenkins
documentation
roadmap
now
one
of
the
revisions
here
is
that
I
had
initially
had
the
concept
that
what
we
needed
was
a
user.
I
had
had
the
concept
that
we
needed
a
user
guide
and
a
separate
administration
guide,
but
the
more
I
have
looked
at
jenkins
content,
the
less
clear
it
has
become
to
me
as
to
what
is
something
that
would
be
in
the
user
guide
and
what
is
something
that
would
be
in
the
administration
guide.
A
A
It
will
also
be
reviewed
and
discussed
in
the
upcoming
jenkins
contributor
summit.
A
That's
part
of
this
jenkins
wiki
plan,
that's
linked
here,
and
the
jenkins
wiki
plan
describes
how,
in
late
2019
spam
caused
us
to
make
the
jenkins
wiki
read
only
and
since
that
time
we've
been
making
progress
as
we
migrate.
The
content
from
the
jenkins
wiki
to
other
places,
plugin
documentation,
is
migrating
into
the
github
repositories
and
jenkins
documentation.
So
things
about
jenkins,
core
or
higher
level
concepts
is
migrating
to
the
www.jenkins.io
site.
A
So,
but
it
needs
to
be
in
a
place
where
we
can
we,
where
we
can
actually
edit,
that
content
make
use
of
it
and
that's
the
progress
process.
We've
been
using
one
page
at
a
time,
but
if
we
were
forced
to
tim
jacom
notes
that
we
may
be
able
to
just
capture
a
copy
of
the
site
statically
and
with
that
static
site,
decommission
the
wiki
server
completely
and
only
serve
static
pages.
A
Now
how's
our
progress
going.
Well,
that's
a
that's
a
good
question,
we're
showing
we
can
see
progress
in
one
of
two
ways,
so
progress
reporting,
we
can
see
progress
in
the
it's
now
included
in
the
metrics.
As
of
today.
That's
wiki
conversion,
progress
and
the
wiki
conversion.
Progress
page
is
here
on
the
jenkins
wiki
exporter,
and
what
it
shows
us
is
that
we
have
one
over
1
100
plugins,
yet
to
migrate
their
documentation
from
wiki
to
github.
A
A
A
A
A
A
In
terms
of
our
other
metrics,
thanks
very
much
to
the
linux
foundation
for
their
devstat
site,
our
time
from
pr
to
engagement
is,
is
looking
quite
good
still
and
and
that
we're
very
grateful
to
markey
jackson
and
others
who
are
very
actively
acting
as
reviewers.
A
What
this
shows
us
is
that,
across
the
last
three
or
more
months,
our
85th
percentile
of
time
to
engage
with
a
pull
request
from
its
initial
creation
to
engagement
to
some
comment
from
someone,
not
the
author
is
well
below
one
day
we
had
one
one
sample
that
was
above
one
day
for
the
85th
percentile.
Our
median
time
is
very
nice,
so
people
we
are
obviously
connecting
very
rapidly
with
contributors
as
they
contribute
new
poll
requests
to
the
to
the
jenkins
dot
io
site.
A
Other
data
is
not
quite
as
quite
as
positive,
so
time
from
pr
open
to
merge
is
looking
a
little
worse
now
than
it
was
before.
You
can
see
an
upward
trend
here
at
the
end
where,
in
december,
our
85th
percentile
was
below
10
hours
for
us
from
open
to
merge.
But
now,
during
january,
we've
gone
upwards,
pushing
towards
pushing
towards
two
and
three
days
before
it
before
we
get
that
initial.
That
merge
for
a
new
pull
request.
A
Now
the
current
state
of
number
of
poll
requests
pending
last
last
month
we
had
32
pull
requests
merged,
that's
down
a
little
bit
from
prior
months.
In
the
past,
we've
done
40
or
more.
We
assume
it's
some
impact
from
many
people
taking
two
weeks
off
during
the
end
of
december
as
their
end
of
year
holiday.
A
We
currently
have
29
open,
pull
requests
with
3723
closed.
Many
of
those
have
been
open
for
an
extended
period.
It's
that's
a
that's
an
ongoing
issue
that
we
need
to
resolve.
We
need
to
either
complete
those
pull
requests
and
close
them
or
admit
that
we
are
going
to
merge
them
and
bring
them
in
all
the
way
into
the
product
into
the
documentation.
A
The
plugin
documentation
conversion
progress
is
a
new
measure
that
just
added
this
month,
we
have
1
000
roughly
to
do
1
100
to
do
and
600
complete,
so
we're
a
little
over
one-third
complete
in
the
process.
Now
we
we
pragmatically
do
not
ever
expect
to
reach
full
completion,
but
there
is
good
progress
here
and
will
continue.