►
From YouTube: GitLab Plan - Sync on Certify Priorities
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
Hi
y'all,
I'm
here
with
dan
and
matthew,
and
this
is
a
stream
of
consciousness.
Transition
of
certify
we're
gonna,
be
talking
about
what
type
of
work
is
in
progress
and
then
why
it's
in
progress
and
what
we're
going
to
be
working
on
next
so
start
at
a
super
high
level
with
saying
and
plan
overall,
the
overarching
project
that
we're
working
on
is
work
items
right.
So
it's
creating
a
unified
implementation
of
planning
work
right.
So
everything
that's
separate
today,
issues
epics
requirements
all
coming
together
into
a
single
thing.
A
So
the
first
step
of
that
is
moving
basically,
in
the
back
end,
the
data
from
the
requirements
table
into
the
issues
table,
which
is
behind
the
scenes,
what's
powering
work
items
so
that
work
has
been
happening
for
a
while
and
now
we're
at
a
stage
where
the
data
is
replicated.
So
it's
in
both
places
in
the
requirements
table
and
the
issues
table,
but
there's
bits
of
functionality
that
are
missing
before
we
can
make
a
full
cutoff
and
basically
deprecate
the
old
requirements.
Experience
from
the
actual
functionality
perspective.
A
So
I
linked
one
thing
that
I
noticed,
as
I
was
putting
this
together.
Is
that
there's
not
really
an
epic
where
all
of
this
transition
work
is
together
right,
so
matthew?
That's
something
that
I
would
really
like
your
help
with.
I
linked
some
things
that
I
know,
but
if
you
ping,
the
team
on
slack,
like
probably
felipe
and
charlie,
will
know
all
the
different
work,
that's
in
progress
from
the
backend
perspective
and
they
can
help
you
and
it'd
be
good
to
just
have
this
all
under
one
epic.
A
B
A
Yeah
they
will
know
what
is
needed,
but
there's
basically
two
flavors
of
work.
A
The
first
flavor
is
like
back
end
behind
the
scenes,
moving
data
from
one
place
to
another,
that's
been
in
progress
for
some
time
and
then
and
really
there's
like
not
a
lot
of
ux
or
product
work
needed
there
right,
because
it's
just
getting
data
in
the
right
tables
and
everything
and
then
there's
a
second
flavor
of
work
which
is
building
out
work
items
to
meet
the
needs
of
requirements,
there's
specific
things
that
requirements
have
that
issues
don't
have
or
that
tasks
don't
have
right
that
need
to
be
present,
the
first
one
being
the
concept
of
s-status.
A
A
So
we
need
to
build
that
out
within
work
items
write
some
some
of
this,
like
additional
level
of
granularity
of
state.
So
that's
where
status
comes
in
and
we
can
do
a
deep
dive
into
that
in
a
minute.
A
The
other
part
that
is
missing
is
the
csv
import
export
that
doesn't
exist
in
work
items.
It
exists
in
issues,
but
there's
even
functional
differences
between
requirements,
import
export
and
issues
import
export.
I
actually
think
requirements.
Import
expert
is
slightly
better
because
it
allows
you
to
select
what
fields
are
exported,
which
is
nice,
but
basically
that
needs
to
be
built
out
in
work
items.
A
The
team
is
spiking,
basically
doing
a
technical
spike
to
see
what
all
the
work
is
entailed
in
doing
that
and
for
now
I
basically
was
very
high
leveling
guidance
and
say
like
build
something,
that's
exactly
like
what
requirements
has
but
there's
an
opportunity.
If
we
want
to
improve
that
experience
in
some
way,
we
could
right,
but
just
to
keep
it
simple.
I
just
my
directions
were
very
high
level
instead,
like
just
exactly
the
same
but
for
work
items,
and
then,
lastly,
in
this
one
I'm
actually
unsure
of
what
work
has
been
done.
A
But
requirements
have
the
ability
to
be
linked
to
a
test
case
so
require
so
work.
Items
should
have
the
ability
to
be
linked
to
a
test
case
and
for
all
of
these,
these
will
be
what
we
call
widgets
for
work
items
where
we
can
say
we
want
this
behavior
available
only
for
requirements,
but
not
for
epics
as
an
example
or
tasks
right
status
and
csv.
A
Import
export,
I
think,
are
more
general,
where
any
work
item
should
have
that
linking
and
working
into
a
test
case,
I
think,
will
be
a
requirement
specific
functionality
right.
We
wouldn't
expect
any
other
type
of
work
item
to
have
this
behavior,
but
maybe
that's
something
to
validate.
I
see
you
thinking
then,
but
that
work,
I
don't
think,
that's
even
started,
but
that's
something
to
figure
out
with
the
team,
because
I'm
actually
not
sure.
A
And
these
are
the
items
that
I
know,
but
this
is
something
else
matthew
and
dan
that
could
use
a
good
scrub
of
just
walking
through
the
requirements,
experience
and
seeing
what
else
needs
to
be
built
out
and
also
maybe
the
team
has
been
thinking
about
this.
A
A
So
how
about
status
in
the
initial
implementation?
So
we
did
one
issue,
there's
an
epic
that
I
linked
here
and
we
did.
We
implemented
one
part
of
it,
but
we
called
it
verification
status
because
we
were
thinking
very
requirement
specific
but
gave-
and
I
talked
about
this
and
we
basically
want
to
build
a
more
granular
concept
of
a
status
for
work
items
in
general.
A
So
we
decided
to
abstract
from
verification
status
to
just
more
generally
status
right,
because
that's
something
that
every
work
item
can
have,
but
then
we
can
have
more
of
the
well
status
for
requirements,
means
verified
unverified,
I
mean
satisfied.
Unsatisfied
unverified
status
for
epics
is
more
in
progress,
complete,
etc
right.
So
each
work
item
can
have
their
own
status,
but
at
the
end
of
the
day
they
all
have
a
status
right.
A
So
we
wanted
to
abstract
it
more
and
that's
what
we
decided
on
and
there's
gonna
be
some
work,
this
milestone
to
like
rename
it
to
status
and
then
build
out
more
of
the
components
for
it.
So
it's
like
a
graphql
api
to
do
like
crud
on
a
status
field,
so
create
read,
update,
delete
now.
There's
like
a
couple
of
things
here
that
are
interesting
dan.
You
asked
around
like
validation,
so
one.
A
The
term
status
I'm
fairly,
confident
that
that's
like
the
right
terminology
and
that
it
would
be
understood
for
requirements,
customers
that
like
status,
means
this,
but
that
would
be
something
that's
good
to
validate
and
then
figure
out.
If
we
need
to
do
any
more
in
on-screen
education
or
something
about
what
this
value
is.
A
So
that's
one
two
is,
I
included
some
screenshots
for
what
the
ui
was.
Gonna
look
well,
it's
in
the
epic
somewhere
and
I
can
find
it
and
direct
link
it,
but
we
had
another
designer
help.
Put
those
together
and
the
assumption
in
those
screenshots
is
that
we
would
change
the
experience
to
basically
have
the
requirements
list
as
it
exists
today.
A
A
Then
we
have
the
more
complex
things
like
archiving,
enclosed
and
requirements.
We
call
it
when
you
set
something
away
as
archiving
and
in
issues
we
call
it
close.
A
It
would
be
good
to
consolidate
that
into
a
single
term
right.
That
means
like
I'm
done
with
this
item,
but
I
don't
know
what
the
right
term
is
or,
if
there's
a
real
need
for
that
difference
in
terminology,
because
there
were
different
implementations,
each
team
named
it
whatever
they
wanted,
but
it
would
be
nice
to
have
a
single
term
and
have
that
be
more
unified.
C
Oh,
we
can.
We
can
rewind
to
what
I
was
thinking
about.
Okay
and
it's
it's
the
definition
of
requirement,
because
in
some
stuff
I've
been
reading
requirements
can
be
business
level
or
the
real
detail
level.
So
some
people
might
document
the
requirements
as
epics
or
as
okrs
or
as
issues.
C
So
the
thing
that
had
my
cogs
were
in
is
about
linking
to
test.
Cases
is
if
the
requirements
are
documented,
like
a
business
requirement
is
documented
at
an
epic
level.
Would
there
be
a
need
to
link
to
a
test
case
then?
And
but
all
of
that
comes
down
to
the
definition
of
requirements,
both
from
a
customer
point
of
view,
but
from
a
feature
point
of
view
as
well.
A
A
B
A
No,
you
don't
need
to
keep
it
confidential.
You
just
need
to
put
the
label.
That
is,
there's
labels
for
each
tier,
so
you
just
put
like
ultimate
on
it,
but
no,
the
I'll
send
you
a
link
for
when
we
do
confidentiality,
but
it's
basically
only
if,
if
it's
related,
if
you
name
a
specific
customer
or
if
you,
if
it's
related
to
security,
but
that's
about
it.
B
A
C
A
Incidents,
definitely
it's
basically,
and
the
reason
is
because
this
represents
the
the
life
cycle
of
an
item
right
now.
We
are
very
coarse-grained
right
where
something
is
either
open
or
closed,
but
there's
a
lot
of
shades
of
gray
in
between
which
customers
want
to
be
able
to
represent,
like
if
you,
if
you
think,
even
as
gitlab
the
workflow
labels
that
we
use
for
our
issues
would
be
what
the
status
is.
A
When
that's
a
first
level
attribute
we're
not
as
gitlab
very
diligent
about
using
epics
right,
but
epics
also
have
a
work
lifecycle
of
their
own.
It's
a
little
bit
more
high
level
right.
It
would
be
something
like
open
in
progress
or
like
something
is
being
validated
right
and
there's
different
workflows,
they're,
not
quite
as
detailed
as
the
workflow
labels
that
we
have
now
for
issues,
but
they
will
have
their
own
lifecycle.
A
A
A
Yes,
they
have
status,
they've
built
on
their
own
triggered
resolved
and
something
else
acknowledged,
triggered
acknowledged
resolved.
So
the
incident
management
team
has
built
their
own
status
flow,
which
again
is
like
why
we
want
it
to
be
unified
right
to
have
it
be
called
the
same
thing.
Maybe
it
holds
different
values
depending
on
the
work
item
type,
but
it's
a
similar
experience.
C
A
Yeah,
that's
the
part
that
we're
trying
to
figure
out
that
we
need
to
validate
more
broadly
and
gabe
is
owning
that
there's
a
different
ways
that
you
can
like
achieve
that
end
result.
But
the
general
concept
is,
you
can
think
of
it
like
you.
Have
this
broad
like?
Let's
take
our
product
development
flow
right
as
an
example,
we
have
labels
that
are
associated
with
each
step
of
the
way,
but
within
that
flow
those
are
the
statuses
right
within
that
flow.
A
There's
almost
like
buckets
right
where
they
signify
something
being
waiting
right.
So
it's
not
not
started
right,
there's
a
particular
set
of
statuses
that
are
not
started
right,
they're,
just
sitting
in
the
backlog
waiting
for
someone
to
work.
If
you
think
of
a
report
like
value
stream
that
you're
very
familiar
with
you,
wouldn't
count
those
as
in
progress
right
these
set
of
statuses,
they're
backlogged,
then
they
get
to
a
set
of
statuses
that
are
in
progress
right.
A
If
we
want
to
be
very
broad-
or
if
you
want
to
be
more
fine-grained,
you
can
say
like
this
is
validation
right,
like
once
you're
in
these
three
four
labels,
you're
technically
in
the
validation
phase,
then
once
you
get
to
this
other
set
of
labels
you're
in
development
right
when
an
engineer
picks
it
up
when
they're
in
dev
being
tested
et
cetera,
these
are
in
progress
or
in
development,
and
then,
in
the
end,
it's
like
you've
completed,
there's
a
specific
set
of
labels
that
are
represent
that
and
then
there's
a
completely
separate
set
of
labels.
A
A
That's
what
other
tools
do
where
they,
you
create
a
status,
and
you
say
this
is
what
part
of
this
category
so
in
progress,
not
started,
etc,
and
they
have
predefined
categories
of
basically
statuses
where
they
go
or
you
can
create
your
own
way
of
creating
those
categories,
and
that's
where
you
have
two
attributes,
but
we
don't
know
exactly
what
that's
going
to
be
gabe
and
the
project
management
team
are
owning
that
part
of
basically,
how
do
we
represent
these
categories
of
statuses?
A
C
It
it
makes
sense
where
the
boundaries
are
between
statuses
and
some
of
these
other
things
doesn't
quite
make
sense
yet,
but
I
don't
think
we
need
to
work
that
out.
A
You
can
look
at
that
issue,
there's
a
really
good
screenshot
of
how
other
tools
do
it
that
I
won't
name,
because
I
want
to
put
this.
That
makes
it
very
clear,
they've
done
a
good
job,
so
it
makes
it
very
clear
what
this
is.
Nice.
C
A
So
we
have
now
metrics
and
using
our
analytics
we
can
definitely
see
some
of
the
customers
that
are
using
it.
A
lot
of
it
is
a
public
sector
because
it
aligns
very
closely
with
how
they
work
right,
where
they
have
regulatory
needs
and
requirements.
Some
of
it
is
kind
of
like
the
the
flavor
of
like
regulated
industries
right
so
like
automotive
banking
tend
to
be
the
ones
that
use
it
and
very
much
how
we
would
expect
there's.
No.
I
haven't
run
across
any
like
surprising
use
cases
of
requirements.
A
I
think
the
naming
is
pretty
clear
and
the
functionality
is
pretty
clear.
That
being
said,
I
think
this
is
an
opportunity
where
we
can
do
a
lot
of
rediscovery
of
our
customers
and
do
some
like
high-level
interviews.
A
That's
something
matthew
listed
it
as
well,
but
that's
something
that
I
wanted
him
and
I
to
work
on
and
and
you
as
well
once
you
all
get
onboarded
of
basically
doing
some
high-level
interviews
with
customers
to
learn
behaviors
and
what
they're,
using
what's
working.
What's
not
working
and
refresh
the
backlog,
because
we
do
need
to
figure
out
what's
next
after
work
items
that
we
get
through
the
hall
of
moving
the
data
from
one
place
to
another.
A
B
I
can
I
can
leverage
that.
A
A
All
right
so
we're
a
little
bit
over
time,
but
we're
almost
done
are
you
guys,
okay,
to
stick
around
for
a
few
more
minutes?
Okay?
So
what's
next,
that's
what
I
so.
We
have
obviously
like
the
big
haul
of
migrating
requirements
to
work
items
right.
There's
a
lot
of
work
to
do
there
a
lot
of
questions
to
answer
like
how
closely
do
we
bring
the
experiences
together
between
the
project
management,
product
planning,
work
and
requirements
work
world
right?
Should
they
completely
be
separate?
A
We
also
need
to
think
about
how
we
introduce
a
new
experience
to
users
in
general
right
as
we're
changing
the
ui
and
moving
things
around
like.
We
should
be
mindful
of
having
that
be
a
good
experience.
A
A
A
Yeah,
just
making
sure
the
transition
from
the
old
experience
and
experience
is
a
positive
and
then,
after
that,
right
after
we
get
through
all
that
is
when
we
can
build
new
and
exciting
things
for
requirements.
Right,
like
the
experiences
moving
to
work,
items
in
itself
will
give
a
lot
of
new
functionality
right,
like,
for
example,
they'll
get
discussions,
labels
assignees
all
things
that
customers
have
asked
for,
so
that
in
itself
will
be
a
huge
win,
but
there's
an
opportunity
for
more
right
requirement,
specific
enhancements.
A
C
Sure
so,
on
on
building
new
things,
will
the
focus
still
be
on
the
aerospace
use
case,
or
do
you
expect?
A
I
think
we
should
go
where
the
customers
are
taking
us
right
like.
If
we've
got
a
lot
of
takers
in
a
specific
sector,
we
should
help
them
expand
their
usage.
I
believe
that
we've
gotten
a
lot
of
adoption
from
pubsec,
so
I
think
it
would
be
interesting
to
see
if
there's
things
that
are
specific
to
that
use
case,
that
we
need
to
build
out
versus
the
more
broad
requirements
use
case,
but
that
will
be
something
that
you
and
matthew
can
help
drive.
B
A
Yes,
actually
like
parting
thought
that
I
haven't
written
down
anywhere,
but
now
is
on
tape
and
with
you
all,
but
us
at
gitlab
we're
doing
all
these
certifications.
Now
right,
we
are
managing
requirements
and
proving
that
we're
meeting
them.
Somehow
I
don't
know
how
we're
doing
it.
A
So
we
should
talk
to
our
own
people
and
say,
like
hey:
are
we
doing
as
we're
doing
all
these
different
certifications?
How
are
we
managing
that
process?
I've
seen
collections
of
issues
that
have
tables
and
line
items
pointing
to
issues
that
would
be
very
interesting
to
explore
and
a
really
good
dog
fooding
opportunity
and
something
that's
more
broad
right.
A
So
anyone
who
has
any
kind
of
company
that's
on
the
internet
probably
has
some
semblance
of
these
certifications
that
they're
pursuing
so
very
excellent
call
out
matthew
and
that's
something
else
that
we
should
put
some
thought
into
like
you,
interviewing
these
internal
customers
and
having
a
goal
of
like
the
next
certification
that
we
pursue
the
process
is
managed
using
requirements
management.
I
feel
like
that
would
be
really
awesome.
A
All
right
is
there
anything
else
that
I
can
help
clarify
from
like
the
very
high
level
of
the
team
and,
what's
in
the
horizon,.