►
From YouTube: Jenkins UX SIG Meeting 17 Aug 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
B
Okay,
so
welcome
to
the
Jenkins
ux
Sig
meeting
for
August
17th
here
I'll
just.
B
I'll
just
put
the
link
into
the
chat
in
case.
Anyone
doesn't
have
it.
B
So
you
feel
free
to
add
any
topics
that
you
want
to
go
through
to
the
chat.
We'll
start
with
the
first
topic
on
here:
Security
reviews
for
ux
pull
requests,
sweatick.
C
D
C
E
So,
for
example,
in
a
fairly
new
PR
around
tool
tips-
sorry,
not
tool
tips,
the
annotations
on
links
on
the
manage
Jenkins
page.
What
are
they
called?
Badges
badges,
yeah,
those
badges
so
as
implemented?
There
would
be
an
HTML
injection
vulnerability
if
implementers
are
unaware
of
that.
E
So,
but
they're
still
ongoing
discussion,
whether
there
should
be
string
valued
at
all
or
whether
we
should
only
allow
numbers
and
if
it's
string
valued,
it
can
escape
the
value
right
there
in
Corinth,
say
it's
plain
text
valued
so
either
that
way
it
works
but
yeah.
This
is
something
that
I
brought
up
in
review
here
as
far
as
I'm
concerned.
This
pull
request
isn't
far
enough
at
all
to
make
a
final
determination,
but
this
is
one
where
reviewing
it
with
an
eye
towards
potential
security
issues.
Wasn't
a
bad
idea.
B
I
haven't
been
put
in
a
Security
review
things
on
the
really
trivial
ones
which
I'm
assuming
is
okay.
There's
things
like
removing
a
line
of
CSS,
removing
some
links
just
to
skip.
Some
of
that.
Just
an
example
is.
B
B
In
terms
of
ux
improvements,
yarn
you've
just
joined,
welcome,
did
you
want
to
take
over
for
that?
We
could
go
through
any
of
the
open
pool,
quests
or
anything
new
that
you've
got.
F
Yeah
I've
not
got
anything
major
to
show,
but
it's
running
locally,
but
we're
good
two
for
the
active
PRS
I
might
have
a
quick
prototype
to
demonstrate
later.
I
just
need
to
see
kind
of
what
state
it's
in
right
now.
I'll
just
do
that
in
the
background.
A
B
Of
the
open,
PRS
we've
got,
which
one
would
you
want
to
go
through.
B
B
The
up
arrow
with
the
people
Icon
this
one
seems
quite
odd
in
general,
because
I
feel
like
in
general,
there's
not
really
an
it's
not
really
descended
from
the
People
page
for
most
people
accessing
out
I,
don't
know
whether
that
I
don't
think
people
would.
Actually
we
generally
don't
often
don't
want
people
accessing
that
page,
because
it
loads
all
the
users
and
there's
not
really
any
need
for
General
users
to
actually
view
that
page
everywhere.
I
would
say.
D
F
I'm
going
to
do
it
really
I
think
off
the
top
of
my
head,
probably
just
replacing
the
icon
make.
This
makes
the
most
sense
like
Daniel's
comments
out
at
the
bottom.
That
seems
Seems
sensible
to
me.
A
B
We're
kind
of
just
just
having
a
look
through
to
see
if
we
can
unblock
or
move
along
some
of
the
open
pull
requests
unless
anyone's
got
any
other.
Well,
so
I!
Guess
that's
more!
This
topic
down
here:
stall,
ux
Progressive!
We
could
just
review
some
of
those
quickly.
E
And
then
I
mean
there
are
certainly
pull
requests
but
I'm
not
sure
how
much
sense
it
makes
to
look
at
once
that
got
updated
18
minutes
ago.
Within
your
comment.
B
B
F
I
guess
if
we
could
kind
of
gather
that
feedback
and
kind
of
I'm
not
sure
might
be
on
like
issues.jenkins,
but
if
we've
kind
of
categorize
that
and
keep
it
in
one
place
kind
of
draw
attention
to
it
in
some
way.
That'd
be.
B
G
E
There
is
feedback,
also
not
open
source
issues
and,
and
the
thing
that
makes
it
complicated
Christina
is
that
obviously
his
customers
are
aware
that
cloud
BCI
is
Jenkins
plus
some
stuff,
so
it
may
as
well
be
customers
who
are
complaining
through
the
open
source
channels
or
it's
just
Jenkins
open
source
users.
We
don't
know,
but
it
is
coming.
I
am
seeing
it
through
those
channels.
I,
don't
know
what
cloudpee
supports
and
and
field.
G
This
is
the
first
time
I'm,
just
the
senior
designer
over
here
that
works
with
CI,
so
I
just
attend
the
kind
of
be
able
to
kind
of
get
an
era
on
what's
happening
in
the
open
source
and
how
I
can
support
it
on
the
Cloudy
side,
but
anyways
do
we
have
a
process
in
place
for
generating
issues
or
generating
tasks
that
aren't
necessarily
development
in
nature,
but
that
are
more
like,
because
I
would
kind
of
want
to
do
a
bit
of
a
dig
into
maybe
doing
some
customer
research
sessions
and
gather
some
info
there
to
see
where
that
type
of
feedback
is
coming
from
before
we
evaluate
whether
that's
actually
something
that's
worth
acting
on.
G
Does
that
make
any
sense?
Would
that
be
useful.
G
Oftentimes,
like
what
people
will
say
online,
it's
very
easy
to
complain
because
in
customer
sessions
I
mean,
of
course,
then
this
is
a
different
user
group
right,
so
it
could
be
vastly
different
experiences
and
perceptions.
But
so
far
the
feedback
has
been
quite
positive,
so
I
just
want
to
make
sure
that
we're.
E
So,
just
just
in
case
I
I,
don't
think
we
should
be
discussing
the
monochrome
icons
here.
It's
just
coming
from
Jan
saying.
Well.
If
we
get
feedback
in
jira,
for
example,
then
we
can
adjust
if
the
feedback
is
negative
but
and
and
I'm
saying
well,
there
was
this
other
change
not
too
long
ago,
where
we
got
negative
feedback
and
we're
not
acting
on
it.
E
So
are
we
only
selectively
looking
at
the
feedback
and
if
there
is
no
way
that
we
provide
where
users
can
say,
I
like
this,
in
addition
to
I,
don't
like
this,
because
obviously
people
will
complain
if
they
don't
like
something
and
if
they
like
something
they
will
just
accept
it
and
move
on.
Do.
E
G
G
Prototyping
and
pushing
through
in
CI,
so
it's
maybe
something
that
we
could.
G
I
think
we'd
want
for
just
to
vet
any
feedback,
whether
it's
icons
or
future
work.
So
if
that
would
work,
I
can
pass
that
kind
of
research
along
so
that
maybe
it.
E
E
G
E
Makes
sense
so
we
have
mechanisms
in
Jenkins
that
can
be
used
to
for
people
to
provide
feedback
or
to
send
data
to
the
Jenkins
project
on
a
very
high
level
that
we
could
hook
into.
E
Although
the
problem
there
is
that
it
is
tied
currently
to
the
usage
statistics
feature,
so
that
could
be
a
bit
of
a
mess.
So
we
may
need
something
completely
new
that
we
don't
have
yet
in
Jenkins
and
obviously,
if
it
is
in
Jenkins,
it
will
also
need
to
report
to
the
Jenkins
project.
E
So
the
folks
you
should
look
in
there
are
like
Damien
who's
working
on
Jenkins
project
infrastructure
and
that
can
then
be
reused
simply
in
in
cloud-based
products
by
simply
being
a
part
of
Jenkins
and
then
also
being
part
of
the
products,
so
yeah
I
think
that
would
be
very
valuable.
So
even
for
something
like
the
icons
right.
If
if
what
you're
hearing
is
that
people
like
it
and
I'm,
seeing
the
very
vocal
fuel
who
absolutely.
G
B
Okay,
so
that
would
be
useful
for
acting
on
feedback
that
we're
all
just
getting
more
feedback,
mostly
but
I
guess
so
specifically
in
this
pull
request.
B
I,
don't
think
I
mean
just
because
it's
good
to
get
feedback
on
these
sort
of
changes,
but
I
think
the
main
wasn't
the
main
thing
that
was
holding
this
up.
Was
it
just
the
title
or
was
there
anything
else
holding
this
pull
request
up.
E
Well,
I
mean
the
site
panel
is
I'll,
write
the
title
in
the
side
panel.
What's
the
one
thing
and
the
other
thing
was
to
separator,
which
is,
for
example,
currently
not
usable
in
anything
that
is
extensible
right.
So
if
we
want
to
have
the
separator
as
part
of
what
side
panels
can
contain,
we
need
a
way
to
have
that
be
part
of
the
actionable
interface,
for
example,.
B
I
can't
see
a
picture
but
I'm
pretty
sure
it's
just
a
line
that
has
a
link
to
update
Center
and
yarn's
planning
to
mostly
get
rid
of
that
link
later
by
inlining
it
into
the
inlining.
The
information
into
the
table
there's
a
problem
with
I
guess
not
having
a
separator
is
that
these
are
well
I
guess
you
could
just
put
it
in
there
there's
a
almost
kind
of
like
their
tabs,
whereas
it's
a
different
page,
which
is
why
it's
separated.
E
F
Yeah,
like
like
Tim,
said
this
is
kind
of
a
stop
Gap
solution,
and
just
so
we
can
separate
the
kind
of
permanent
items.
I
guess
we
can
call
them
at
the
top.
So
we've
got
the
active
the
the
updates
available
in
still
in
advanced,
so
we
can
separate
those
visually
from
the
update
Center
there's
like
terms
of
that
I'll.
F
Take
you
to
a
separate
page
altogether
in
terms
of
kind
of
extending
the
API
to
support
separators
I'm
I'm
happy
to
do
that,
and
it's
just
whether
other
pages
on
Jenkins
would
benefit
from
having
that
separator.
F
B
F
E
So
another
option
how
we
could
get
this
effect
without
needing
a
separator
could
be
to
to
have
a
nested
side.
Panel
items
like
we
have
for
whiteboard
workspace
and
we
used
to
have
for
the
plain
text
log
which
are
basically
there's
basically
a
tree
of
site
panel
items
that
exist
in
some
places
in
Jenkins.
So
that
way
you
install
plugins
advanced
settings
could
be
shown
as
part
of
the
or
available
plugins
can
be
shot
as
part
of
plugin
manager.
While
the
other
top
level
item
would
be
the
update.
E
Sender
no
separator
required,
because
the
tree
structure
makes
it
clear.
What's
related
I'm,
not
sure
it
needs
to
be
discussed
in
this
meeting.
No
just
just
to
follow
it.
If,
if
you
want
to
move
this
forward
without
the
separator,
although
it
would
probably
make
sense
for
us
to
look
into
the
feedback
mechanism
rather
early,
because
the
more
changes
and
the
more
experiments
we
publish
without
having
a
feedback
mechanism,
the
worse,
the
situation
will
be
because
why
would
anyone
provide
feedback
on
something
they've
been
using
for
months?.
F
E
So
I
I
think
janyu
weren't
here
I
think
it
was
in
the
last
meeting
right
where
we
already
discussed
in
quite
some
detail
potential
issues
with
having
the
title
in
the
side
panel,
for
example
the
resulting
length
limitations,
especially
in
more
both
languages
stuff
like
that.
E
So,
for
example,
if
we
move
the
title
into
the
side
panel
on
all
pages,
what
does
it
look
like
on
job
Pages,
where
the
job
name
is
the
page
title
and
job
names
can
be
extremely
long
and
very
difficult
to
break
because
people
like
their
word,
separation
using
underscores
which
are
not
really
easily
breakable,
with
normal
normal
rules
and
so
on.
So
I
don't
want
to
reopen
this
particular
kind
of
worms.
I
just
want
to
mention.
E
This
was
something
that
we
discussed
in
some
detail
last
time,
where
quite
a
few
concerns
exist
with
having
the
title
in
the
site
panel.
Obviously,
on
this
page,
it's
easy,
but
if,
if
this
is
something
that
should
be
done
more
on
more
and
more,
perhaps
ultimately
all
pages
of
Jenkins,
then
these
are
problems.
We
need
to
figure
out
an
answer
for.
F
I
I
agree
completely:
I
I
managed
to
watch
the
last
meeting
and
so
I
managed
to
capture
all
your
points
really
and
I
responded
on
on
the
guitar
as
well,
I'm,
not
sure
if
you
at
all
scene.
It's
like,
like
you,
said
this.
This
page
it
worked
with
the
head
because
plugins
as
a
title
isn't
particularly
long
but
yeah
for
the
job
page
and
whatnot.
If
you
have
a
kind
of
crazy
job
name
it
it
wouldn't
handle
it.
At
least
in
this
kind
of
current
implementation.
G
G
It
could
be
that
the
plug-in
manager
page
is
unique
enough
to
stand
alone
within
the
sidebar
with
no
problem,
but
I
would
agree
that,
like
future
Pages
like
it
couldn't
hurt
to
have
further
discussion,
but
that's
just
my
two
cents.
My
opinion
is.
F
I
I
wouldn't
mind
actually,
if
we
had
the
time
today,
potentially
just
to
go
over
a
small
prototype
for
the
kind
of
project
page,
it's
pretty
much
like
a
wireframe
at
this
point,
but
it's
just
an
idea
of
kind
of
cards
they
haven't.
We
spoke
about
a
few
months
back
on
the
ux
meetings.
B
We've
got
time
for
that,
I
think
I,
guess
the
main
thing
here,
I
was
just
trying
to
work
out
a
way
forward
on
the
support
request
is
just
a
main
one
that
probably
not
too
much,
hopefully
not
too
much
work
to
unblock
this
one.
F
If
we
kind
of
class
this
page,
as
as
being
neat
like
Christina,
said,
then
that
could
stand
like
it's
compared
to
the
rest
of
Jenkins.
The
plug-in
manager
is
quite
a
unique
page.
It's
all
like
a
storefront,
then
kind
of
managing
builds
or
whatever.
F
F
E
E
A
E
Review
what
the
API
offers,
however,
both
of
these
have
apis,
and
so
that
could
be
awkward
having
the
download
progress
page
having
an
API
that
has
little
to
do
with
downloads,
but
it
I
think
it's
the
jobs,
so
it
might
actually
work.
So
perhaps
that
would
be
a
way
forward
and
then
we,
you
don't
need
a
separator,
because
the
plugin
manager
suddenly
has
a
download
progress.
Page
yeah.
E
E
E
I
mean
at
this
point
it's
just
another
page
like
all
of
them
or
another
site
panel,
like
all
of
them
right.
There's
nothing
special
about
this
side
panel
compared
to
the
job
configuration
right.
As
I
explained,
job
configuration
has
a
special
side
panel.
That
is
the
like
the
what
used
to
be
the
scroll
spy
on
top,
and
so
it
kind
of
made
sense
there.
But
now
it's
just
a
regular
side
panel.
E
Why
does
this
have
and
if
you
scroll
down,
you
will
see
how
the
side
panel
actually
progresses
through
the
different
options
right,
which
is
very
different
from
the
usual,
go
to
a
different
page
side
panel,
that
other
pages
and
Jenkins
have,
and
so
this
kind
of
I
thought
this
signified
this
special
kind
of
side
panel
as
well,
and
now
you
apply
this
to
plugin
manager.
Why?
Why
does
plug-in
manager?
Have
it
but
not
system
log,
for
example,
system
log
is
also
a
sort
of
unique
page
on
manage
Jenkins.
F
F
F
If
there's
time
just
just
bear
in
mind,
it's
not
like
kind
of
anywhere
near
future,
complete
or
developed,
it's
just
like
a
rough
idea
at
this
point.
I
just
wanted
to
get
some
feedback
on
it.
If
you
were
to
demo
it
kind
of
next
month,
yeah
I'll
I'll
share
my
screen
desktop
2,
all
right,
so
you
will
see
my
screen.
F
Yes,
so
it
looks
quite
a
bit
different.
What
we've
got
currently
the
idea
behind
it
is
to
kind
of
cut
down
on
the
white
space
that
we
have
on
the
build
page
or
the
project
page,
as
we
currently
have
kind
of
controls,
currently
everywhere,
centralized
kind
of
the
controls
aspects.
You've
got
to
kind
of
build
a
parameters,
option
configure
and
kind
of
generic
options.
They're
not
really
thought
of
there
kind
of
put
the
most
kind
of
important
information
kind
of
Center
Stage.
F
So
for
this
kind
of
project
we
have
the
stage
view
plugin,
and
that
provides
this
kind
of
massive
canvas,
so
it
can
display
all
of
its
information
and
then,
instead
of
rather
having
kind
of
sideboarding
traditionally
have
the
contents
of
those
pages
is
instead
visible
on
the
project.
Page
itself,
it's
kind
of
rather
than
clicking
through
different
pages,
you
can
just
scroll
down
to
see
different
information
such
as
the
test
result,
Trend
or
the
stages,
for
example,
kind
of
nice
things
that
it's
scaled.
F
B
It
looks
pretty
I
think
the
main
problem
is
always
going
to
be.
How
do
you
get
the
plugins
to
fit
in
and
behave
and
go
and
like,
as
you
provide
areas
for
these
sort
of
things
to
make
it
configurable,
so
people
can
choose
what
they
want
or
or
is
there
like
specific
areas
and
sizes
that
they're
allowed
and
they
hook
into
because
currently
it's
just
a
hot
mess
on
a
table?
B
F
But
then
that
obviously
had
lots
of
complexity
but
I
also
kind
of
agree.
I.
Think
Jenkins
of
the
South
is
quite
complex,
so
you
kind
of
need
that
fine-grain
control
over
what's
visible.
B
B
B
I
think
I
mean
this
page
is
well
due
a
overhaul.
It's
a
mess
in
the
yeah.
The
page
structure
doesn't
lend
it
well
to
that
without.
Currently
is
like
things
like.
If
you,
if
you've
shown
like
a
before
view
on
like
some
plug-in
on
CI
dot,
you
can
start
some
build
on
CR
that
you
can
say:
oh
you'll,
probably
see
maybe
15
side
panel
icons
or
something
on
that.
I
guess
this.
This
does
the
Run
page
and
then
there's
the
project
page
but
yeah.
B
D
B
E
A
E
So
yeah
so
anyway,
the
experiment
or
the
demo
that
you
showed
looks
great,
it's
actually
fairly
similar
to
what
I
suggested
or
meant
to
suggest
recently,
when
I
asked
about
the
build
overview
and
or
job
overview
page.
E
Obviously
that
was
in
the
details
as
usual,
but
this
looks
looks
pretty
good,
and
this
is
also
the
kind
of
magnitude
of
change
that
makes
it
where
we
can
basically
defend
us
breaking
stuff.
So,
for
example,
the
build
history
on
the
site
there
looks
different
than
what
the
side
panel
widget
would
be
right
with
the
accompanying
breaking
changes
around
richest
and
alignment
and
I'll
be
showing
the
description
and
on
and
on
the
problems
that
create
regressions.
Basically,
every
time
we
touch
it.
So
we
have
a.
F
Sweet
I'm,
this
kind
of
design
carries
through
to
the
build
page
as
well,
but
I
think
the
pages
horrifically
broken
right
now.
So
that's
why
I'm
not
really
showed
it,
but
has
some
of
the
concepts
where
we
kind
of
bring
the
side
panel
actions
out.
I.
E
A
F
A
D
B
Just
in
terms
of
the
plug-in
manager
page
just
to
Loop
background
I
thought
it
was
worth
just
seeing
that
demo,
shhh
so
I
think
the
last
bit
we
were
at
was
it's
not
completely
special
because
Pages
like
the
job
page,
have
it
the
log
recorder
page
could
have
it
and
so
Jan's
I
guess
you
showed
how
a
different
action
bar
I
think.
Was
there
still
a
title
title
on
that
page
was
it
was
like
that?
Was
it
the
bilge?
Was
it
the
project
name?
And
then
there
was.
A
F
Just
I.
E
So
this
might
be
a
really
stupid
question,
but
why
is
the
plug-in
title
not
above
the
search
bar?
Would
that
be
so
terrible.
F
I
think
it
would
sweep
down
to
like
the
vertical
space.
If
we
have
the
space
on
the
left,
we
could
always
take
advantage
of
that
I
guess
rather
than
trying
to
put
more
stuff
on
top.
F
G
E
E
Suggestion
would
be
perhaps
we
could
do
the
following
change
it
to
move
the
title
back
to
the
main
area,
where
it
unnecessarily
takes
up
vertical
space
change
the
update
sender
to
be
called
plugin
manager.
So
it's
just
yet
another
page
of
the
plugin
manager
that
shows
up
as
needed
and
remove
the
separator.
E
That
way.
This
kind
of
looks
more
like
a
classic
page
of
Jenkins.
We
can
basically
postpone
the
discussion
with
the
title
in
the
site
panel
for
now
and
basically
re-submit
that
for
review
and
postpone
the
title
in
the
site
panel
until
we
have
a
feedback
mechanism,
because
that
intro
kind
of
introduces
a
new
way
for
the
pages
and
Jenkins
to
look.
F
A
E
Oh,
did
it
make
sense
to
split
that
page
up
into
three
separate
pages?
One
is
the
proxy
configuration
one
is
the
plug-in
deployment.
One
is
the
update
side
source,
it's
basically
just
a
random
grab
bag
of
other
options
that
are
vaguely
related
to
plugins,
I'm
and
I'm,
saying
vaguely,
because
the
proxy
configuration
isn't
just
for
the
plugin
manager,
but
also
affects
the
rest
of
Jenkins,
so
this
might
as
well
be
in
the
global
configuration
for
system
options.
E
E
The
proxy
configuration
could
be
moved
elsewhere.
Obviously,
you
know
I
might
need
to
look
into
whether
that
makes
sense
structurally,
but
I
can
see
this
happening.
We've
moved
options
around
in
the
past,
for
example,
the
cloud
configurations
used
to
be
part
of
the
system
configuration
we
had
this
label
that
they
removed
the
tool
configuration
used
to
be
part
of
the
global
configuration.
E
E
I
think
that's
your
pull
request,
as
suggested,
would
be
slightly
Awkward
on
this
page
is
acceptable
if
we
intend
to
split
this
up
a
paid
job
afterwards,
anyway,.
B
F
Yeah,
it
sounds
good
suggest
to
kind
of
clarify,
move
the
title
above
the
search
bar
right
and
then
kind
of
rename
the
update,
Center
and
accordingly,.
E
Right
so
the
breadcrumb
would
also
be
plug-in
manager
to
basically
make
it
appear,
as
is
it
as
if
it
is
part
of
the
plugin
manager.
Have
the
sidebars
look
identical
between
plug-in
Monitor
and
update
sender
and
the
site
panel
item,
for
it
could
be
download
progress
or
something
along
those
lines,
because
really
that's
what
it's
used
for
right
now,
it
does
nothing
else.
E
And
then
the
only
thing
that's
kind
of
separate
is
it
has
a
separate
API
which
I
expect
to
be
fairly
little
used.
So
that's
not
a
huge
deal,
probably
hopefully,
and
the
other
is
to
separate
URL
and
who
cares.
B
A
E
So
you
always
got
there
from
the
plugin
manager
and
it
only
exists
if
you
are
actually
downloaded
something.
E
And
so
that's
why
I
think
it
makes
sense
to
consider
it
part
of
the
plugin
manager.
You
take
an
action,
plugin
manager
and
the
update
sender
becomes
available,
which
is
kind
of
dumb.
So
if
you
go
back
to
plugin
manager-
and
just
you
know
just
install
any
of
these
updates,
nobody
cares
right.
Just
click
any
of
the
updates
say
download.
Now,
suddenly
it
exists,
go
back
to
plugin
manager,
and
now
you
have
the
link
to
update
sender
right
and
if
you
call
this
link,
download
progress.
E
We're
done
here
now
go
back
to
update
sender.
The
only
thing
that
you
need
to
be
careful
of
is
in
the
breadcrumb
bar.
We
would
also
want
to
call
this
plugin
manager
because
we
want
it
to
appear
as
part
of
the
plugin
manager
and
then
I
think
the
entire
rename
this
page,
the
title
on
this
page
as
well
to
be
download
progress
or
whatever
the
site
panel
title
would
be
for
a
bit
of
redundancy
and
and
we're
through
I
think
that
would
make
sense
thoughts.
F
How
how
straightforward
is
kind
of
changing
that
breadcrumb
to
be
plug-in
manager?
F
B
D
E
B
E
F
B
E
B
I
mean
if
you,
if
you
treat
it
as
it's
an
actual
page
of
plugin
manager,
it's,
and
so,
if,
when
you're
on,
when
you're
on
plugin
manager
and
you
click,
it
doesn't
do
anything,
it
just
takes
you
to
the
same
page
well
to
technically
it
takes.
You
saw
this
because
these
are
actually
pages,
but
if
you
click
this,
it
does
nothing.
B
E
We
might
be
able
to
hack
the
get
URL
to
say,
plugin
manager
and
if
nothing
else
breaks
we're
good,
so
yeah.
So
there
might
be
some
pain
here
that
we'll
need
to
we'll
need
to
see
in
implementation,
and
if
you
want,
I
can
take
a
stab
at
this
to
see
whether
it
even
works.
B
F
Yeah
I
can
definitely
take
a
look
at
some
of
them.
I
just
might
need
help
with
the
kind
of
javary
side
of
things,
because
Jenkins
job
confuses
me.
B
Cool
has
anyone
got
anything
else.
Does
mention
of
an
accessibility
assessment
here,
but
as
far
as
I
know,
that
was
It
was
a
done
by
a
company
and
it
was
in
German
and
I'm,
not
sure.
If
anything
was
done
about
that.