►
From YouTube: Jenkins UX SIG meeting. Nov 26, 2019
Description
Recording of the inaugural Jenkins UX special interest group. Draft mission statement:
The User Experience SIG focuses on improving Jenkins user interface and user experience. The SIG will seek feedback from the community on the current UI and UX and new designs proposed by SIG members and others and will discuss alternatives, identify compromises, and test implementations to improve the Jenkins UI / UX.
Meeting notes: https://docs.google.com/document/d/1xA6UN7ORv3OFYBC3Kw6y4mtqDekAjwYVNhsrH4PBwBk/edit?usp=sharing
A
What
I
want
to
do
is
quickly
review
the
agenda
and
then
I
think
it
might
be
better
if
everybody
introduces
themselves
and
mentions
their
interest
and
then
once
that's
done,
we
can
kind
of
loop
back
and
agree
on
agenda
topics
just
to
make
sure
that
everybody's
covered
after
that
I'd
like
to
just
have
a
discussion
on
the
scope
of
the
user
experience
special
interest
group,
which
I'll
be
together
with
Joe
Bruijn,
we're
going
to
review
cloudBees
plans
for
the
UI
UX,
so
part
of.
What's
driving
this
not
talk
more
about
this.
A
As
cloud
we've
had
some
quite
big
plans
in
this
area.
This
will
be
driven
by
myself
by
Joe
by
Felix
Gregor
who's
just
joined
the
cloud
news
team,
we're
going
to
look
at
strategies
for
making
changes
to
the
UX
without
breaking
plugins,
which
Felix
will
be
leading.
Finally,
I'd
like
to
talk
about
how
often
we
should
do
these
sessions
reflects
on
where
it's
valuable
or
not,
but
we
did
is
every
two
weeks
every
month,
any
other
business.
A
A
So
I
really
cut
my
teeth
on
what
it
means
to
take
a
project
from
being
in
that
classic
scenario
of
having
three
to
four
months:
release
cycles
where
the
sins
it
lands
with
your
customers,
everything
being
broken
to
having
you
know
fully
automated
pipeline,
going
from
all
the
way
from
unit
tests,
performance
testing
and
all
the
steps
in-between.
So
that's
a
little
bit
my
background
within
cloud
base,
I'm
responsible
for
Jenkins
and
the
cloud
news,
Jenkins
distribution.
A
A
B
Hi
I'm
Felix
gate
over
I'm
I'm
located
in
Bolivia
northwestern
Spain
I'm.
The
front-end
engineer
who
I
have
during
closes
recently
and
I
will
be
working
emerging
issue
I,
basically
well.
I
will
talk
about
this
in
more
detail
later
I'm
I'm
a
bit
new
to
come
to
contribute
into
jangan
himself,
although
I
have
used
the
engines
in
the
past
and
I
and
I'm
familiar
with
the
pain
points
of
why
so
I'm
eager
to
help
improve
the
situation.
C
C
So
I
do
B
Class
developments
those
days,
even
if
I'm
sitting
bald
and
in
Jenkins
in
general,
for
various
reasons
for
personal
and
professor
reasons
so
and
I'm
here,
to
help
and
trying
to
keep
Jenkins
the
best
CSE
server
innovation
server
in
the
world
is
in
hi.
Everyone
already
met,
we,
the
others
already
I,
know
and
Tim
hello.
First
time,
I
see
Nicole.
D
Sure
I'm,
based
in
Malaga
in
the
south
of
Spain
I
joined
cloudBees
little
more
than
three
years
ago
and
I
have
background.
As
a
software
engineer,
I
was
also
some
time
working
as
a
front-end
engineer,
so
my
interest
here
basically
come
from
the
usability
standpoint,
because
I
consider
that's
something
basic
for
for
a
pro
to
be
interesting
and
successful,
and
also
from
the
technology
point
of
view,
I.
Think
nice
and
great
things
are
happening
in
their
front
angle,
especially
around
the
developer
tools.
So
it's
it's
a
lot
of
there's
a
lot
of
interesting
things
happening.
E
I'm,
only
half
now
I'm
based
in
Munich
I'm,
committed
on
Jenkins
I
think
for
more
than
12
years
now,
so
my
interests
are
I'm
at
the
author
of
the
warnings
plug-in
and
yeah
I'm,
contributing
to
this
plug-in
yeah.
Ten
years
now
and
I'm
always
trying
to
improve
the
user
experience
for
the
plug-in
and
yeah.
So
I'm
quite
interested,
what's
happening
on
the
tank
inside
to
improve
the
overall
user
experience.
E
C
A
B
F
I,
get
quite
a
lot
of
issues
on
the
slick
slide,
with
a
lot
of
users
and
options
and
doing
them
doing
the
best
but
ease,
and
it
was
due
to
help
you
to
experience
the
drinking
Qi.
To
help
guide.
Users
would
be
very
useful
and
your
help
lead
a
team
that,
across
a
few
hundred
developers
using
Jenkins
for
our
CD
platform
and
seeing
the
things
that
we
can
do
to
help
make
it
easier
to
use
for
them
is
great
as
well.
F
G
Hey
everyone:
my
name
is
Joe
I'm,
a
product
designer
so
another
term,
being
user
experience
designer
at
cloudBees,
working
on
Jenkins
and
Jenkins
related
products
at
Khloe's.
I'm
really
excited
to
be
digging
into
this
topic
and
to
be
getting
feedback
from
all
of
you
in
the
community
and
and
working
together
with
you
on
this
I
think
I
think
that's.
It
join
cloudBees
back
in
early
2019,
happy
they're
here
right.
I
Hi
everybody,
my
name,
is
crawl.
Schulz
I
am
a
software
engineer
at
cloud.
These
have
been
working
with
Jenkins
for
I
guess
about
four
years.
I
joined
cloudBees
about
three
and
a
half
years
ago,
and
one
of
the
things
that
was
shown
to
me
as
a
thing
that
I
might
be
working
on
would
be
was
was
blue
ocean
as
it
turned
out
and
ever
since
then
usability
and
user
experience.
I
Improvements
to
Jenkins
have
been
something
that
I've
been
really
super
interested
in,
and
I
only
just
found
out
about
this
meeting
about
10
minutes
ago
and
thought
well.
If
I'm
gonna
be
the
person,
that's
always
asking
if
we
can
make
things
better,
I
need
to
also
participate
in
the
meeting.
So
here
I
am.
A
A
Mean
if
something
comes
up,
I
mean
I
think
we
have
depending
on
how
long
we
discuss
each
item.
We
potentially
have
plenty
of
time,
but
please
raise
points
as
they
come
by
so
I'd
like
to
quickly
discuss
I,
guess
the
scope
of
the
user
experience
sig
and
why
are
we
doing
this
I
mean
I,
think
the
main
reason
why,
with
the
launching
this
sake,
that
we've
come
to
realization
over
the
past
year
or
so
that
the
ocean
is
not
going
to
be
what
it
originally
was
promised
these.
A
A
At
some
point,
a
decision
was
made
to
read
rescale
ocean
to
being
just
about
pipelines
and
I.
Think
for
some
aspects
of
pipelines
the
ocean
does
a
really
pretty
good
job,
especially
around
the
visualization
I
mean
it's
not
perfect,
but
I
mean
it's
something
that
I
know
from
experience
is
used
by
a
lot
of
people
and
it's
not
a
candidate
to
your
place
very
quickly.
If
I
think
the
rest
of
Jenkins
UX
looks
old,
I
mean
I.
Remember
whenever
I
used
to
see
Jenkins
before
I
was
the
prime
man
I
used
to
think
wow.
A
This
UX
could
use
a
bit
of
love
and
you
know
that's
the
thing.
What
we
really
need
to
do
now
is
to
really
think
and
we're
also
getting
a
lot
of
feedback
from
the
market
slack.
You
know,
Jenkins
looks
old,
you
know,
Jenkins
is
ugly,
you
know,
there's
a
lot
of
negativity
around
it
and
I
think
it.
Even
though
Jenkins
is
you
know
the
number
one
DevOps
tool.
It's
super
powerful
product
which
I
don't
feel
I
need
to
explain
to
everybody.
A
If
the
first
thing
you
see
is
outdated,
UX
and
it
just
doesn't
really
give
you
good
impression
of
the
product
so
so,
based
on
all
this
I
mean
we
want
to
start
an
internal
movement
in
cloud
beans
to
really
build
a
new
UX
Jenkins.
We
would
like
to
get
as
much
support
from
the
community
as
possible.
We
want
to
learn
from
what
went
wrong
with
the
ocean.
A
One
of
the
things
we
really
need
to
decide
is:
is
there
a
way
to
completely
overhaul
the
UX
of
Jenkins
and
leave
no
plugin
behind,
or
is
this
something
that
simply
impractical
and
impossible?
And
if
the
latter
is
the
case
which
I'm
not
haven't
decided
yet
and
I'm
not
sure
about?
But
let's
say
it
is
the
case,
then
what
criteria
do
we
do
to
get?
You
know
90%
of
the
plugins
to
come
along
with
us.
A
C
B
C
C
C
But
if,
if
what
you're
saying
is
that
you
know
we
are
going
to
define,
what's
what's:
okay,
what's
not
okay
to
keep
saying,
is
rocking
and
then
plugging
author
with
have
to
adapt
and
I
fully
agree,
because
you
know,
and
and
for
older
plugins
that
have
not
been
rave
and
since
Vickers
or
whatever
I'm,
not
very
confident
that
we
can
keep
every
single
plugins.
You
know
internet
community
working
without
changing
anything,
while
still
you
know
keeping
Jenkins
free,
relevant
and
more
there
and
everything
nowadays
he's
kind
of
my
concern
so
I.
G
Was
just
gonna
say
really
I
strongly
agree.
I'm
really
glad
you
pointed
that
out.
It's
not
really
on
the
agenda
for
today,
just
because
it
doesn't
have
any
any
substance
to
it
yet,
but
part
of
the
the
long-term
strategy
here
is
certainly
providing
a
toolkit
of
sorts
development
resources
so
that
you
know
plug
in
contributors
such
as
yourself
and
just
everyone
in
the
community
has
the
opportunity
to
benefit
from
the
investigation,
that's
being
done
for
this
project
and
bring
that
knowledge
into
their
contributions.
Rather
than
saying,
we've
made
a
change.
B
If
I
may
say
so,
that's
also
something
where
I
wanted
to
well
over
eight.
So
maybe
we
can
talk
about
these
our
when
when
we
are
going
to
once
we
talk
about
plugins
in
more
detail,
but
I
think
this
isn't
something
nice
to
mention
about
faces
and
they're
under
a
Google
document
we
have
different
faces
and
the
first
is
the
CSS
overhaul.
B
G
And
I
guess
we'll
talk
on
point
number
four
we'll
get
into
it
in
just
a
second,
but
just
to
add
on
to
what
Jeremy
was
saying
about
the
nature
of
this.
This
say
great
Jenkins,
user
experiences.
Obviously
a
huge
topic-
and
this
is
so-
this
won't
be
a
at
least.
The
current
thinking
is.
This
won't
be
like
a
temporary
cig
that
lasts
a
couple
months
and
then
maybe
we
move
on
to
other
priorities.
G
This
is
gonna,
be
a
long-term
topic
and
therefore
our
long
term
sort
of
group
and
meeting
and
we're
gonna
start
in
with
and
we'll
get
into
the
phases
in
a
second
but
we're
gonna
start
in
with
with
more
aesthetic
stuff
and
then
get
into
tackling
a
deeper
user
experience
and
usability
issues.
But
but
that's
all
I
had
to
say
on
that
for
now,
I.
A
Mean
just
one
question
for
early
I
mean:
let's
just
assume
that
we
come
up
with
some
guidelines.
We
come
up
with
kids
and
you
know
you
need
to
let's
say
on
average,
a
plug-in
developer
needs
to
invest
one
day
worth
of
work
to
make
their
plug-in
work
with
the
new
UI.
Obviously,
some
of
them
will
need
to
be
nothing
and
others
will
probably
need
to
do
a
week's
work.
A
What
percentage
my
concern
I
guess
is
that
10,
20
%
of
plugins
will
come
along
and
at
least
initially
for
the
first
year
or
two.
Eighty
percent
of
more
of
the
plugins
will
be
left
behind.
What's
your
feeling
about
this,
or
do
you
think
that,
yes,
this
is
my
concern?
This
is
the
this
is
the
biggest
problem.
E
C
That
that's
really
interesting,
because
that
thinking
we
we
touched
on
recently
again
because
you
mmmm
the
essentials
Jenkins
essentials
are
really
cold
and
then
junkies
evergreen
within
evergreen.
There
was
something
about
these
defining
essential
plugins.
That
would
be
like
higher
quality
plugins
like
in
the
short
list
of
you,
know
things
that
are
done
more
than
the
others
and
I
think
it's
it's
something.
Maybe
that
could
be
leveraged
around
that
will
indeed
to
designate
the
plugins
the
community
committed
to
maintain
over
time
and
there's
a
long,
long
tail
of
breaking
the
waist.
A
Guess
I
mean
maybe
she's
looking
too
far
into
the
future,
but
I
mean
it
would
be
nice
if,
if
let's
say
there
was
some
kind
of
fallback
mechanism
that
you
know
to
look
good,
you
have
to
follow
these
guidelines.
If
you
don't
follow
these
guidelines,
it's
not
going
to
look
good,
but
it's
still
gonna
work
rather
than
you
can't
use
this
plug-in
anymore,
or
you
can
only
use
that
in
kind
of
a
headless
mode.
Almost
you
know.
E
Very
dangerous
move
if
we're
going
to
do
that
in
blue
ocean
I.
Think
we
had
this
exit
button
where
a
blue
ocean
could
be
exited
to
these
old
user
interface.
Yeah
I
think
if
we
had
tried
a
little
bit
more
moderate
that
we
have
the
view
with
the
new
plugins
and
then
we
have
a
link
where
you
see
the
results
of
the
old
plugins,
for
instance.
So
you
don't
need
to
enter
a
new
mode
in
Jenkins,
but
you
can
still
see
the
old
results,
but
not
in
the
new
user
interface,
nice
yeah.
A
G
And
at
a
super
high
level
right,
we
have
what's
laid
out
on
screen
there,
so
this
this
first,
our
initial
investment.
Our
initial
investigation
here
is
around
a
CSS
based
visual
overhaul.
So
this
would
not
be
solving
a
lot
of
the
fundamental
usability
challenges
that
we
encounter
in
Jenkins
right
now.
This
is
actually
more
about
updating
the
aesthetic
of
Jenkins
making
it
look
more
modern
which,
as
we
know,
does
actually
impact
and
improve
usability,
but
it's
not
about
solving
those
deeper
issues
just
yet
when
we
are
able
to
successfully
roll
those
role.
G
Those
improvements
out,
we
can
begin
investigating,
fixes
and
improvements
that
are
more
fundamental
to
Jenkins,
that
long
term
architecture
defining
that
strategy
and
working
toward
that,
which
I
personally
expect
will
take
us.
You
know
a
good,
a
good
amount
of
time.
This
is
going
to
be
a
lengthy
process,
but
the
idea
is
that
we
can
improve
the
aesthetics
and
at
least
have
Jenkins
look
more
modern
to
feel
more
modern
and
therefore
be
a
little
bit
easier
to
use.
In
the
meantime,
with
phase
one.
B
B
Her
on
the
side
of
caution,
we
want
to
make
sure
we
want
to
learn
from
our
previous
mistakes.
We
want
to
be
innovative,
try
to
not
break
stuff
and
unjabi,
be
really
careful
and
try
to
be
served,
maybe
surgical
whenever
we
try
to
make
changes-
and
this
is
something
when
I
go.
For
example.
This
is
something
that
I'm
going
to
mention.
Well,
sir
also
about
0.5.
We,
for
example,
we
will
try
to
start
working
on
components
that
have
no
sty
input
from
plugins.
B
Maybe
the
headers
may
be
stuffed
and
then
move
on
to
more
complex
stuff.
So
we
can
start
seeing
benefits
from
the
cattle
and
we
also
want
to
be
producing
often,
maybe
we
we
will
make
the
new
interface
obtained,
but
we
won't
plug
him
in
dangerous
people
to
test,
and
there
are
combination
of
plugins
on
the
UI
as
soon
as
possible
to
help
us
catch
any
any
possible
issues
which
will
happen.
F
B
G
Absolutely
and
one
really
important
thing
mentioned
in
there
as
well
as
this
is
all
intended
to
be
gradual
and
incremental.
We
want
to
improving
the
Jenkins
UI
continuously
and
we
know
that
we're
going
to
need
to
iterate,
but
certainly
we
don't
want
grand
reveals
that
are
kind
of
suddenly
result
in
a
lot
of
breakages,
and
things
like
that.
So
so
part
of
the
purpose
of
this
recurring
call
as
we
will
have
it
for
the
Jenkins
UX
is
anytime.
We
want
to
introduce
an
aesthetic
change
within
phase.
G
J
Process
and
its
relation
to
Jensen
husband
proposals,
so
we
have
for
phase
1
when
the
really
minor
changes
it's
better
to
find
to
do
it
without
jibs.
But
if
we
talk
about
that
case,
actually
changes
or
major
changes
or
pay
attention
to
breaking
changes,
then
you
should
likely
be
a
gentle
husband
proposal.
J
A
Yeah
so
I
think
that's
so
I
mean
when
it
comes
to
these
sort
of
timelines,
for
this
I
mean
it's
also
worth
being
you
know,
cognizance
I
mean
I,
think
the
CSS
overhaul,
it's
probably
three
to
six
months
of
work,
defining
the
long
term
architecture
will
probably
be
starting
in
parallel
with
this.
Once
the
CSS
overhaul,
there's
some
we're
underway,
we're
going
to
start
working
on
the
long
term,
architecture
and
I
think
we
complete
UI
overhaul
is
at
least
two
years
worth
of
work.
A
A
There
really
a
very
good
way
of
speeding
these
things
up
a
lot
either
I
mean
it
can
be
upsetting
things
like
plugging
work
or
somewhere.
It
can
be
parallelized,
but
it's
not
very
easy
to
get
120
people
and
to
give
more,
you
know
one
little
widget
a
check
something
great
to
come
out
of
it
again.
It'll
magically
works
better.
J
J
Simple
theme
plug-in
which
there
are
dozens
of
public
themes
and
open
source
and
some
things
are
really
good.
Basically,
they
use
existing
cans
stretch
and
they
and
just
apply
a
new
CSS
or
JavaScript,
and
it's
a
kind
of
existing
engine.
You
got
a
lot
of
adoption,
so
hopefully
is
one.
It
might
make
sense
to
just
take
a
look
at
existing
things
and
maybe.
K
J
A
G
C
There's
perfect
because
that's
exactly
what
people
already
have
proposed
idea,
so
yeah,
no,
no
I
mean
it's
been
discussed
here
and
therefore
shortened.
Obviously
it's
been.
You
know
obvious
thing
like
trying
to
basically
make
Jenkins
G
for
Jenkins
behave
more
like
some
good
things
inside
the
same
plug-in,
but
maybe
I'm
going
to
actually
leave
Joe
discuss
this
a
bit
more
because
he's
the
UX
expert
here.
So
it
will
pray
out
more
around
the
potential
improvements
that
we
can't
watch
genki's
itself.
C
G
I
love
the
efficiency
of
the
idea
right,
but
there's
a
a
bit
of
a
danger
there
to
where
we
don't
want
necessarily
to
just
be
picking
up,
I,
think
themes
or
themes
or
styles.
That
currently
exist,
because
in
the
long
term,
that
sort
of
can
inhibit
our
ability
to
form
a
proper
design
language
for
Jenkins,
so
additional
components
that
we're
redesigning
and
implementing
in
the
coming
months.
Throughout
phase,
one
will
have
to
be
informed
by
the
design
and
style
choices
that
have
been
made
for
those
themes
and
that's
not
to
knock
those
themes
at
all.
G
J
C
I
think
the
phase
one
I
making
purely
high-level
like
simple
things.
Changes
is
a
good
thing
also,
because
maybe
you
would
create
no
desire
traction
from
the
community
to
see
you
know.
Jenkins's
are
already
evolving
or
the
changing
face
already
being
nicer
and
that
we
would
have
more
people
from
the
community
actually
come
here
and
then
we
can,
you
know,
enter
deeper
surgery,
changes
and
everything.
A
B
J
B
B
J
All
seems
really
tied
to
the
current
CSS
and
of
course
you
can
tell
move
jinkies
design
forward
without
breaking
them,
and
the
Jenkins
project
doesn't
define
any
compatibility
for
the
layouts
and
for
the
structure.
So,
basically,
even
now,
in
weekly
releases,
we
are
free
to
break
the
structure
of
layout
as
much
as
we
want.
So
obviously
we
don't
want
to
break
it
to
just
because,
but
there
is
no
practical
restrictions
and
yeah
I
understand
your
concern
and
I
just
don't
think
it's
a
real
obstacle
for
faced.
Oh
yeah.
B
G
So
when
it
comes
to
actual
stylisation
and
aesthetics
of
the
UI
like
creating
a
you
know,
defining
a
colour
palette
and
typography,
for
example,
iconography
throughout
Jenkins,
all
of
that
stuff
will
will
be
created
from
scratch
so
that
we
can
eventually
have
in
the
Jenkins
design.
Language
is
consistent
rather
than
picked
up
from
a
current
theme,
if
we
can
utilize
some
of
the
infrastructure
and
some
of
the
code
that
that
goes
into
making
themes
possible.
G
A
B
B
We
are
going
as
I
mentioned
before
we
are
going
to
be
prioritizing
changes
based
on
different
priorities,
for
example,
whether
removing
some
piece
of
the
UI
can
help
us
free
and
remove
a
library
after
making
sure
it's
not
used
by
plugins.
Secondly,
we
trying
to
change.
We
will
focus
of
changing
stuff
where
we
can,
where
we
are
confident.
B
You
are
a
elements
that
have
no
contributions
from
plugins,
for
example,
many
federal
programs
versus
the
config
forms,
the
config
forms
are
those
have
more
delicate
and
we
will
also
a
concern
we
have
something
we
will
try
to
avoid
is
having
we
will.
We
want
to
minimize
inconsistency
in
the
UI.
Were
the
new
elements
clash
officially
with
the
old
elements
on
the
page,
so
we
will
probably
iterate
it's
going
to
be
it's
probably.
We
are
going
to
do
several
iterations.
B
J
A
I
think
this
is
a
really
good
question
that
obviously
we're
gonna
be
defining
during
the
long
term
architecture,
but
I
mean
I.
Think
it's
good
that
we
talk
about.
It
now
mean
what
I
mean
I.
Think
these
exactly
the
things
we
need
to
decide,
I
mean
in
my
opinion.
We
need
to
have
a
form:
the
UI
for
Jenkins,
that's
in
modern
UI,
that's
based
on
you
know
the
clear
separation
between
front
end
and
back
end
and
for
me
one
of
the
goal.
A
B
A
K
J
The
most
of
Jenkins
front-end,
except
a
few
plugins
like
warning,
spotty
engine
body
and
other
similar
ones.
They
use
server-side
a
generation
of
pages.
So
what
you
need
to
keep
an
account
when
you
work
on
this
project
and
that
for
many
things
that
is
just
not
know,
restate
carry
and
basically
in
Jenkins,
we
have
documentation
for
this
case,
so
you
just
have
to
into
the
code.
Yet
there
is
a
JSOC
project
for
generating
core
open,
API
or
Schwager,
but
it's
not
yet
implemented.
C
Yeah
I
think
the
current
idea.
That's
really
there.
There
would
be
a
phase,
one
that
reads
or
something
like
this:
whatever
we
call
it,
that
would
be
more
around
what
we
we
will
code,
somehow
CSS
down,
which
changes
but
like
trying
to
have.
You
know
kind
of
high
impact
in
a
very
short-term
trying
to
fix
what
is
maybe
not
only
low-hanging
fruits
but
think
that
are
abused,
and
you
know
that
would
at
least
first
you
know
start
eating
things
that
make
Jenkins.
C
You
know,
look
like
old
at
first
sight
and
I
think
we
can
do
have
an
impact
on
that
in
a
very
short
term
and
then,
as
Jim
is
saying,
I
think
that
what
Jamie
is
referring
to
mean
like
two
years
no
plan
is
indeed
trying
to
do
as
we
go,
get
getting
bolder
and
bolder.
We
get
construction,
we
get
people
know
complaining
being
happy.
C
We
try
to
see
what
we
can
do.
What
is
succeeding?
What
is
breaking
everything
trying
to
maybe
really
soggy
basis
very,
very
to
8:30,
so
we
avoid
blowing
up
everything.
You
know,
after
a
very
long
channel,
so
yeah
I
do
not
see
so,
in
other
words,
I
do
not
really
see
the
rest
API
as
the
very
very
first
thing
we
need
to
do,
but
because
to
kind
of
stuff
having
something
like
you
know,
linked
visibly
initiative,
that's
been
impacted,
yeah
in
the
mid
term,
short
shortage.
A
B
J
A
A
A
A
A
G
G
C
To
be
honest,
I
would
rather
have
more
frequent
cold
with
shorter
one.
I
mean
we
are
doing
continuous
thing
right
so
and
so
having
it
30
minutes
cold
every
two
week,
instead
of
one
hour
every
month,
I
think
is
slightly
maybe
better
to
keep
the
ball
roll.
The
balls
rolling,
but
I'm
fine
with
whatever
people
think,
would
be
better
these
days,
you
know
we're
still
getting
started,
so
you
know
trying
to
incur
some.
Some
rhythm
is
maybe
the
state
at
least
just
me
I
agree.
A
I
B
G
B
A
B
B
C
J
J
A
Free
tonight,
so
should
we
try
I
mean
obviously
people
when
we
use
the
Jenkins
UX
many
lists
excessive,
announced
it's
great
on
there,
I
mean
it's,
not
it's
hardly
any
traffic
on
it.
So
it
will
be
easy
to
use
that,
but
we
can
try
slack
as
well
I'm
happy
to
try
to
add
it.
You
can.
You
can
take
to
actually
to
track
that
slack.
Well,.
J
C
Anyway,
I
think
we
can
handle
those
things,
maybe
I
synchronously
with
actually
more
well.
Maybe
we
have
more
people
complaining,
but
for
more
visibility
in
the
end
on
Jenkins
there
for
now
or
a
vengeance
is
UX
and
their
opinion,
people
about
the
fact
that
we
are
switching
conversation
on
Jesus
UX
mailing
list.
For
now,
my
personal
preference
is
that
I
do
not
really
really
mind
about
the
instant
messaging
channel
we
would
use,
but
I
I
am
NOT
a
huge
fan
using
such
tools
for
synchronous,
compatible
messaging
and
discussions
like
instead
of
many
X's
but
yeah.