►
From YouTube: Jenkins UX SIG Meeting 1 Feb 2023
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
everyone:
this
is
the
Jenkins
user
experience
special
interest
group
meeting
it's
the
first
day
of
February
2023..
Thanks
for
attending
so
topics.
For
today
we
had
included
Security
reviews
for
ux
pull
requests;
Tim's,
probably
not
here
vodac.
Is
it
okay?
If
I
put
you
on
the
on
as
that
topic,
yeah
for
sure,
okay,
collecting,
General
feedback
on
UI
and
ux
regressions
was
a
topic
we
had
before.
A
What's
happened
recently
in
UI
improvements,
what's
coming
in
additional
ones
and
improving
keyboard
usability,
Christina
I'm
prone
to
move
this
one
Higher
on
the
list
to
be
sure
we
get
to
it.
If
that's
okay,
yeah.
A
C
D
I
had
a
topic
to
add
close
to
the
bottom
of
the
list,
which
is
deprecation
of
Jenkins
JS
Libs.
It's.
It
has
something
to
do
with
the
work
I've
been
doing
on
the
pipeline.
Groovy
plugin.
A
E
I'm
not
sure
if
that
makes
sense,
if
never
young
or
yeah
Tim.
A
Is
there,
but
we
will
see
and
and
I
think,
let's
if
you're,
okay
with
it,
let's
put
it,
keep
it
on
the
agenda
and
and
we
may
decide
to
defer
it
to
next
meeting-
that's
okay
as
well
great
all
right!
Let's
do
that
then,
and
I
don't
see
Kayla,
okay,
good,
all
right,
any
other
topics
that
need
to
be
on
the
agenda.
C
Yep,
that
was
a
good.
Thank
you
all
right.
So,
as
you
can
see,
there
are,
there
are
only
two
pull
requests
that
are
waiting
for
a
security
review.
Both
of
them
are
mainly
spelled
in
some
of
the
development,
so
we
are
not
reviewing
them
if
they
are
not
ready
to
be
reviewed
in
a
sense,
if
you
open
the
first
one,
it
will
be
especially
interesting
to
see
there
something
that
I
would
like
to
avoid
for
the
future
is
mainly
yeah.
C
It's
mainly
it
was
approved,
but
there
were
some
change
that
were
added
to
the
pull
request.
We
need
to
have
the
need
Security
review
level
to
be
bringing
back
at
that
point.
Otherwise
we
could
have
some
vulnerability
introduced
as
well.
At
the
bottom
of
the
page.
You
will
see
as
a
potential
feature
that
there
was
a
vulnerability
introduced
after
the
security
review.
A
C
A
Great,
thank
you
any
concerns
from
any
others
on
how
Security
reviews
are
progressing.
I
I,
like
the
suggestion,
the
recommendation
please
ask
again
for
Security
review.
I
assume
that's
what
you're
envisioning
there
is
that
the
the
plug-in
or
the
that
the
author
of
the
pull
request
should
put
the
need
Security
review
label
on
again
after
they've
made
significant
changes.
C
A
C
There
is
also
related
to
the
use
of
feature
flag
if
you
are
able
to
provide
a
feature
that
is
broken,
you
just
disable
the
flag
and
data
formation
could
be
collected
in
the
future
automatically
with
the
termitory,
so
that
we
know
if
a
feature
is
broken
for
some
people
or
not
looking
forward
to
have
the
true
requests
being
merged
into
a
play.
Some
perimeteria.
A
B
Not
this
meeting
so
a
bit
of
a
background
on
this,
so
we
know
that
we
have
a
few
accessibility
issues
to
resolve
on
CI
in
general,
some
of
them
originate
from
the
open
source
I
meet
tomorrow
with
Jake.
We
have
to
work
out
a
few
details
just
around
how
we
want
to
handle
pull
requests
from
the
community
and
work
out
our
process
there
before
I
start
I
want
to
get
that
sorted
before
I
start
to
create
tickets
and
bug
people.
B
None
of
the
changes
that
are
needed
are
heavy
lifts.
It's
all
front
end
facing
around
keyboard
accessibility,
mostly
for
this
round.
Anyways
and
I
can
certainly
provide
guidance
around
what's
needed,
so
there
will
be
tickets
coming
we're
working
out
our
own
process
around
that
right
now,
just
because
it
it
needs
to
kind
of
align
with
some
work
that
we're
going
to
do
internally
as
well,
so
they're
coming
plans
getting
put
in
place
and
then
I'll
create
tickets
for
for
the
open
source.
A
B
Yeah
we
have
a
laundry
list
of
requests
from
clients,
and
some
of
them
are
issues
that
are
more
pressing
than
others.
So
for
this
initial
round,
we're
really
looking
to
just
deal
with
the
kind
of
the
show
stopping
issues
where
say
a
user
who's
relying
on
accessible
Technologies
literally,
cannot
navigate
we're
looking
to
fix
those
first
and
then
we
can
work
through
the
kind
of
the
I.
Don't
want
to
call
them
nice
to
haves
they're.
All
you
know
we're
supposed
to
accommodate
them,
but
the
ones
that
aren't
quite
as.
A
A
E
A
A
Great
and
the
what's
coming
in
UI
improvements,
I
know
that
Jan
and
Tim
had
been
working
on
further
removal
steps
for
Yahoo
UI
and
that
there
are
some
things
in
Flight.
There
I
think
it's
a
good
lead
into
our
next
topic:
the
deprecation
of
the
JavaScript
libraries.
Unless
there
are
others
who
have
topics
they
want
to
discuss
on
what's
coming
in
UI.
A
D
Yeah-
and
it's
not
just
me
working
on
this-
it
started
back
a
couple
of
months
ago
when
the
pipeline
stage
view
plugin
was
updated
to
remove
its
dependency
on
handlebars
and
since
then
it's
also
been
updated
to
remove
its
dependency
on
moment,
Js
and
then
I've
also
yesterday
proposed
a
change
to.
B
D
The
ace
editor
from
pipeline
groovy-
these
were
the
last
three
big
dependencies
on
the
Jenkins
JS
Libs
plug-in,
which
just
dates
back
to
2015
and
has
not
really
been
maintained
since
then,
so
we've
been
deprecating.
D
D
D
The
less
likely
I
think
that
they
are
needed.
So
maybe
it
very
well
might
be
the
case
that
once
we
rip
out
AC
editor
from
pipeline,
groovy
I
think
that's
the
last
or
close
to
the
last
plugin.
That's
using
the
subsystem.
We
might
also
be
able
to
remove
the
bits
and
pieces
that
are
in
Jenkins
core
that
only
exist
to
support
this
framework
now
I'm
not
really
sure
one
way
or
another.
D
So
that's
why
I
wanted
to
bring
this
to
more
people's
attention
since
I,
don't
know
much
about
this,
but
I
think
there
I
think
there's
more
cleanup.
That
can
be
done,
and
this
has
some
security
impact,
because
these
libraries
are
all
pretty
old,
even
if
none
of
them
are
vulnerable
right
now
they
put
us
at
risk
for
future
vulnerabilities
just
because
of
their
age.
So
it
would
be
good
to
get
rid
of
these
little
bits
and
pieces
if
we
can
I
think
there's
also
still
a
plug-in.
D
That's
using
this
that
nobody
has
fixed
yet,
which
is
the
GitHub
one
of
the
GitHub
plugins
forget,
which
one
I
want
to
I.
Think
one
of
the
GitHub
plugins
is
still
using
one
of
these
Jenkins
JS
Libs
plugin
from
2015..
D
So
you
know
we
could
decide
if
we,
if
we
think
that
it's
important
enough
to
patch
or
if
we
could
leave
it
behind,
but
I
think
so.
There's
there's
still
more
cleanup.
We're
not
done
with
the
cleanup
work
is
what
I'm
saying
there's
still
plug-ins
left,
even
though
they're
obscure
that
are
that
are
using
this
stuff
and
then
there's
still
bits
and
pieces
in
core,
so
definitely
something
that
we'd
like
to
to
get
fully
deleted
so
that
we
don't
have
to
worry
about
it.
D
Just
a
rapper,
so
if
you're
doing
your
most
most
of
actually,
you
know
what
I
did
with
pipeline
groovy
was
it
already
had
its
own
webpack
build
so
I,
just
integrated
Ace
editor
into
that
and
in
general,
that's
essentially
an
equivalent
to
Jenkins
JS
Libs
is
stuff
like
these
modern
Technologies,
like
webpack
they're,
doing
the
same
thing
as
what
Jenkins
JS
Libs
was
doing
or
similar,
but
it's
just
that
these
are
now
standardized
industry-wide,
rather
than
something
that
our
project
developed
seven
years
ago.
That's
not
maintained
anymore
and.
D
Yeah,
there's
always
tax
yeah.
This
there's
more
cleanup
that
needs
to
be
done
here
so
that.
E
D
Definitely
looking
for
people
to
help
with
cleaning
up
some
of
the
long
tail
of
this.
You
know
I,
think
I.
Definitely
and
if
we
put
a
dent
in
the
problem
with
pipeline
groovy
plug-in
yesterday,
but
yeah
there's
still
more
left.
E
Because
if
I
remember
correctly,
when
I
started
to
use
some
Modern
Channel
scripting
libraries
in
my
plugins
I
I
found
these,
that
I
should
bundle
them
with
JS
lips
and
there
is
a
really
a
good
water
tutorial
and
I
think
we
should
remove
these
from
our
web
page.
So
nobody
will
find
them
anymore.
Yeah.
A
A
C
A
B
A
E
Yes,
okay,
good,
okay,
I,
think
what
I
want
to
show
is
that
recently
we
let's
go
to
the
make
this
a
little
bit
quicker,
so
I
think
Tim
and
young
proposed
some
kind
of
new
scheme
to
me
to
to
have
some
new
views
that
use
the
sidebar
on
the
left
here.
So
the
plugin
manager
now
has
a
separate
sidebar
with
updates
available,
plugins
installed,
plugins
and
so
on,
and
a
lot
of
let's
say,
manage.
E
Jenkins
views
are
using
this
new
scheme
and
this
scheme
is
having
a
new
sidebar
and
having
an
application
bar
where
you
have
some
buttons
to.
You
know
to
change
the
view
or
the
look
and
look
and
feel
and
I'm
wondering
if
this
concept
should
be
used
for
build
actions
as
well.
E
So,
let's
have
a
look
at
this
is
one
of
my
builds
from
yeah
from
one
of
my
plugins,
and
we
have
a
lot
of
summaries
here
in
this
screen
and
what
I
would
like
to
know
is
if,
if
I
am,
for
instance,
going
to
the
code
coverage
results,
typically,
you
have
a
few
which
shows
the
code
coverage
results,
and
this
is
just
an
experiment.
So
it's
not
really
ready
what
I've
a
normal.
Sorry,
let's
start
from
the
beginning.
E
Normally,
if
you
click
into
the
summary
of
a
build,
for
instance,
we
are
looking
at
the
test
results.
Normally
you
have
the
same
on
the
left.
You
have
still
the
your
old
application
or
the
side
panel
is
the
same
on
the
left,
so
I'm
wondering
if
I
should
change
that
in
the
same
way
as
we
have
done
that
on
the
plugin
manager.
E
So
when
I
click
mutation
coverage,
I
have
a
new
side
panel,
which
shows
only
the
details
of
my
view
so,
and
this
is
a
question
if
we
should
go
this
way
or
not
so
I'm
I
just
experimented
a
little
bit
with
it,
but
before
that
change,
I
have
Taps
here,
where
you
can
see
the
overview
you
can
have
the
line
coverage
and
so
on,
I'm
using
tabs
to
show
different
elements
of
my
view
and
now
I'm
wondering
if
I
should
rather
use
this
sidebar
to
show
these
results.
E
For
instance,
if
I
click
here
on
files,
then
I
have
only
the
files
and
I
should
click
on
overview.
I
see
only
the
overview
and
load.
That's
not
really
clear
for
me.
If
I
should
go
this
way
or
not,
and
that
is
yeah
more
a
little
bit
of
question
for
Jan
and
Tim.
If
we
should
use
that
in
builds
as
well,
and
if
we
use
that
in
bills,
I
think
we
need
some
guidelines
on
how
to
use
it.
For
instance,
should
I
have
buttons
there
for
the
previous
build
and
the
next
build
your?
E
A
E
A
E
Will
click
here
it's
not
implemented,
but
this
is
my
idea
to
have
a,
for
instance,
a
list
box
to
a
button
and
toggle
button
where
you
can
select
show
only
the
coverage
of
the
changed
files
or
show
the
coverage
of
the
whole
project.
E
Or
another
thing
is:
when
you
let's
say
you
can
see
here
the
line
coverage
and
maybe
it's
simpler.
If
I
have
a
talking
button
where
you
can
switch
to
the
branch
coverage
or
the
mutation
coverage
or
something
like
that,
so
you
don't
have
so
many
tabs.
You
just
have
one
Tab
and
you
have
some
other
element
to
select
what
you
actually
would
like
to
see.
E
A
So
so,
for
me,
I've
I've
recently
been
using
exactly
these
pages
and
and
have
been
very
deeply
happy
with
the
the
data
I
get
from
them,
so
I'm
I'm
interested.
Would
then
this
would
mean
line
coverage,
Branch
coverage
and
file
coverage
in
one
model
would
move
to
the
or
in
one
idea
would
move
to
the
left
and
be
along
the
sidebar
and
I
would
click
through
them
to
to
get
to
those
so
that
so
that,
instead
of
a
top
level
list
of
tabs,
it
would
be
immediately
the
coverage
page
with
coverage
data.
E
Yeah
yeah,
that
was
the
idea,
especially
now
I've
integrated.
For
instance,
we
have
a
code
coverage
from
Chicago,
it's
line
and
Branch
coverage
and
I've
also
interpreted
mutation
coverage
using
the
same
model
now-
and
this
is
a
concept
I'm
using
in
my
warnings,
plugins
as
well.
I
have
results
for
check
style
for
find
parks
for
PMD
Etc,
and
it
would
be
simpler
if
I
have
them
in
control
in
one
side
panel
and
show
only
the
results
I'm
interested.
E
So
when
I'm
looking
at
code
coverage,
I
want
to
see
only
code
coverage
and
now
warnings
and
if
I'm
looking
into
my
warnings,
plugin
I
don't
want
to
see
the
test
results.
So
maybe
we
can
focus
more
on
the
details,
I'm
interested
for
now
when
we
are
using
the
sidebarm,
and
currently
you
see
the
sidebar
is
very
long
even
longer
when
I.
Let's
say,
let's
see
if
I
have
a
project
which
is
a
little
bit
longer.
E
So
when
I'm
opening
yeah,
it's
not
longer,
I
think
my
plugin
is
not
loaded.
My
warnings
plug-in
so
typically
the
the
sidebar
can
get
very
long,
so
you
need
even
scrolling
and
yeah.
This
is
something
I
would
like
to
avoid
and
it
would
help
if
I
replace
the
the
sidebar
with
thumbs
with
a
special
sidebar
for
my
plugins,
so
I'm,
not
sure
if
that
makes
sense
or
not
so,
and
it's
a
little
bit
feedback
for
that.
A
I
think
we
should,
but
let's
bring
it
to
the
next
session.
I
think
we
could
also
benefit
by
by
pointing
Yan
and
Tim
to
the
recording
of
this
session,
so
that
they
could
see
the
the
concept
that
you're
envisioning
and
your
question
so
that
they
may
be
able
to
to
prepare
and
have
their
thoughts
gathered
in
ready
for
our
next
session.
E
And
one
thing-
maybe
that's
interesting-
is
what's
also
important
for
me,
which
does
not
work.
Currently.
I
would
like
to
have
the
screen
of
100
for
my
plugin
and
currently,
if
I
set
the
size
of
my
frame
to
100,
it's
an
overlay
with
the
Bottom
bar,
so
I
think
it
would
be
really
helpful
for
plugins.
If
I
can
say,
please
let
my
view
fill
the
whole
few
and
yeah,
but
not
the
bottom
here.
E
So
I'm
not
sure
if
this
is
an
overlay,
why
this
is
you
know
not
calculated
correctly
here,
so
these
are
I.
Think
as
a
plug-in
outer
I
need
some
advice
on
how
to
do
special
things,
and
we
don't
have
these
advices
yet
so
yeah.