►
From YouTube: Docs SIG 2020 05 22
Description
Jenkins documentation special interest group met May 22, 2020 and reviewed progress on projects and issues, including the Wiki migration project and Google Season of Docs interactions. We reviewed the Google Season of Docs timeline and the upcoming start of the technical writer application period.
A demonstration was shown of automatic image compression for new pull requests to jenkins.io. The change is in progress, hoped to be completed and merged within the next few days.
Latest data on contributions and engagement was also provided.
A
A
B
A
All
right,
so
then,
let's
work
through
the
action
items,
a
doc
cig
summary
I'll,
dried
on
that
today
submit
it
for
review
over
the
weekend
in
hopes
that
we
can
consider
posting
it
next
week
as
part
of
the
FAQ
fist,
blog
posts
that
will
be
coming
out,
Oleg
had
run
the
palm
meet
up
with
James
north
thanks
very
much.
The
presentation
has
been
recorded
and
is
available
on
YouTube
through
that
that
link,
and
then
we
had
an
item,
Oleg
lists
the
github,
apps
and
plugins
that
use
them.
Are
you
comfortable
with
that
one
or.
A
C
Obviously,
additional
to
github
wishes
so
github
wishes
are
helpful
because
they
easily
discoverable
by
users.
They
can
manage
the
writing.
The
same
repositories
who
requests
and
in
general
they're
much
more
convenient
for
users
than
Jenkins
in
our
projects
is
just
a
representation
in
basically
a
snapshot
of
the
project.
Why
benefit
from
that?
Everybody
can
go
to
do
this.
The
dashboard
and
see
what's
planned
on,
what's
left
what
some
progress
and
what
needs
reviews
so
yeah,
that's
the
main
benefit
of
this
work.
C
A
You
bet,
and
so
so
one
of
the
things
that
I
needed
to
clarify
was
that
the
content
should,
in
general
that
we're
creating
and
github
issues
here
should
generally
assigned
to
one
of
those
two
projects.
It's
not
it's,
not
it's
rather
atypical
that
we'll
get
something
that's
in
an
issue.
That's
not
either
a
user
guide
or
an
admin
guide.
Is
that
correct?
Well,.
C
There
might
be
other
issues,
of
course,
but
yeah
for
documentation,
almost
everything
now
so
we
have
user
guides.
We
have
documentation
that
we
have
contributed
regards,
so
this
is
semi-official
categorization
right
now
and
also
in
developer
guides.
So
four
types
of
guides
from
the
project,
so
whatever
wiki
page
likely,
belongs
to
one
of
these
four
categories.
A
Okay,
so
I
can
revisit
those
and
be
sure
that
they're
assigned
to
the
projects
as
I've
been
working
through
these
making
progress
on
them.
They'll
they
each
one
should
go
to
one
of
those
I
assume
would
be
also
okay.
If
we
create
created
additional
projects,
not
just
for
user
guide
and
had
been
guide
but
for
developer
guide,
if
there's
something
that
is
developer,
centered.
C
Yeah,
if
you
clung
to
the
immigration,
it
would
be
nice
because
yeah
right
now,
we
have
on
the
user
guide
an
administrator
right,
for
example,
Jake
it's
project,
formal,
so
having
something
for
for
developer
guide
would
be
used
for
contributor
guidance.
We
don't
need
a
project,
because
that
is
all
of
the
one
engine
which
is
mostly
complete
right,
but
here
for
developer,
guys
I
think
it
would
host
having
the
project
great.
Okay.
Thank
you.
A
A
C
A
Thank
you
thanks
very
much.
Okay,
so
in
terms
of
our
progress
we've
got,
we've
we've
run
a
series
of.
We
ran
a
90-day
sample
of
the
of
the
accesses
to
the
wiki
pages,
and
out
of
that
came
a
list
of
245
pages
that
had
been
accessed
of
those
74
have
been
triage
and
either
assigned
to
github
issue
or
listed
as
no
no
action
to
be
taken,
or
we
just
need
to
redirect.
A
171
of
them
still
need
to
be
triaged,
so
the
I'm
working
through
them
steadily
and
others
are
welcome
to.
There
is
actually
a
spreadsheet
that
I'm
using
to
do
that
now.
I
got
tired
of
fighting
with
editing
tables
inside
JIRA,
and
so
that
sheet
is
fear
and
I'll
embed
a
link
to
that
into
the
signals.
Okay,.
C
A
A
C
A
Okay,
the
next
topic
proc
out
this
one
I
think
is
for
for
your
benefit
and
for
others
who
may
be
viewing
the
recording.
So
the
Jenkins
project
has
been
accepted
as
a
google
season
of
docs
project
and
oleg
is
one
of
our
org
admins,
I'm
one
of
the
mentors.
This
is
our
our
chance
to
review
the
timeline.
So
right
now
we
are
in
the
technical
writer
expert
exploration
phase
in
that
phase
writers
become
familiar
with
the
project
and
come
to
understand
what
the
project
offers
and
how
they
can
contribute.
A
So
this
is
what
has
to
be
done
and
submitted
to
by
the
due
date.
It
should
we've
found
that
it's
very
good
for
these
things
to
be
reviewed
first
by
project
members
in
draft
form,
so
by
jenkins
project
members
in
draft
form
before
they
are
ever
submitted
to
google
or
like
in
your
in
your
experience
with
google
Summer
of
Code.
Are
there
things
that
you
would
guide
us
on
in
terms
of
what
makes
an
effective
project
proposal
and
what
sorts
of
things
those
writing
the
proposal
should
do.
Oh.
C
So
Google
Sentinel
dogs
is
slightly
different
from
JSOC,
but
expectations
are
basically
the
same,
so
we
expect
a
consistent
proposal
which
would
be
specific
in
terms
of
deliverables,
so
basically
items
you
would
like
to
improve.
Also,
this
proposal
has
to
be
feasible.
So,
for
example,
if
you
say
that
I'm
going
to
the
right
edge,
Inc
is
user
documentation
completely.
C
It's
not
feasible
proposal,
it
might
be
a
valiant
goal,
but
it's
not
possible
to
be
giving
goals
in
our
books
but,
for
example,
focusing
on
a
particular
area
like
let's
say,
kubernetes
doc
here
or
maybe
just
defining
user
guidelines,
so
installation
guidelines.
This
would
be
scope
which
is
feasible
also
for
all
seasonal
docs.
It's
important
to
take
project
which
would
be
available
to
the
community
it's
available
to
contributors
and
to
junkies
users
in
the
backseat.
So
obviously,
if
you
do
any
contributions
to
the
Jenkins
project,
of
course,
will
be
much
shaded
and
usually
contributions.
C
B
A
B
B
C
I
listed
what
would
be
needed
in
the
previous
question,
so
if
you're
interested,
you
can
refer
to
some
code
which
want
to
comment
on
the
drinkin
side
but
yeah.
The
most
critical
thing
is
clear
list
of
deliverables.
So
basically
what
you
want
to
do
probably
be
some
funny,
preferably
with
some
details
but
yeah.
This
is
the
key
part.
A
And
the
document
here
on
the
season
of
darkseid
gives
you
the
specifics
of
what
what
they
expect
will
be
included
and
then,
if
you're,
looking
for
ideas
Oh,
what
what
things
might
you
include
in
the
proposal,
the
the
google
season
of
Docs
page
on
jenkins?
That
io
includes
a
number
of
suggestions
of
possible
project
ideas.
A
A
All
right,
okay,
so
then,
in
the
past
I've
gathered
data
on
contributors
and
contributions.
We've
we've
got
86
open,
github
issues.
Now
29
have
been
closed,
that
that's
a
steady
improvement.
Will
we
expect
the
number
of
open
issues
to
increase
significantly
as
we
work
through
the
triage
process
and
we're
very
grateful
for
people
who
are
contributing
things
to
close
it
in
terms
of
the
graphs
this
time
from
poll
requests,
initial
submission
to
engagement
from
someone
who
is
not
the
author
is
looking
pretty
good.
A
It
shows
that
for
the
last
month
or
more
time
to
mean
median
time
to
engagement
has
stayed
at
or
below
four
hours
so
that
that's
really
encouraging,
particularly
given
that
we
have
a
24
hour
a
day
and
and
so
we've
got
people
helping
regularly
and
there's
a
concern
here
in
the
time
from
PR
open
to
merge
that
we've
over
the
course
of
the
last
month
shown
a
steady
increase
in
the
time
it
takes
for
us
to
merge
something.
So
that's
one
where
I've
got
to
do
more
work
on
reviewing.
A
C
So,
in
my
case,
I
just
have
no
band
wife,
because
you
are
your
exact
cast
and
other
things.
So
all
my
time,
so
I
can't
contribute
on
a
regular
pages
of
basically
on
daily
basis
to
reviews.
But
you
know
what
I
would
like
to
say
that
even
this
recently
Chris
we're
still
in
a
pretty
good
French
good,
very
good.
Yes,
we
did
get
a
bit
more
time.
Well,.
A
And
it's
one
that
that
same
same
problem
for
all
of
us
I
think
this
is
one
where,
as
we
encourage
more
contributors,
we
may
be
able
to
do
it.
We
had
added
several
people
to
to
invited
them
to
contribute,
reviews
and
I
think
that's
a
good
way
to
get
more
help
there.
Yeah
I'll
I'll
be
working
that
a
birthday.
C
C
Reviews
pull
requests
are
good,
okay,
oh
so
kinky
yeah,
it
image
also
I
believe
is
prep
work
and
we
have
system
recognition
settle
out
which
ones
request
time
pass
Jenkins
core,
because
I
can
use
them
big
chunk
of
work
to
James
Corden.
Anything
else
at
the
moment.
So
oh
I
think
that
we
should
encourage
Jupiter's
to
do
more
reviews,
but
at
the
same
time
we
still
in
Africa
within
a
pretty
good
range.
A
Yes
and
that
that
is
certainly
true
right,
we
I
mean
be
85th.
Percentile
emerged
within
four
days,
so
yes,
absolutely
mm-hmm,
okay
and
in
terms
of
contributions
from
the
last
month,
we've
merged
124
requests,
that's
a
significant
increase
from
previous
months,
and
the
number
of
issues
with
our
switch
to
github
issues
has
nicely
increased.
A
C
A
A
C
A
C
C
So
one
of
the
issues
we
have
miss
Jenkins
are
you
at
the
moment
that
we
store
images
in
the
main
repository
to
be
honest,
I,
wouldn't
call
it
good
practice
for
starters,
because
this
repository
is
extremely
big
at
the
moment
and
by
contributing
new
content
with
images
actually
make
it
big
every
time.
And
while
we
have
opportunity
to
change
it
in
principle
by
moving
image
to
another
repository
or
maybe
not
even
to
the
visit
ori,
because
you
really
need
to
version
images
as
well
and
versioning
them
in
get
basically
doesn't
give
you
a
significant
advantage.
C
So
what
you
have
now
better,
extremely
big
depository
and,
for
example,
the
reason
you
put
request
for
aid
increasing
cloggers
its
in
Clovis
in
artwork,
and
basically
this
is
from
where
my
actual
work
started,
because
this
put
waste.
Also
it's
a
bunch
of
images
and
they
were
avoided,
concerns
about
you
much
another
twenty
years
or
so,
and
this
images
are
not
optimized
and
hence
the
size
increases
one
of
the
ways
to
do.
That
is
to
ask
contributors
to
optimize
them.
C
But
it
causes
first
initial
contributors
because
they
need
to
figure
out
how
to
do
it
properly
in
this
lossless
compression.
It's
not
always
easy.
At
the
same
time,
they
need
spend
time
on
that
and
as
diversity
still
for
our
team
to
say
what
the
people
compressed
enough
I
unless
which
hit
the
mount
and
verifying
so
witnesses
that
there
are
tools
we
share,
allowing
automation
around
it,
for
example,
that
our
github
actions
and
github
applications
which
can
modify
images
right
hand
sides
immediately,
so
how
it
would
like
yeah
I'll
just
open.
C
So
he,
if
you
go,
you
have
yeah
meetup,
always
plus
perfections
a
compression
test.
So
basically
it's
a
bit
simple
request,
but
in
this
repository
else
have
a
word
configured
which
automatically
process
the
images
in
this
pool,
requests
and
compress
them.
Well,
one
thing
which
was
mentioning
that
it
actually
compressed
all
images,
not
all
images
submitted
in
this
request,
because
yeah
this
is
how
this
bot
works.
C
So
it
doesn't
support
SVG
at
the
moment
on
PNG
and
JPEG
I
think
this
with
the
small
metal
program
and
for
making
it
so
this
mod
but
yeah
what
what's
mentioning
here,
but
okay,
so
in
the
dome
on
you
can
see
that
compassionate
reduced
images
by
26%
or
by
20
megabits.
So
in
our
repository
we
have
around
80
megabytes
of
images
all
over
there
and
every
time
you
modify
them
and
you
just
increase.
So,
for
example,
if
I
merge
this
pull
request,
it
won't
even
use
repository
by
a
20
megabytes.
C
Actually
it
will
increase
it
by
16
megabytes
by
15.
So
that's
the
main
program
with
our
architectural
decision,
with
the
current
website
layout
and
structure,
but
yeah
so
I
think
we
have
to
do
that
for
a
while.
So
what
is
my
plan
here?
That
I
will
create
a
block
list
which
basically
just
includes
all
previous
images
so
that
we
do
not
archive?
C
We
don't
compress
what
is
already
in
the
repository,
but
for
the
rest
we
enforce
automatic
compilations
or
every
time
somebody
said
it's
a
pool
request.
The
image
will
built
automatically
compressed
unless
is
not
all
and
decompressed
obvious
downside
about
that
with.
After
that,
you
have
to
pull
the
branch,
because
this
boat
commits
directly
to
the
development
bench
yeah
this
whole
BOTS
work
but
I
think
it
would
be
still
convenient
the
users
because,
for
example,
here
we
can
just
a
squash.
A
So
so
the
technique
that
the
bot
is
using
actually
is
it
optimizes
the
image
and
adds
a
new
commit,
so
it
we
must
be
sure
that
we
squash
marriage.
Otherwise
we
get
the
unoptimized
and
be
optimized.
Ok,
there's
there
a
way
that
the
bot
can
can
automatically
label
it.
For
us
laughter.
There
is
yes,
so
technically.
C
C
Happy
to
consider
that,
assuming
that
we
do
our
sexual
changing
so,
for
example,
if
we
move
all
images,
another
kind
of
storage
I
see
well,
it
I'm
not
sure
what
would
be
the
storage.
It
can
be
a
service
because,
right
now
we
have
CDN.
So
these
images
are
served
from
cDNA
anyway,
it
just
a
separate
repository.
It
might
be
it
at
first
or
whatever.
So
it's
an
implementation
detail.
If
you
move
images
outside
this
repository
it
would,
it
will
be
technically
feasible
to
do
force
push
but
yeah.
A
C
One
of
the
ways
to
do
that
is
to
actually
create
a
new
repository
of
the
existing
one,
but
again
you
lead
to
the
loss
of
contribution,
history,
etc.
So
it's
pick
your
poison.
The
problem
that
right
now,
if
any
contributed,
wants
to
work
on
this
repository,
then
this
contribute
needs
to
check
out
around
100
megabytes,
which
doesn't
seem
to
be
a
tremendous
size
because
your
example,
if
you
want
to
develop
this,
is
we
will
actually
need
to
check
out
a
few
gigabytes
from
dhaka,
because
I'll
make
file
is
based
on
doctor.
A
So
now,
Daniel
Beckett
asked
a
question
about
some
of
the
images
where
he
felt
like
we
could
dramatic
could
have
dramatically
sized
them
down
earlier
any
guidance
there
I
think
his
comment
was
something
about
hey
we're,
presenting
a
700
pixel
wide
image,
but
it
is
the
source.
The
source
image
is
ten
times
that
size
or
something
like
that.
Yes,
it's.
C
A
it's
the
keys,
it's
not
something
called
the
existing
boots
can
do
for
you
at
least
I
haven't
seen
the
fish
would
automatically
resize
images.
I
can
assume
that
they
exist
for
us.
There
was
some
bleeding
examples
if
you
wish
just
a
second
so,
for
example,
at
some
point,
English
a
blog
post
about
five
superpowers.
You
may
remember
that,
yes,.
C
A
It
okay,
thank
you,
so
so
that
would
be
it.
That
is
that
is
enviable
and
separate
thing
that
we
that
we
could
do
now.
It
would
for
that
particular
page.
It
would
benefit
that
page
if
we
optimize
the
image
at
the
cost
of
adding
a
new
copy
of
these,
the
reduced
size
images
to
replace
those
bloated
images
that
are
there.
A
C
So
and
we
couldn't
do
drastic
changes,
but
there
should
be
stronger
justification
for
our.
My
suggestion
is
to
just
ignore
everything
here
that
risk
start
doing
it
only
for
new
images,
because
some
images
they
can
easily
be
filtered
out.
Someone
who
just
cannot
be,
but
it's
the
small
matter
of
programming,
to
have
everything
not
great
all
right.
Well,.
A
Thank
you
Oh
like
that,
so
this
will
mean
that,
when,
when
a
contributor
after
this,
this
poor
request
after
this
tooling
is
available,
a
contributor
can
submit
images
not
having
had
to
worry
about
them
being
optimized
images.
It
will
optimize
the
images
I
assume
they
should
choose
an
image
size,
that's
reasonable,
so
keep
it
about
the
size
that
that
they
need
for
their
page
exactly.