►
From YouTube: Tech writing + Verify Team Process
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
But
I
also
want
to
ensure
that
if
there
are
common
things
that
we
can
learn
and
implement
kind
of
across
the
board,
it's
like
I
am.
I
am
that
sort
of
person
that
will
steal
good
ideas
and
try
to
implement
them
as
possible.
B
That
that
makes
that
makes
a
lot
of
sense.
Okay.
Well,
my
name
is
jackie
porter
for
those
watching
the
recording,
I'm
the
group
manager
of
the
verified
product
team,
I'm
here
with
craig
norris
tech,
writing
manager,.
A
Yup,
thank
you
and
we're
basically
talking
about
ways
that
we
can't
how
how
technical
writing
is
currently
being
is
working
with
the
verify
stage,
but
also
finding
requirements
or
other
particular
types
of
things
or
improvements
or
ideas
or
just
general
conversations
about
how
you
know.
Technical
writing
can
be
a
better
resource
for
the
developer
teams,
as
it
pertains
to
product
documentation,
development
and
other
improvements.
Absolutely.
B
Well,
I
think,
on
the
verify
team,
we
have
a
really
great
overlap
with
technical
writing
in
that
we
always
bring
technical
writing
into
early
into
the
milestone
into
the
issues,
especially
when
it
comes
to
design
planning.
So
we
always,
if
there's
front
end
changes
we
will.
Typically,
I
haven't
found
a
time
where
an
issue
that
didn't
have
a
design
so
far,
because
I
just
recently
have
been
transplanted
into
the
pipeline
execution
group
as
a
hands-on,
hands-on
product
manager,
and
then
I
was
promoted
into
the
group
manager
role
from
release
management.
B
So
when
we
look
at
my
interactions
with
the
technical
writing
and
engineering
teammates,
which
is
like
design
and
and
front-end
and
back-end
engineering,
I
typically
see
you
know
two
different
interactions.
One
of
them
is
in
the
planning
design,
phase
of
the
feature
or
correction
of
the
bug
where
we're
creating
like
ui
text
or
we're
checking.
B
If
this
is
if
this
makes
sense
from
an
experience
perspective,
and
then
the
other
part
is
during
the
actual,
like
implementation
of
the
issue,
we
may
go
back
and
forth
with
technical
writing
about
how
should
this
documentation
look
and
that's
when
the
engineer
will
typically
proactively
ping?
The
technical
writer
inside
of
the
merge
request
for
review
going
back
to
one
of
the
points
that
you
mentioned
earlier
on
the
conversation
of
wanting
to
be
more
proactive
and
want
to
like
shift
tech
writing
left
into
our
planning
process.
B
All
of
these
actions
are
are
still
like
a
little
reactive
in
that
tech.
Writing
is
typically
brought
in,
as
the
designs
are
finishing
up
for
contribution
of
like
ui
text
or
even
like
user
experience.
When
it
comes
to,
should
we
add,
like
a
tool,
tip
that
then
redirects
to
a
documentation
page
which
documentation
page
may
be
best
for
this,
so
those
kind
of
cons,
consultation,
pieces
and
then,
of
course,
like
actual
reviews
and
then
merge
requests
for
the
documentation
is
all
like
hey.
A
So
I
do
have
one
question,
so
we
so
we
have
issues
from
product
design
from
from
the
designers
from
ux
and-
and
I
say
this-
we
are
part
of
ux,
but
you
know
from
the
designers
right.
A
So
we
have
issues
that
are
created
there
and
there
are
conversations
with
you
know,
pms
and
developers,
and
all
of
that-
and
these
are
fleshed
out
into
real
ideas.
And
you
know
there
are
areas
for
us
to
have
conversations
as
part
of
like
you
said,
the
ui
text,
the
tool
tips
the
all
of
these
different
types
of
things
and
that's
one
issue.
A
But
then,
when
does
that
issue
then
get
recreated
or
or
created
again
over
on
this
side
on
the
planning
side
on
the
in
the
get
lab
project
itself
to
be
actually
being
implemented,
or
do
we
sometimes
work
directly
off
of
the
product
design?
This
is
what
it
should
look
like
make
it
go.
Do
this?
Okay,
let's
just
go
connect,
mrs
to
that
particular
product
design,
issue
and
just
kind
of
work
from
there.
B
So,
typically,
the
product
design
issues
that
come
from
a
user
insight
will
be
implementation,
issues
that
get
built
inside
of
the
gitlab.org
project.
So
those
are
implementation
issues.
Typically,
the
ux
insights
are
in
dovetail
and
if
we
have
an
actionable
insight,
those
will
get
transcribed
directly
into
the
gitlab.org
project
for
prioritization
scoping
and
technical
proposals.
C
B
B
A
Behavior
change
of
the
product.
That
would
be
something
that
would
more
than
likely
be
a
product
documentation,
modification
kind
of
thing
anyway,
and
so
I
would
think
that
in
many
of
those
circumstances,
if
we
could
get
some
sort
of
indicator
that
even
just
says
documentation
on
this
just
so
that
we
can
at
least
know
hey.
This
is
something
that's
going
to
have
a
documentation
impact,
because
it's
a
ui
change.
It's
a
ui
ad!
It's
a
new
feature.
It's
a
change
in
behavior,
or
anything
like
that.
A
Probably
documentation,
I'm
just
going
to
put
the
documentation
label
on
there,
just
so
that,
maybe
as
part
of
the
planning
process,
maybe
as
part
of
you
know,
you
know
just
general
research
of
things
going
on
or
just
or
whatever
we
would
just
be
apprised
of
knowing
oh
there's
a
documentation
thing
there.
Let
me
take
a
look,
oh,
that
that
involves
us.
B
Yeah
definitely
so
I
would
say
it
sounds
a
little
bit
like
you
want
to
kind
of
detect
capacity
and
like
forecast
capacity
of
tech,
writers,.
A
What
what's
possible?
What's
what
what's
a
what's
what's
possible
for
this
particular
milestone
based
off
of
their
particular
group
assignments,
because
we
don't
just
have
one
technical
writer
per
one
developer
group.
We
have
multiple
developer
groups
that
are
associated
with
each
technical
writer,
so
we
have
the
balance.
It's
always
a
balancing
act,
but
but
we're
trying
to
get
a
better
sense
of
what?
What
capacity
does
a
technical
writer
have?
A
What
what
can
they
do
so
that
we
can
have
a
conversation
with
with
the
pms
and
say
it's
like
this
is
kind
of
what
my
capacity
is
looking
like
with
documentation,
and
so
perhaps
these
are
things
that
I
can
more
fully
develop.
Maybe
these
are
things
that
I
just
kind
of.
This
is
okay
and
I
will
revisit
at
some
particular
point
in
the
future.
Maybe
some
of
these
things
are
just
you're
just
going
to
have
to
kind
of
push
through,
but
instead
of
here
we
are
coming
up
to
the
end
of
the
milestone.
A
Are
you
done
with
this?
It's
like?
No,
I
we
would
rather
actually
let
you
kind
of
know
these
are
what
we're
focusing
on
and
these
other
ones.
We
will
have
to
focus
on
at
a
later
time,
because
of
reasons
or
it
could
be.
We
have
no
problem
with
capacity
whatsoever
smooth
sailing.
You
know
one
less
thing
for
you
to
worry
about
this
release.
B
So,
taking
a
little
bit
of
a
step
back,
I
think
in
the
verify,
in
the
verify
stage,
we
do
have
opportunities
to
maybe
add
additional
labels
to
our
existing
issues.
That
could
help
us
understand
like
what's
the
forecasted
requirements
for
for
tech
writing,
because
inside
of
each
engineering
implementation
issue,
if
there's
a
significant
user
experience
change,
the
definition
of
done
in
order
for
that
issue
to
be
closed
requires
documentation
to
be
added.
B
A
B
So
with
that,
like,
we
may
need
to
make
sure
that
we're
always
adding
like
the
documentation
label
specifically
to
those
issues.
So
then
we
can
key
off
of
like
okay.
If
this
is
something
that's
in
documentation,
workflow
in
development,
maybe
it's
tech,
writer
doing
or
tech
writer
backlog
and
those
are
ways
to
key
off
of
the
label.
A
So
we
do
actually
have
something
in
there,
so
we
we
have
a
technical
writing
label,
which
is
so
ideally
what
the
technical
writing
label
indicates.
Is
that
we're
involved
with
a
particular
issue.
So
we
have
identified
the
issue
and
it's
something
that
we
are
going
to
be
doing
and
or
have
done,
and
then
we
also
have
a
tw
doing
label
a
tw
dash
doing
label
I've
seen.
B
That
on
a
release
post,
mrs,
where
I'm
engaging
with
myself
so.
A
What
that
indicates
is
is
that
we're
working
on
it?
It
may
not
necessarily
yet
be
done,
but
it's
something
that
is
in
progress
and
then
we
have
a
tw
finished
label.
So
it's
a
it's
a
scoped
label,
so
t
will
be
doing
to
be
finished.
Tw
finished
is
normally
when
we
indicate
we
have
completed
this
particular
the
work
on
this
particular
item.
Ideally,
it's
meant
more
for
merge
requests
that
we
don't
own.
So
in
other
words,
perhaps
it's
a
it's.
A
shared
code,
documentation,
merge,
request
and
so
tw
finished
is
where
we
can
indicate.
A
B
Yes,
so
taking
another
step
back
like
I'm
trying
to
find
ways
to
inject
tech
writing
into
our
current
engineering
issues,
so
I'm
wondering
if
we
can
repurpose
these
labels
that
I
know
we
currently
have
for
tech,
writing
and
maybe
add
them
to
particular
issues
that
we
know
are
going
to
be
flagged
for
implementation
in
the
upcoming
milestone.
I
think
the
biggest
gap
is
for
tech
writing.
Scoped
labels
is
that
you
don't
have
like
an
nq
or
ready
for
tech
writing
kind
of
workflow
label.
A
You're,
so
if
I'm
following
correctly,
would
it
be
kind
of
one
of
those
things
where
you're
saying
that
it's
a
documentation
related
item?
It
may
not
necessarily
be
ready
for
technical
writing
to
work
on
yet,
but
it
would
be
an
indicator
from
the
developers
to
say,
hey,
technical
writing.
This
is
something
that
that
we
have
prepared
for
you
and
we're
ready
for
you
to
work
on.
A
A
Yeah,
let
me
let
me
let
me
chew
on
that.
I
don't
have
an
answer
for
that
one
and
maybe
it's
a
maybe
it's
a
an
extension
of
the
scope
label.
Maybe
it's
another
label.
I
would
rather
not
be
under
the
label,
but
it's
an
extension
of
the
scope
label
to
say
almost
like
a
ping
like
you
said,
you
know,
tw
ping,
for
readiness,
because.
B
What
you
could
also
do
is
like
set
up
a
subscription
for
tech
writers
that
they're
subscribed
to
issues
once
it
goes
into
this
ready
for
tech
writing
a
label
that
they
get
notified.
They
get
it
to
do
for
it
yeah.
I
think,
that's
that's
an
opportunity
to
normalize
your
capacity
and
understand
how
many
things
are
incoming
and
how
many
things
are
outgoing
per
milestone,
because
it
doesn't
sound
like
you
necessarily
have
like
an
incoming
metric.
A
We
absolutely
do
not
because
we
we
have
the
we
go
and
look
for
things
and
we
look
for,
like
I
said,
the
documentation
label,
we
put
the
technical
writing
label
on
there
as
needed.
We
control
the
information
understanding
of
kind
of
where
we
are
when
we're
in
the
process,
but
you're
right.
We
don't
have
that.
Hey
we're
ready
for
the
technical
writers
to
provide
assistance
in
these
things.
A
A
B
And
then
there's,
like
a
pinch
point
in
a
bottleneck
between
tech,
writing,
review
and
engineering
review
at
the
end
of
the
milestone,
which
could
cause
an
issue
to
slip.
So
there
might
be
an
opportunity
for
us
to
start
working
on
the
documentation
earlier
in
the
milestone
to
normalize
the
intra
milestone.
Workflow
of
tech
writing
so
that
they're
not
all
getting
slammed
two
weeks
before
the
end
of
the
milestone,
because
I
imagine
that's.
B
Are
going
right
now,
they're
getting
hammered
two
weeks
before
the
end
of
the
milestone
versus
staging
documentation
up
front,
because
you
know
in
in
an
ideal
case,
like
the
engineer
knows
how
it's
going
to
work,
so
they
can
frame
out
like
what
they
think
it's
going
to
do
and
then
do
a
first
draft
pass
with
the
tech
writer.
So
the.
C
A
I've,
it
kind
of
begs
the
question
of
we.
Could
I
mean
the
review
process
could
continue
to
be
utilized,
but
it
could
also
be
that
conversation
could
conceivably
happen
exclusively
within
the
scope
label
so
that
you
don't
even
have
to
go
through
the
review
process.
You
just
basically
look
and
see
all
right,
we've
pinged
them
we're
ready
to
go
they're
working
on
it.
I
can
see
they're
working
on
it
because
they
have
a
doing
label
on
there.
They're
done
finished.
We
don't
even
have
to
talk
to
the
technical
writers.
We're
done.
B
Yes
right
exactly,
and
I
think
right
now,
there's
probably
that
visibility
on
the
merge
requests
and
where
we're
missing,
that
is
in
the
issue
where
that's
that's
the
focal
point
by
which
product
managers
are
projecting
communications
to
users
to
the
community
to
customers.
So
if
there's
some
sort
of
way
that
it
might
not
be
necessary
either,
but
I'm
thinking
about
things
that
don't
have
merge,
requests
on
them
that
are
just
beginning
the
milestone.
B
A
Absolutely
right
absolutely
yeah
issues
are
the
place
where
we
have
the
conversation.
We
we
use
merge,
requests
to
get
an
understanding
of
how
painful
was
the
work,
whereas
issues
are
what
do
we
need
to
invest
to
try
to
get
the
work
done?
Issues
are
forward-looking.
Merge
requests
are
like
what
did
we
do?
Yeah.
B
Execution
based
exactly
so
something
I
did
want
to
share
with
you
is
this
group
opportunity
canvas
that
I
conduct
kind
of
on
a
quarterly
basis
and
a
part
of
my
view,
as
a
product
manager
at
the
group
level,
is
to
look
at
launch
and
growth
and
find
opportunities
for
us
to
really
consider
utilizing
all
of
the
different
resources
that
we
have
available
to
us
as
a
team.
B
So
this
is
like
marketing
campaigns,
tutorials
product
managers,
doing
continuous
interviewing
with
customers
with
different
pieces
of
features,
but
also
something
that
would
be
that
I've
done
at
my
previous
company
tech
writers
is
like
create
a
tech
writing
roadmap
for
these
big
boulders
in
our
in
our
in
our
vision,
so
that
we
are
prioritizing
the
user
experience
of
our
documentation
for
these
areas
that
are
about
to
have
an
immense
amount
of
development
to
them.
B
So
if
we
know
that
in
our
backlog,
we
have
60
variables
bugs
and
we
want
to
burn
down
50
of
those
variables
bugs
it
might
be
really
important
for
us
to
have
that
dialogue
with
tech
writing
about
improving
the
flow
and
the
user
experience
of
the
existing
documentation.
B
So
that
once
we
improve
all
these
bugs
and
maybe
add
some
features
that
users
know
how
to
best
utilize,
the
existing
features
available
to
them
in
gitlab.
So
it's
more
about
like
that
discoverability
conversation,
but
having
that
at
a
quarterly
basis,
so
that
we
can
create
these.
B
You
know
I
guess
story
arcs
inside
of
our
documentation,
because
documentation
can't
be
its
own
marketing
mechanism
right.
A
It's
effectively
communicating
these
group
and
stage
based,
you
know,
goals
you
know
effectively
into
our
backlog
and
ensuring
that
they
get
prioritized
along
with
the
other
work
that
we're
doing
or
at
least
prioritized
effectively
and
not
necessarily
just
thrown
into
the
backlog
and
done
whenever.
But
you
know
like
affording
that
ability
to
be
able
to
you
know,
set
an
import
set
of
priorities
set
a
you
know.
This
is
important
to
us.
Please
prioritize
this
over
some
of
the
other
work
that
you
may
have,
because
it's
important
yeah.
B
These
sorts
of
things
intra
milestone.
Two
like
the
the
tech
writers,
can
then
push
back
and
be
like
hey.
I
have
over
30
review,
mrs,
but
then
I'm
supposed
to
be
working
on
this
big
strategic
initiative
so
tell
me
gmp
what
you
think
I
should
be
doing,
and
this
should
all
be
transparent
based
off
of
the
okrs
that
we're
setting
for
the
quarter.
A
Yeah
that,
yes,
all
of
that,
that
that
makes
absolute
sense,
it's
it's
allowing
there
to
be
a
a
more
well-defined
conversation
between
product
and
the
technical
writer
about
these
sorts
of
things
as
compared
to
what
we
have
right
now,
which
is
just
a
set
of
handshake
agreements
and
conversations
that
kind
of
happen
over
time
or
it's
like.
Are
you
busy
it's
like
as
compared
to
a
real
plan?
Yeah
that
makes
sense.
B
Right
yeah,
so
I
feel
like
we
have
an
opportunity
to,
at
these
quarterly
stage
level
opportunity
campuses
that
gmps
conduct
connecting
with
the
tech
writer
once
that
opportunity.
Campus
has
been
approved
by
project
leadership
and
detailing
out
what
are
like
a
handful
of
clear
action
items
that
tech
writing
could
commit
to
in
the
quarter,
and
I
think
that's
an
opportunity
to
align
on
the
same
results
of
the
product
strategy,
but
also
help
them
fit
along
their
current
capacity
and
flow
so
that
we're
not
we're
not
over
inundating
every
every
month.
A
Again
part
of
the
conversation
you
know
it
becomes,
it
becomes
literally
part
of
the
conversation.
This
is
a
priority,
but
these
are
these.
These
are
also
in
here,
which
things
do
I
pass
along
hit
another
time
in
order
to
be
able
to
elevate
certain
things
within
this
in
order
to
be
able
to
help
move
this
forward
right.
B
Exactly
I
completely
agree
with
you
on
that,
so
I
think
one
requirement
that
we
would
need
to
identify,
though,
is
that
in
queue
ready
for
tech
writing
label,
because
I
think
that
that
would
be
the
forward-looking
scope.
You
know
the
road
map.
A
Which
to
me
is
related
to,
but
slightly
different
from
the
the
readiness
label
that
we
kind
of
talked
about
before
it's
like
that's
more
of
the
the
longer
term.
This
is
a
priority
for
us
as
compared
to
the
other
one,
which
is
a
we're
we've
been
working
on.
You
know
we're
ready
for
a
technical
writer
to
take
a
look
at
this
issue
as
compared
to
having
a
technical
writer,
be
you
know,
ensure
that
this
is
prioritized
for
planning.
You
know
kind
of
thing.
I
see
them
as
two
separate
labels.
B
If
it's
ready
for
tech,
writing
and
planning
breakdown,
that's
going
to
be
a
future
facing
priority
on
the
roadmap
yeah,
where.
B
Yeah,
whereas
if
it's
ready
for
tech
writing
in
ready
for
development
or
in
dev,
these
are
opportunities
where
maybe
the
tech
writing
is
actually
collaborating
in
the
issue.
B
I'm
not
trying
to
like
add
more
work
to
your
plate.
I
just
want
to
find
ways
that
we
can
solve
for
the
problems
that
you
were
keying
off
of,
like
as
I
was
walking
through.
How
verify
interacts
with
tech
writing
today
seems
like
there
might
be
some
gaps
in
what
what
we
need
to
accomplish
with
tech
writings
goals
for
results.
A
Yeah
we're
I
get
the
feeling
that
we're
kind
of
keeping
up,
but
I
would
like
for
us
to
be
able
to
again,
like
I
said,
not
be
quite
so
reactive
and
actually
be
a
little
bit
more
forward-facing,
because
one
of
the
things
that
I
really
want
us
to
do
is
I
want
us
to
be
trusted
partners
as
compared
to
well.
You've
met
our
needs
so
far,
and
we
continue
to
hope
that
you
will.
But
I
want
us
to
be
able
to
walk
in
and
go.
A
We
can
meet
your
needs
in
these
particular
ways
on
a
regular
basis
and
and
and
have
a
conversation.
You
know
throughout.
B
And
as
you
start
to
think
about
it
more,
if
you
need
another
like
clarification
or
if
you
want
to
talk
about,
it
feel
free
to
open
up
an
issue,
and
we
can
go
back
and
forth
in
that
and
talk
about
how
we
want
to
apply
it
inside
of
the
verify
team.
I.
A
Would
be
happy
to
I'm
going
to
have
a
conversation
about
this
with
my
peer
manager,
so
you
know,
because
you
know
between
the
two
of
us,
we
manage
the
teams
and
I
can
venture
to
say
you
will
probably
see
an
issue
and
I
will
be
sure
to
copy
you
in
it
and-
and
we
will
continue
to
work
for
this,
but
this
is
great.
Thank
you
very
much.
Thank.
B
You
thank
you
for
connecting
with
me
and
we
should
try
to
set
up
some
sort
of
recurring
touch
point
just
to
keep
everything
you
know.
A
Aligned
and
yeah
and
yeah
and
again
this
is
you
have
given
me
a
lot
of
information,
hopefully
at
some
particular
point
I
can
you
know,
return
the
favor
more
with
you
know
very
specific
things
that
we
can
do
to
continue
to
make
the
verified
documentation
that
much
better.
As
a
general
note
we
are
working
on,
you
know,
the
cicd
documentation
is
some
of
the.
B
A
Heavily
visited
page
views,
I
don't
know
if
you
have
seen
the
content
audit
page
that
we
have
here.
B
I've
seen
it
like
in
a
slack
message
somewhere
so
yeah.
A
So
we
do
have
the
content
audit.
It
does
list
all
of
the
the
different
pages
it.
Actually,
you
can
use
it
to
find
which
pages
are
associated
with
which
groups
and
stages
and
all
the
way
over
to
the
right.
A
It
actually
gives
you
breakdowns
for
page
views
on
a
per
month
basis
for
the
past
year,
so
you
can
actually
see
which
pages
are
getting
hit
more
or
less
the
ciaml
reference
file,
if
I
remember
correctly,
is
the
actual
number
one
and
then
ci
cd
is
pretty
much
in
the
top
ten,
and
we
are
very
focused
on
improving
those
pages
and
marcel
is
working
regularly
to
to
get
improvements
in
place
and
make
those
pages
a
better
reference
for
our
internal
and
external
users.