►
From YouTube: 2023 04 13 Docs Office Hours
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
Okay,
welcome
to
Jenkins
documentation
office
hours
today
is
April
13th
2023..
This
is
the
EU
and
U.S
Edition.
Today
we
have
myself
Mark,
Waite
and
Alexander
Brandeis.
Thank
you
for
joining
us
today
on
the
agenda.
A
We
have
a
jenkins.io
topic
that
Alex
will
share
with
us
a
few
blog
posts
to
highlight
that
have
been
published
in
the
last
week
or
two
Google
summer
of
code
update
some
recent
blog
layout
improvements
that
were
submitted
by
Jan
firecheck
image,
contributing
guidelines
that
have
been
added
recently
and
in
addition
to
that,
some
new
documentation
guidelines
I've
submitted
for
consideration
a
couple.
One
poll
request
to
discuss
something
that
we've
been
working
on
and
could
just
love
to
have
some
Community
discussion
on
alternative
options
to
handle
stale
pull
requests.
A
If
that
becomes
a
something
that
we
want
to
talk
about,
the
end
of
life
notifications
in
Jenkins
core-
and
this
is
something
that
Mark's
got
a
concept
for,
that
we
can
discuss
and
talk
through
and
the
improved
CI
process
for
jenkins.io
that
Airway
has
merged
and
saved
a
bunch
of
space
and
time.
For
so
we'll
talk
about
that.
Reducing
the
number
of
open
pull
requests
in
general
and
the
early
end
of
life
for
Centos
7
in
the
Jenkins
project,
provided
we
have
and
I
found
to
get
to
that
point.
A
B
B
Basically
what
I'm
going
about
over
the
past
few
months,
I
proposed
over
90
pull
requests
that
have
which
have
already
been
merged
and
I'm,
pretty
surprised
by
that
and
have
also
reviewed
over
155
pull
requests
just
in
the
Jenkins
that
I
or
Repository,
and
the
contributing
file
says
that
the
decision
of
adding
more
people
to
the
team
is
up
to
the
documentation
officer
and
Kevin.
That's
why
I
would
like
to
ask
you
if
you
are
fine
with
me
joining
the
copy
editors
team
to
continue
my
doing
on
a
more
official
area?
B
C
B
D
C
D
A
Yeah
and
I'm
absolutely
inclined
to
just
say:
yes
automatically
I,
don't
think
there's
any
doubt
or
question
in
my
mind
and
I,
don't
think
Mark
has
any
either,
but
no
that's
awesome.
Alex.
Thank
you
so
much
for
bringing
that
up
asking.
Obviously
you
have
more
than
enough
permissions
and
you're
part
of
the
governance
board,
so
it's
yeah
making
sure
that
that's
at
least
formalized
and
put
clearly
would
be
nice
just
for
visual
sake,
but
yeah.
A
No
thank
you
and
thank
you
so
much
for
all
of
your
work
and
contributions,
reviews
everything.
A
Just
since
I
started
last
year
with
Jenkins
in
the
community
I
you're,
one
of
the
names
that's
come
up
at
infinite,
so
I
yeah.
Just
thank
you
for
everything.
So.
D
A
Every
once
in
a
while
I
try
but
noted
cool
anything
else
on
that
Alex
or
is
that
that's.
C
Objections
if
yeah
approval
question
mark
okay,.
A
Mark,
thank
you
very
much.
Mark
yep
I
just
got
it
perfect.
Awesome!
Well
great
news
to
start
the
meeting
off
with
well
now,
I'm
really
excited
so
next
up,
just
a
few
blog
posts
that
we've
recently
sorry
I'm.
D
In
a
cheat
Now
Kevin,
because
we've
got
Alex
here,
I
want
to
shift
the
agenda.
I
propose
we
shift
the
agenda
around
and
bring
up
some
specific
topics
that
you
and
I
have
talked
about,
but
Alex
I'd,
like
Alex's
feedback
on
so
the
alternate
ways
to
handle
stale
pull
requests
and
the
end
of
life.
Notifications
are
two
topics:
Alex,
where
I
wanted
your
feedback.
D
D
D
All
right,
good,
okay,
so
first
first
idea,
Alex
was
we've
got
a
long
list
of
pull
requests
in
the
jenkins.io
repositories.
One
of
them
is
all
the
way
back
from
2019..
The
content
is
actually
still
useful,
but
none
of
us
have
had
the
time
to
go
in
and
correct
the
errors
that
are
in
the
content,
and
it's
be
it's
beginning
to
become
distracting
that
we've
got
content
there,
that
we
just
don't
have
time
to
work
and
there's
no
way
to
flag
to
others
that
they
might
take
it
to
work
on
it.
D
So
what
what
Kevin
and
I
were
discussing
was
a
possible
rule
where
we
say
hey.
If
the
content
of
the
stale
pull
request
is
not
valuable,
just
close,
it
right
junk
pull
requests.
We
just
closed.
That's
easy.
If
it
is
valuable
but
needs
more
work
than
we're
ready
to
do
over
the
next
say
a
few
months,
then
we
create
an
issue
to
track
that
content.
B
Is
the
least
acceptable
and
most
hostile
way
to
close
issues
and
pull
requests
given
you're,
basically
feeding
the
user,
with
a
copy
paste
answer
and
getting
ahead
hey?
This
has
been
inactive
for
30,
60
90
days
and
so
on.
We
will
close
it
and
that's
it,
but
we
don't
need
to
say,
but
for
that
can
also
do
this
by
hand
and
it
has
the
basically
same
bad
effect
but
yeah.
In
the
meantime,
I
opened
the
pull
request
on
jenkins.io
and
just
to
get
myself
into
the
scope.
Real,
quick
and
I
see
on
the
second
page.
B
Basically,
I
think
you
can
face
a
similar
problem
in
many
open
source
projects
size
of
Jenkins.
If
you
go
through
the
larger
latest
pages
of
issues
and
stuff
like
that,
how
to
address
those
things
in
core,
we
have
a
label
called
stalled.
If
I
remember
correctly,
which
bezel
introduced
or
I
don't
know
at
least
bezel
used
it
a
lot
to
Mark
pull
requests
where
the
author
is
inactive,
unresponsive
or
didn't
address
the
feedback
proposed
in
a
timely
manner
like
let's
say
one
or
two
months,
and
they
basically
didn't
do
anything.
B
So
we
put
the
label
on
it
and
the
deadly
basically
means
the
pull.
Requests
needs
some
work,
but
we
allow
others
to
take
over
like
Cherry
Picked
the
commitment
to
their
branch
and
fix
it
up,
make
a
new
pull
request
and
say
hey.
This
is
a
progress
for
that
and
therefore
request
supersedes
the
other
one.
Please
review
it
contains
the
review
feedback
and
so
on,
followed
on
the
state
followed.
On
the
start
level,
we
have
the
proposed
foreclosed
label,
which
we
don't
use
that
much,
but
the
point
of
that
is
to
basically.
B
Ahead
yeah:
this
is
what
we
have
in
core
I,
don't
know
if
that
is
applicable
to
jenkins.io,
given
the
majority
of
contributions.
Aren't
that
much
technical
rather
than
text
file
or
documentation.
So
you
don't
need
to
have
tests
or
something
like
that
to
cover
that,
so
it
will
probably
make
sense
to
I.
Don't
know,
have
a
label
that
says
possibly
or
just
put
the
pull
requests
in
a
draft
State
and
say:
hey
I'm,
working
on
that.
B
Please
don't
review
that
and
I
will
get
back
to
it
at
a
later
point
or
if
a
review
reviewer
says
this,
pull
requests
need
some
work.
Please
address
this,
and
this
and
this
or
at
least
providing
a
compelling
list
of
feedback.
The
submit
I
can
go
off
instead
of
saying:
hey,
I,
don't
like
this
or
hey.
This
is
a
bad
practice
without
providing
any
details.
D
So
I
I,
like
the
you,
you
indicated
one
more
thing
that
we
could
use
for
State
transition,
which
is
draft
or
non-draft.
So
so
that's
a
one
I
hadn't
considered
so
the
now
the
so
I
think
the
okay.
The
inactive
submitter
is
the
is
the
most
common
case
for
the
old
pull
requests
on
jenkins.io
and
and
then
I'm
confident
they're
not
coming
back
right.
They
submitted
it
long
ago.
D
It's
it
was
submitted
as
part
of
hacktoberfest
or
as
part
of
some
other
event
and
they're
they're
they've
not
been
involved
in
the
Jenkins
project
for
a
very
long
time,
so
with
inactive
submitter,
the
stalled
label
would
be
an
easy
one.
To
tell
me:
oh
I've
got
an
inactive
submitter
and
then
proposed
for
close
could
also
be
used.
Although
I
worry
there,
we
lose
the
fact
that
or
it
by
closing
it,
it
becomes
completely
invisible
right.
It
no
longer
is
visible
to
anyone
that
they
could
include
it
as
content.
D
B
B
Oh
go
ahead,
I
mean
we
don't
need
to
accept
every
contribution,
because
not
everything
fits
into
our
stance
of
jenkins.io
in
that
case,
so
proposed
for
close,
isn't
just
for
stock
for
requests,
but
it's
a
good
start
but
needs
a
bit
of
fun
tuning
here
and
there
to
bring
on
stage
and
say
hey.
This
is
good.
B
We
can
approve
and
merge
this
allowing
others
to
take
it
to
take
over
in
case
the
submitter
is
not
responding
or
doesn't
want
to
address
the
feedback
in
a
timely
manner,
because
there's
no
real
benefit
in
keeping
a
pull
request
open
for
six
months
and
continuously
taking
the
submitter
asking
hey.
Can
you
fix
this?
If
they
don't
want
to,
we
can't
force
them
to
do
that.
So
right,
yeah.
A
And
I
actually
I
like
the
style
label.
A
lot
I
did
check
jenkins.io
that
does
have
the
install
label
in
the
repo,
so
it
can
be
used.
We
have
it's
in
place,
which
is
great
and
I
I.
Like
all
of
what
you
said,
Alex
a
lot
I
think
that's
a
really
good
way
to
handle
all
these
without
closing
them,
and
you
know,
locking
someone
out
from
that.
A
A
Maybe
taking
some
of
the
older
pull
requests
that
are
worth
it
and
have
value
and
putting
that
into
a
new
issue
could
be
a
way
to
get
eyes
on
it,
while
still
holding
on
to
that
information
and
data,
but
also
kind
of
respecting
the
idea
that,
if
someone's
not
going
to
work
on
it,
someone
else
could
or
something
like
that
along
those
lines.
A
Just
in
an
effort
to
keep
it
still.
You
know
alive,
obviously,.
B
Yeah,
that
sounds
like
an
interesting
approach.
We
could
try
it
out
like
create
an
issue
based
on
a
pull
request,
go
and
go
the
reverse
order
and
say
we
have
that
so
I'm
going
to
contributed
that,
but
this
is
incomplete
because
it
lacks
a
b
c
and
d.
If
someone
is
interested
in
contributing
that
please
go
ahead,
Be
Our
Guest,
you
could
see
how
it
works,
especially
during
Oktoberfest.
B
A
D
D
Very
good
thanks,
so
that
was
all
that
I
had
to
discuss
on
alternate
ways
to
handle
stale
pull
requests.
I.
Think
the
action
item
is
I'm,
going
to
I'm
going
to
apply
stalled
labels
to
a
number
of
the
ones
that
I
know
are
stalled
first
test
and
and
we'll
watch
and
see,
and
then
we
can
consider
in
future
sessions
should
we
assign
some
of
those
the
hacktoberfest
label.
The
stalled
label
is
easy
right.
It's
clear
for
me:
I
know
which
ones
are
stalled:
great.
Okay,
so
Kevin
are
you?
Okay?
D
If
we
go
to
the
next
topic,
absolutely
Mark,
all
right,
so
Alex
this
one
is
one
where
it's
more
of
a
software,
slash
user
experience,
design
question
than
anything,
so
we've
got
a
general
purpose
challenge.
D
Centos
7
is
end
of
life
in
June
of
2024
Alpine
3.14
is
end
of
life
in
April.
Ubuntu
18
is
end
of
life
in
end
of
May
Etc.
There
are
these
different
things.
Some
of
our
containers
need
to
be
end
of
life,
and
so
we've
got
a
notion
that
I
would
love
to
not
just
have
blog
posts
as
the
only
way
to
inform
people
that
something
is
end
of
life.
D
I'd,
like
an
administrative
monitor
that
says,
we've
detected
that
your
end
of
life
on
something
that's
important
to
the
Jenkins
project
in
your
environment,
the
ideas
so,
for
instance,
we
detect
inside
Jenkins
you're
running
on
Centos
7.,
and
it
will
be
end
of
life
at
this
date
or
you
Ubuntu
18.
It
will
be
end
of
life,
May,
31,
2023,
we're
warning
you
now
that
the
Jenkins
project
does
not
support
Jenkins
running
on
operating
systems
that
the
vendor
does
not
support.
D
So
the
the
concept
was.
We
need
a
way
of
detecting
that
we're
on
that
thing,
and
then
we
need
a
way
of
saying
here's.
The
message
we
should
display
before
the
end
of
life
and
here's
the
message
we
should
display
after
the
end
of
life
and
the
thought
I
had-
was
this
notion
of
a
general
purpose:
admin
monitor
that
is
fed
by
data
files
in
a
directory
in
Jenkins
home
those
data
files
are
delivered
by
the
Jenkins,
install
process
and
or
yeah.
D
Maybe
their
resources
built
into
the
War
I
guess
they
have
to
be
resources
built
into
the
war,
don't
they
but
one
way
other
day
they
come
with
Jenkins.
That
say
here
are
some
various
end-of-life
things
that
we
need
to
do
where
if
we
find
the
file
on
the
system,
Etc
OS
release-
and
it
has
the
contents
that
match
Ubuntu
18,
we
know
this
admin
monitor
should
be
displayed.
B
Yeah
that
sounds
similar
to
our
approach
that
we
used
when
we
want
users
about
our
transition
from
java
8
to
11.
We
also
use
the
administrative
monitor
there
alongside
other
communication
channels,
of
course,
but
it's
definitely
an
interesting
and
to
me
right
approach
to
also
display
that
forces
admins
right
into
Jenkins
itself
to
say:
hey.
B
This
OS
is
going
to
be
end
of
life
then,
but
the
Jenkins
project
supports
it
until
then,
so
they
can
plan
ahead
and
have
dates
that
can
actually
go
off
rather
than
following
a
blog
post
that
takes
place
likely
a
few
weeks
well
before
or
after
end
of
life.
So
this
is
not
really
optimal
to
plan
ahead,
but
yeah.
Like
you
mentioned,
we
have
various
os's
that
are
going
to
be
end
of
life
very
soon
in
Jenkins
and
very
soon
end
of
life
itself
and
I.
B
Think
an
administrative
monitor
would
definitely
be
beneficial
about
the
data
I
mean
if
they.
If
the
data
doesn't
change,
we
can
just
build
it
into
the
war
file
or
otherwise.
We
would
need
to
seek
a
way
to
keep
it
up
to
date,
but
I,
don't
think
that
would
be
a
concern
because
I
don't
know
unless
you
thought,
unless
you
thought
about
shifting
support
dates.
D
I
I
do,
and
you
you
just
described
something
I
had
not
considered
I
hadn't
thought
about
the
scenario
we
had
with
Java
the
Java
8
to
Java
11
transition,
where
we
actually
adjusted
the
dates.
We
adjust
the
dates
after
initial
publication
and
so
that
that's
a
good
good
question.
My
initial
thought
is
I.
Don't
want
to
have
create
a
service
that
provides
updates
to
these
to
these
definitions,
but
you
may
have
highlighted.
We
really
need
to
think
about
such
a
service
at
a
minimum
in
the
Jenkins
enhancement
proposal
that
I
want
to
do
for
this.
D
B
D
B
D
Well-
and
it's
it's
a
it's
a
valid
okay,
so
so
some
some
things
that
are
involved
there,
then
I
had
originally
envisioned
it
being
multiple
files
in
a
directory.
But
realistically
because
it's
bundled
inside
the
war
file,
it
doesn't
have
to
be
multiple
files.
It
could
be
a
single
single
collection
of
data
because
it's
specific
to
the
verse
Jenkins
version
We
ship
right.
We
at
the
time
we
shipped
that
Jenkins
release.
We
knew
these
things
the
next
release.
We
may
know
more
things.
D
D
C
D
A
You
so
much
great
okay.
In
that
case,
let's
keep
moving
blog
posts,
so
we
did
just
publish
the
March
newsletter.
So
all
the
lovely
updates
from
mark
from
the
various
Sig
leaders
are
nice
and
condensing
here
again
always
want
to
thank
Roxanne
from
CDF
for
the
image,
headers
really
lovely
and
help
bring
a
little
bit
more
personality
to
it.
Another
blog
post
that
we
recently
published
is
regarding
digitalocean
and
there's
continued
sponsorship
of
Jenkins.
A
They
have
graciously
extended
to
us
an
additional
8
400
credit
for
the
next
six
months.
We
had
some
heavy
usage
in
March
that
was
unexpected
and
relied
on
due
to
some
other
issues.
A
We
were
fixing
but
digitalocean
came
through
and
just
showed
us
that
they're
here
for
us
and
gave
us
the
credit
to
help
get
us
through
the
next
six
months
and
that'll
get
us
to
roughly
about
the
year
Mark
for
our
latest
sponsorship
with
them
so
nice
time
to
talk
about
it
and
just
something
that
we
want
to
share
our
unending,
thanks
for
from
digitalocean,
truly
just
amazing
and
super
helpful
in
making
sure
we
can
dedicate
our
resources
accordingly,.
A
The
next
one
is
that
so
Bruno,
who
usually
is
here
with
us,
he's
currently
at
devox
France,
giving
some
awesome
talks
and
information
out,
but
he
has
a
second
post
about
building
Android
apps
with
Jenkins,
so
this
was
just
published
last
week.
If
you
want
more
information
about
the
relationship
between
Jenkins
and
Android
apps
great
place
to
start
and
Bruno
will
be
continuing
this.
A
This
series,
as
we
go
on
so
more
to
come
on
that
and
then
the
last
post
I
wanted
to
highlight
today,
is
that
I
just
posted
this
today,
it's
about
Jenkins
at
cdcon
and
get
opscom
this
year,
so
cdcon
is
happening.
May,
8th
and
9th
Mark's
actually
going
to
be
there
taking
part
in
the
graduated
projects
keynote
panel,
so
exciting
representation.
There.
A
Awesome
That's,
so
exciting
and
I
know.
Gavin
might
be
there
too
at
some
point,
so
just
really
exciting
glad
to
have
everyone
participating.
That's
gonna
be
a
really
good
time
and
we'll
be
announcing
the
Jenkins
Awards
winners
there
as
well.
So
if
you're
gonna
be
there,
you
may
win
something.
You
never
know,
but
just
again
super
appreciate
it's
continuous
delivery
foundation
for
providing
this
and
sharing
this
and
signaling
that
how
much
excitement
there
is
for
this
year,
a
quick
update
for
Google
Center
of
code.
A
So
in
total
we
got
about
55
valid
proposals,
which
is
far
more
than
we've
gotten
recently,
which
is
great
to
hear
that
just
means
a
lot
more
review,
work
for
our
mentors
and
org
leaders,
so
they've
been
hard
at
work.
Reviewing
and
Grading
every
proposal.
That's
come
through
they're
still
working,
but
thank
you
to
all
of
the
folks
that
are
helping
with
that.
A
The
recently
we
had
a
pull
request
submitted
by
Jan
varchek
about
improving
the
blog
layout.
This
is
now
live.
We
got
some
really
good
feedback
from
Community
around
this,
but
instead
of
having
it
listed
down
in
the
page,
we've
now
got
these
nice
little
cards
and
blurbs
and
highlights
showing
the
authors
the
publication
date,
just
a
nicer
look
overall
to
the
Jake
and
the
blog.
There
are
some
things
that
we
have
to.
A
You
know
look
into
and
address
at
some
point
background
color
versus
the
actual
background
for
the
page,
making
these
a
bit
more
uniform
things
like
that.
But
ultimately
this
is
a
really
great
facelift
for
the
Jenkins
blog
and
additionally,
the
Jenkins
dashboard
or
the
Jenkins
homepage,
because
it's
present
here
as
well
so
just
across
the
board
nice
little
updates
and
quality
of
life
improvements
overall,
thanks
to
Jan
for
again
contributing
all
this
and
working
on.
A
This
really
appreciate
that
as
well
and
yeah,
the
image
contributing
guidelines
I
submitted
those
last
week
they
have
been
merged
now,
so
we
got
I
got
some
good
feedback
from
Alex
and
other
members
of
the
community.
Alex
has
actually
gone
out
of
his
way
to
go
ahead
and
compress
400
images
I'm
still
working
my
way
through
that,
but
I
trust,
stuff.
Yeah,
it's
just
a
matter
of
making
sure
everything
looks:
okay,
yeah
that.
D
A
Fantastic
right
now
and
yeah,
it
saves
about
37
megabytes
on
the
page,
great
amazing,
more
space
we
saved
better.
Thank
you
Alex
for
that.
Even
if
it's
something
you
descriptive,
that's
that's
still.
Some
that's
a
lot
of
work
either
way
so
and
then,
just
today,
I
submitted
some
documentation
guidelines.
This
includes
some
just
general
practices
that
I've
been
working
on
and
developing
myself,
as
well
as
things
that
my
fellow
documentation,
writers,
are
sharing
and
I
wanted
to
make
sure
I
included
the
inclusive,
naming
aspect
in
the
guidelines.
A
That
is
something
that
we've
been
working
on
for
quite
some
time
now.
We've
had
several
projects
in
for
that
through
she,
code,
Africa
and
various
other
areas,
there's
still
some
places
that
could
exist,
but
we
want
to
make
sure
that
we're
not
adding
more
to
that
and
that
we're
using
the
updated
naming
so
things
to
consider
I
know
and
thank
you
to
Chris
Stern
for
reviewing
and
sharing
some
feedback
on
that
already
I
did
see.
A
He
added
some
information
there,
as
well,
so
I'm
going
to
be
reviewing
and
going
forward
with
that
as
well.
Now
we
are
at
time.
So
if
there's
anything,
anyone
wanted
to
discuss
further
on
these
last
few
topics
between
there's
one
pull
request
that
we
could
look
at
and
a
couple
other
smaller
notes,
but
I
want
to
be
respectful
of
everyone's
day.
Is
there
anything
that
wants
to
be
called
out.
A
Nope,
okay,
so
in
that
case,
we'll
table
these
three
for
the
next
time
and
continue
our
discussions
at
that.
In
the
meantime,
I'll
also
go
ahead
and
stop
the
video
here.
The
recording
will
be
available
in
about
24
to
48
hours
and
as
always,
thank
you
for
joining
and
really
great
to
see.
Everyone
take
care
and
have
a
great
weekend.