►
From YouTube: 2021 10 09 Docs without Wiki Contributor Summit
Description
Jenkins documentation without wiki.jenkins.io, a segment of the Jenkins Contributor Summit Part II October 9, 2021.
See https://docs.google.com/document/d/1uhhDp-UTz9oWdqG6a1FDZGrjvTW-MjxNpIfiUMQApe8/edit# for the session notes
See https://docs.google.com/spreadsheets/d/1xxz6v-N6h17PI9Qu9uKrWaiKdI94StfeTfzWbwIYsX8/edit#gid=842561319 for the Hacktoberfest worksheet on plugin docs migration to GitHub.
A
A
What
we've
got
today
and
this
will
be
there'll-
be
some
parts
that
will
be
sad
parts
that
will
be
depressing
parts
that
will
be
positive,
but
we
at
least
understand
and
talk
to
each
other.
Make
notes
in
this
section
about
hey
here
are
the
challenges
that
are
ahead
of
us,
the
things
that
we
have
right
now,
where
there
are
issues
and
then
we
could
talk
briefly
about
what's
in
progress,
so
we
know
hey
things
are
already
improving
and
then
what
are
the
alternatives
and
next
steps.
A
Okay,
great
so
so
then,
let's
on
the
what
we
have
today
side,
jenkins.io
www.jenkins.io
is
the
primary
documentation
site
and
it's
it's
doing
reasonable
job
of
of
having
that.
It's
got
sections
on
installation
sections
on
managing
and
on
securing
it's
got
sections
focused
on
development
and
on
developer
guide
and
on
tutorials.
A
A
So
so
those
are
the
kinds
of
things
where
we've
got
lots
of
pages
that
have
links
to
now
that
that
page
is
actually
we
can
find
its
html
representation.
Now
we've
saved
its
html
representation,
but
it's
not
not
directly
linked
to
that
location
any
longer,
so
so
page
they're
incomplete
pages
and
that
page
that
I
just
referenced
is
actually
stored
on
this
confluence
data
site
now
as
static
html
under
jenkins.
Slash,
let's
go
get
it.
A
I
should
have
just
kept
it
that
way,
because
it
it
helps,
at
least
for
me
to
describe
this
process
so
that
we
people
can
see
the
information
is
not
completely
lost,
but
right
now
it's
not
in
a
format
that
is
usable
or
beneficial
to
the
to
the
the
reader.
We've
we've
lost
access
to
it,
convenient
access
to
it
because
of
these
the
attack
that
was
that
happened
to
our
jenkins
wiki.
A
A
A
What
it
doesn't
give
us
is
a
convenient
location
to
reach
it
so
problem,
one
one
very
early
problem
is:
we've
got
them
stored,
but
we
don't
have
them.
Rendering
second
class
of
problem
plugins.jenkins.io
is
is
a
really
strong
place
for
our
for
our
locate
for
our
our
plugin
documentation
and
it's
it's
working
great
gavin
mogan
has
done
a
a
wonderful
job
of
making
this
thing
very
effective,
very
useful
and
very
usable.
A
He
and
spinach
connection
have
made
great
progress
here
so
that
even
even
old
old
plug-ins,
like
let's
see
what's
a
good
one
schedule
builds,
is
a
an
old
plug-in
that
the
schedule
builds
plug-in,
even
though
it's
up
for
adoption,
even
though
its
documentation
has
not
been
converted.
Yet
it
presents
some
very
useful
and
workable
documentation
because
of
their
efforts
so
plug.
A
So
we
have
the
markdown
source
ready
here
we
have
the
html
source
ready
here.
We
just
have
to
have
to
get
them
into
the
right
location,
any
questions
on
what
we
have
today,
dhiraj
anything.
You
wanted
to
specifically
make
note
of
here
things
that
that
I
may
have
missed
in
terms
of
our
weaknesses,
flaws
or
problems.
B
A
And
is
generated
by
extracting
information
from
all
the
plugins
and
their
online
help,
and
that's
that's
really
cool
that.
So,
let's
let
me
put
a
link
to
that
into
the
notes
here.
That's
an
excellent
one,
so
documentation.
If
we
go
to
the
top
level
page,
let's
go
to
yeah.
Let's,
let's
see
if
we
can
get
here,
we
go
so
pipeline
steps
reference
here.
A
This
is
the
enumeration
of
every
plugin
that
provides
a
pipeline
step
notice
that
this
is
not
a
terribly
comfortable
navigation
experience
right.
This
is
an
enormous
page
and
and
no
grouping,
no
no
hints
of
which
things
belong,
where
it's
just
a
great
big
collection
of,
but
it
does
have
the
steps.
So
now,
if
we
look
for
the
let's
see
one
that
I
have
to
commonly
look
for
is
get
so
if
we
look
for
git,
we
continue
here
and
we'll
find
here
are
a
bunch
of
get
related
plugins
and
here's
the
get
plugin.
A
So
it's
description
then
has
the
for
the
one
step
provided
by
the
git.
Plugin
called
get
now
wait
a
sec,
but
where
is
the
checkout
step?
Oh,
it's
not
provided
by
the
git
plugin.
It's
provided
by
something
else,
so
we'd
have
to
go
looking
to
find
that
something
else
levi
was
that
the
kind
of
the
kind
of
question
you
had.
B
A
Yeah
that
covers
it,
okay!
Well
so,
and
let
me
let
me
take
some
notes
here
because
that's
an
important
thing,
dhiraj
and
I
have
had
a
good
good
exercise
with
this
during
the
doc's
office
hours
as
we
went
through
various
various
descriptions
to
understand
how's
that
thing
generated.
How
do
we
improve
it?
We
even
did
a
she
code,
africa,
one
month
project,
to
try
to
improve
that
and
and
the
some
of
the
things
we
we
learned
from
that
improvement
project
could
could
help
us
make
much
better
progress
on
it.
A
Documentation
to
www.jenkins.io,
which
is
really
cool.
However,
most
steps
have
very
little
documentation
right.
If
we
look
at
it's
a
pretty
common,
pretty
common
complaint
on
the
feedback
forms
to
read
from
users.
Saying
hey,
could
you
please
tell
me
what
the
default
values
are?
What
are
the
default
values
for
arguments.
A
A
A
A
A
Okay,
great
thanks
yeah,
so
the
syntax
reference
is
is
yeah
there
are
there.
There
have
been
comments
about
the
syntax
reference
people
wanting
more
almost
always.
It's
hey.
Give
me
more
examples,
and
usually
what
the
the
voice
is
really
saying
is.
Please
I
need
I
would
prefer
a
solution
to
the
exact
problem
I'm
trying
to
solve
and-
and
that's
a
great
great
thing
it's
just
it's-
it's
very
difficult
to
create
solutions
for
everybody's
exact
problem.
A
Okay,
I'm
going
to
assume
not
super
all
right.
So
now,
let's
talk
about
what's
in
progress,
then,
because
this
these
are
the
places
we've
chosen
to
work.
So
we've
got
an
active
hacktoberfest
project
right
now
on
migrating,
more
plug-in
documentation
to
github.
So
we
did
a
recording
hello.
Oh
hey!
Yes,
dear,
are
you
there.
C
C
Oh,
I
was
just
saying
that
from
my
side
I
just
wanted
to
contribute
that
one
point
that
you
already
discussed,
that
is
transferring
everything
from
wiki
to
jenkins
to
the
individual
gated
repositories.
So
that
is
the
important
thing
that
we're
doing
and
that's
exactly
what
I
wanted
to
highlight.
So
nothing
else
great
all
right.
A
A
And
there's
been
no
review
from
the
maintainers
since
then,
so
it's
it's
not
terribly
motivating
to
a
contributor
to
contribute
a
change
that
doesn't
get
any
reviews.
So
as
part
of
our
effort
on
that,
we
have
a
list
of
about
35
plugins
that
the
maintainers
have
committed
to
review,
pull
requests
to
review,
doc's,
pull
requests
and
that
commitment
means
okay.
We've
got
hacktoberfest
that
can
help
that
so
that
sheet
that
tracks.
It
is
right
here
and
let
me
put
a
link
to
it
into
our
notes.
A
A
A
B
Yeah,
that's
nice.
You
know
obviously
a
much
better
architecture
when
you
can
like
dynamically
populate
the
docs
page.
You
know
from
the
source-
and
you
know.
Obviously
it
was.
It's
always
been
kind
of
a
complaint
around
jenkins
documentation,
not
necessarily
if
there
isn't
documentation
that
it
has
always
been
scattered
between
all
these
different
pages
that
you
referenced.
The
steps
reference,
the
plugin
page,
the
wiki,
the
readme
and
so
to
kind
of
point
everything
to
the
jenkins
like
plug-in
marketplace
where
the
readme
is
automatically
displayed.
A
Exactly
right
and
and
and
what
what
you're
highlighting
is
just
what
a
great
job,
gavin
and
spinach
nichini
have
done.
Gavin,
mogan
and
spinec
have
done
on
making
the
plug-in
site
useful
by
steady,
so
they
also
include
a
link
to
the
pipeline
steps
reference
for
that
exact,
plug-in
right
and
and
it's
javadoc
so
oops.
The
javadoc
looks
like
this.
A
One
needs
work
interesting,
but
but
I
think
you're
right
that
it's
brilliant,
that
we
make
documentation
navigation
much
much
better
for
people
by
doing
those
kinds
of
things
yeah,
so
you're
or
even
the
reported
issue
when
okay
now
it
it
takes
me
to
a
okay.
If
I'd
like
to
say
something
is
broken,
go
here
and
yes,
it
really
put
me
into
a
jira
ticket.
So
so
absolutely.
A
So
the
the
the
for
me
at
least
the
there's-
there's
real
power
in
us
getting
plug-in
maintainers
to
review
these
documentation,
pull
requests
that
shift
strategically
shift
information
into
the
plug-in
repository
instead
of
having
them
expecting
them
to
edit
in
a
wiki
page
somewhere.
So
I
I
think
this
is
exactly
the
right
step
to
take,
and
now
there
are
more
steps
to
be
taken
right
things
like
this,
where
the
change
log,
we
can
automate
the
change
log
generation
now
as
well,
and
we
can
put
it
in
a
separate
location.
A
So
it's
right
in
github
and
all
sorts
of
improvements
that
can
help
with
these.
Instead
of
these
releases
being
shown
just
as
a
sha-1,
we
can
have
them
shown
with
real
descriptions
of
of
the
of
what
changed
in
the
release
like
shows
up
here
and
all
the
and
this
is
actually
maintained
automatically
for
us
by
github
through
the
release
drafter
process.
So
so
there
are
all
sorts
of
improvements
that
plugins
can
make.
We
just
have
to
get
them
to
do
code
review
and
merge
and
release.
A
A
A
A
A
A
So,
for
example,
there
are
times
when
there's
there
is
a
page
on
the
old
wiki
that
that
has
some
outdated
but
useful
information,
but
intermingled
in
the
outdated.
But
useful
information
is
a
bunch
of
information.
That's
just
no
longer
accurate
and
if
all
we
do
is
bring
it
forward
onto
www.jenkins.org,
we
actually
make
things
worse.
A
So
so
we
need
needs,
structure,
checks
and
it
needs
accuracy,
checks
and
that's
not
well
suited
to
someone
who's
a
first
time
contributor.
We
can't
just
give
this
to
somebody
who's,
never
used
jenkins
before
and
say
do
this
transformation,
it
really
needs
someone
who
is
isn't
experienced
with
jenkins
and
can
say:
oh
yeah,
that's
false,
that's
true,
etc.
A
A
A
A
C
A
A
A
Wow,
that's
that's
a
really
good
number
150
plus
right.
Well,
it
was
it
was
an
interest.
It
was
a
challenging
experience,
actually
an
interesting,
a
very
positive
experience,
but
a
challenging
experience
for
us.
We've
never
attempted
to
do
mentoring
for
a
group
at
once.
We've
done
google
summer
of
code
for
many
years
and
we're
quite
good
at
google
summer
of
code
we're
really
expert
at
it.
A
We
know
how
to
make
that
mentoring
work,
how
to
be
effective,
but
this
mentoring,
a
team
of
five
people
at
once
when
they
were
in
fact
in
several
different
countries
of
africa
and
and
they
were
a
team
assembled
by
choosing
what
was
selected
as
best
candidates,
not
necessarily
people
who
were
physically
near
each
other
and
with
covet.
It
wouldn't
have
mattered
anyway
right.
The
physical
nearness
wouldn't
have
helped,
but
but
it
meant
they
had
different
experiences.
They
had
different
backgrounds,
different
access
to
internet
bandwidth,
all
sorts
of
things
like
that.
A
Oh
yeah,
that
makes
sense
okay,
so
any
other
questions
or
comments
with
regard
to
the
the
what
are
our
current
projects.
So
again,
the
theme
was
what's
in
progress
right
now,
and
we've
got
hacktoberfest
wiki
migration
that
is
largely
stalled,
and
the
shecod
africa
pipeline
steps
project
that
completed
earlier
this
year,
and
we
intend
to
do
it
again
now
this
this
this
last
one,
this
pipeline
steps
improvement,
could
be
used
for
hacktoberfest
as
well.
It's
just
a
little
more
complicated
than
the
the
docs
migration
effort
that
we
chose
for
hacktoberfest.
A
A
Okay,
I
think
we're
ready
to
talk
about
alternatives
and
next
steps
then,
and
open
to
suggestions
and
different
different
ideas
and
alternatives.
So
the
the
challenge
we've
got
for
docs
without
the
wiki
is,
let's
remind
ourselves,
there
is
what
we
have
is
we
have
html
source
code
for
all
the
pages
that
were
on
the
wiki.
A
A
A
A
A
We
don't
want
to
keep
separate
pages
around.
We
don't
want
to
keep
them
anywhere
else
other
than
inside
the
plugins
own
github
repository
they'll
then
be
extracted
from
there
and
placed
onto
plugins.jenkins.io
like
this
is
done
so
so
that
that
is
for
me
is
a
very
clear
direction
and
I
like
that
direction
and
the
project
is,
is
running
well.
That
will
make
that
transition.
A
The
more
challenging
one
is
non-plug-in
docks,
and
this
is
where
I'd
love
love
your
insights
on,
and
suggestions
on
alternatives.
We
might
consider
so
when
I
say
non-plug-in
docs,
I
mean
things
like
well.
If
we
go
to
documentation,
developer
guide,
the
one
we
looked
at
earlier
in
the
session
was
in
architecture.
There's
this
architecture,
wiki
page,
that's
not
tied
to
a
specific
plugin,
so
it
really
doesn't
belong
in
a
plug-in
document.
A
A
C
A
C
A
Yes,
yes,
we
do
yeah,
so
we've
got,
we've
got
sections
in
jenkins.io
for
each
of
these
topics,
but
what
we
don't
have
is
transition
from
from
the
wiki
wiki
page.
That
was
where
was
it
here,
this
reference
that
as
an
example-
or
there
are
examples
like
that
on
developer,
tutorials
as
well,
that
are
on
the
wiki
and
not
anywhere
else.
A
A
B
A
A
If
we
would
worry
that
much
about
that
excellent
okay,
good,
so
so
that
that's
that's
also,
then
very
interesting
that
we
could
we
could.
That
would
give
us
another
alternative.
We've
said:
hey,
we
don't
want
to
do
it.
For
me,
github
pages
is
interesting
because
it
allows
us
to
use
the
pull
request
workflow
if
we
need
to
make
changes
to
it,
but
but
cloudflare
with
with
a
site
we
published
sounds
interesting
as
well
good,
all
right.
A
B
B
You
know,
can
we
get
a
docs.jenkins
that
holds
everything
and
we
don't
have
necessarily
so
many
places
of
truth,
basically
getting
the
documentation
off
jenkins.io
and
maybe
getting
it
into
a
docs.jenkins.io,
a
documentation
site
just
for
documentation?
And
then
there
is
no
question
about
you
know.
Oh
I'm
looking
for
documentation.
Where
do
I
go
docs.jenkins.io
you'll
see
that
in
a
lot
of
other
tooling,
terraform
and
aws,
and
things
like
that.
A
A
Now,
as
you
think,
about
docs.jenkins.io
as
a
concept,
what
are
some
of
the
things
you
would
envision
would
would
best
fit
there.
Levi
so
is
is.
Is
that
a
the
compared
to
what
we
have
today?
It
would
be
all
right,
everything's
there,
rather
than
no
no
links
to
the
wiki.
Just
no
links
to
wiki
everything
is
is
self-contained.
B
Yeah
I
mean
I,
I
think
when
I
look
at
jenkins
dot
io,
you
know
it's,
it
seems
like
it's
been
updated
and
modernized
over
the
last
year
or
two
and
it
looks
really
good
and
it
has
a
lot
of
different
good
content
on
it.
It's
got
the
blog,
you
know
and
things
like
that,
the
about
how
to
contact
right
those
kind
of
things
and
then
it's
got
the
documentation
which
is
a
bunch
of
subpages
on
itself
and
just
for
me,
I
feel
like
having
a
separate
site.
B
A
docs.unions.io
where
I
can
go
and
anything
documentation
related
is
either
there
or
is
a
gateway
to
it.
So,
like
I
wouldn't
get
rid
of
your
guys's
plugins
page,
especially
with
all
the
great
work.
That's
been
done
to
it,
but
I
feel
like
if
I
click
documentation,
it
should
take
me
to
a
site
and
then
that
site
should
say
oh
plugin
documentation
and
I
click
it
and
you
know
it
either
has
its
own
search
bar
or
it
redirects
me
to
the
plugins
site.
A
Interesting
good
good
suggestion.
Thanks,
okay,
you
know
I
like
the
idea
interesting,
okay,
yeah,
so
so
for
me,
that
feels
like
a
a
massive
project
but
fascinating
okay,
yeah
long
long
term,
long
term,
right
right,
exactly
that's
that's
they're
in
long
term,
maybe
what
we
do
is
put
it
there
as
long
term
ideas,
slash
vision
and
we've
got
that
on
our
notes.
It
says
hey.
B
Yep-
and
I
guess,
along
that
same
long-term
thing,
kind
of
something
that's
been
on
my
mind-
is
the
splitting
of
declarative
and
scripted
pipeline
documentation
right
before
we
pointed
at
scripted
and
the
declarative
was
hidden,
that's
been
reversed
in
the
last
year
or
so
where
by
default,
we're
showing
declarative
and
we're
showing
scripted
as
advanced,
but
I
think
sometimes
that
can
be
confusing.
Even
for
me
that
has
you
know
I've
used
jenkins,
for
you
know,
probably
over
five
years
and
written
lots
of
pipelines
and
sometimes
at
a
glance.
B
Scripted
and
declarative
can
look
awful
similar
to
where
right
really
got
to
look
like
okay,
this
is
declarative
and
so
having
that
kind
of
separation,
and
I
don't
care
what
you
guys
call
it.
I
don't
care
if
you
call
one
beginner
and
one
advanced
or
one
easy
and
one
difficult
right,
but
maybe
in
long
term
having
like
this,
because
I
think
feel
like
there's
this
hierarchy
of
where
there's
plug-ins
and
plug-in
documentation
is
focused
a
lot
on
users
right
users
of
pipelines
want
to
find
out
how
to
do
things
in
their
in
their
builds.
B
And
then
you
have
the
second
form
of
documentation
which
is
very
similar,
which
is
like
your
your
scripted,
your
declarative,
syntax
and
then
there's
this
whole
other
segment,
like
you
said
of
like
developer
docs
and
that's
where
you're
like.
I
want
to
develop
a
plug-in,
but
I
I
kind
of
need
to
know
some
of
the
architecture
of
jenkins
and
I
need
to
know
how
do
I
do
this
and
so
yeah
having.
I
think
we
already
got
that
kind
of
well.
B
If
I
look
at
the
jenkins
dot
io,
that's
kind
of
split
up
the
document
yeah.
So
there's
like
the
developer
guide,
the
contributor
and
tutorials,
so
yeah,
just
going
down
that
path
and
still
making
sure
the
documentation
has
kind
of
like
a
table
of
contents,
almost
like
a
flow
and
a
guided
path.
If
you
will.
A
Content
by
by
audience
right,
so
it's
you,
you
noted
there
are
specific
audiences
for
for
different
things.
Right
there
are.
There
are
people
who
are
not
the
least
bit
interested
in
creating
a
specific
plug-in,
but
they
rather
need
to
get
their
pipeline
tasks
complete,
and
so,
oh,
no,
I'm
creating
a
new
plug-in.
I
need
this
and
they're.
Those
are
different
layers,
yeah,
good
insight.
Thank
you.