►
From YouTube: Jenkins UX SIG Meeting - Dec 11 2019
Description
Recording of the 2nd Jenkins User Experience Special Interest Group (SIG). This meeting took place on December the 11th 2019 at 1600 UTC. This meeting was attended by Jeremy Hartley, Felix Queiruga, Joseph Brueggen, Oleg Nenashev, Evaristo Gutierrez, Adrien Lecharpentier, Parker Ennis, Sladyn Nunes, Alex Earl and Karl Shultz.
A
A
To
reshare,
so
let
me
do
that
again,
so,
let's
just
do
quick
review
of
the
agenda.
So
first
of
all,
anybody
is
welcome
to
suggest
topics.
So,
if
you
want
to
please
go
ahead
and
interrupt
me
but
think
stings,
this
is
a
fairly
new
sig
and
I
think
Alex.
This
is
the
first
time
you're
joining
it,
be
good
at
our
bridges.
There's
a
quick
round
of
introductions,
though
we
know
he's
here,
I
wanted
to
give
the
quick
updates.
Recently
I
made
a
statement
about
blue
ocean
on
both
on
the
developers.
A
Mailing
list
I
also
repeated
that
statement
that
began
to
contribute
is
dominant
and
that
DevOps
world
Jenkins
website
just
like
to
spend
a
minute
on
that
I'm,
then,
over
to
Joe
Joe's
gonna
talk
about
the
CD
f's
black
channel
Muncie's
credited
to
attract
from
the
resources.
Felix
is
going
to
talk
about
the
you.
I
read
that
strategy,
then
Joe's
gonna
show
a
little
bit
of
it
as
the
science
in
his
processes.
A
A
Specific
quick
introduction,
because
so
Alex
and
slidin
both
won
here
last
time,
so
my
name
is
Jeremy
Afghan
I'm,
the
leader
of
this
special
interest
group
I'm,
also
professional
court
manager
working
at
cloud
base,
fine
responsible
for
Jenkins
and
for
the
cloud
news,
Jenkins
distribution,
putting
cloud
these
the
foundation
team,
which
is
one
of
the
main
engineering
teams
working
on
Jenkins
and
the
security
team.
All
underneath
my
pride
management
and
well,
one
of
my
special
interests
is
replacing
the
Jenkins
you
axe
and
it's
been
my
goal
since
I
joined
flower.
A
B
Hello
there,
a
couple
of
you
have
not
met
before
on
the
call
today.
My
name
is
Joe
Rubin
I'm,
a
product
designer
at
cloudy's,
working
on
Jenkins
and
I.
Think
I
think
that's
about
it.
I'll
tell
you
a
little
bit
more
about.
What's
going
on
in
the
slides
later
on
in
the
call
today
nice
to
meet
y'all,
okay.
C
E
H
I
J
Hey
there,
my
name
is
Carl
Schultz
and
out
of
North
Carolina
in
the
u.s.
I.
Am
a
software
engineer
at
cloudBees
working
mostly
on
pipeline
stuff
and
have
had
an
interest
in
the
the
evolution
of
the
Jenkins
user
interface
and
user
experience
since
joining
the
company
and
becoming
involved
with
Jenkins.
Okay.
A
Brights
we've
welcome
everybody,
so
just
very
briefly,
because
we've
got
a
lot
of
points
to
cover,
but
I
think
the
week
before
last
I
made
a
statement
on
the
developers
group
about
blue
ocean
and
the
status
of
the
ocean.
So
for
those
that
haven't
read
this
I
mean
the
statement
basically
says
that
blue
ocean
didn't
reach
its
original
objectives
so
original
objectives.
The
blue
ocean
was
that
it
would
replace
the
whole
of
Jenkins.
A
A
A
I
made
a
similar
statements
that
dejected
contributor
summits
and
the
Jenkins
world,
as
focus
that
was
the
next
week
and
I
also
talked
about
the
new
UI
project,
which
is
obviously
subjective.
It's
sick
think
people
were
happy.
Some
people
quite
worried
about
blue
ocean
going
away,
but
I
think
people
are
happy
that
a
new
UI
is
being
built.
However,
and
I
think
it's
important
to
be
clear
that
blue
ocean
will
remain
base
until
something
is
there
to
replace
it.
A
My
feeling,
personally
is
that
I
mean
we
have
pushed
blue
ocean
very
hard,
so
we
need
to
at
least
maintain
it
and
keep
it
alive
until
we're
ready
to
replace
it.
We
can't
simply
pull
the
plug
on
it.
You
know
just
because
they've
been
achieving
objectives.
We
think
it's
reasonable,
that
we
stop
investing
strongly
in
it,
but
I
mean
we
need
to
keep
it.
A
A
A
B
B
Just
since
this
is
our
second
instance
of
this
of
this
SIG
meeting
just
some
housekeeping
stuff
item
a
there
is
that
in
the
previous
call
in
the
first
call,
we
had
a
consensus
that
we
would
have
conversation
in
between
cig
meetings
in
a
dedicated
slack
channel
in
the
CDF
slack
organization.
So
if
you
scroll
up
in
this
document
on
screen,
which
you
don't
have
to
do
right
now,
Jeremy
you'll
see
notes
where
we
we
sort
of
came
to
that
conclusion.
B
Unfortunately,
slack
doesn't
allow
me
to
go
and
and
send
a
direct
link,
at
least
not
that
I've
seen
to
join
that.
So,
if
you
just
shoot
me
an
email
@
@j
brueggen
at
cloudy's,
calm
I'll
get
you
added
right
away.
No
questions
asked
and
we'll
get
everyone
in
there
and
that's
where
a
host
conversation
between
these
meetings
and
then
item
4b
there.
Could
you
open
that
one
up
real
quickly,
Jeremy,
yes,.
A
B
B
Awesome
so
what
this
document
on
screen
is
here
is
we
know
that
we're
gonna
have
these
meetings
they're
currently
scheduled
for
every
other
week.
We're
gonna
have
our
conversations
in
slack,
but
you
know
things
can
get
a
little,
but
messy
with
with
a
bunch
of
different
locations
for
communication
in
the
community.
Sometimes
you
know
have
mailing
lists
and
we
have
works
like
general.
Now
we
have
this
and
that
so
this
is
one
document
where
all
resources
that
are
created
in
relation
to
this
project
will
just
be
listed
in
this
document.
B
I'll
throw
this
in
the
slide
journal
as
well
as
the
topic
for
the
Select
channel.
So
anytime,
you
need
to
reference
anything
related
to
this
sig.
It
should
be
linked
here,
meeting
agenda
notes,
Jenkins
UI,
revamp
document
that
we'll
look
at
in
a
little
bit
a
header
bar
with
breadcrumbs
design
that
we'll
look
at
in
a
little
bit
as
we
create
more
stuff,
we'll
put
it
on
this
document,
so
very
simple
resource.
That's
that.
A
D
A
D
So
we've
created
a
document
where
we
summarize,
basically
our
what
our
approach
will
be
to
the
project.
Will
we
consider
its
own
scope
out
of
scope?
We
have
also
dong
sound
technical
analysis,
what
they
will
and
really
some
of
the
difficulties
we
we
think
we
are
going
to
have.
We
did
a
brief
analysis
on
the
current
state
of
CSS
within
Jenkins.
We
little
bit
of
a
problems.
We
think
we
are
going
to
start
with
plugins
it's
a
high
level
document.
D
It
doesn't
go
into
really
really
big
detail
on
any
topic,
but
it's
definitely
titling
and
honey's,
and
if
anybody
I
encourage
everybody
to
take
a
look
at
it,
read
it
and
if
you're,
something
that
seems
of
any
feedback
on
the
strategy
and
if
it
was
work
on
any
point,
please
do
tell
create
a
pull
up
to
the
comment
and
we
will
discuss
it
for
some
of
the
examples
I
mentioned
here.
Is
you
scroll
down
a
bit
example?
Here
is
a
a
bit
down.
H
D
Example
here
plucking
impact
at
least
we
will
have
a
section
dedicated
to
issues
possible
issues
with
plugins
which
problems
I
for
I,
see
that
can't
happen
with
plugins.
It's
more
of
this
is
going
to
happen.
We
need
to
decide
what
to
do
and
basically
also
a
way
to
raise
a
discussion
of
how
to
produce
stuff.
D
A
B
Yeah,
if
you
could
open
that
slide
back
up
so
for
a
little
bit
more
context
on
this,
something
that
we
want
to
do,
ideally
in
every
one
of
these
twice
monthly
sig
meetups
is
present
a
little
bit
of
design
and
and
the
redesign
of
a
new
component
within
the
Jenkins
interface
and
the
reason
we're
doing.
That
is
because
this
is
what,
while
these
components
are
being
actually
designed
and
implemented
as
part
of
a
cloud-based
project,
we're
leaning,
pretty
heavily
and
we'll
really
cherish
community
feedback
to
inform
these
designs
and,
of
course,
how
we
implement
them.
B
That's
why
everything
is
being
so
being
done
so
openly
here,
so
this
first
deck
is
a
little
bit
pedantic,
just
because
this
is
the
first
time
we're
doing
this.
There's
a
lot
here
and
I
won't
redo
everything
at
this
point.
Of
course,
this
is
all
linked
to
me
on
almost
in
all
those
locations
for
you
to
check
out,
but
let's
go
ahead
and
do
that
with
slide
two,
let's
jump
in
there
Jeremy.
B
So
just
laying
this
out,
because
I
figured
probably
the
vast
majority
of
people
who
will
look
at
these
things
won't
be
on
these
calls
right.
So
this
is
what
the
sig
is
setting
the
expectation
for
these.
Hopefully
we'll
have
one
of
these
every
other
week,
as
you
mentioned,
and
each
one
will
focus
on
one
component
within
the
Jenkins
interface
sort
of
outlines,
some
of
the
design
logic,
that's
going
into
that
components,
redesign
and
then
details
about
how
and
where
to
provide
feedback
to
take
away
from
this
slide.
B
This
Jenkins
just
excuse
me
cloudy's,
is
obviously
working
on
a
visual
refresh
of
drinkin's
and
that's
yeah.
That's
that's
the
overview
here.
I'm
go
to
slide
3,
since
we
have
so
much
to
cover
in
today's
agenda,
which
is
awesome,
I'm
not
going
to
redo
every
single
thing,
but
there
are
some
valuable,
takeaways
and
survival
notes
in
here
for
you
to
reference
after
this
call
thinking
about
how
the
Jenkins
brand
will
continue
to
evolve
through
the
interface
through
this
redesign
specifically
and
how
it
relates
to
the
cloud-based
brands.
B
These
are
two
very
distinct
brands,
as
they
should
be.
The
goal
of
the
project
of
the
CSS
refreshes
is
not
to
bring
them
any
closer
together.
In
fact,
it's
to
strengthen
the
independent
Jenkins
brand
and
and
strengthen
the
Jenkins
product
and
improve
usability.
Of
course,
through
the
design
you
can
jump
to
slide,
4,
I,
think
yeah,
and
then
a
couple
really
important
points
here
as
well.
In
addition
to
introducing
a
really
modern
interface
in
Jenkins
for
everyone
that
uses
it
in
the
global
community.
Here
we
also
want
to
improve
basic
visual
accessibility.
B
There
are
a
lot
of
excuse
me.
There
are
a
lot
of
interactions
inside
of
Jenkins
that
suffer
from
poor.
Visual
accessibility
could
be
made
a
lot
better
with
somewhere,
straightforward
tweaks,
so
that's
a
priority
in
addition
to
making
things
look
better
and
therefore
feel
and
therefore
be
a
little
bit
more
intuitive,
it
will
also
be
a
little
bit
more
accessible
and
follow
more
modern
web
standards
for
visual
yeah.
C
B
D
D
H
D
E
D
D
E
D
C
B
D
B
We
won't
be
able
to
solve
also
stability
issues,
certainly
within
the
scope
of
this
project.
However,
whenever
we're
redesigning
a
component
just
to
reiterate,
whenever
we're
redesigning
component,
we
have
that
opportunity
to
make
sure
our
typography,
our
color
palette
is
accessible
I'm.
Wherever
we
can,
we
will.
We
will
fix
and
improve
accessibility
in
that
regard,
but
it
won't
be
a
total
overhaul.
Yet
you
know
it's
something
to
work
toward
yeah.
C
That's
and
yeah
if
we
just
retain
the
same
level
of
extensibility
as
it's
available
in
the
car,
enjoy
I,
guess
it
without
the
rest
of
the
screen.
We
because
somebody
would
be
able
to
apply
a
custom
theme
and
this
it
can.
You
repeat
that
last
bit,
so
if
you
editing
the
same
level
of
her
extensibility
like
we
have
now
or
one
in
basically,
everybody
can
replace,
CSS
and
add
additional
JavaScript
through
jenkins
web
interface
and
basically
they
design
it
entirely
if
needed.
So,
if
me
looking
in
these
features
after
the
redesign
these.
B
B
The
second
item
on
the
screen.
There
is
just
a
note
about
working
toward
a
Jenkins
design
system.
This
doesn't
have
like
a
formal
name
yet
because
we
don't
need
a
need
to
be
confusing
anyone,
thinking
it's
a
different
product
or
a
different
project,
or
anything
like
that.
It's
something
that'll
be
built
organically.
As
we
move
through
component
designs,
I
think
we
can
jump
to
slide
5.
B
So
real
quickly,
just
address
Oleg
I
see
you
have
a
comment
there.
This
is
Jenkins
design
language
v2,
so
there
was
a
instill
is
documented
on
the
web,
the
Jenkins
design
language,
which
is
slightly
before
my
time
at
cloudBees,
but
from
what
I
understand
an
initiative
to
create
a
a
design
language,
a
design
system
of
sorts
based
on
the
blue
ocean
interface.
B
Obviously,
following
you
know,
Jeremy's
update
there
about
the
future,
ablution
and
and
cloudy's
our
stance
toward
it,
how
we're
maintaining
it
moving
forward?
Yes,
this
is
not
a
v2,
but
this
is
a
different
initiative
just
because
we're
taking
a
different
approach
with
this
project.
So
when
you
see
reference,
if
you
do
to
jenkins
design
language
around
the
web,
that
is.
D
B
D
I
should
be
all
right
about
that.
Also
give
me
see
also
in
the
refer
to
the
scope
of
what
we
think
the
project
should
cover
and
the
strategy
document
where
we
would
like
to
be
able
to
provide
a
place
like
sort
of
storybook,
a
place
where
we
could
least
designers
components
develop
those
in
isolation,
so
people
could
see
all
the
components
separated
without
going
to
the
Jenkins
instance.
This
is
not
something
we
can
commit
to
do
right
now.
D
It's
something
that
we
would
like
it
may
happen,
but
it's
not
even
we
are
not
sure
it's
like
we.
We
are
not
saying
it's
going
to
happen.
It's
something
that
it's
a
possibility,
but
the
our
focus
is
to
do
the
lever
changes,
so
the
thinking's
you
I
am
NOT,
creating
and
move
towards
a
design
system,
but
not
to
create
a
design
system.
Our
four
focuses
driven
the
UI
changes.
D
B
So
so
to
clarify
it
and
I
think
we're.
On
the
same
page,
there
Felix
right
when
I
say
working
toward
a
Jenkins
design
system.
It's
not
say
I'm,
a
designer
promising
new,
that
you'll
have
a
design
system
to
reference
starting
tomorrow
or
anything
like
that.
It's
just
to
say
that,
as
we
move
through
these
design,
improvements
will
be
thinking
about
them
cohesively
as
part
of
a
larger
system
of
sorts
which
isn't
being
formalized
right
now,
but
that
they
will
be
design.
B
H
B
So
I
mentioned
that
we're
sort
of
starting
off
small.
This
is
our
second
cig
meeting
ever
and
the
first
design
that
we,
when
introduced
for
feedback
here
and
keep
in
mind
we
can,
we
can
do
feedback
in
the
call
here.
That's
totally
fine,
but
we
also
have
a
select
Channel
and
feedback
is
welcome
anytime
after
after
this
call
as
well.
B
The
first
one
we
want
to
look
at
here
is
a
header
bar
with
breadcrumbs,
so
throughout
the
course
in
this
visual
refresh.
Really
this
is
CSS
centric
and
therefore
functionality
will
remain
largely
the
same.
This
is
about
aesthetics
right
now,
but
this
will
allow
us
to
do
to
achieve
some
of
the
stuff
we
mentioned
earlier,
like
improving
visual
accessibility
with
a
new
color
palette,
modern
iconography
things
like
that
so
just
running
through
these
bullets.
B
Here
imagine
this
is
a
fairly
straightforward
choice
for
our
first
one,
not
super
controversial,
because
this
one,
since
functionality
would
be
remaining
largely
the
same,
won't
really
have
too
much
impact
on
user
workflow
and
won't
have
too
many
plug-in
implications
and
impacting
people's
day
to
day
right
off
the
bat
so
slightly
less
controversial.
But
you
know,
let
me
know
if
something
let
us
know
something
stands
out
as
problematic
and,
and
you
know
this
is
the
sort
of
dialogue
that
and
go
back
to
inform
the
design.
B
Of
course,
I
mentioned
all
colors
and
typography,
since
we
have
the
opportunity
to
do
so
are
being
measured
by
modern
visual
accessibility
standards,
even
though
we're
not
you
know,
fixing
Jenkins
accessibility
for
lack
of
a
better
expression
right
now,
there's
an
opportunity
to
do
that
in
small
ways
here,
so
we're
taking
advantage
of
that
this.
This
component
and
other
components
in
future
sig
calls
I'll
share,
are
also
being
designed
to
scale
down
well
to
mobile
I.
B
Don't
have
that
for
you
this
week
and
I'll
share
that
in
the
next
sync
alongside
some
other
designs
and
really
this
is
this
is
fairly
straightforward.
We're
looking
at
a
few
states
here
so
on
the
very
top
page
they're.
Looking
at
your
start,
our
drinkin's
landing
right.
If
you're,
if
you're
brand
new
into
the
interface,
for
example,
very
straightforward,
everything
should
look
the
same
or
excuse
me,
everything
should
work
the
same
way
but
looks
slightly
better
in
that
middle
screen,
shot
there,
we've
got
a
comment,
come
through
I'll.
B
Look
at
that
comment
just
a
second
and
that
middle
screen
shot
there.
We
have
the
auto
fill
auto
fill
selection
stay
for
the
search
bar,
so
you
see
that
the
selected
auto
flight
of
this
is
a
slight
tweak
here.
In
addition
to
the
very
light
color
fill
that's
applied
to
each
item,
as
you
sort
of
excuse
me
as
you
sort
of
scroll
down
through
that
list,
you
also
have
a
little
icon
indicator
on
the
right
there.
B
This
is
a
common
technique
for
autofill
lists
like
this
in
modern
UI,
is
to
improve
accessibility
and
then
some
minor
adjustments
to
how
we
do
breadcrumbs
as
well.
Although
the
logic
of
breadcrumbs
can
certainly
be
improved,
that's
a
bit
out
of
scope
for
this
effort
right
now.
So
again,
just
visual
improvements
at
the
moment.
H
B
Again,
this
is
a
fairly
straightforward
one.
You
know
in
future
weeks
and
months
there
will
be
designs
reintroduced
for
additional
components
that
are
going
to
be
a
lot
more
controversial,
a
lot
more
confusing.
Potentially,
what
does
this
mean
for
my
workflow?
What
does
this
mean
for
XYZ
plugin
and
that's
where
we're
really
going
to
get
into
the
meat
of
a
conversation
I
think
by
your
feedback
is
and
I
speak
into
everyone.
Of
course,
Trebek
is
more
than
welcome
here
and
in
slack
after
for
this
first
component,
let
me
see
there
was
a
chat,
yeah.
A
B
A
C
One
question
about
the
technology:
under
the
hood
of
your
components.
This
summer
we
had
a
pretty
successful
google
Summer
of
Code
project,
which
was
the
devoted
to
flagging,
draw
improvements
and
basically
was
using
care
and
include
standard
libraries
until
the
Jing
has
plug-in
to
have
some
controls
etc.
What
is
the
current
consideration
for
this
project?
D
C
C
D
Right
now
we
want,
we
don't
want
to
touch
any
new
JavaScript
at
all.
So,
for
example,
here
the
research
autocomplete
widget
is
I.
Think
it
is
long
is
Indian
who
UI
it.
If
it's
for
me,
it's
going
to
still
be
the
same.
I
agree.
We
don't
want
to
touch
any
JavaScript
at
all.
If
it's
not
hundred
percent,
so
inverter
forgot,
the
control
would
be
exactly
the
same.
B
So
I
wasn't
you're,
not
I
might
have
misspoken
there
Oh
like
if
I
was
talking.
If
I
was
talking
about
different
controls
yeah.
This
is
definitely
all
about
all
meant
to
be
about
styling
and
even
looking
at
at
that
automatic
refresh
toggle
there
right.
That's
something
that
just
in
the
past
day
or
so.
D
Said,
oh,
look
if
there's
any
yeah
and
that's
the
one
of
the
points
of
these
meetings,
if
you
think
there's
any
project
or
ongoing
some
of
code
project
or
something
that
we
haven't
change
any
of
these
UI
controls
do
tell
us
and
we
were
looking
to
it
and
we
will
communicate
as
possible
with
people
working
on
those
changes.
Of
course,.
A
B
A
D
No
I
listened
I'm,
not
even
going
to
share
anything
visually
more
code,
Jenkins
uses.
Well,
the
juridical
system
uses
a
tool
called
Jas
builder.
Well,
a
family
of
tools
called
J,
is
various
modules
etc
to
us,
the
way
to
build
the
UI
elements,
sorry
for
the
UI
ethics
say
JavaScript,
CSS
and
stuff,
like
that,
some
people
have
expressed
some
trouble
is
in
tattoo.
Those
tools
are
custom.
D
D
D
Will
we
have
a
few
examples?
For
example,
it
will
be
trivial
to
add
a
type
script
present
in
this
project.
Once
we
will
replace
J's
bin
der
with
webpack.
There
is
also
going
to
be
a
more
immediate
benefit,
which
would
be.
We
can
start
using
a
tool
called
post
CSS,
which
is
a
tool
press
to
process
yourself
to
enhance
back,
but
worse
compatibility,
optimize.
The
media
queries
things
like
that.
That
are
right
now,
it's
not
possible
to
to
J's
builder.
D
So,
just
to
summarize,
this
is
a
way
to
way
to
remove
a
custom
piece
of
infrastructure
on
the
changes
project
on
the
Jenkins
cause
repo
and
replace
it
with
a
more
widely
used
tool
with
better
maintenance,
and
that
will
empower
us
well
and
the
people
working
the
Jenkins
fronton
to
deliver
better,
more
changes.
Basically,.
C
Like
put
some
kids
to
that
yeah,
you
Emily
actually
existed.
The
correct,
so
giant
is
Jason.
Do
that
is
a
historical
thing.
It
was
originally
created
for
Jenkins
2.0.
When
there
was
new
installation
manager
developed,
then
it
was
partially
adopted
in
lotion
and
other
components.
But
forging
this
is
a
project
of
these
components
have
been
always
a
major
positive
because
yeah,
the
maintainer
of
these
components
come
phonetic.
He
moved
on
and
basically
there
was
no
releases
for
xx
which
one,
although
Jenkins
us
builder
companies,
since
the
very
first
three
Jesus
they
released.
C
Four,
is
not
trivial
on
my
machine,
the
builds
just
fail
and
they,
if
we
can
get
little
bit
stuff,
it
would
be
really
nice
and
we
have
success
stories
for
web
Park.
We
have
success
stories
for
pure
NPM,
so
if
we
can
now
move
forward
to
standard
technologies
would
be
each
step
forward.
So
I
would
definitely
I
wouldn't
be
missing
any
of
these
technologies,
because
even
now
we
unable
to
maintain
basically.
C
C
D
D
Brook
Jes
builder
just
built
a
JavaScript
pocket.
Some
plugins
are
free
to
use
it
as
any
other
project
is
and
just
want
to
change
it
on
the
Jenkins
court,
because
the
Jenkins
core
has
the
most
complex
and
setup
of
JavaScript
and
CSS,
and
it's
also
were
working.
Basically,
it's
on
a
project-by-project
basis,
he's
changing
it.
My
project,
choosing
the
50
other
projects.
A
A
K
A
K
Can
we
actually
put
a
project
for
the
UI
Olimpica
component
from
this
from
the
entire
project
and
put
it
in
google
Summer
of
Code,
so
that
any
student
can
probably
take
it
up
and
implement
it?
So
I
would
like
to
know
your
thoughts
and
actually
picking
any
one
of
the
any
one
of
the
topics
that
we
discuss
by
Joseph
and
in
the
slide,
for
example,
and
maybe
put
it
as
a
project
question.
K
A
C
Big
time
indication
so
wait
span
expect
mentors
to
spend
more
than
five
hours
per
week
to
the
entire
summer.
So
it's
quite
a
commitment,
but
also
you
can
results
out,
but
that's
why
we
advertise
jae-seok
on
the
Jencks
community
and
any
thoughts,
any
ideas
which
would
be
a
2
G
sub
project.
It
would
be
nice,
I
think.
A
A
E
G
E
B
Yeah
I'm
sorry
good
I
was
gonna,
say
I
also
agree
that
it's
a
really
cool
idea:
I
I'm,
not
sure
if
this
is
what
you
were
mentioning
every
surface
is
similar
to
that,
but
I'm
thinking
anytime
you,
you
branch
out
the
group,
that's
implementing
a
certain
design.
It
can
become
a
little
murky
as
far
as
how
these
designs
relate
to
one
another,
making
sure
we're
having
consistent
aesthetics
and
consistent
patterns
between
them.
So
there
might
be
a
little
bit
of
danger.
B
There,
however,
I
mean
personally
I'm
open
to
talking
about
this,
and
even
if
it's
not
exactly
implementing
a
specific
component,
it
could
be
something
even
more
creative
that
can
contribute
back
to
this
project
in
some
way.
But
it's
got
me
thinking
and
I.
Think
it's
a
good
opportunity.
Can
someone
remind
me
when
this
actually
occurs?
C
It's
accused
nets
on
next
summer,
but
the
garden
project
ideas
we
expect
to
have
them
publish
in
in
January
or
February.
We
already
have
some
project
ideas
which
are
clearly
related
to
the
UX
special
interest
group,
for
example,
REST
API
is
which
would
be
really
important
for
clicking
your
eyes.
We
want
to
automatically
generate
specifications
for
that.
Then
there
are
projects
which
are
related
to
user
focus
for
documentation
like
pipeline
documentation,
generators
again
they
could
be
a
part
of
this
seek
in
some
sense.
A
C
D
C
A
A
A
So,
let's
move
on
to
point
I
because
we're
running
out
of
time
quickly,
I
guess
very
quickly.
We
can
make
an
update.
We
thanks
to
our
suggestion
from
Felix
and
then
the
work
I
like
we
now
have
an
updated
browser
and
its
ability
matrix,
which
is
very
good
because
we
no
longer
need
support.
Ie9
and
tan
I've
been
that's
the
major
changes,
no
look
yeah.
A
C
A
A
C
And
mm-hmm
so
which
they
have
one
of
big
projects,
it's
generated
of
market
places
for
github
iyong.
So
you
may
have
seen
that
where
there
are
some
market
places,
for
example,
pulling
his
heart
actions
and
other
projects
and
I
was
just
experimenting
with
Universal
repository,
which
allows
to
cater.
This
marketplace
is
easily
basically
powered
by
Jekyll
and
I
have
two
potential
applications
for
watching
his
project.
One
is
pipeline
library
marketplace.
C
Another
one
is
simple
things
like
a
marketplace,
so
a
simple
theme
plug-in
would
just
released
existing
themes,
maybe
some
descriptions
with
some
links,
so
it
would
help
users
to
find
that
these
themes
and
it
will
also
add
a
place
for
maintain
heirs
to
them.
So
that's
the
idea.
Nothing
really
complex
inside
I
just
wanted
to
check
whether
this
is
something
useful
from
your
point
of
view
or
whether
it's
something
which
would
color
it
with
the
story.
A
bit
secret
working
on.
D
If'
I
think
it
can
be
problematic
because
it
and
I'm
not
saying
it
would
be
I'm
not
saying
that
encouraging
I
think
it
would
encourage
same
ability,
but
right
now
the
current
there
is
internal
like
clear
guidelines
for
seeming
Dinky's
interface
right
now,
every
plugin
go.
Does
it
something
they
look
into?
The
look
at
the
HTML.
A
D
C
For
me,
it
would
be
also
a
way
to
highlight
potential
compatibility
issues.
For
example,
we
could
use
marketplace
in
order
to
explicit
agreement
with
this
target
gene
expression.
So,
instead
of
embracing
picked
for
an
inversion
and,
as
you
said,
committing
to
breaking
changes,
we
could
be
explicit
what
is
so
the
third
equation
and
then
maintain.
Yes,
when
they
update
the
plugins,
they
can
also
update
information
in
the
marketplace
so
that
they
explicitly
say
what
is
the
version
be
carded,
so
we
can
actually
turn
it
around
and
use
it
for
the
benefit
of
the
project.