►
From YouTube: Work Items Weekly Sync - 2021-07-20
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
Yeah
I
was
talking
to
lee
last
week
and
we
spoke
of
a
number
of
projects
at
least
working
on,
but
one
of
the
ones
that
was
interesting
that
came
up
was
the
fact
that
he's
keen
to
have
a
customer
database
for
service
desk,
and
rather
than
I
mean
we
discussed
the
various
options
of
whether
to
like
hold
off
or
to
go
ahead
and
build
this.
But
one
of
the
things
that
came
up
was
that
this
signs
an
awful
lot
like
like
a
work
item
like
it's
got.
B
Custom
fields
as
in
like
the
customer
has
a
billing
rate.
They
have
a
name,
they
don't
they're,
not
a
user
in
the
traditional
senses
and
that
he
specifically
doesn't
want
to
give
them
a
email
address
or
to
have
them
log
on
to
his
instance,
or
anything
like
that.
He
just
wants
a
billing
entity.
On
the
other
hand,
they're
not
really
quote-unquote
work
items
because
there's
no
work
to
be
done
on
a
customer,
they're,
never
finished
like
so
yeah.
B
C
I
can
go
first,
I
would
just
say
like
I.
I
think
that
it
is
similar
in
to
a
work
item.
I
think
we
should
be
careful
not
to
treat
everything
like
a
hammer,
though,
doesn't
mean
it's
not
a
bad,
a
good
idea.
C
I
personally
want
something
like
a
customer
or,
and
we
propose
an
organization
and
then
with
the
contacts,
basically,
because
I
want
to
figure
out
how
to
use
gitlab
as
a
crm,
so
we
don't
have
to
pass
paste
in
like
salesforce
links
when
a
customer
is
interested
in
a
feature
we
actually
roll
all
that
data
up
in
gitlab
itself.
I
think
that's
important
and
like,
at
the
end
of
the
day,
we're
building
a
collection
of
objects
with
defined
relationships
where
each
object
has
different
attributes
right.
C
How
we,
how
we
end
up
building
that
is
implementation,
details
that
I
would
lean
on
engineers
to
drive.
I
don't
think
it's
a
bad
idea
and
it
has
lots
of
use
cases
far
beyond
just
service
desk.
I
think
that's
my
two
cents.
C
I
think
customers
will
have
relationships
to
work
items,
but
I
don't
know
if
they
would
ever
have
like.
You
wouldn't
put
a
customer
necessarily
through
a
workflow,
but
what
this
does
open
up?
The
ability
to
do
is
use
work
items
as
a
way
to
like
track
opportunities
right
like
in
salesforce.
The
way
it
works
is
you
have
a
organization,
then
you
have
contacts,
but
then
you
have
these
like
opportunities,
which
are
more
temporal
type
things,
and
this
is
what
you
could
use
it
for
it's
like.
C
If
a
customer
has
a
request,
that's
like
a
work
item,
so
I'm
in
favor
of
making
a
first
class
thing,
but
if
there's
a
way
to
make
a
generic,
I
also
pitch
in
that
same
example
like
can
we
create
a
custom?
C
C
D
B
B
F
C
C
I
see
them
as
collaboration
really
because
really
a
merge
request.
The
only
thing
it's
doing
is
facilitating
the
merging
of
one
branch
into
another
branch.
So
a
code
change,
it's
not
the
actual
change
itself,
the
branches,
the
change
itself
and
then
the
merge
request
is
where
you
collaborate
on
that
change
and
that's
where
I
sort
of
see
work
items
as
generals
as
a
place
to
collaborate.
F
Yes,
we
are
rarely
going
to
like
differentiate
them.
I
would
think,
like
an
mr,
would
just
be
this
really
tiny
thing
where
it's
just
like
all
right.
This
is
just
the
execution
of
our
collaboration.
I
don't
know
if
we
want
to
get
like
that,
especially
at
gitlab.
It's
not
a
very
get
lobby
way
of
thinking.
I.
F
E
Sure
yeah,
I
was
just
saying
like
this-
is
kind
of
along
the
lines
of
what
lee
said.
You
know
once
we
give
we're
building
a
really
flexible
system
once
we
give
customers
these
tools
that
are
are
highly
customizable.
They
will
start
using
them
to
solve
problems
that
they
have
in
ways
that
we
may
not
have
foreseen.
So
it
may
be
worthwhile.
E
You
know
up
front
to
consider
if
we
do
have
strong
opinions
or
like
opinions
that
we
would
encourage
customers
to
abide
by
then
we
should,
you
know,
provide
a
document
or
something,
but
I
I
do
like
where
john's
train
of
thought
is
going
as
well,
so
let
him
voice
that.
B
If
I
get
spell
emergent
like
but
anyway,
yeah
like,
I
agree,
I'm
just
curious
about
what
what
they
might
do,
that
we
haven't
thought
of
and
what
they
might
use
it
for
and
whether,
like
we
should
we'll
see
emergent,
behaviors
and
then
like
be
able
to
adapt
to
those
behaviors
like
we'll,
see
a
need.
B
If
people
go
out
of
their
way
as
we
do
already,
I
guess
when
people
turn
the
application
to
a
certain
task
or
whatever
like
test
cases
where
we
built
them
as
an
object,
because
our
own
internal
team
were
building
out
test
reports.
Using
issues
like
there
might
be
some
interesting
insights
from
this
as
well.
C
Concern,
yes,
not
turning
into
gi
the
big
thing
that
I
was
actually
talking
with
a
large
customer
that
we
have
about
how
modeling
their
jrly,
interior
and
gitlab
and
they
talked
about
their
their
abusive
use
of
enforced
workflows
and
how
it's
impressive,
and
I
think,
that's
like
where
you
don't
want
to
go.
C
I
also
think
it's
interesting
when
you
give
people
a
set
of
tools
that
are
sort
of
flexible
and
because
then
they're
going
to
use
the
proctor
agent
design,
but
this
also
means
there's
an
opportunity
to
create
a
better
solution
for
the
job
to
be
done.
So
they
could
use
this
like
generic
sort
of
thing.
When
you
start
to
see
these
patterns
of
how
they
use
these
generic
kinds
of
things,
then
you
can
create
a
more
custom
solution.
C
It's
sort
of
like
the
approach
we've
taken
with
status
and
issue
type
right,
because
when
you
look
at
how
people
are
using
their
labels
and
what
they're
searching
for
the
most
at
least
on.com,
they
use
labels
for
type
and
for
status
right.
So,
instead
of
using
the
label
hammer
now,
we
can
create
a
better
experience
around
that
because
it's
submerged
as
like
a
consistent
need
that
we
want
to
productize.
C
C
G
So
it's
more
of
an
fyi
about
where
we
stand
with
the
work
items.
I
guess
everyone
is
on
we're
on
same
page,
that
we
are
moving
forward
with
issues
table
used
for
all
artwork
items
and
I'm
working
tirelessly
to
combine
everything
into
some
sort
of
a
developer
documentation
where
we
will
document
how
how
this
is
going
to
be
implemented
with
some
general
guidelines
and
stuff
like
that.
So
hopefully
I'll
have
something
ready
this
week
for
a
review
and
for
marriage
in
the
documentation.
G
There
are
still
some
open
questions
that
I
I
need
to
investigate
and
I'll,
probably
ping
people
on
the
team
to
ask
her
opinion
or
if
they
thought
this
through
and
stuff
like
that
list,
some
of
them
there
but
yeah
just
as
an.
B
Yeah,
I
just
had
a
point
alex
on
the
on
the
on
your
second
question.
There,
like.
How
should
we
define
work
item
type
hierarchies?
B
B
No
sorry,
unless
they're
on
the
bottom
of
the
hierarchy
at
the
maximum
depth
of
the
hierarchy,
and
then
they
can
just
have
an
issue.
So
I'm
wondering
like.
Can
we
build
for
that
one
use
case
and
maybe
like
get
away
without
having
to
answer
every
question
ahead
of
time
and
design
the
whole
system
ahead
of
time?
I
think
in
some
cases,
even
though
we're
trying
to
produce
a
blueprint,
it's
okay
to
say
we
don't
know
how
we'll
do
this
yet
we'll
return
to
after
the
first
iteration.
G
To
me,
I
think
designing
it,
for
any
type
is
the
same
as
designing
it
for
one
type,
because
you
need
to
account
for
the
fact
that
this
type
is
going
to
change
to
a
different
type
right.
So
how
do
you
react
in
that
situation
like
you
have,
as
you
said,
epic
feature
and
then
issue
what
happens
when
the
app
on
the
feature
type
changes
to
an
issue
or
changes
to
an
epic
and
stuff
like
that?
G
So
I
don't
know
if
we
can
design
for
a
single
one
but
yeah.
I'm
welcome
to
details
and
suggestions
and
thinking
it
through
I've.
I've
kind
of
had
an
idea
of
doing
it
with
some
pl
sql
functionality,
but
we
don't
really
want
to
do
that
from
the
database
team
perspective
is
that
code
is
kind
of
hard
to
maintain
and
test
and
all
other
things,
so
there
probably
needs
to
be
a
way
to
do
it
at
the
application
level,
I
think,
or
through
some
sort
of
like
queries.
Other
than
creating
sql
functions
but
yeah.
C
I
just
added
a
couple
I
mean,
I
think
it
is
outside
the
scope
for
the
first
few
iterations
or
nbc's,
but
to
the
extent
it
does
impact
how
we
design
things
just
think
of
custom
widgets.
The
first
thing
would
just
be
custom
fields
like
I
would
think
about,
and
scion
does
a
good
job
with
this,
where
they
let
you
have
a
custom
field
like
if
you
create
it
on
a
project,
you
can
move
it
or
promote
it
to
like
the
global
field,
library
for
the
workspace
right.
C
So
I
sort
of
think
that,
like
custom,
widgets
would
be
able
to
be
linked
to
or
work
on,
many
different
kinds
of
work,
item
types
and
then
inheriting
custom
widgets,
like
I
think,
custom
fields
or
have
like
a
shared
custom,
would
just
library
the
top
level
name
space
that
things
could
look
into.
I
think
this
is
a
whole
like
set
of
npcs
themselves,
so
I
wouldn't,
I
think,
for
now,
like
focusing
just
on
the
widgets
that
we
have
that
are
predefined,
but
we
will
have
to
think
about
this
for
custom
fields.
C
So
at
least
it's
a
starting
point,
but
I'm
happy
to
come
in
and
issue
if
you
drop
a
link
where
you
want
to
have
these
kind
of
conversations.
B
H
I'll
go
ahead
and
just
touch
on
mine
for
the
sake
of
time,
if
you
haven't
already,
please
watch
my
loom
recording
of
my
walkthrough
with
the
prototypes.
If
you
have
any
questions
or
comments,
please
let
me
know,
I
also
forgot
to
add
and
I'll
add
it
right
now
to
the
agenda.
H
That
donald
was
asking
where
I
we
should
collaborate
on
the
design
essentially
for
work
items
for
the
pieces
that
I've
been
working
on
specifically-
and
I
looked
through
all
of
the
issues-
there
were
some
that
felt
similar,
but
I
didn't
feel
that
there
were
any
that
specifically
addressed
the
parts
that
I'm
working
on.
So
I
went
ahead
and
created
another
issue
for
this
and
I'll
put
it
here
in
the
agenda.
It
does
have
all
of
the
screens
in
it
and.
H
You're
welcome
to
comment
on
those
if
you
have
any
thoughts.
The
second
question
is
one
that
I'm
kind
of
still
working
through.
It
came
about
as
a
result
of
talking
with
marcel
this
morning
and
as
well
as
jeremy,
and
I
spoke
with
michael
lee
yesterday.
H
So
michael
lee's
team
is
working
on
the
editor
and
I
wanted
to
get
him
looped
into
what
we
were
proposing
in
terms
of
changes
to
that,
and
then
jeremy,
of
course,
is
kind
of
our
primary
contact
when
it
comes
to
accessibility
and
design
patterns,
and
things
like
that,
so
just
getting
them
looped
in
I
and
jeremy
have
some
concerns
about
accessibility
and
we're
going
to
meet
later
this
afternoon,
just
to
kind
of
talk
through
some
possibilities
with
those
I
don't
see
any
major
changes
to
the
design
as
a
result
of
that,
but
one
example
is
just
ensuring
that
there's
a
consistent
flow
top
to
bottom
in
the
dom
between
mobile
and
desktop.
H
So
I
might
just
be
kind
of
moving
around
some
of
the
elements
from
like
top
to
middle
of
the
page,
instead
of
the
order
that
they're,
currently
in
as
far
as
the
design
patterns,
some
of
the
patterns
we're
proposing
are
new
they're,
not
in
pajamas.
They
would
require
the
same
amount,
ideally
of
conversation
and
vetting
that
we
have
for
all
of
our
other
pajamas
objects.
But
that
takes
a
lot
of
time.
H
If
anyone
has
thoughts,
my
thought
is
that
if
we
keep
everything
small
and
we
continue
to
iterate,
then
we
can
continue
to
also
improve
things
iteratively,
but
just
curious.
If
anybody
has
thoughts
on
that.
C
Yes,
yeah
so
like
if
we
give
feedback
that
something's
not
great
like
we
want
to
take
it
and
iterate
on
it.
So,
like
I
feel
like
we're
going
to
have
enough
front
end
engineers
focus
on
this,
that,
like
we
can
split
up
different
pieces
and
people
can
own
different
things,
but
I
think
we,
the
goal,
is
to
build
together
and
have
as
short
of
feedback
loops
as
possible.
C
C
Like
I,
I
hope
we
were
able
to
figure
out
how
to
solve,
for
allowing
people
to
opt
into
the
new
view
or
not
back
out,
because
we're
not
technically
adding
new
data
necessarily
beyond
like
parenting
issues
that
being
able
to
kind
of
switch
between
the
two
would
be
nice,
if
at
all
possible
that
way
like
we
can
have
a
blog
post
about
it.
H
Well,
my
number
one
concern
is
accessibility
over
any
of
the
other
usability
opportunities
that
we
have.
So
I
am
looking
at
ways
to
ensure
that
we
are
compliant
with
that
and
that
it
is
still
a
good
experience
for
folks
who
might
be
using
things
like
screen
readers
and
I'll
keep
you
all
up
to
date
with
any
changes
that
result
from
that.
But
I
also
am
still
working
on
annotating
the
get
lab,
ui
elements
and
I'll
keep
you
all
also
in
the
loop
on
that
progress.
C
A
I'm
I'm
yes,
sorry!
I
I
was
thinking
that
we
could
have
a
a
special
branch
where
a
lot
of
different
mrs
can
come
in.
That's
not
part
of
master,
but
we
can
all
work
together
and
iterate
quickly
on
ideas
and
stuff
like
that,
because
it
always
slows
me
down
trying
to
get
everything
ready
to
go
into
master.
E
D
E
D
D
D
I
wanted
to
ask
if
we
could
also
have
the
snapshots
of
the
screenshots
put
up
into
designs
on
some
of
these
issues.
Holly,
I'm
wondering
if
you've
thought
about
doing
that.
Just
so,
we
could
have
discussions
on
the
geography
of
some
of
the
parts
as
we
get
into
waiting.
H
H
I've
got
that
I've
got
that
in
the
issue
that
I
posted
in
the
agenda,
but
it
is
in
the
form
of
so
I
used
the
figma
integration,
and
so
it's
pulling
in
the
frame
oh
yeah
yeah.
Would
it
be
preferable?
I
was
thinking
about
this
this
morning,
because
I
would
imagine
those
will
update
when
I
change
the
frame
and
sigma.
So
would
it
be
preferable
to
have
like
snapshot
screenshots
that
aren't
changing?
H
It's
new:
it's
no
problem!
I
just
finished
adding
everything
yesterday,
so
it's
it's
still
pretty
new,
but
yeah
that
let
me
know
if
there's
a
preferred
way
to
do
it
as
opposed
to
this
and
I'm
happy
to
you
know,
making
the
adjustments.
D
H
Well,
donald,
do
you
want
to,
or
maybe
kristen
is
responding,
I'm
just
saying.
Thank
you
donald.
Do
you
want
to
verbalize
your
question,
or
do
you
want
me
just
to
respond.
I
Yeah
I
can
verbalize
it.
So
what
is
the
like
when
we're
changing
components
within
work
items
like
a
gitlab
ui
component
at
its
core,
we're
changing
the
design?
What
would
be
the
ideal
path,
then
we
we
release
work
items
and
we
get
the
thumb
like
people.
Users
like
it
are.
We
then
gonna
go
into
gitlab
ui
and
make
the
changes
so
that
it's
like
that's
the
new
pattern
or
what's
kind
of
your
ideal
approach
toward
these
redesigns.
H
I'd
like
to
also
hear
if
alexis
has
any
thoughts
on
this,
but
I
there's
the
ideal
path
that
I
have
just
as
a
designer
and
then
there's
the
ideal
path
that
I
would
have
to
have
in
order
for
us
to
to
make
some
progress
quickly
and
so
I'll
focus
on
that
one.
My
thought
is
that
we
need
to
have
it
in
gitlab
ui
as
soon
as
possible,
but
of
course
it
needs
to
be
finalized,
at
least
to
the
point
where
we're
ready
to
launch
it.
H
I
also
fully
admit
that
I
don't
thoroughly
understand
the
relationship
between
get
lab
ui
and
what
we
actually
see
in
the
product
from
a
programmatic
standpoint
like
if,
if
we're
testing
something
in
gitlab
ui,
is
it
also
surfaced
in
the
product
where
we
can
be
getting
feedback
on
it
from
live
users?
Or
is
that
sort
of
like
a
staging
environment
where
we
are
seeing
the
changes
and
we
can
view
and
respond
and
comment
and
play
with
those
things?
But
it's
not
actually
in
the
production
environment.
Yet.
I
Both
so
it's
it's
versioned
separately.
So
if
we
made
a
change
to
get
lab
ui
and
then
we
bumped
it
up,
even
just
a
minor
version,
gitlab
would
then
pull
in
the
updates
during
the
next
round
of
updates,
which
happened
pretty
frequently.
Okay,.
H
So
then,
in
that
case
I
would
again
say
that
it
needs
to
be
dependent
upon
what
we
determined
to
be
done,
and
I
would
imagine
that
that
would
be
me
in
which
case
what
I
would
consider
to
be
done
would
be
validated
with
users
and
at
least
maybe
not
even
signed
off
on
per
se
by
some
of
the
other
parties
that
would
be
affected
by
the
decision.
But
at
least
they're
aware
of
it
and
that's
what
I've
been
trying
to
do
for
the
past
week.
H
To
two
weeks
is
poland,
pedro
and
jeremy,
and
michael
lee
and
various
other
people
that
could
be
affected
by
inline,
editing
and
the
assignees
module,
and
things
like
that.
So
I
am
trying
trying
to
already
get
that
ball
rolling
and
have
as
few
kind
of
last
minute
gotchas
as
possible.
H
The
quick
and
easy
way
to
do.
It
is
to
just
use
as
many
of
the
existing
patterns
that
we
have,
but
obviously,
if
we're
redesigning
things
anyway
and
rebuilding
things
anyway,
there's
opportunity
to
improve
those
and
that's
what
we're
trying
to
do
so.
Does
that
answer
the
question,
though
I
mean
I
really
in
my
opinion,
it
comes
down
to
when
it's
considered
done
enough,
not
done
forever,
but
done
enough
to
put
it
into
the
product,
and
then
it
should
be
in
sync,
I
would
say
with
gitlab
ui
and
vice
versa.
I
Yeah
it
does,
I
wonder
if
we
can
also
like
we
can
also
solve
for
the
the
prototyping
iteration
side
of
things
too
like
if
we're,
if
we're
gonna,
if
we
hope
to
make
some
of
these
changes
to
the
patterns
within
gitlab
ui.
I
If
we
go
ahead
and
make
those
changes
now
and
then
they're
applied
everywhere
that
uses
those
components
within
gitlab,
then
we
can
get
feedback
from
those
other
teams
usages
of
them.
And
then,
if
we
hear
that
hey
this
doesn't
work,
then
we
go
ahead
and
revert.
So
it's
like
a
smaller
iteration
as
opposed
to
rebuilding
these
components,
just
for
work
items
right
now,
waiting
to
get
feedback
in
work
items
and
then
determining
how
we're
going
to
change
the
gitlab
ui
component.
H
I
So
I
mean
if,
if
it's
a
brand
new
thing
like,
we
would
eventually
create
a
new
gitlab
ui
component
for
it.
Then
there
is
no
revert
there.
It's
just
tweaking,
but
I'm
thinking
more
of
a
component
like
like
drop
downs,
where
we
want
to
approach
it
differently
within
work
items.
I
H
That
is
a
good
question.
It
was
my
understanding
that,
because
we
were
rewriting
the
code
for
all
of
these
things
anyway,
that
they
would
all
be
some
form
of
new,
but
I
guess
there
are
cases
where
we
could
be
pulling
in.
Maybe
parts
like
to
your
point:
a
drop
down
might
exist
inside
of
the
assignees
module,
and
so
would
we
be
using
the
existing
drop
down
for
the
new
assignees
module.
Is
that
kind
of
an
example.
H
H
I
No
that's
helpful
and
I
think
that's
the
mindset
we
should
take
as
we're
designing
these,
and
I
think
that
that'd
be
helpful
if
we
had
that
annotated
too.
So
as
you're
annotating,
the
other
parts
like
the
padding
and
stuff
on
the
designs
just
go
in
and
say:
okay,
this
drop
down
is
using
the
gitlab
ui
drop-down
component.
H
Well,
that's
what
I'm
doing,
and
I'm
also
going
to
create
a
separate
issue
after
talking
with
jeremy
today,
that
will
outline
all
of
the
new
proposed
pieces
and
tag
foundations
and
get
those
folks
involved
with
all
of
my
proposed
changes
in
one
place,
so
I'll
tag
you
all
on
that
too.
Just
in
case
you're
interested
in
following
that
conversation,
yeah.
F
I
think
that's
a
good
idea
holly
because
I
think,
like
sharepoint
donald
any
changes
that
are
too
you
know
foundational
components
like
a
drop
down.
For
example,
we
could
validate
that
through
that
flow,
like
that
ideal
component
life
cycle
and
validate
that
at
a
design
level,
and
even
just
do
like
quick
prototypes
there,
that
we
don't
have
to
build
out
necessarily
and
then
we
apply
those
changes
within
gitlab
ui
to
use.
But
we
don't.
I
don't
think
we
need
to
get
there
yet.
Does
that
make
sense?
I
agree.