►
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).
B
So
one
of
the
design
problems
I'm
trying
to
address
is
oh
welcome.
Nick
welcome,
blair,
hello,
so
yeah
we're
daniel
and
I
were
just
kicking
off
one
of
the
design
problems.
I've
been
trying
to
approach
is
in
part
because
of
a
very,
very
minimum,
viable
change.
B
The
compliance
group
introduced
many
moons
ago
this
button
right
here
does
not
actually
have
anything
to
do
with
what
is
on
the
rest
of
this
page
is
just
like
a
combination
of
data
on
this
page
and
then
a
completely
separate
feature
as
a
way
to
get
your
merge
commit
history,
you
can
search
for
a
specific,
commit
or
just
export
the
list
itself,
so
yeah.
It
has
nothing
to
do
with
this.
This
has
all
to
do
like
merge
requests
violations,
and
this
has
to
do
here.
B
Merge
commits
so
based
off
of
some
of
that
user
feedback.
We've
gotten
from
both
a
few
customers,
but
also
like
our
sales
team
and
people
have
been
trying
to
put
together
like
recommendations.
People
were
very
confused
about
what
that
button
did
or
how
it
related
or
how
it
worked.
B
What
made
the
most
sense
to
me
was
creating
a
separate
page
for
each
of
these
two
features,
but
since
this
feature
is
just
purely
data
in
a
csv,
I
wanted
to
try
and
like
bring
that
data
forward,
a
way
that
you
could
search
it
and
then
still
retain
the
functionality,
but
where
I'm
hung
up
is
what
would
be
worthwhile
to
validate
from
a
research
perspective.
B
B
So
I
have
all
these
ideas
that
I've
kind
of
broken
up
across
numerous
issues.
So
this
is
a
bigger
epic,
but
I'm
kind
of
like
what
should
I
go
test?
What
would
be
meaningful?
I
don't
necessarily
think
it
would
help
too
much
to
say.
Okay,
can
you
find
this
specific
commit
and
then
export
it,
because
I
know
they
can
they
already
do
that
today?
This
will
just
make
it
a
little
bit
easier
to
do
it
in
the
ui,
rather
than
exporting
it
to
a
google
sheet
and
then
filtering
the
data.
B
I
wouldn't
say
have
like
a
list
of
just
requests:
it
was
more
or
less
like
an
amalgamation
of
just
hearing,
different
posts
and
slack
or
reading
different
posts
and
slack
and
more
or
less
just
examining
the
fact
that
these
things
are
not
tied
together
at
all.
So
why
do
we
have
them
on
the
same
page,
it's
like
kind
of
like
incongruent
design
principles
to
me.
B
So
I
feel
like
this
would
be
the
most
logical
iteration.
Next
would
be
to
take
all
that
data.
That's
currently
hidden
behind
a
csv,
so
some
things
that
would
be
painful
for
the
user
right
now.
Is
you
don't
know?
What's
going
to
be
in
the
csv
file,
you
have
no
idea
how
big
it
is
if
you're
searching
for
a
merge
commit.
You
also
have
no
idea
if
it's
going
to
work
until
you
actually
hit
the
export
button
and
wait
for
the
file
to
be
generated
for
you.
So
there's
some.
B
I
would
assume
some
better
ways
to
bring
basic
functionality
into
the
application
without
having
to
do
like
a
giant
research
initiative
around
it,
because
it's
like
we
know
it's
too
minimal,
but
it
was.
It
was
initially
released
as
to
be
the
most
minimal
thing,
so
I
was
trying
to
think
of
like
what
would
be
the
most
meaningful,
valued
iteration
next,
and
what
made
sense
to
me
was
bringing
that
data
into
gitlab
so
that
users
don't
have
to
leave
the
product
in
order
to
interact
with
the
data.
C
Yeah
I
mean
it
makes
sense
that
you
that
this
is
an
mvc,
but
for
me,
like
my
assumption,
would
be
based
off
of
the
previous
work,
where
the
mvc
was
just
like.
Okay,
this
is
our
first
step.
Was
there
a
trail
or
an
idea
where
it
would
go
next,
and
does
this
fit
into
that?
Or
did
it
kind
of
just
die
off
and
it
was?
The
mvc
was
the
end
of
the
road.
C
Because
I
can,
I
remember,
like
what
we
were
talking
about
was
like
a
dashboard
system
and
a
monitoring
system
and
all
sorts
of
other
stuff
yeah.
So
I
don't
know
yeah
since
then
till
now.
If
that
still
has
validity
or
or
not,
because
this
is
not
really
a
dashboard,
this
is
just
strictly
correct.
An
export
csv
audit
report
trail.
B
Right,
so
that's
a
really
great
question
and
a
good
a
good
lead
into.
Why
is
the
compliance
report?
The
way
it
is
today,
so
this
current
functionality
is
nothing
more
than
the
data
we
already
have
now,
but
we're
actually
highlighting
what
was
wrong
with
the
merge
request
itself
like
in
this
scenario,
we
tell
you
it
was
approved
by
a
committer
or
had
less
than
two
approvals
today.
B
If
you
didn't
have
this
feature,
flag
turned
on,
you
wouldn't
be
able
to
know,
you'd
have
to
guess.
So
we
heard
a
couple
things
in
our
research,
which
was
the
data,
wasn't
much
of
a
dashboard
like
it
wasn't
giving
you
metrics
on
data.
It
was
giving
you
specific
things
to
investigate,
so
it
felt
like
more
of
a
report,
and
so
with
that,
like
I
think,
that's
why
this
tab
has
focused
on
the
reports
that
correspond
with
compliance.
B
But
at
this
point
we
don't
have
these
data
points
yet
so
we're
just
going
through
the
very
slow
process
of
refining
the
data
set
that
we
have
currently
and
we
can
work
towards
a
more
holistic
dashboard,
but
the
biggest
thing
we
heard
from
users,
specifically
compliance
managers,
was
they're
looking
for
points
in
which
to
investigate
further
or
to
create
artifacts.
Those
are
generally
their
two
biggest
jobs.
They
got
to
find
out
if
there
are
any
violations
that
happened
and
then
they
got
to
be
able
to
share
those
findings
with
auditors.
B
So
yes
like
it
does
look
like
just
like
a
table
of
results,
but
that's
what's
proved
most
useful
for
them,
but
currently
this
like
separate
feature
to
export
the
commits
everything
has
to
be
done
outside
of
gitlab,
so
just
trying
to
really
prevent
that
from
having
to
happen.
C
This
reminds
me
a
bit
about
the
thread
that
becca
had
brought
up.
I
put
the
link
in
the
agenda.
She
wants
to
propose
like
a
complex
reporting
system
which
just
feels
kind
of
related
to
that
in
the
you're
building
the
assets
or
the
data
that
you
need,
and
it
kind
of
describes
a
little
bit
what
you
mentioned.
C
B
D
Yeah,
I
I
I
think
this
is
a
good
approach
like
having
the
tab.
D
Getting
more
data
in
into
gitlab
rather
than
having
it
done
somewhere
externally
is,
is
useful
because
you
can
you
can
track
what
the
user
is
doing
and
therefore
get
a
better
understanding
of
like
the
direction
that
you're
going,
and
this
is
just
like
a
fairly
standard
pattern
that
we
see
in
like
analytics
as
well
just
the
tab,
tab
above
the
table,
so
it
sort
of
seems
to
align
with
the
way
that
we
structure
things
now
and
then,
if
you,
if
you
take
that
csv
and
you
put
it
in
gitlab,
it
means
you
can
track,
learn
and
iterate
on
on
whatever
data
you
gather
from
it.
D
So
I
think
this
is
a
good
direction,
certainly
a
good
next
step
compared
to
what
the
mdc
was.
B
Got
it
so
if
I'm
merging
you
correctly
nick,
you
wouldn't
necessarily
say
you
should
definitely
go.
Do
some
solution,
validation
on
a
specific
task
or
something.
This
just
seems
like
the
next
logical
step
of
expanding
the
offering
to
something
that
we
do
fairly
commonly
across
the
product
and
then
telling
you
what
daniel
was
saying
was
perhaps
there's
a
way
that
we
can
make
that
more
standard
across
the
different
components
of
gitlab.
D
Yeah,
it's
a
fairly
standard
way
of
presenting
data,
and
if
the
data
that,
if
the
data
that
was
downloaded
off
csvs
was
validated
as
useful
data,
then
I
think
that's
probably
good
enough
validation.
In
order
just
to
put
that
in
into
the
into
the
system
into
the
interface.
B
That's
a
great
question
too,
was
the
data
valuable.
This
is
very
confusing.
It
was
confusing
to
me
at
least
we
use
specifically
merge
commits
right
now.
That's
the
only
thing
you
can
find
in
there,
but
all
of
our
users,
not
all
of
our
users.
Many
users
have
put
in
requests
asking
why
they
can't
look
up
all
commits
it's
it's
a
back
end
limitation
right
now.
I
would
love
to
see
that
go
away,
but
I
don't
know
it
will
be
feasible
to
index
and
be
able
to
pull
all
that
data
in.
B
D
B
Yeah,
if
you
go
to
a
specific
project,
get
a
repo
you'll
go
to
commits
yeah.
You
can
look
them
up
there.
D
D
Is
that
would
that
be
necessary,
like
I
don't
know
like
how
do
you?
How
do
you
create
more
of
a
thread
between
them?
Is
the
constant
thing
I've
been
thinking
with
like
optimizing
stuff.
B
Yeah,
I
I
think
what
we've
heard
from
users
what's
frustrating
and
I'll
I'll,
try
and
wrap
it
up
here,
so
I
don't
take
up
too
much
time.
B
They
want
to
be
able
to
take
like
a
list
of
commits,
ideally
that
someone
has
sent
them,
maybe
like
their
development,
vp
or
something
and
be
able
to
take
these
shaws
from
the
commits
and
then
be
able
to
go
into
our
feature
and
grab
specific
ones,
so
they
won't
be
able
to
drop
it
in
paste
it
here
and
be
on
their
merry
way,
but
they
can't
so
I
mean
possibly
the
other
part
that
makes
it
fun
is.
This
is
a
group
a
root
group
feature?
Well,
no!
B
B
B
They
just
do
everything
in
this
commit
page
in
general,
yeah
yeah,
I
initially
was
wondering
but
yeah
I
mean
I
think
the
biggest
thing
is
it.
You
can't
see
it
because
it's
in
the
csv,
but
you
get
to
find
out
more
data
about
that
specific
merge,
commit
that
you
don't
just
see
at
the
glance
here
and
that's
what
they
want.
So
they
want
to
see
that
data
alongside
their
commits,
but
it's
a
very
like
it's
very
auditor
perspective.
B
B
D
D
Just
just
because
there's
like
a
there's
a
gravity
to
it,
like,
I
feel
like
I'm
more
inclined
to
have
to
accept
adding
features
than
stripping
them
away.
So
that
sort
of
prompted
the
question:
how
how
can
we
start
to
incentivize
stripping
away
stuff
in
the
interface
once
something's
added?
So,
for
example,
austin's
just
just
done
an
mvc
there
with
the
compliance.
D
So
my
question
here
within
this
is
like:
how
can
we
incentivize
stripping
stuff
away
after
an
mvc
has
potentially
been
tested?
What
processes,
what
thing?
What
tools
can
we
put
in
place
in
order
to
in
order
to
make
this
happen?
So
my
first
proposal
here
is:
we
have
the
feature,
scoped
label
and
you
can
see
our
bias
within
gitlab
is
there's
either
feature
enhancement
and
feature
addition
within
the
scope,
labels,
there's
no
feature
reduction
or
consolidation
or
anything.
So
this
is
my
proposal.
D
I
was
wondering
if
anyone
else
has
proposals
either
to
do
with
this
issue
that
I
was
shared
or
with
this
just
general
problem
that
I've
experienced
within
gitlab.
In
my
time,
I'll
pause
there
and
and
open
up
the
floor.
C
I
do
think
there
is
value
in
that
the
thinking
about
reducing
the
complexity
or
reducing
the
features
that
are
bloated
so
to
speak
or
have
outlived
their
their
usefulness,
and
I
do
think
that
we'd
lack
that
categorization.
So
definitely
from
that
perspective,
I
don't
see
the
the
reason
not
to
add
this.
C
The
problem
I
encounter
specifically
in
context
with,
like
a
comment,
jeremy
made.
He
said
that
he's
encountered
a
few
proposals
that
add
complexity
where
he
thinks
the
opposite
should
be
explored
more
fully.
C
And
so
I
think
I
would
want
more
guidance
on
what
consolidation
or
feature
removal
should
look
like
in
a
complex,
app
or
environment
right.
So
my
argument
is
that
speaking
of
the
example
that
I'm
thinking
of
this
table
builder
idea
that
I
feel
that
reduces
complexity,
because
you're
removing
the
sort
behavior
from
two
different
locations
and
putting
it
in
one
location.
C
D
Yeah,
that's
that's
a
really
it's
a
really
valuable
point
and
like
if
it's
straight,
like
I
often
think
about
it
in
terms
of
like
when
you
are
making
a
trade-off.
Where
are
you
pushing
the
complexity
to
so
like
with
with
when
we,
whenever
we
decide
on
what
an
mvc
should
be?
The
nbc
is,
is
some
level
of
of
trade-off
between
something
for
the
user,
so
desirability
something
for
the
the
business
viability
and
something
for
the
the
technical
side
which
feasibility
and
often
with
the
mvc.
D
We
tend
to
bias
towards
the
the
feasibility
side,
and
then
we
push
the
complexity
onto
the
user,
so
that
means
like
they
need
to
configure
something
a
little
bit
more
before
they
whatever
that
may
be.
So
I
I
suppose
it
comes
down
to
creating
the
the
right
business
case
to
say
this
is
actually
stripping
away
complexity,
but
it
needs
to
be
anchored
within
persona,
yeah
cool.
That's!
No!
But
that's!
That's
super!
That's
super
important.
I
appreciate
that.
B
B
B
So
I
had
opened
an
issue
for
front
end
to
review
it
six
months
later
and
see.
What's
usage,
look
like
the
tldr
on
it
as
no
one
uses
it.
So
this
feature
actually
brought
a
ton
of
like
technical
debt
to
the
product
in
terms
of
we
needed
to
like
update
the
component
fix
bugs
that
came
up
with
it
deal
with
like
weird
constraints
that
showed
up
with
using
it
in
conglomerate
right
in
conjunction
with
the
date
range
selector
itself.
B
So
all
those
will
disappear
because
I'm
saying
no,
let's
just
delete
it
because
it's
not
actually
add
any
value
but
like,
for
example,
I'm
leaving
the
compliance
team
to
go
different
group.
The
new
designer
probably
wouldn't
have
had
that
perspective,
and
I
think
we
just
have
a
lot
of
that
in
our
product,
like
we
don't
have
the
perspective
of
why
it
was
added
in
so
it's
hard
to
know
why
we
should
remove
it.
Mine
was
if
no
one's
using
it.
Then
I'm
going
to
take
it
out.
B
B
But
if
you're
looking
for
someone
that
I
think
that
is
very
good
at
tactfully,
trying
to
decide
how
to
introduce
prop
like
features
into
the
product
code
review
is
particularly
sensitive,
especially
around
like
merge
requests
and
kai
is
very,
very
data
oriented
when
it
comes
to
justifying
whether
something
needs
to
be
added
in.
B
So
I
added
a
thread
in
which
he
actually
helped
pull
data
from
sisense
and
like
walk
through
like
why
his
thought
process
of
looking
at
that
data
set
would
inform
whether
or
not
we
should
add
something
in.
I
think
it's
something
that
we
could
all
challenge
ourselves
to
do
more
of,
but
it's
I
mean
I
realized
it's
freaking
hard
to
like
think
about
it
in
that
way
and
then
really
come
up
with
it.
But
it's
a
great
question:
it's
a
great
question
overall.
Hopefully
those
things
will
give
you
some
inspiration.
C
Yeah,
so
continuing
with
this
topic
of
needing
guidance
for
what
consolidation
could
be.
I
had
these
two
issues
where
I
lacked
documentation
in
the
pajamas
handbook,
the
first
one.
Let
me
share
the
screen
real,
quick.
C
Sure
why
not
we'll
share
the
whole
screen,
so
the
one
that
I
was
speaking
of
specifically
is
this
so
they're
something
I
wanted
to
talk
about
about
is
the
how
we
talk
think
about
our
components
and
right
now.
I
think
nick
spent
time
on
this
also
that
we
only
deal
with
stuff
at
the
object
or
the
basic
atomic
level
and
not
like
the
component
above
it
or
the
organism
level.
So
thinking
of
like
atomic
design,
why
are
these
functional
components
all
separate
and
all
in
different
places?
C
Again
they're,
just
everything
all
over
the
place,
but
there's
no
guidance
on
when
to
use
sort.
Filter
action
bars
drop
down
table
because
it's
not
a
more
or
less
atomic
component
or
a
small
defined
object,
because
we
don't
have
that
guidance.
So
I
was
hoping
that
at
least
there'd
be
a
way.
We
could
start
off
that
discussion
by
defining
a
search,
filter
or
sort
bar
component,
and
this
is
kind
of
just
a
rough
placeholder
issue
for
it.
C
There
was
also
this
related
issue
update
documentation
on
when
to
use
tabs
versus
filters,
because
there's
no
documentation
on
when
to
use
filters.
It's
tbd.
It
feels
like
some
stuff
in
the
design
system
is
still
lacking
guidance
see
to
do
so.
I
was
hoping
that
this
might
generate
some
discussion
with
the
group
I'll
try
and
bring
this
up
in
the
weekly
for
the
rest
of
the
team,
but
this
is
something
that's
kind
of
bugging
me
because
I'm
trying
to
work
on
some
workflows
and
some
wireframes
and
I'm
like.
Well,
what
method
do
I
use?
C
D
So
I
I'm
trying
to
dig
out
I
I
raised
this,
I
think,
probably
two
years
ago
trying
to
dig
out
the
filter
issue
and
where
we
came
to
where
the
challenge
is,
is
getting
the
engineers
on
board
to
actually
go
ahead
and
invest
time
within
creating
like
for
actually
creating
these
more
standardized
beyond
beyond.
Just
like
the
component
level,
as
you
say,
doing
it
at
the
organism
level
like
there's
a
lot
of
complexity
there
and
it's
hard
to
incentivize
the
engineers
to
actually
want
to
do
that.
D
So
I'll
share
the
I'll
share
the
thing
I
did,
but
I
definitely
feel
like
there's
there's
such
a
need
for
it
like,
for
example,
lists
we
have
different
code
for
issue
lists
commit
lists,
mr
lists,
all
this
sort
of
stuff.
Wouldn't
it
be
great
if
we
had
this
generalized
list
view
and
we
were
able
to
pull
in
data
in
a
standardized
way
from
from
whichever
apis
that
we
have.
D
C
I
would
kind
of
maybe
counter
that,
at
least
in
terms
of
my
example
with
like
the
filters
in
the
cert
search
and
the
sort,
and
that
I'm
not
going
to
suggest
that
it's
a
development
issue,
it's
more
of
strictly
a
documentation
aspect
that
we're
not
developing
the
component
as
a
single
organism,
but
rather
for
us
to
define
the
organisms.
This
is
how
it
works
and
that
we'll
just
plug
it
in
as
necessary.
B
I
feel
like
you're,
both
right,
so
what
I've
personal
experience,
I'm
trying
to
make
sure
I
pick
the
right
tab
here.
Let's
see
there,
we
go.
I
think,
that's
right,
so
bringing
up
your
example
we're
using
tabs
versus
filters.
We
can.
We
talked
about
this
a
little
bit
with
peter,
but
like
a
great
example
of
this.
Is
it
doesn't
necessarily
matter
for
say
what
the
component
is?
The
problem
all
has
to
do
with
how
the
back
end
can
handle
what
we
pass
to
it.
B
If
you
mind
my
analogy
and
those
load-bearing
walls
are
typically
non-performant
queries
that
we
have
to
build
around
so
in
this
situation,
you're
seeing
a
tab
for
enabled
two-factor
accounts
that
are
active,
completely
isolated
from
just
being
like
a
filter
underneath
this
tab
because
of
a
performance
issue.
B
We
can
try
to
document
that,
but
I
think
what's
hard
about.
It
is
depending
on
what
queries
have
been
built
on
the
back
end.
You
may
not
be
able
to
get
around
it
and
there
may
just
have
to
be
an
odd
or
different
user
experience,
because
of
that
I
run
to
the
situation
with
audit
events
and
compliance
reports.
The
constraints
are
completely
different.
B
It
depends
on
if
it's
a
group
or
if
it's
a
project
page
depends
if
it's
in
the
admin
area
and
it
all
just
kind
of
depends
on
how
big
the
data
set
is,
and
I
think
it's
both
engineering
challenge.
I
like
yeah,
you
don't
have
perfectly
indexed
databases
for
this
scenario,
but
then
also
like
we
haven't
like
perfectly
defined.
C
Yeah,
I
think
I
had
I
don't
know
if
that's
the
comment.
Yeah
the
ad
search
and
filter
categories
peter
had
dug
into
this
quite
a
bit,
and
that
was
his
comment
right
there
about
this.
B
Yeah,
I
don't
know
just
to
kind
of
like
put
this
out
there,
other
dan
damn
izzy
harris
kind
of
seeing
some
of
the
issues
that
we
are
facing
today.
What
are
your
thoughts?
What
are
your
impressions.
A
So
the
the
bit
that's
missing
for
me
is
a
lot
of
the
context
around
the
app
itself.
What
the
app
can
do,
how
it's
built,
but
the
the
challenges
are
sent
to
the
other
daniel
m
last
week,
like
the
challenges
of
when,
when
should
you
filter
using
tabs
versus
like
things
that
you
can
add
and
toggle
and
turn
on
and
off,
and
how
do
you
present
data
and
navigate
and
move
through
it?
When
does
consistency
help?
When
does
it
not
help?
Those
are
the
the
ugly
challenges
that
you
never
never
see.
A
People
talk
about
design
conferences
but
they're,
the
ones
that
we
we're
dealing
with
as
designers,
most
of
the
time
and
yeah.
The
only
answer
is,
it
depends
for
all
of
them,
which
is
really
frustrating
and
and
satisfying
so
that
the
challenges
all
look
like
ones
that
I've
had
to
hack
solutions
to
or
find
really
elegant
solutions
to
before,
but
yeah
it's
just
a
completely
different
context.
Again,
I'm
just
trying
to
get
my
head
around
at
the
minute
deep
in
the
onboarding,
yes
good.
A
It's
good,
satisfying
technical
design,
challenges
which
I
really
love.
So
it's
really
cool.
B
Sweet
sure,
sharing
that
perspective,
my
non-uh
articulated
opinion,
and
it's
not
pajamas,
I
feel
like
tabs,
should
be
distinct
pages.
They
should
not
be
filters
of
pages,
but
maybe
that's
where
documentation
should
come
into
play
like
we
should
define
that
something
like
that
should
be
a
pattern
yeah.
I
like
that
user
page.
I
totally
get
a
daniel.
C
Exactly
15
tabs,
that's
probably
like
what
I
was
trying
to
get
to
earlier.
Is
that
like
there
needs
to
be
standardization
on
this
and
there
needs
to
be
documentation
by
like
yes,
we
understand
tabs
are
an
easy
solution,
but
they
shouldn't
be
right.
If
you
have
something
that
you
want
to
filter
then
create
a
filter
for
it
and
then
request
engineering
to
create
a
filter
for
it
and
make
you
know.
B
Which
requests
having
a
page
for
pipelines
and
a
page
for
the
discussion
and
a
page
for
the
changes,
those
tabs
make
sense
to
me,
but
it's
like
when
I
look
at.
Let's
say
I
don't
know
this
is
the
you
know
page
that
has
tabs
that
doesn't
sort
of
make
sense
like
to
do's,
have
tabs
for
to
do
and
done
like.
Why
isn't
it
just
like
a
maybe
a
segmented
control
button
group
or
something
that's
like
applying
a
filter
to
the
existing
data
set?
D
Yep,
definitely
it's
it's
just
it's
constant
local
optimization,
rather
than
global,
optimization
like
doing
components,
is
global,
optimization
and
we're
trying
to
make
the
user
experience
consistent
across
the
product
when
it
comes
to
like
filtering
specifically,
and
it's
these
technical
decisions
or
technical
constraints
that
impact
the
the
team's
decision
making
to
actually
say
we
gotta,
we
gotta
use
tabs
in
this
case
and
all
that
sort
of
stuff.
So
that's
like
going
back
to.
Where
are
you
hiding
the
complexity
in
this
decision
that
you've
made.
A
Yeah,
it's
always
going
to
be
complex
for
someone,
I
guess,
isn't
it
and
we
we
get
to
choose
where
that
is
sorry,
I
guess,
and
coming
back
to
something
else
that
we
spoke
about
today
about
the
how
to
incentivize
stripping
away
features.
I
found
that
it's
like
relatively
easy
to
get
people
on
board
with
the
idea
yeah
yeah
we
if
we
built
it,
we've
got
to
maintain
it
and
take
out
all
of
these
things,
but
it
was
the
the
killer.
Word
of
that
question
was
incentivized.
I
think
that's
the
bit.
A
I
haven't
seen
done
effectively
anywhere
making
it
happen
because
it
doesn't,
it
doesn't
make
good
release,
notes
or
headlines
or
anything.
Oh,
we
removed.
We
took
away
things
yeah.
One
of
the
comments
suggested
thinking
about
is
tech
debt
and
maybe,
if
there's
any
performance,
metrics
that
attract
against
tech
debt
like
if
a
certain
number
of
issues
a
month
with
tech
debt
need
to
be
closed.
Maybe
that's
the
way
we
can
approach
it,
but
I
don't.
I
don't
know
enough
yet
to
add
anything
sensible
to
how
you
incentivize
it.
D
How's
how's
onboarding,
going
down
down
mh.
A
It's
it's
big,
but
it's
pretty
good,
I'm
hoping
start
of
next
week,
I'll
start
digging
into
import
and
optimize
and
see
really
work
out.
What's
going
on
there
and
start
being
able
to
add
some
value
the
week
after
that,
but
I
managed
to
get
the
gdk
up
and
running.
I
was
pretty
pleased
with
that
and
thankfully
it
was
a
lot
simpler
than
other
stuff.
I've
had
to
do
like
that
in
the
past.
D
Yeah
soon
enough
you
may
just
have
to
like
all
I
do
is
rely
on
git
pod
now,
which
is
an
absolute
lifesaver.
So
try
and
figure
it
yeah.
That's
have
you
tried,
have
you
tried
git
pod,
yet.
A
A
Yeah
but
it's.
C
B
Transition
is
still
underway,
I'm
just
kind
of
trying
to
wrap
up
a
few
design
ideas
at
the
top
of
my
head.
I
really
wanted
to
try
and
finish
a
really
even
start
category
maturity
scorecard
evaluations
before
the
new
designer
comes.
They
start
off
february
7th,
so
you'll
see
them
in
like
a
week
and
a
half.
B
You
know
two
weeks
if
they've
even
booted
up
their
laptop
on
time
for
this
meeting,
but
yeah
I'm
just
kind
of
working
through
a
few
of
those
things
and
starting
14,
9
I'll
start
picking
up
tasks
and
foundations,
I
probably
will
stop
attending
the
manage
related
meetings
and
then
yeah
just
kind
of
help
that
designer
on
board
and
get
familiarized
with
compliance.
They'll
probably
still
see
me
randomly
on
issues.
If
you
happen
to
jump
into
something
compliance
related
like
daniel
did
for
me
for
a
little
while.
C
B
C
D
Mr
with
pj's,
documentation
is
super
easy
yeah,
changing
the
components
a
little
bit
more
difficult
to
say.
B
But
it
sounds
like
if
you
got
the
change
documented,
then
it
would
give
you
justification
to
make
suggestions
for
changes
to
figma
or
to
our
component
front
end,
but
really
like
I.
I
do
think
if
you
just
came
up
with
like
a
do
or
don't
line
that
could
go
somewhere
in
our
pajamas,
don't
use
tabs
as
filters.
C
C
B
C
That's
the
whole
thing
too,
so
again
what
you
mentioned
earlier
about
the
the
lists:
they're
presented
differently
in
different
code
like
camel
or
view,
and
so
that's
another
tech
debt
that
we
have
is
convert
all
of
these
things
to
one
standard
one
or
the
other
right.
B
B
B
Some
have
the
search
magnifying
glass,
some
don't
some
have
buttons
to
hit
some
don't
it's
just.
We
have
a
lot
of
variations
of
the
search
itself.
D
Cool
well,
I'm
gonna,
drop
and
good
catching
up
with
everyone
have
a
good
rest
of
the
day.