►
From YouTube: Jenkins UX SIG Meeting 22 Jun 2022
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
Welcome
to
the
jenkins
user
experience
special
interest
group,
it's
the
22nd
of
june
2022
and
delighted
to
have
everyone
here.
Thanks
very
much
agenda
topics
that
I've
got
include
june
lts
code
coverage
improvements
prevented
but
presented
by
uli,
further
discussion
on
an
accessibility
assessment
and
actually
I'd
like
to
move
that
one
down,
because
I
think
that's
much
less
valuable
than
the
next
one
on
the
list.
A
Vodk's
commentary
on
some
specific
specific
pull
request
and
then
a
security
review
of
ui
related
prs
and
I've
got
this
accessibility
assessment
and
if
yon
joins
us
on
time,
we'll
look
to
discuss
further
ui
improvements.
Any
other
topics
that
need
to
be
on
our
agenda
today.
A
A
A
Thanks
to
kevin
martins
for
the
the
change
log
and
the
upgrade
guide,
and
thanks
to
basel
crowe
as
well
for
his
contributions
there,
there
are
a
number
of
changes
in
packaging
in
other
things
like
the
alpine
docker
image,
for
instance,
no
longer
includes
g
leipzig.
It's
really
shrunk
to
be
what
closer
to
what
you
expect
an
alpine
image
to
be
those
kinds
of
of
improvements,
really
positive.
B
B
I
think
this
will
be
a
little
bit.
Hopefully
our
script
will
follow
this
new.
A
Release
as
far
as
as
far
as
I
know,
it
does
follow
it.
So
so
when
we're
when
so,
what
uli
is
referring
to
is
when
setting
the
minimum
jenkins
version
that
is
required
by
a
plug-in.
A
Our
general
guidance
is,
please
use
the
tail
end
of
a
preceding
lts,
so
the
basically
the
end
point
of
a
preceding
lts
release.
Usually
that's
a
dot
3
2,
319.3
2.303.3,
but
2.332
like
a
number
of
preceding
ones,
had
one
additional
release
in
it,
and
so,
when
choosing
a
minimum
jenkins
version,
use
the
final
release
of
that
lts
line,
and
so
in
this
case
it
would
be
dot.
Four
good
question
julie,
thank
you
and
as
far
and
so
let
me
put
myself
an
action
item
mark
to
check
that
the
the
version
page
has
been
updated.
C
A
So
right
right,
that's
tweet's,
not
the
last
one,
that's
the
main
message
right,
yeah
and
thankfully
we
haven't
the
mistakes
that
caused
us
to
do
the
dot.
Six.
All
that
time
ago,
were
mostly
mark
waite's
fault
and
so
mark
stopped
making
that
particular
class
of
mistake.
He
makes
other
mistakes
now
yeah
exactly
great
all
right
anything
else.
On
june
lts.
A
Okay
next
topic,
then
code
coverage
improvements,
julie,
you,
okay,
if
I
have
you
share
your
screen.
B
Sorry,
I
didn't
find
the
button
now
I
find
it
and
I
think
it
would
make
sense.
Is
it
okay
in
this
way,
do
you
see.
A
B
I
think
it's
a
little
bit
easier
for
me
when
I
see
it
here
and
me
on
the
same
page
so
yeah,
maybe
just
to
give
a
summary
of
the
work
we
had
in
the
previous
session
of
our
ui
for
uis
meeting
about
the
code
coverage
plugin,
a
student
of
our
university
started
to
refactor
the
code
and
add
a
new
feature
that
we
can
only
not
only
show
the
total
coverage
of
a
project
report,
but
we
now
can
also
see
a
delta
report
of
a
change
request.
B
That
means,
if
someone
is
changing
only
three
files,
or
so
we
can
now
look
at
the
coverage
of
the
of
these
three
files
only
and
visualize
the
results
which
are
actually
interesting.
So
I
don't
want
to
see
for
a
pull
request.
How
the
code
coverage
of
the
whole
project
changes.
It's
more
important,
I
think,
to
see
the
actual
code
coverage
the
committer
has
in
this
pull
request.
B
So
this
was
basically
the
background
of
the
work
we
added
in
the
code
coverage
plugin
and
to
facilitate
this
new
feature.
We
needed
to
grab
information
from
git,
so
we
are
using
the
git
forensics
plugin
to
look
at
a
pull
request
which
changes
we
had,
which
files
have
been
modified
and
we
merged
these
changes
with
the
coverage
information.
B
So
we
have
a
mapping
of
changed
files
and
your
code
coverage
that
actually
changed.
So
this
is
the
background
and
let's
see
it
on
the
screen,
and
what
we
now
have
is
a
new
code
coverage
report.
So
maybe
I
start
here
on
this
build
site,
so
we
have
typically
a
code
coverage
report
was
shown
by
a
trend
chart,
and
this
is
the
old
chart.
This
is
not
changed
yet
we
have
a
trend
chart
where
we
see
the
how
the
code
coverage
of
the
whole
project
changes
from
build
to
built.
B
Now
what
we
have
added
to
the
build
report
is
we
have
the
code
coverage
report
for
each
build
and
what
I've
highlighted
now
is
the
the
previous
information
that
we
see
the
project
coverage
in
one
project
and
typically
it
does
not
change
very
much
from
from
commit
to
commit,
because
if
you
have
a
lot
of
files
here
in
this
example,
I
have
a
code
coverage
of
90
and
the
next
commit
will
not
change
it
to
20.
This
is
not
possible.
B
B
B
For
instance,
here
we
have
what
I,
as
in
my
my
test
instance,
I
basically
built
all
my
releases
of
the
analysis
model
plug-in,
so
I
started
with
release
8,
then
it
released
9,
release,
10
and
so
on
and
every
release.
I
created
this
delta
coverage
and
compared
the
delta
coverage
to
the
results
of
the
previous
release,
and
and
if
we
look
here,
we
see
again,
okay,
the
code
coverage
actually
did
not
change
much
only
by
0.05,
it's
almost
nothing,
but
here
we
see.
Okay,
the
change
coverage
is
perfect.
B
We
have
a
line
coverage
of
100
and
a
branch
coverage
of
100
as
well,
and
we
have
nine
lines
changed
and
three
files
effect.
So
this
is
a
new
overview
where
we
have
where
we
now
better
see
the
results
for
pull
requests.
For
instance,
if
this
computation
is
not
only
available
for
pull
requests,
it's
also
available.
If
you're
just
building
one
build
on
the
master
branch
and
the
next
build
on
the
master
branch,
then
you
can
also
compare
the
differences
from
build
to
build
as
well.
B
A
And
is
there
is
there
source
code,
visualization
or
uli?
Are
you
okay
with
questions,
or
would
you
like
to
continue
questions
please
so
so
the
change
coverage
report
is
there
a
way
for
me
to
see
at
the
statement
level
which
statements
were
missed
in
the
change
cover?
Is
the
coverage?
Is
there
a
way
for
me
to
look
at
that
at
the
at
the
source
code
level,
yeah.
B
So,
let's
look
at
the
report.
This
was
the
wrong
button.
Sorry
I've
clicked
on
the
wrong
screen.
So
this
is
the
new
report.
The
details
report
and
the
details
report
has
been
rearranged.
I'm
now
using
some
taps,
because
there
is
a
lot
of
additional
information
I
needed
to
place
somewhere.
So
I'm
starting.
We
have
some
overview,
which
is
the
same
as
in
the
previous
release,
but
what
we
now
have
we
have
a
tab
for
the
file
coverage.
This
is
the
code
coverage
of
all
files
of
the
project.
B
This
is
similar
as
we
had
before.
The
only
thing
is
that
we
that
we
changed
visualization
that
we
have
now
these
yeah,
you
can
sort,
and
you
see
the
different
batches.
B
You
have
and
see
how
good
your
code
coverage
is,
and
if
you
look
at
the
change
coverage-
and
this
is
the
more
most
important
thing
I
mean-
then
you
can
see
when
you
look
here-
you
see
the
change
coverage
and
in
the
change
coverage
you
see
actually
only
three
files-
and
these
are
these
three
files
have
been
changed
and
you
can
now
look
at
the
individual
lines
of
these
changes
and
see
how
it
behaves.
B
So,
let's
see,
I
think
I
need
to
make
the
screen
a
little
bit
smaller.
The
problem
is
what
we
have
we
have.
Let's
start,
I
need
to
redrive
sorry,
one
more
okay,
because
one
problem
is:
where
do
we
show
the
source
code?
One
thing
is:
we
can
show
the
source
code
by
clicking
into
the
link
and
following
it
then
we
have
the
source
code
here,
and
this
currently
is
the
whole
source
code.
Where
you
see
yeah,
here's
everything
is
green.
B
Let's
see
if
I
can
make
it
a
little
bit,
I'm
not
sure
if
it
will
work.
Let
me
see
if
it
I
make
the
screen
a
little
bit
bigger,
but
I
think
it
will
not
work
now
we
have
it.
Okay,
normally
on
a
real
screen,
it
looks
a
little
bit
better
than
in
sumit
now,
but
what
we
also
have
is
that
we,
we
can
click
here
and
then
you
see
on
the
right
as
a
source
code.
B
This
does
not
work
on
a
laptop.
It's
just.
You
need
a
good
monitor,
but
then
you
see
only
the
change.
What
actually?
So
you
see
it's
just
one
line
that
has
been
modified
and
this
is
yeah.
I
think
a
more
interesting
view
for
pull
requests
that
you
are
not
interested
in.
Everything
was
what
is
already
here.
You
will
see
only
the
changes
which
we
have
in
this
full
request,
and
now
we
have
this
information.
We
grabbed
it
from
git
and
combine
it
with
the
code
coverage
information
from
kubatoora
or
from
chacoco.
A
B
I
wanted
to
release
it
this
weekend
because
I
need
some
time
for
potential
bug
reports
so
yeah
it's.
Basically
it's
ready
to
be
released
now
and
I
thought
to
release
it
today
in
the
morning,
but
then
I
thought
yeah.
I
have
no
time
to
fix
any
bugs
that
may
occur,
so
I
thought
it's
better
to
release
it
on
the
weekend,
where
I
have
some
more
time
to
fix
some
things
which
might
not
work
in
all
instances.
So.
A
Well,
and
if
the
security
team
doesn't
thank
you
for
not
releasing
it
today,
I
thank
you
for
not
releasing
it
today
as
a
jenkins
administrator,
who
has
to
update
his
jenkins
for
the
security
release,
I'm
delighted
not
to
also
have
major
features
arriving
in
a
plug-in
on
the
same
day.
Thank
you.
So
weekend
is
great
with
me.
B
Okay
done
it's
fine,
I
will
release
it,
I
think
on
the
weekend
and
then
everybody
can
look
at
it.
What
I
also
changed
is
we
have
this
this
chart
here,
where
we
see
the
line
coverage
information.
This
is
already
part
of
the
last
release.
What
we
now
also
have,
we
can
look
at
the
same
chart
if
we
look
only
at
the
branch
coverage
and
what
here
we
had
this
chart
as
well
for
the
delta
information,
but
for
the
data
information
it
did
not
make
much
sense,
because
we
only
have
three
or
four
files.
B
Yes,
for
instance,
here
we
have
only
58
percent,
and
here
we
have
83,
and
this
is
currently
not
customizable,
but
in
future
releases
we
can
add
a
customization
that
projects
which
have
not
so
good
coverage
can
reduce
this
information.
So
green
is
maybe
green
if
we
have
80,
for
instance,
but
this
is
not
yet
possible.
So
one
thing
after
the
others
and
yeah.
What's
also
not
ready,
is
you
can
click
here,
but
you
can't
see
the
source
code
now.
B
Yes,
it
will
be
available
in
the
pull
request
as
well.
Actually
I
I
did
not
test
it
yet
for
pull
requests,
but
for
pull
requests.
We
have
this
so
called
a
reference
build
and,
and
the
reference
build,
is
the
built
in
the
main
branch
where
we
have
the
information,
the
same
information
and
then
we
are
comparing
versus
this
reference
field
perfect.
Thank
you.
B
Maybe
one
thing
I
would
like
to
highlight
here
is
or
is
more
a
question.
A
Yeah
yeah,
so
that
the
ui,
I
think,
daniel
daniel's
comment
in
the
chat
hints
that
frames
frames
have
had
a
different
set
of
usability
problems.
We're
actually
looking
at
possibly
injecting
something
like
that
onto
jenkins.io
www.jenkins.io
as
a
way
to
help
the
navigation
there
for
large
pages.
But
it's
it's
a
complicated
problem.
Trying
to
get
those
left
hand
sides
the
sidebar
stable
to
hold
still
while
we
move
around
on
the
right
hand,
side.
B
C
Separated
no,
I
think
your
example
in
the
current
page
is
a
bit
particular
because
we
don't
expect
to
have
so
many
items
on
the
left
side.
Usually
it's
between
10
and
20
maximum.
In
your
case,
I
think
you
are
close
to
30.,
so
it's
also
perhaps
part
of
the
issue
there
that
it
was
not
really
expected
at
that
point.
B
And
it
depends
a
little
bit
if
I'm
showing
this
thing
on
my
laptop
screen
or,
if
I'm
showing
it
on
my
monitor
and
currently
I
can
say,
to
the
browser
or
to
javascript.
Please
fill
the
screen
for
this
box
here,
for
instance,
but
this
box,
the
screen,
means
it
go
to
here
to
the
at
the
footer,
and
that
is
not
really
the
screen
I
want
to
show
on
it
use
a
place
which
is
free
for
or
visit,
which
is
visible.
B
So
this
would
be
something
would
be
really
helpful
for
ui
design.
If
we
can
have
this
navigation
bar
even
typically,
if
the
navigation
is
too
big,
it
is
going
in
an
off-screen
navigation
where
you
can
select
or
deselect
it.
So
maybe
this
would
be.
Something
would
be
very
helpful
if
we
can
add
it
in
jenkins.
C
Idea,
no
just
to
to
fill
the
page.
There
are
some
ways
depending
of
what
you
are
doing
exactly
potentially
with
a
flexbox.
It
could
be
sufficient
or
perhaps
looking
at
the
else,
the
air,
the
sizing
vertical
of
the
panel.
It
could
be
interesting.
Perhaps
if
you
are
trying
with
vh
equal
one
things
like
this,
meaning
it's
equal
to
the
full
size
that
is
available
for
the
screen.
There
could
be
some
ways
to
do
like
this,
not.
B
And
maybe
another
thing
what
we
implemented
is
now
we
have
some
responsive
design
for
the
tables
as
well.
That
means
the
content
of
the
tables
it
changes
if
your
screen
is
going
smaller.
So
if
I
go
smaller,
then
yeah,
okay,
it's
then
the
package
will
disappear,
so
it
depends.
This
is,
I
think,
very
helpful.
B
B
B
A
Well,
and
I'm
I'm
wondering
if
we
need
to
use
what
you're
doing
in
the
google
summer
of
code
project
for
automatic,
get
cash
maintenance
in
terms
of
presenting
its
results,
because
there
may
be
lots
of
there
may
be
many
things
we
want
to
show
some
of
the
much
less
important
than
others.
Thank
you.
This
is
good
to
know
that
the
capabilities
there.
B
A
A
So
next
topic
was
vadak,
two
two
items
related
to
security,
but
is
there
anything
that
you
would
like
to
share
your
screen
with
it
or
do
you
want
me
to
just
keep
the
notes
up?
How
would
you,
how
would
you
prefer,
if
you.
C
C
And
there
is
another
parallel
effort
done
by
the
submitting
your
people.
That
is
overriding
a
bit
of
effort
from
the
others,
not
necessarily
it
was
the
wilt
or
the
override
or
effort
from
the
others,
but
it's
more
that
for
the
contributor
at
the
end,
it's
like.
Oh
thank
you
for
your
job,
but
we
are
doing
something
else
in
the
meantime,
so
your
code
is
no
longer
very
valuable
for
us.
That's
this
kind
of
thing
that
is
a
bit
annoying
to
see
there.
C
I'm
not
saying
it's
something
to
someone
to
blame
or
things
like
that,
not
at
all.
It's
really
is
it
something
that
we
want
to
do
or
not
like
in
this
case,
that
person
perhaps
could
be
interested
to
join
the
sick
meeting
to
discuss
to
show
his
request
or
have
other
people
working
with
him
instead
of
doing
their
own
job
on
the
other
side.
So
that's
more
to
open
the
discussion.
C
A
C
No,
that's
that
you
can
look
at
the
one
of
the
last
comments.
It's
mainly
yeah.
In
the
meantime,
we
have
done
something
that
will
make
your
request
no
longer
valuable.
So
that's
this
kind
of
thing.
We
have
seen
that
also
with
tooltip
someone
proposed
to
have
some
tooltip
using
the
direct,
the
title
or
the
tooltip
inside
an
attribute,
and
that
was
mainly
rewritten
in
a
different
pull
request
by
using
type
gs.
A
Thank
you
so
so
here
I
think
alexander
brandes
was
suggesting
hey
it's
it's
a
bad
pattern
to
have
something:
a
relatively
small
change:
diff
diff
content,
wise
on
on
unevaluated
for
a
year
and
basel
notes.
Then
there
are
some
additional
challenges
in
this
particular
one
if
it
if
it
actually
applies
still
or
not.
So
there's
certainly
more
to
be
done
here.
A
Good-
and
so
I
assume
we
may
want
to
bring
this
topic
again
in
future
meetings,
just
as
a
reminder,
or
do
we
systematically
want
to
look
at
pending,
pull
requests
on
ui?
Maybe
we
should
be
labeling
the
pull
requests
for
ui
and
and
remind
ourselves
in
this
meeting,
hey,
which
ones
are
our
pending
review
and
we
could
use
people
looking
at
them.
C
A
Yeah,
so
I
I
think
now
that
means
I've
got
to
take
some
some
initiative
and
and
look
at
the
pull
requests
and
identify
which
ones
which
ones
are
ui
and
possibly
tag
them,
but
I
think
I
think
that
would
be
a
good
thing
to
to
add
to
this
meeting
agenda.
Just
I
know
it's.
It's
turned
really
positive
in
the
doc
sig,
when
we've
done
that
a
little
embarrassing
in
that
we
look
at
some
really
really
old,
pull
requests,
but
we're
actually
closing
them
by
looking
at
them.
A
A
All
right
anything
else
on
the
the
long
or
on
let's
see
there
was
a
phrase
that
basel
used.
It
was
long
long-lived
pull
requests
that
oh
stalled.
There
you
go
anything
else:
unstalled
pull
requests.
C
So
the
next
one
is
a
bit
less
fpa,
we'll
see
you
have
privacy
we
have
released,
especially
thank
you,
daniel,
for
that
a
new
version,
new
security
version.
Today,
as
I
mentioned
before,
in
that
version,
we
are
correcting
five
vulnerabilities
that
were
recently
introduced
in
jenkins
core,
I
will
say
mainly
I'm
not
totally
sure,
but
mainly
related
to
the
ui,
at
least
for
them
and
the
issue.
There
is
mainly
it's
very
rare
in
the
past
history
of
jenkins
that
we
have
seen
such
I
will
say.
A
newly
introduced
vulnerability.
C
Most
of
the
time
is
things
that
we
are
finding
from
the
past.
In
this
case,
it
was
things
that
were
recently
added
by
accident,
of
course,
but
it's
just
the
fact
that
it
was
a
bit
of
change
of
peace
in
terms
of
introduction
of
some
things.
That
was
a
bit
annoying
me
to
see.
We
had
to
work
on
that
very
quickly
in
urgency,
in
some
sense
to
prevent
that
or
to
stay
for
long
in
the
project.
C
So
that's
a
bit
painful
to
see
the
effort
that
is
needed
to
correct
them
after
the
request
is
merged,
compared
to
correcting
that
during
the
pro
request.
So
for
that,
I
would
like
to
block
all
the
ui
pull
requests
until
they
got
an
approval
from
the
security
team.
The
goal
is
not
to
block
them
forever,
do
not
review
them
and
just
to
block
the
process
at
all.
It's
not
at
all
the
goal.
The
goal
is
really
that
we
got
someone
from
security
to
review
the
request.
C
I
will
assign
people
more
resources
in
general
from
my
team
to
work
on
that,
to
put
the
effort
to
review
the
different
things,
especially
when
they
are
closed
of
your
merch.
I
will
say
so
that
we
are
reducing
the
likelihood
to
introduce
new
vulnerabilities.
That's
a
big
idea
there
and
I
wanted
to
discuss
that
with
you.
What
do
you
think?
Is
it
something
that
you
think
would
be
too
annoying?
What
could
be
the
counterpart
or
any
thought
about
that
aspect?.
A
So
for
me
so
long
as
security
team
members
are
assigned
and
have
the
capacity
to
do
it,
I
think
it's
great
the
danger,
the
the
danger
that
worries
me
about
those
is
about
that
is,
if
they
don't
have
time
to
do
it,
then
it's
just
a
block
on
the
pull
request
without
any
without
any
progress,
but
if
you're
assigning
people,
I
think
that's
that's
significant
positive,
because
that
means
more
people
are
reviewing
the
pull
requests
in
general,
not
just
for
for
security.
So
I
I
think
that's
great.
C
That's
really
the
goal
if
at
some
point
we
are
no
longer
able
to
provide
the
resources,
it's
mainly
go
with
photos.
In
essence,
I
don't
want
to
block
the
improvements.
The
different
ui
revamp
if
evolution
and
jenkins
are
very
nice
very
great
for
the
community.
It's
really
not
the
goal
to
kill
this
kind
of
effort,
it's
just
to
be
there
to
prevent
the
vulnerability
to
be
introduced
at
that
point
and
most
of
the
time
it's
because
of
a
single
line
that
is
not
written
in
the
correct
way,
this
kind
of
thing.
C
C
The
side
effect,
interestingly,
there
is
that
we
will
have
more
people,
as
you
said,
on
the
request
to
review
the
stuff,
because
I
don't
expect
the
security
people
who
are
doing
the
review
to
just
look
at
the
code.
I
expect
them
to
play
with
the
pull
requests
to
try
with
payload
everywhere,
like
you
can
imagine,
with
security
people
with
xss
payload
everywhere
in
the
screen
to
see
if
something
is
triggered.
So
it's
also
a
way
to
see
if
there
are
some
regression
and
things
like
that.
B
I
think
if
we
have
the
resources,
it
is
really
good,
but
currently
we
have
a
lot
of
ui
changes,
so
maybe
this
is
also
the
problem
that
we
have
so
many
bugs,
because
we
have
a
lot
of
new
things
which
appear
and
the
last
10
years,
and
actually
nothing
happened
on
jenkins
ui.
So
I
don't
think
this
is
a
problem.
This
is
just
a
lot
of
changes
cause
a
lot
of
problems.
C
B
C
Fine
yeah,
sorry!
So
if
there
is
no
objection,
this
kind
of
thing
I
will
send
an
email
but
a
message
in.
C
For
the
developer
of
jenkins,
to
mention
that
new
policy,
in
a
sense
with
the
blockage
of
the
different
pull
requests
related
to
the
ui,
so
the
point
you
mentioned
mark
before
concerning
the
level
the
target
about
the
ui
will
be
more
important
as
well
and
also,
I
think,
basil
created
a
label,
especially
for
a
security
review.
Something
like
this.
C
C
C
And,
of
course,
you
will
be
revised
over
time
if
we
are
seeing
a
huge
progress
in
term
of
quality
like
if
we
are
not
able
to
correct
anything,
because
there
is
nothing
wrong
in
terms
of
security.
We
will
reduce
this
kind
of
requirement
policy
in
the
mid
long
term,
the
sooner
the
better.
I
will
say
from
my
point
of
view
to
prevent
the
resources
to
be
spent
there,
but
that's
really
for
the
ears
of
the
project
teams.
B
C
I
will
say
thank
you
very
much
for
the
question,
but
at
the
same
time
no
thank
you.
It's
a
problem
in
jenkins,
in
the
sense
that
we
are
not
using
regular
view
templating
with
jelly
it's
particular.
So
we
are
not
able
to
find
this
kind
of
thing
very
quickly.
We
are
able
to
have
some
custom
roles
in
codesql,
for
example,
for
regular
java
code
to
find.
Oh,
you
are
lacking
this
kind
of
annotation.
C
You
are
lacking
this
kind
of
thing,
but
for
jelly
it's
a
lot
more
complicated,
especially
these
excesses
that
we
have
found
recently
were,
I
would
say,
complicated
to
find
just
by
looking
at
the
code,
it's
a
matter
of
things
that
are
not
escaped
or
escaped,
but
then
unescaped
by
some
javascript
that
is
then
passed
and
executed.
So
it's
really
a
multiple
step
effort
to
have
the
vulnerability
really
impacting
the
project.
C
So
that's
a
very
good
question.
We
are
asking
the
question
ourselves
what
we
could
do
to
prevent
this
kind
of
thing
to
be
introduced
and
I'm
getting
the
question
also
from
a
lot
of
other
people.
You
can
imagine
at
the
moment
we
do
not
have
a
good
solution,
it's
something
that
we
can
work
on,
trying
to
find
a
way,
especially
with
ql.
C
D
B
But
would
it
well,
I
think
it
would
be
at
least
helpful
if
these
five
problems
we
have
would
be
clarified
a
little
bit
on
the
mailing
list,
for
example
that
other
developers
would
see
what
actually
was
a
problem.
Currently,
I
only
see
we
have
some
vulnerabilities,
then
I
upgrade
my
jenkins
and
everything
is
fine,
but
what
for
me
as
a
developer
would
help
if
I
see
what
actually
was
the
problem,
what
should
I
avoid
in
my
code?
B
D
We
have
test
cases
so,
if
you're,
looking,
if
you're,
trying
to
understand
a
specific
vulnerability
that
we
addressed,
you
can
look
at
the
test
case,
testing
that
it
is
actually
fixed,
and
that
should
give
you
an
idea
of
what
not
to
do
some.
Some
of
them
are
kind
of
artificial,
necessarily
because
jenkins
is
a
framework
for
plugins
in
a
way,
and
so
it's
not
immediately
visible
in
all
cases
how
this
would
be
done,
but
one
example
is:
don't
build
an
html
string
that
includes
user
input
without
properly
escaping
that
user
input.
C
And
just
to
do
some
advertisement
as
well
for
csp,
so
content
security
policy,
it's
a
project
that
I
would
like
to
put
more
effort
in
waiting,
perhaps
for
october
fest
against
easier
to
have
other
contribution
there.
But
that
could
be
really
a
way
to
prevent
this
kind
of
xs
classes
in
general.
That
could
be
nice.
But,
as
daniel
said
it's
a
long
long
project.
A
What's
the
most
effective
way
to
contribute
to
the
community
and-
and
my
thought
was
should-
or
my
questions
were
things
like-
shall
we
one
get
it
translated
from
german
language
to
something
I
can
read
as
in
english
and
then
two
do
we
create
in
an
epic
in
jira
that
describes
these
things
with
individual
topics,
or
do
we
just
create
the
epic
and
wait
for
for
people
who
have
capacity
you
know?
Is
it?
Is
it
premature
to
create
a
bunch
of
issues
in
jira
for
accessibility
improvements?
A
Rather,
would
it
be
better
to
think
about
accessibility
in
some
different
way,
prioritize
differently,
etc?
This
is
where
I'm
I'm
looking
for
input
from
others
on,
what's
what's
most
effective
in
terms
of
how
we
interact
with
these
observations
about
accessibility
that
have
been
made
by
somebody
as
part
of
their
a
company
evaluation
of
jenkins.
C
A
Oh,
I
would
guess
it's
on
the
order
of
hundreds.
I
haven't
looked
at
the
report
specifically,
but
considering
what
these
these
kinds
of
assessments
usually
detect,
I
would
expect
it
to
be
on
the
order
of
hundreds,
probably
not
thousands
but
hundreds.
I
could
easily
see
where
hey
missing,
tab
navigation
for
this
or
doesn't
have
screen
reader
support
for
that
or
lacks
a
keyboard
shortcut
here.
That
could
help
the
user
in
this
way,
those
kinds
of
things
and-
and
they
they're
quite
frequent.
C
My
recommendation
will
be
to
mainly
get
some
tasks
more
as
a
spike
to
analyze
the
report
and
to
categorize
a
big
issue,
because,
for
example,
if
something
is
related
to
the
missing
alt
text
for
icon,
it's
something
that
could
be
done
at
once
in
the
jellytech
directly.
But
if
it's
about
the
tab,
navigation
that
will
require
revamp
of
different
pages,
that's
something
that
need
to
be
grouped
together
as
a
category
in
a
sub
epic.
This
kind
of
thing
that
could
easily
do
the
work
there.
A
Oh
good
point:
okay,
so
so
maybe
outline
it
as
stepwise
saying:
hey
first
step
is
we
need
to
review
and
assess
and
as
part
of
that,
review
and
assessment,
that
probably
involves
a
grouping
and
a
prioritization
and
possibly
a
partitioning
of
here's
here-
are
various
classes
of
of
interesting
things
that
this
report
gave
yeah.
Okay,
review
prioritize
summarize
the
areas
areas
impacted
areas.
C
A
Any
other
observations
or
recommendations
there.
My
specific
request
to
the
submitters
was:
I
don't
want
to
treat
their
their
work
with
disrespect
in
the
sense
of
putting
it
into
something
that
then
we
don't
get
the
benefit
out
of
it,
and
I
like
the
idea
of
review,
prioritize
and
summarize,
because
that's
giving
us
real
value.
B
Great
thank
you.
I
think
it
would
be
really
helpful
to
see
this
report
somewhere
publicly,
so
I
can
read
it,
for
instance,
because
I'm
interested
in
ui,
I
think
so.
I
think
we
had
such
a
report
about
usability
a
couple
of
years
ago.
It
was
also
in
german,
and
it
was
really
helpful
for
me
to
read
it
to
see
what
I'm
doing
wrong
in
my
plugins.
A
In
the
first
agreed-
and
I
think
I
think
that's
a
that's
already-
a
good
first
step,
just
attaching
it
and
using
that
jira
as
an
epic
gives
us
the
source
document
and
the
source
document
for
those
who
are
already
comfortable
in
german
language
is
already
good
enough
right.
That's
already
a
great
start,
and,
and
those
of
us
who
are
not
comfortable
in
german
language,
can
always
apply.
Google
translate
and
get
it
get
some
help
with
google
translate
to
generate
it
in
in
other
forms.
A
A
All
right
thanks,
everyone
recording
will
be
available
in
probably
24
hours
or
less
and
we'll
post
it.
Oh
daniel
asks
if
it's
deutsch
telecom,
I
don't
think
so,
but
I
don't
know
who
it
was
so
I
will
certainly
look
up
that
document
and
daniel.
I
think
I'm
going
to
put
a
link
to
that
document
into
these
notes,
thanks
very
much
because
that
way,
I've
got
a
reference
to
a
past
historical
document
see
previous
from
deutsche.