►
From YouTube: 2021/12/16 Backdrop Design / UX
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
All
right
we
are
live
on
youtube
today
is
december,
16
2021.
This
is
our
design
and
user
experience
meeting
and
before
we
get
into
the
agenda,
we
should
go
around
and
do
some
quick
introductions,
I'm
happy
to
start.
My
name
is
jan
lampton,
I'm
joining
from
oakland
california,
which
is
surprisingly
sunny
today,
because
it's
supposed
to
be
raining
all
week
and
I'm
finding
myself
unexplicably
happy
about
the
sunshine.
So
that's
where
I
am
today,
let's
see
robert.
Do
you
want
to
go
next.
B
I'm
robert
lyon
folder
on
the
internet
in
altadena,
california,
where
it
is
also
sunny
today
after
rain
and
flight
flood.
That
kept
me
out
of
my
studio
a
few
days
ago
and
I
will
pass
it
to
greg.
C
D
My
name
is
tim
erickson,
saint
paul
tim.
I
am
in
deerwood
minnesota,
where
it
is
not
sunny
and
warm.
We
had
a
thunderst.
We,
we
went
from
freezing
temperatures
a
few
days
ago
to
40
degrees
to
thunderstorms
last
night
and
now
six
inches
of
snow
and
10
degrees.
So
it's
been
up
down
crazy,
it's
just
a
mess
outside.
So
I'm
glad
I'm
in
here
working
on
background
anybody
joseph,
are
you
there.
E
A
A
D
D
D
So
I
I
know
that
in
the
godzilla
was
posting
something
about
the
jquery
issue,
but
she
must
have
posted
it
in
a
zoo,
and
I
just
got
mixed
up.
It
was
in
last
week's
forum
that
would
be
a
good
thing
to
pull.
C
Yeah,
that's
that's
the
most
dev
issue,
rather
than
a
ux
right.
D
Yeah,
I'm
pretty
sure
that
there's
some
people
in
the
room,
though
that
probably
have
some
issues,
don't
you
because
we
we've
got
a
number
of
things
going
on.
That
would
be
related.
We're
two
weeks
from
future
freeze.
C
Yeah,
so
I'm
working
on
that,
where
I'm
working
towards
the
1040
issue,
the
inline
form
errors
stay
with
me.
D
Well
I'll
mention
one
or
two
other
things
we
could
talk
about
now.
You
could
do
that
right.
We
could
talk
about
the
nodeless
pages.
We
have
the
prs
working
now.
Olaf
gave
a
little
bit
of
feedback.
We
have
something
to
respond
to
so
we're
gonna
need
to
get
going
on
that
if
we
want
to
yeah,
we
want
to
get
that
in
this
release.
So
that's
one
thing.
D
D
I
don't
know
another
ux
issue
that
I
feel
is
really
close
and
jen
you've
maybe
lost
touch
with
is
the
the
contextual
link
which
is
now
an
admin
link
to
so
I
I
don't
know
if
we
need
to
talk
about
that
in
this
meeting,
but
if
anybody.
B
It
actually
touches
on
sort
of
a
meta
issue,
because
the
same
thing
that
happened
there
just
happened
on
another
issue,
which
is
we
have
two
pr's
that
propose
different
things
and
more
than
one
person
likes
a
and
multiple
people
like
b
and
and
how
do
we
decide
which
to
go
with?
I
mean
with
that
one.
It's
actually
pretty
clear.
B
That's
it's
like
there's
a
pretty
clear
majority
on
one,
but
on
one
of
the
others,
which
is
actually
the
issue,
the
pr
of
gens
that
I
rewrote
recently
that
there's
another
pr
and
some
people
have
said.
I
prefer
that
one.
So
you
know
do
we
do
we
put
for
things
like
that?
Do
we
put
it
out
to
get
a
formal,
a
way
of
getting
some
sort
of
formal
vote,
or
is
that
what
or
does
it
go
to
the
pmc
like?
C
Both
options
have
been
arcaded
by
quark
for
meters,
because
we
should
get
the
opinion
of
core
committees
code
wise,
I
mean
I'm
aware
of
one
of
the
issues.
The
one
is
with
the
contextual
links
for
the
layouts
and
themes,
and
that
comes
to
those
cons
and
breakages,
and
things
like
that.
So
we
have
solid
sort
of
like
a
solid
list
that
would
help
us
decide.
But
I'm
not
aware
of
the
other
issue,
which
one
is
that.
B
Yeah,
the
other,
that's
what
I
was
saying
that
that's
pretty
clear-cut,
that
there's
a
majority
and
and
and
it's
clear
that
that's
kind
of
the
way
it
will
go.
B
The
other
one
is
this
issue
of
reformatting
the
layout
page
and
to
make
clear
the
distinction
between
layout
provided
pages
and
layouts
that
override
an
existing
page
or
that
wrap
around
and
in
the
original
pr
that
I
had
put
in,
I
suggested
we
add
some
text
next
to
the
path
saying
module
provided
layout
and
then
jenna
made
an
alternate
suggestion
and
put
it
put
it
put
a
pr
together
that
that
instead
broke
the
layouts
into
two
groups,
a
group
of
layout
provided
and
the
other-
and
I
I
kind
of
like
that
and
and
and
rewrote
it
and
then
just
like
yesterday,
someone
chimed
so
I
rewrote
jen's
vr
and
said
you
know:
can
I
get
review
and
and
so
forth,
testing
and
review
just
rewrote
it,
so
it
would
pass
tests
and
and
rebase.
B
You
know
no
changes
to
what
it
did
and
then
just
recently
someone
came
in
and
said:
oh
I
like
the
former
one
better,
so
that
then
kind
of
so
now
we've
got
people
wanting
both.
How
do
we?
How
do
we
resolve
them?
Yeah?
Well,
we
don't
have
a
thing.
An
official.
C
Process
for
that,
but
my
gut
says
that
I
like
that
one
better,
won't
cut
it
unless
it
says
because
enlists
points
like
so
we
I'm
I'm
very
passionate
about
ux
issues.
So
if
and
I'm
not
saying
that
I
always
catch
everything
ux
related
right,
but
in
the
example
of
the
contextual
links,
because
one
of
the
solutions,
cr
breaks
things
or
has
potential
to
break
things
and
it
adds
complicated
configuration
options
to
the
user
interface.
C
Although
I
didn't
like
the
other
solution,
I
leaned
toward
the
towards
the
other
solution
now
because
sort
of
like
it
it
it
sort
of
like,
doesn't
have
those
issues,
but
with
that
one
that
you're
saying
like
I
haven't
seen,
I
know
which
issue
you're
referring
to,
but
I
haven't
gotten
a
chance
to
to
review
it
recently
yeah.
So
we
need
a
summary
of
pros
and
cons
of
both
and
a
summary
can
be
done
by
a
single
person
and
then,
if
they
miss
something,
someone
can
come
and
say.
C
A
Do
I
do
think
that
if
we
don't
reach
a
decision
easily,
we
have
a
process
for
that,
and
that
would
be
like
okay.
Well,
it
looks
like
you
know.
Four
people
like
one
and
four
people,
like
the
other
and
there's
pros
and
cons
to
both
kick
it
to
the
pmc
and
they'll,
make
the
final
decision.
So
I
don't
think
we
should
let
it
drag
on
really
long.
I
think,
in
this
case,
like
our
goal,
is
to
get
it
in
the
next
core.
A
E
A
Pmc
respond
quickly,
which
they
don't
always
do,
but
that
would
be
my
recommendation.
D
D
That's
the
other
thing
sort
of
for
me
before
going
to
the
pmc
like
be
sure
to
bring
it
up
in
a
meeting,
because
sometimes
the
discussion
helps
settle,
something
that
isn't
getting
settled
in
the
you
know
in
the
issue
and
then,
if
that
doesn't
settle
it,
then
that
bmc.
B
C
Would
get
this
like
in
this
specific
situation?
Would
be
user
studies,
so
the
problem
that
we're
trying
to
solve
is
this
ui
is
confusing
to
people
to
newcomers.
C
So
if
we
can
get
people,
and
ideally
people
that
are
not-
are
familiar
with
cms,
the
cms
sort
of
like
mentality
like
using
other
cmss
and
then
drop
them
in
that
ui
and
ask
them
questions
or
do
a
specific,
targeted
ux,
because
we're
making
a
lot
of
assumptions
and
we
have
been
working
with
drupal
and
backdrop
for
like
a
really
long
time.
So
our
assumptions
might
not
be
solving
the
ux
problem
that
we're
trying
to
solve.
So
we
have
two
different
solutions.
C
Ideally,
we
should
solicit
help
from
these
kind
of
people
and
say
hey,
which
one
you
found
less
confusing
right
and
that
should
provide
another
sort
of
like
bullet
point
in
the
checklist.
Like
newcomers
found
this
more
intuitive
or
easy
whatever.
C
D
Side
by
side
screenshots
help
as
well
yeah,
I
think
greg's
thing
about
you
know
what
I
often
find
is
that
coming
in
and
summarizing
an
issue
that
gets
to
be
divided
like
this
and
making
a
clear
distinction
between
what
the
options
are,
will
let
other
people
come
in
and
weigh
in
and
then
a
consensus
may
form
so
and
then,
like
I
said,
bring
it
up
at
the
meeting.
So
I
don't
know.
Is
it
something
we're
talking
about
right
now?
A
B
Yeah,
I
I
I
can
like
take
the
action
with
screenshots
and
a
new
comment
with
screenshots,
because
it's
a
pretty
long
comment
thread
now
right.
C
Yeah
and
actually
in
the
other
issue,
26
26
doc,
I
summarized
things
and
dr
brought
up
a
very
valid
point
that
hey,
if
there's
two
pull
requests
which
usually
some
like
most
of
the
times,
they
work
having
to
pull
requests
into
sandboxes.
To
compare,
compare
but
doc,
wilmot
says
if
I'm
testing
then,
and
I'm
to
use
the
pr
works
for
me
or
rtbc
tag
which
one
of
the
two
pr's
am
I
to
be
seeing.
A
Yeah,
I
mean,
I
think
I
think
it's
impo
it's
important
for
court
committers
to
know
like
which,
like
if
one
of
them
has
been
rtbc'd.
That
would
be
good
to
know.
A
I
think
probably
what
we
should
do
is
have
at
any
time
one
pull
request,
that's
like
currently
under
consideration
and
if
someone
recommends
another
one
and
everyone
goes
oh,
I
like
that
better,
we
switch
it,
and
so
there's
always
one
like
lead
candidate,
and
we
can
do
that
with
the
pr
line
that
we
used
to
use
at
the
bottom
of
the
issue
summary
where
we
indicate
which
one
it
is.
A
I
know
it's
really
nice
to
have
the
github
links
in
the
sidebar,
but
when
there's
more
than
one
that
does
become
confusing,
but
I
think
if
we
have
that
comment
in
the
top
issue,
that's
like
this
is
the
one.
Then
all
of
the
labels
for
like
works
for
me,
whatever
can
go
on
that
one
and
then,
if
everybody's
like.
Oh,
I
do
like
this
new
idea
better.
A
We
can
switch,
remove
the
labels
and
then
retest
re-uh
code
review
on
the
new
one
and
that
way,
if
a
core
commander
does
get
to
the
issue-
and
there
are
two
pull
requests-
it'll
be
really
clear,
which
one
is
the
one:
that's
ready
for
consideration,
or
we
could
close
the
other
one.
If
it's
obvious
that
that
one's
not
getting.
D
Yeah
but
my
my
personal
opinion
is
that
if
there's
two
full
requests,
it's
not
really
ready
for
code
review,
you
know
we
have
to
make
a
decision.
So
I
you
know-
and
I
don't
know
that
having
two
different
issues
solves
the
problem
because
then,
actually
I
think
that
makes
it
worse.
Because
that's
worse
so
I
you
know,
I
would
rather
just
say
that
is
one.
D
You
know
that
when,
if
somebody
introduces
a
second
full
request,
that
should
be
at
the
stage
where
we're
still
just
talking
about
it
and
looking
for
a
solution
and
we're
not
really
ready
for
a
code
review
yet
right
and
it
isn't.
The
code
review
doesn't
really
make
sense
to
me
until
we've
kind
of
decided
and
limited
it
to
one.
A
Sometimes
it
comes
after
that,
like
like
the
process
could
be.
Oh
I've
got
a
thing:
here's
a
full
request.
Here's
a
code
review,
wait.
I
have
a
new
idea
and
at
that
point,
like
obviously
the
rtbc
stays
on
the
first
issue
until
people
decide,
the
new
idea
is
better,
but
we
should
have
a
process
for
like
how
do
we
officially
make
that
change,
and
sometimes
the
person
who
wrote
the
pull
request
isn't
around
to
close
it.
D
You're
right,
I
think,
that's
happened
and
I
think
normally
that
when
that's
happened,
we
just
you
know
whoever
is
leading.
The
issue
is
kind
of
indicating
which
one
they're
working
on
so
maybe
formalizing
that
a
bit
would
help.
But
that's
not
the
situation
with
with
the
current
one.
The
current
one
is,
we
don't
even
know
which
direction
we're
going
so
like
doing
doing
a
code
review
is
maybe
a
little
premature
right.
We
gotta
figure
out
which
direction
we're
going.
C
So
the
next
fact
would
be
ascending
yeah.
I
would
say
that
these
things
organically
sort
of
like
already
happen.
We
don't
have
an
official
sort
of
like
guideline
and
sometimes
the
the
alternative
solution
is
so
drastically
different,
that
it
does
get
split
to
a
separate
issue,
but
that's
not
the
majority
of
the
times
that
this
happens.
I.
A
Do
think
it
would
be
good
to
have
a
process
documented,
especially
for
people
who,
like
don't
know
how
this
stuff
works.
If
we
could
just
be
like
you
know,
this
is
what
we
usually
do.
You
mostly
know
how
things
work,
but
then
you
know
here's
a
scenario.
You've
never
been
in
before.
Where
now
there's
two
pull
requests
and
I
don't
know
how
to
do
just
having
some
kind
of
guidance
written
there
to.
C
A
Indicate
the
current
one
in
the
top
issue
summarize
the
state
of
the
two.
If
you
still
can't
reach
a
consensus,
kick
at
the
pmc,
hopefully
the
summary
and
the
indication
of
which
one's
preferred
in
the
talk
issue
is
enough.
D
D
A
We
do
have
a
section
on
the
doc
site
for
using
the
issue,
queue
that
might
be
a
good
place.
C
At
some
point
it
was
in
the
main
side,
but
I
think
that
we
moved
it.
If
we
didn't,
we
need
to.
A
D
D
Bring
it
to
a
meeting
elevate
that
pmc
right.
D
D
So,
while
we're
just
talking
about
process,
there's
another
scenario
right
now
that
I
don't
know
if
there's
like
a
it's,
the
herbs
that
you
could
and
robert's
familiar
with
this
herb's
got
duplicating
full
requests.
I
think
you
commented
no,
no,
it
was
in
the
gospel.
That's
right
that
they
commented
on
that.
D
D
Ids
and
I
feel
like
all
of
these
issues
are
stalled
because
there
is
so
interrelated
that
you
know.
How
can
you
make
a
decision
on
one?
If
you
don't
know
what's
happening
in
the
others
yeah?
They
were
deliberately
broken
apart,
because
there
was
some
disagreement
like
some
people
thought
that
we
should
add
the
automatic
classes,
but
not
the
so.
But
but
you
know
now
it's
better
broken
apart
and
herb's
got.
D
A
A
D
That
that
was
the
right
move.
My
expectation
would
have
been
that
we
would
have
made
that
first,
the
consensus
decision
first.
So
then
we
could
talk
about
the
other.
But
what's
happened
is
that
both
of
them
are
being
debated
alongside
each
other,
as
if
they're
like
competing
proposals,
and
it's
gotten
confusing
so
yeah.
F
D
A
Yeah,
I
also
think
if
this
might
be
a
good,
a
good
use
case
for
putting
a
summary
at
the
top
of
each
one
in
terms
of
pros
and
cons,
and
you
know
I
there
was,
I
know
like
some
of
them.
There
are
things
where
I
was
like.
We
don't
need
that
and
then
someone's
like
you,
use
it
on
your
own
website,
and
I
was
like
oh
right,
that's
very
clear
that
there
was
a
use
case
there
that
I
wasn't
considering
it's
just
having
that
listed
at
the
top.
C
I
think,
as
actionable
items,
we
should
document
the
process,
even
if
it's
conditional
as
in
if
this
happens,
then
that,
because
it's
not
it's,
it's
apparent
that
it's
not
a
single
process
that
we
follow.
It
depends
on
how
things
evolve
and
it
might
be.
It
might
also
depend
on
the
person
that
is
actually
suggesting
the
alternative.
They
might
feel
that
it's
totally
a
totally
different
issue
right
and
specifically
for
the.
C
The
2626
issue
is
stated,
like
the
title,
is:
add:
contextual
menu
for
quick
access
to
blah
blah,
whatever
right
so
so.
This
is
a
an
issue
that
has
a
specific
title.
If
it
is
an
issue
that
has
a
problem
listed
as
in
fix
this,
then
multiple
pull
requests
or
solutions
can
be
added.
C
D
Would
recommend
that
that
I
mean
I
think
we
have
some
actionable
like
we
want
to
draft
up
some
guidelines
on
this,
and
I
would
think
that
we've
only
got
20
minutes
left
in
this
meeting
and
we're
two
weeks
from
code
free.
So
are
there
some
issues
that
we
could
actually
unblock?
C
Yeah,
so
the
main
issue
that
I'm
working
towards
is
1040,
which
is
basically
the
the
inline
form
errors,
but
before
we
get
to
do
that,
there's
two
other
issues
that
need
to
be
sorted.
So
I'm
currently
working
on
issue
43,
sorry
5348,
which
is
allow
forms
to
set
custom
validation,
error
messages
right
and
robert.
Thank
you
for
reviewing
that.
But
I
realized
that
something
has
broken
and
I
need
some
advice.
C
I
I
I
can
like.
I
can
fix
it,
but
I
need
some
advice
about
ux
issues,
so
the
way
that
the
search
form
currently
works
like
if
you
go
to
slash
search
once
you
enable
it.
You
have
a
search
field
and
then
you
have
oh
by
the
way.
Jen
your
keyboard
is
too
loud.
C
It's
yeah
thankful,
so
the
we
have
the
main
search
field
and
then
a
search
button
and
then
there's
a
collapsible
field
set
below
it,
which
says
advanced
search
and
it
has
more
fields
right,
and
it
also
has
another
submit
button
which
says
advanced
search.
C
So
you
have
to
submit
buttons
in
the
form
and
the
issue
there
is
with
the
form,
validation,
so
how
it
used
to
work
is
that
if
you
add
a
term
on
the
main
field-
and
you
click
the
advanced
search
button
without
filling
anything
in
that
gets
lost,
so
you
get
validation,
errors,
I'll,
explain
things
like
I'll,
allow,
screenshots
and
workflow
like
steps
to
reproduce
the
issue.
C
But
the
main
point
is
that
previously,
if
you
had
a
search
term
on
the
main
field,
expanded
the
advanced
shirts
and
added
more
things
when
you
submitted
the
advanced
search
button,
the
the
term
that
you
added
on
the
main
field
was
returned
retained.
Now
it's
not
being
reclaimed
so
it
gets
lost.
C
B
C
C
C
Oh,
maybe
I
pushed
the
chains
since
sorry,
but
but
the
point
is
that-
or
maybe
these
were
not
retained.
C
I
have
to
take
another
look,
but
my
point
and
the
the
decision
that
I
want
to
make
is:
do
we
actually
need
two
to
submit
buttons
here
because
they
actually
go
through
the
same
validation
and
submission
process,
and
I
was
thinking
that
if
we
move
like
there's
no
there's
nowhere,
that
I
know
that
this
advanced
stretch
thing
becomes
an
individual
thing
that
you
can
use
on
its
own,
like
this
form
here.
A
A
A
designer
input,
because,
if
we're
going
to
figure
out
well
moving
the
search
thing
below,
creates
a
problem
for
people
who
aren't
using
advanced
search.
We
would
need
to
like
deal
with
it
separately,
for
whether
advanced
search
is
available
to
the
person
or
not,
and
usually
it's
that's
a
permission.
Based
thing:
it's
not
like
a
setting,
so
it's
a
little
trickier
and
then
for
when
we
I
also
agree.
A
We
should
only
have
one
button
but
trying
to
figure
this
out
as
hard
and
then,
if
we
did
want
to
try
and
figure
out
how
to
take
the
advanced
search
stuff
and
push
it
closer
to
where
the
search
box
is.
That
is
probably
going
to
need
some
one
with
some
design
skills
to
figure
out
how
to
organize
that
in
a
way,
that's
going
to
make
more
sense.
A
C
C
I'll
quickly,
spin
a
demo,
so
I
think
that
this
thing
was
not
there
before
so
this
is.
This
is
probably
one
of
my
workarounds
to
retain
this
functionality
here.
C
But
yeah
would
you
would
you
guys
prefer
it
if
I
spin
another
issue
for
to
figure
out
that
thing
it's
going
to
be
related
to
everything,
but
it's
another.
It's
yet
another
rabbit
hole,
because
the
main
issue
was
not
that
the
main,
the
main
issue
that
I'm
working
on
is
basically
making
these
things
required
automatically
trimming
values.
B
C
Yeah
yeah,
so
so
this
works
with
a
current
pull
request.
If,
if
the
so,
the
original
issue
is
this,
this
would
say,
search
field
is
required
or
something
like
that.
And
then,
if
you
have
this
and
then
the
example
that
I
mentioned
is
imagine
for
some
reason,
another
person
has
a
search
block
here
that
is
showing
up
here
right,
which
search
field
is
required.
This
is
not
called
search
field.
It
has
a
label
of
enter
your
keywords
right.
C
So
the
the
even
the
code
had
the
inline
comment,
which
was
saying
that
the
message,
the
error
message
is
confusing
and
it
basically
comes
down
to.
C
C
C
Yeah,
so
just
let
me
stop
sharing
the
screen
if
I
can
find
yeah.
C
So
here's
the
thing
in
trouble:
eight
they've
implemented
html
native
html
error,
sort
of
like
validation,
and
that
was
the
problem
that
they
were
facing,
that
the
errors
were
too
generic
anymore,
and
sometimes
there
were
situations
where
you
couldn't
tell
which
error
was
was
for
which
field
when
they
were
required
and
that's
what
I'm
trying
to
to
to
so
in
drupal
8.
They
basically
implemented
the
inline
error
solution,
and
now
they
have
this
regression.
C
C
C
A
Another
thing,
too,
is
so
in
backdrop.
We
also
have
a
required
attribute
on
required
fields.
We
could
set
up,
and
this
might
already
exist-
some
form
api
abilities
where
you
could
define
when
the
browser
should
add
the
required
attribute
and
when
it
shouldn't,
because
we
could
have
only
only
our
validation
and
not
browser
validation.
So
if
there
is
something
like
in
this
case,
you
could
either
put
something
in
the
top
search
field,
or
you
could
put
it
in
any
one
of
those
advanced
fields
that
top
field
isn't
really
required.
A
When
you
have
advanced
search
turned
on,
we
could
have
something
like
that,
where
the
browser
won't
stop
you
from
submitting
the
form,
but
if
you
put
none,
none,
nothing
in
any
of
those
fields,
we
obviously
still
need
an
error.
That's
like
one
of
these
fields
is
required,
so
there
might-
and
I
don't
think
right
now-
we
have
a
way
to
make
a
field
required.
C
You
get
into
states
territory
there
where
states
cannot.
No,
let
me
rephrase
that,
because
I've
done
a
research
a
couple
of
weeks
ago,
in
order
to
make
the
required
thing
conditionally
apply,
it's
a
bit
tricky
it
still.
It
can
still
happen,
but
you
have
to
dig
down
to
the
value
of
the
like
states
normally
requires
to
enter
the
name
of
the
field,
whereas
now
you
have
to
go
down
to
undefined
zero,
something
like
the
value
and
rely
on
that.
It's
still
possible.
C
It's
undocumented
and
I
found
the
respective
articles
indeed.,
but
again,
it's
sort
of
like
we're
getting
down
multiple
rabbit
holes
in
the
form
api
quirks
of
what
needs
to
happen.
So
yeah
anyways
I'll,
try
to
summarize,
and
maybe
even
split
a
separate
issue
for
those
things
so
that
it's
clearer,
but
in
the
meantime,
robert
what
I've
done
is
so
the
this
thing
was
the
addition
of
this
thing
and
how
I
discovered
that
this
is
a
problem.
Now
was
based
on
your
feedback.
C
Yeah,
so
I
think
that
I
have
to
review
the
the
issue
that
what
you
mentioned
is
that
it
was
working
for
the
main
search
field,
but
the
error
message
was
different.
If
you
added,
if
you
omitted
terms
on
the
advanced
sets,
he
said
shouldn't
that
be
the
same
and
say
yep
that
should
be
easy,
fixed
it,
and
then
you
reviewed
it.
He
said
it's
ready,
but
now
I've
found
this
regression.
C
C
All
right
does
anyone
have
any
other,
ux
or
design
meeting
sorry
issue
that
they
would
like
us
to
review,
even
if
it
doesn't
happen
now
like
that
they
want
us
to
draw
our
attention.
D
I'll
just
mention
that
new
hidden
path,
content
type,
but
we've
sort
of
made
some
progress.
We
have
a
pull
request.
Olaf
has
raised
some
questions
and
we're
going
to
need.
You
know
I
think,
to
make
this
happen
in
this
issue.
We're
going
to
need
a
fair
amount
of
feedback.
So
you
don't
have
time
right
now,
but.
C
People
can
look
at
that.
Did
we
solve
the
issue
where
things
wouldn't
work
on
installation
on
the
type
of
yeah
that
back
willmon
figured
that
out?