►
From YouTube: Jenkins UX SIG Meeting 20 Jul 2022
Description
July 20, 2022 Jenkins user experience special interest group with topics including:
1:06 - Check on security process and progress
8:36 - New user experience paradigms in mostly unrelated pull requests
34:20 - Simplifying developer GitHub tasks by using GitHub comments
52:00 - Preparing for content security policy on Jenkins core
A
Welcome
everyone:
this
is
jenkins
user
experience,
special
interest
group,
it's
the
20th
of
july
2022,
thanks
very
much
for
being
here,
reminder
that
we
abide
by
the
jenkins
code
of
conduct
in
our
meetings,
topics
proposed
for
the
agenda
today:
security
reviews
for
pull
requests
and
vada.
I
believe
this
is
you,
then
ux
improvements
and
daniel
added
a
new
one,
a
subtopic
there
ux
paradigms.
A
I
had
require
java
11
and
fully
support
java
17,
and
this
one
on
stalled.
Ux
poll
requests
had
been
added,
I'm
not
sure
if
there's
anything
to
say
other
than
that
I
haven't
done
that
action.
We
had
an
accessibility
assessment
that
I've
made
no
progress
on
as
well.
Are
there
other
topics
that
you
would
like
to
put
on
the
agenda
before
we
start
going
through
the
agenda.
B
So
I
think
it
was
not
my
topic.
It
was
added
by
team
last
time.
I
think,
because
we
wanted
to
review
that
after
one
more
for
this
kind
of
thing,
what
is
the
status
and
like?
Are
we
blocking
too
many
pro
requests
without
a
good
reason?
Are
we
able
to
allocate
the
correct
resources
this
kind
of
thing
so.
C
B
C
I'm
not
sure
it
makes
a
lot
of
sense
to
review
it
now
for
how
safe
it
is
like,
for
example.
The
last
comments
I
remember
is
whether
there's
a
selection
of
colors
or
whether
it's
completely
free
form
and
if
there's
a
selection
of
colors,
there's,
probably
not
going
to
be
a
text
field
where
users
can
end
or
whatever
right.
E
E
D
D
A
D
D
A
B
B
In
the
past,
we
got
close
to
no
new
vulnerability
added,
so
it's
really
to
be
a
more
stable
in
terms
of
the
situation.
The
cost
to
correct
something
during
the
pro
request,
compared
to
once
it's
already
merged,
is
so
huge
that
we
can
just
let
the
things
moving
on
there.
Now
if
we
are
reducing
the
number
of
things
that
we
are
finding,
I'm
totally
fine
to
reduce
completely
this
kind
of
policy
for
the
review.
A
Before
the
words
yes
so
so,
but
I
think
that
was
an
important
point
from
my
mind,
is:
is
you're
doing
it
like
it's
cheaper
for
the
security
team
to
find
the
issues
before
the
pr
is
merged,
so
reviews
are
a
really
good
thing
for
you.
That's
a
positive
for
your
team,
not
not
anything
you
consider
as
just
a
cost.
It's
really
a
benefit
you're,
avoiding
avoiding
later
work.
By
doing
earlier,
work.
B
A
All
right
so
so,
then,
is
the
the
message
I
think
I'm
hearing
is
we're
happy
to
continue
the
process,
and
should
we
keep
this
as
a
regular
item
on
the
agenda
just
to
be
sure
so
that
we
can
look
at
these
things?
Saying
hey
if
something's
been
a
long
while
I
could
certainly
prepare
I
didn't
prepare
for
today.
I
could
prepare
lists
of
things
that
have
been
there
for
a
while,
if
that,
if
that
helps.
A
B
C
A
Okay,
next
topic,
then
we've
had
a
general
placeholder
ux
improvements
for
yon
and
tim
daniel's.
Put
this
one
on
as
a
sub-topic
daniel.
Should
we
take
that
one
first
ux
paradigms
and
then
tim?
If
there
are,
if
there
are
things
you
want
to
discuss
in
terms
of
other
ux
things
we
would,
we
would
then
give
it
to.
You
is
that,
okay,
with
you
tim.
D
E
C
This
is
basically
a
repeat
what
I
wrote
in
one
of
the
one
of
recent
pull
request:
reviews.
Let
me
pull
it
up,
so
what
I
noticed
is
that
it
seems
we
kind
of
introduce
completely
new
ui
elements
in
otherwise
unrelated
changes,
without
considering
how
that
impacts,
the
larger
plug-in
ecosystem,
for
example.
C
That
is
the
only
page
in
jenkins
where
the
page
title
is
on
the
site
panel
rather
than
the
main
panel,
and
there's
a
new
pull
request
that
changes
some
stuff
around
in
the
plugin
manager,
where
that
was
also
done.
So
my
question
was:
is
this
a
new
thing
and
jan's
response
to
that
was
yes
long
term?
All
pages
should
move
the
page
title
to
the
site
panel
and.
E
C
A
C
Right
so
the
problem
is,
it's
an.
It
went
unmentioned
as
a
change
in
the
pull
request
that
changed
something
else
about
the
plugin
manager,
largely
something
else,
and
when
I
asked
well,
is
this
the
new
thing,
because
it
was
the
second
time
I
saw
it.
Jan's
initial
response
was
yeah
long
term.
Everything
should
be
changed
and,
to
me,
a
one-off
change
in
an
otherwise
unrelated
core
pull
request
is
not
where
we
should
set
project-wide
standards
for
all
viewers
that
have
a
lot
of
downstream
work
attached
to
them.
C
And
so
my
pro
proposal
in
the
pull
request
was
well
have
something
chip
like
so
that
these
changes
that
affect
many
developers
in
the
ecosystem
can
be
reviewed
and
discussed
in
advance
rather
than
say,
you
know
a
few
weeks
down
the
road
hey.
This
exists
now
so
time
to
use
it,
which
is
kind
of
how
I
feel
about
the
app
bar.
E
A
E
E
A
C
A
A
C
E
F
F
C
D
D
Yeah,
so
there
hasn't
been
a
request
now
to
change
all
them.
It's
to
kind
of
experiment,
with
a
couple
of
the
pages
where
this
makes
sense,
where
they're
quite
self-contained
and
specifically
not
plugins.
But
I
don't
like
I
mean
yarn's,
not
here,
so
I
don't
really
want,
like.
I
don't
know
the
exact
reasoning
around
things
which.
F
Just
sorry
this
may
be
a
silly
question,
but
has
the
open
source
community
kind
of
a
b
test
and
the
stuff
among
yourselves
like
do
you
ever
share
things
with
like
a
limited
group
of
people
like
soliciting
feedback,
or
do
you
put
it
out
there
until
someone
complains
and
if
there's
enough
complaints,
then
it's
something
that's
evaluated
like?
Is
there
a
form
so.
A
A
So
so
I'm
I'm
sorry,
I'm
still
trying
to
catch
up
here
so
tim.
I
think
your
your
note
was
this.
This
configuration
form
is
relatively
specific.
It's
configuring
a
the
job
and
and
with
that
specific
configuration
form,
it's
a
it's
an
intentional
exploration.
Could
we
do
more
of
this
move
the
title
of
the
side
panel,
but
it's
not
a
requirement
that
we
must
is.
D
Part
of
this
piece
of
work
is
looking
at
improving
the
side
panels
for
pages
reducing,
what's
on
there
and
simplifying
it.
So
not
so
not
just
dumping
a
side
panel
with
20
actions
on
it,
which
is
what
like
you'll
often
get.
So
if
you
go
to
like
a
dashboard
or
maybe
maybe
see
our
dodging
style,
but
probably
probably
more
like
someone,
who's
got
a
million
plugins
as.
A
D
Yeah
and
that's
not
a
very
big
one
yeah
I
mean
yeah
that
one's
pretty
crazy,
but
I'm
more
thinking
like
the
dashboard,
just
how
sort
of
crazy
actions
get
there,
and
everyone
puts
a
link
there,
some
more
about
looking
at
places
that
we
can
improve
this,
and
so
it's
like
targeted
a
couple
of
areas.
First,
so
there's
like
the
navigation
here
and
plug-in
manager.
D
E
A
Yeah
and
that
that's
my,
I
I
think,
I've
I'm
aligned
with
tim's
concern
there
that
I
I
like
the
incremental
approach
daniel.
Do
you
have
any
any
suggestions
of
okay?
This
one
was
was
a
change
that
you're
worried
will
affect,
could
affect
many
plug-ins
in
many
ways.
If
we
do
it
more
broadly
right,
as
I
think
that
was
your
concern,
is
that
the
site
panel
is
used
in
many
different
ways,
not
just
this
context.
C
C
D
D
C
F
A
F
C
C
F
F
The
context
of
this
page,
with
the
first
link
that
appears
on
the
page,
be
recent
changes
like
the
pull
request,
was
kind
of
the
ideal
thing
right
you
want
feature.
Search
search
is
prominent
at
the
top.
It
works
in
that
context.
That's
not
going
to
be
the
case
for
every
plug-in
right,
where
the
first
thing
at
the
top
of
the
page
like
in
this
case
recent
changes.
E
F
F
F
Then
navigates
so
in
the
right
panel
general
is
right.
There.
It
has
its
own
subheader
things
have
context.
They
make
sense
because
it
that
content
in
particular
sits
okay
with
the
title
removed.
Would
all
pages
feel
like
that?
Or
will
you
have
some
where
it
goes
right
into
kind
of
a
list
of
links
or
a
list
of?
F
I
don't
know
what
the
possible
scenarios
would
be.
Would
it
still
read
right
in
that
context,
or
would
it
seem
really
awkward
and
disjointed?
I
don't
think
it's
something
we're
gonna
solve
on
this
call.
I'm
just
saying
like
I
would
recommend
looking
up
some
edge
cases
mocking
it
up
and
seeing
if
it
still
sits
as
well
with
some
obscenely
long
titles.
D
A
Yeah,
so
the
so
daniel.
I
think
your
point
was
this
one.
The
job
name
on
on
the
page
for
a
job
is
potentially
very
very
long.
I
know
I've
got
several
like
that,
so
so
that
part,
I
think
I
understood
it's
this.
This
text,
wouldn't
in
the
general
case,
fit
on
the
sidebar,
but
jan
certainly
hasn't
proposed
to
do
that.
It's
just
you
don't
have
a
pull
request
for
it.
Go
ahead.
F
F
Not
knowing
how
your
customers
may
use
it,
there
may
be
situations
where
they
may
have
quite
a
bit
of
quite
verbose
descriptions.
Does
that
now
move
the
links
down
the
page
like
not
saying
it's
not
a
potential
solution,
but
that
there's
it's
it's
easy
to
look
at
like
one
ideal
page
where
it
works
well,
but
there
may
be
pages
like
depending
on
how
someone
is
using
it
that
may
not
work
because
then,
if
you
move
pipeline
hello
world
over
to
the
left
nav,
what
about
your
add
description
button
on
the
right?
F
F
C
To
be
clear,
I
I
do
not
object
to
doing
this
right.
I
just
think
I
expect
there
to
be
problems
like
we
discussed
just
now,
and
it
needs
more
planning
in
a
way
right.
So,
first
of
all,
it
needs
to
show
that
pages
like
this
one
would
handle
it
if
the
idea
is
to
roll
it
out
widely
on
most
or
all
views,
and
perhaps
define
standards
like,
for
example,
in
this
case,
if
the
pipeline
hello
world
moves
to
the
left,
then
the
first
thing
shown
on
the
page
needs
to
have
an
extra
title
added.
A
Great
well-
and
I
I
think
I've
understood
so
there
are-
there-
are
specific
cases
and
daniel
no
objections
to
this
one,
that's
already
merged.
For
instance,
it's
it's
it's
a
good.
This
is
a
good
positive
change,
a
good
improvement
and
christina
your
ux
observation
was
hey.
This
actually
matches
well
with
a
pers,
a
user's
experience,
because
of
this
word
general
here
associating
there
that
makes
sense.
A
D
D
D
D
But
other
issues
like
having
to
rely
on
triadges
to
come
along
and
label
issues
and
pull
requests.
So
gap
issue
templates
mitigate
that
a
bit
by
allowing
you
to
set
up
sets
and
labels
through
templates.
But
then,
basically,
we
will
rely
on
contributors
to
judging,
rather
than
the
person
issuing.
It
may
be
able
to
charge
it
at
the
time
to
say,
save
some
effort
so
indira
we
have
this
like
free-for-all.
D
D
Now
generally,
they
don't
need
transferring
too
much,
but
you
need
to
have,
I
think
at
least
right,
if
not
admin
access
on
both
sides
to
transfer
an
issue,
so
it
might
be
right
on
both
sides,
but
basically
you
need
to
be
the
owner
of
both
three
pros
to
move
it
to
a
different
place.
So
it's
not
ideal
and
there's
no
way
to
change
that
in
the
github
permission
settings
so
yeah.
Basically,
there's
some
comments
where
you
can
go
along
and
move
things
around.
So
if
I
go
to
my
org.
D
D
A
A
D
E
D
D
This
one's
a
bit
slow,
the
api
is
not
very
good
for
it
like
it's
it.
Everything
just
gets
a
bit
funny.
I
think
it's
a
bit
weird
on
the
github
side,
how
they've
implemented
it
and
you'll
get
a
bit
of
lag
time
while
it's
transferring
and
sometimes
it
will
show
up
immediately
and
sometimes
it
doesn't
it's
just
how
to
get
up
api
or
just
how
this
whole
feature
works.
Sometimes
it
takes
a
few
minutes
to
even
show
up
that
it's
moved
but
see
it
has
moved
up
in
the
new
places.
Now.
D
So
that's
that
and
then
the
other
thing
is
pull
requests.
So
jesse
asked
like
what
happens
if
you
try
and
close
a
pool
request
as
someone
with
no
permissions
like
if
you're
gonna
go
spam
stuff,
it
doesn't
do
anything.
So
you
can't
you
can't
close
a
pull
request.
Currently
just
ignores
you.
Well,
it
throws
an
error,
but
but
you
can
do
things
that
you
would
like
to
do
like
you
can
label
this
as
a
bug
and
a.
D
D
So,
yes,
it's
just
a
github
app.
It's
installed
on.
I
think
I've
installed
it
on
my
personal
account
and
my
and
my
org
has
a
webhook
secret,
which
is
mandatory
with
the
library.
So
you
have
to
verify
requests.
So
you
don't
have
to
worry
about
people
trying
to
send
your
requests
because
you've
got
a
secret.
That
is
the
hmac
of
the
body.
D
So
the
secrets
they
said
they
had
a
header
to
the
request.
They
send
you
with
an
h
mac
of
the
body
which
you
need
to
compare
with
with
the
secret.
So
it's
a
there's,
a
shared
secret
that
you
enter
here
and
store
locally
and
then
your
private
key,
which
is
used
for
integration
back
with
github,
it's
multi-tenanted,
so
it
uses
the
events
so
advanced.
So
if
I
go
here,
you
get
the
recent
deliveries
and
something
I
didn't
know
before
doing.
D
D
D
C
D
D
D
D
C
Yeah,
so
the
thing
with
the
reviewers
definitely
makes
sense
that
github
doesn't
allow.
It
is
really
weird,
I'm
less
sure
about.
You
know
labels,
for
example,
because
if
people
just
go
not
supplying
every
label
to
a
thing
or
you
know
just
well-meaning
but
doing
it
wrong,
which
I've
seen
on
some
of
my
repos,
then
yeah
but
yeah
still
looks,
looks
pretty
cool.
A
Let's
see
for
me,
I
think
the
risk
of
mislabeling
is
less
than
the
value
much
less
than
the
value
I
get
from
having
them
at
least
propose
a
label
as
a
maintainer.
I
was
going
to
have
to
visit
the
labels
anyway,
if
they,
since
there's
a
submitter,
they
couldn't
have
assigned
them,
isn't
it
it
seems
like
it's
no
worse
for
me
to
have
them,
propose
the
wrong
label
than
what
I
would
have
received
previously,
which
was
no
labels.
A
C
A
A
Okay
and
and
slash
reviewer,
I
I
would
expect
universal
agreement.
Slash
reviewer
is
a
great
choice
and
then
transfer
yeah,
you
said
transfer
is
relatively
low
use
right
now,
but
as
more
and
more
repositories
choose
github
issues,
this
may
become
more
and
more
of
a
a
thing,
and
I
think
I
have
seen
it
in
jenkins
infra
much
more
frequently
where
a
help
desk
issue
may
need
to
be
transferred
to
another
repository
as
the
better
location
for
it.
A
C
D
A
Great
yeah
and
daniel
in
the
chat
notes,
probably
a
good
topic
for
the
developer
list.
Maybe
if
it's
okay,
what
I'll
do
is
I
could
or
tim?
I
can
give
you
the
link
to
the
video
of
this
so
that
we
can
point
people
to
the
demo.
As
a
starter
and
say,
hey,
look
here,
here's
this
idea
of
a
thing
we
think
would
really
help
if
we
had
it
in
in
the
jenkins
ci
github
org.
E
A
A
A
C
My
suggestion
and
why
I'm
mentioning
it
in
this
group
is,
I
would
propose
that
at
least
for
jenkins
core,
but
perhaps
plug-in
maintainers
can
also
adapt
that
a
kind
of
a
standard.
If
you
will
that
new
javascript
code
or
substantially
changed
javascript
code
should
be
compatible
with
csp,
so
basically
saying
while
we're
cleaning
it
up,
let's
not
make
a
mess
over
there.
At
the
same
time,.
A
C
D
D
A
C
C
C
Right,
so
that
is
something
that
I
plan
to
do
next
and
I
hope
other
co-maintainers.
You
just
agree
there,
just
like
I
phrased
it
at
the
beginning,
new
or
substantially
altered
javascript
code.
Obviously,
if
you
intend
it
to
fix
formatting,
it's
not
your
code,
but
anything
more
than
that
should
probably
be
adapted.
A
C
Core
itself
isn't
ready
yet,
but
what
what
we
could
consider
in
the
future
is
having
stuff
like
the
plug-in
injected
tests
or
just
test
cases
in
core
that
visit
some
pages
in
jenkins
and
look
for
csp
violations.
So
that's
definitely
doable
most
likely
doable
to
not
accidentally
reintroduce
something
like
that,
but
there
are
still
tons
of
pages
left.
So
most
of
the
ui
sort
of
is
fairly
clean.
After
my
recent
pull
requests,
at
least
including
the
open
ones,
but
it's
still
a
way
to
go.
C
D
B
C
C
Right
and
especially
the
build
button
is
a
painful
one
because
of
the
context
menu,
which
also
made
me
think,
I
think,
of
the
context
menu
when
I
brought
up
the
dividing
line
on
the
plugin
manager
ui
in
the
earlier
topic,
because
I
thought
I
had
a
fix
and
then
I
saw
where,
where
it's
being
displayed
on
the
jenkins,
ui
somewhere
completely
different.
And
then
I
didn't
have
a
fix
anymore.