►
From YouTube: Plan Stage Weekly (APAC) - 2023-06-15
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
Hello,
everyone
to
plan
weekly,
Apec
Edition,
it's
15th
of
June
2023,
so
we
have
a
couple
of
demos.
Today
there
is
one
announcement
from
Arsen,
so
I'll,
just
read
it
out.
Last
quarter
as
a
part
of
technical
lighting,
okrs
I
created
a
tutorial,
there's
a
link
to
tutorial,
which
was
basically
around
how
to
set
up
an
issue
board
for
team
handoffs.
So
this
quarter
I
should
create
another
one.
A
Kr
that
is
and
plan
docs
are
the
most
visited
ones
from
my
assigned
groups,
so
the
most
likely
candidate
is
to
how
to
do
issue
triage
in
gitlab.
If
you
have
any
other
ideas
for
tutorial
steps
for
this
one,
please
share
them
here
on
the
issue
so
yeah.
So
in
case
you
have
any
ideas
regarding
what
additional
tutorial
steps.
The
technical
writing
team
can
help
us
with
particularly
for
plan
stage,
feel
free
to
add
your
links
there
and
that
should
be
covered
on
to
demos.
First
demo
is
from
Rajan.
B
B
So
we
have
just
added
a
copy
reference
and
copy
email
address
links
in
the
work
items
now
this
is
similar
to
what
we
have
on
issues.
So
if
you
want
to
copy
reference
of
an
issue
or
email
address,
you
can
just
do
it,
and
it's
basically
give
you
reference
in
the
incoming
email
address
similar
to
that.
We
now
have
it
for
work
items,
so
we
can
do
it
for
task
and
similar.
We
have
given
it
for
objective
and
the
key
results.
B
So
we
have
maintained
the
key
consistency
of
keeping
the
work
item
type
in
the
button.
Let's
see
if
it
is
a
key
result,
it
will
mention
that
copy
key
results
email
address.
So
this
is
similar
to
what,
if
you
have
any
issue
so
in
issue,
it
shows
copy
issue,
numerators
kind
of
thing,
but
it
does
the
same
thing
and
then
it
will
just
give
you
the
email
address
and
reference
to
that
particular
work.
Item
yeah
I
mean
that's,
that's
what
it
is
about.
This
particular
demo.
C
So
do
we
have
to
do
any
setup,
because
I
remember
when
I
was
doing
the
changes
for
the
move,
sidebar
items
there
was
a
setup
that
was
required
for
the
issue
email
address.
Is
there
a
setup
required
for
work
items
as
well?
Yeah.
B
So
I
found
it
one
document
around
that,
so
we
just
need
to
enable
the
incoming
address
and
config
gitlab
yml
on
on
our
local
setup.
C
B
This
was
I,
guess
related
to
more
of
I
mean
that
was
the
common
configuration
I'm,
not
sure.
If
there
is
a
setting
yeah.
A
So
that
that
jdk
config
is
globally
and
it
is
applicable
across
the
board,
regardless
of
what
the
underlying
objective
type
is.
Okay
and.
C
Okay,
so
I've
been
working
on,
I
haven't
been
doing
demos
a
lot
lately,
but
then
I
can
show
you
a
couple
of
things
that
I've
been
working
recently.
The
latest
that
I've
been
working
on
is
the
the
user
role.
Badges
and
work
item
notes.
C
So
there
are
three
kinds
of
badges
that
you
see
on
notes:
the
author,
the
user
access
level
and,
if
the
user,
if
the
author
of
the
node
is
a
contributor
or
not,
so
these
are
three
different
badges
depending
upon
the
access
the
level
of
access
the
author
node
has
so
author
is,
if
you
see
the
author
role,
it
is
basically
that
the
issue
able-
or
the
work
item
is
created
by
the
work
item-
node
author,
so
I
see
author
here,
because
admin
created
this
issuable,
so
you
don't
see
it
on
any
other,
because
wherever
the
comments
are
by
the
author
of
the
work
item,
you
can
see
the
author
badge,
the
owner
or
the
maintainer
or
the
developer.
C
These
are
the
roles
that
you
have
in
a
project.
Then
you
are
the
note
author.
So
here,
if
you
want
to
see
how
to
create
these
level
of
access,
I
have
in
the
Mr,
there
are
steps
to
create
different
levels
of
access
for
the
project.
So
for
this
we
had
to
add
to
back
like
for
this.
This
is
just
a
front-end
change.
You
can
check.
C
If
the
note
author
is
the
author
of
the
work
item,
which
information
is
already
available,
but
to
check
that
the
note
author
is
the
access
level
of
the
note
author,
which
we
don't
have
right
now
we
have
to,
we
are
getting
it
from
the
API
and
the
contributor.
This
is
what
we
are
getting
from
the
API.
These
are
two
flags
which
we
added
in
this
in
this
Milestone
and
the
front
end
is
what
you
are
seeing.
C
It
will
be
merge
in
the
next
Milestone,
because
the
backward
compatibility
so
me,
like
I,
started
it
out
for
the
backend
changes
and
Mars
March
cell
muscle.
He
helped
me
in
because
they
were
n,
plus
one
queries
resulting
to
that.
So
this
is
the
backing
change
and
the
front
end
will
do
merge
in
the
next
Milestone,
the
other
things
which
I
know
it's
not
a
part
of
the
agenda,
but
I
still
wanted
to
show
their
couple
of
things
which
haven't
been
demoed
is
the
internal
notes.
C
Internal
notes
work
in
the
same
way
as
we
do
in
we've
seen
issueables
in
issues.
If
you
write
a
comment
here
and
you
see
this
checkbox
and
this
will
only
be
available
to
the
project
with
certain
access.
So
if
you
add
an
internal
node
here,
it
will
be
an
unload
and
all
the
comments,
and
the
replies
will
also
be
any
reply
to
a
main
comment
is
also
internal
note,
and
you
will
see
the
same
changes
here
yeah.
C
So
that's
that's
that
and
there
were
some
UI
changes
which
are
which
were
done
both
in
issueables
and
in
work
items,
for
example
this
in
the
main,
in
a
not
in
a
in
a
comment
that
is
not
internal,
you
can
see
that
apply.
Background
is
different,
and
even
when
you
open
it,
this
background
was
merged.
So
there
were
some
UI
changes
that
were
also
done
in
both
issues
and
in
work
out
in
work
items
in
the
same
Milestone.
Also
there
was
a
in
the
dark
mode.
Also
you
can
check.
C
There
was
some
bug
which
was
present,
which
I
saw
during
this.
That
was
also
done
other
than
that
this
is
a
description
diff
also,
which
was
there,
which
was
merged
in
the
last
last
Milestone,
not
this
one,
but
you
can
check
it
out
how
it
works.
It
works
the
same
way
as
initiables,
but
just
to
give
you
a
different,
a
little
info
on
how
it
works.
C
When
you
change
the
description
of
any
work
item
or
issuable
within
the
first
in
within
10
minutes,
it
results
in
the
same
system
node,
for
example.
If
you
see
a
system
right
now,
if
I
change
the
description
here,
I
don't
know
if
I
within
the
10
within
10
minutes,
for
example,
if
I
keep
on
changing
it
again
and
again
in
from
the
back
end
I'm,
getting
all
the
system
notes
and
they
are
being
you
know
they
are
being
scanned
through
if
it's
within
the
time,
differences
within
10
minutes.
C
C
So
if
you
look
at
this
there's
a
right
now,
this
change
is
a
breast
API,
which
there
are
plans
of
changing
that
to
graphql
endpoint,
delete
and
fetch
the
diff
are
in
rest,
but
then
they
will
be
changed
into
graphql.
C
There
are
plans
of
doing
that,
but
it's
not
like
prioritized
or
planned
right
now,
but
we
have
an
issue
for
that.
So
yeah.
There
are
a
couple
of
other
things
UI
here
and
there
that
you
can
see
but
yeah.
These
are
the
major
changes
in
work
items
that
I've
been
working
on
so
yeah.
A
So
not
strictly
related,
but
I
I
see
that
emoji
buttons
are
present
on
notes
for
a
while.
Now.
A
Think
yeah
but
I.
A
Are
working
and
I
was
discussing
Apex
to
work
items,
migration
plan
with
Amanda,
and
this
was
one
of
the
things
that
was
brought
up.
That,
in
terms
of
like
discussion
features.
What
is
the
parity
that
we
have
between
work
items
and
epics
today
and
what
are
the
things
which
are
missing
and
I
said
that
emojis
are
I,
think
under
progress
but
haven't
been
completed
yet
yeah.
C
So
this
is
also
something
that
I
have
I
was
personally
thinking
of
looking
into,
because
in
my
local
I
have
the
work
items
and
we
see
to
flag
on
okay
and
and
it
doesn't
work.
So
this
is
not
something
that
I
have
been
working
on
actively
I.
Think
Simon
started
it
right,
but
then
yeah
I
have
to
like
see
how
what
is
the
status?
But
yes,
I'll
I'll,
see
where
it
is.
I
haven't
I
looked
into
the
issue
like
when
it
was
started,
so
it
was.
C
The
same
thing
was
happening,
but
I,
don't
I'm,
not
really
sure
at
work
State.
This
is
this
is
in,
but
I
look
into
it
and
confirm.
But
this
is
not
something
I've
been
actively
working
on,
but
I
will
yeah
I
would
like
to
get
it
finished.
That's
why
I
was
looking
at
why
this
is
the
only
thing
which
is
otherwise.
C
If
you've
seen
work
item
discussions
a
lot,
a
lot
of
things
have
been
done
like
more
and
more,
like
I
personally
started
using
tasks
also
because
all
of
the
things
that
were
present
in
issuables
are
almost
there.
So
yeah
I
know
that
com,
the
Emojis,
are
missing
because.
B
Simon
has
yesterday
sent
me
one
Mr
related
to
this
and
I
guess.
It
was
working
great.
We
are
just
reviewing
back
and
forth,
so
we
can
get
results
but
I
guess
it
is
planned
in
16.1,
but
the
work
is
still
going
on
and
I
hope
we.
We
will
be
able
to
clear
that
today,
so
one
we
are
just
stuck
due
to
one
test
case
failures,
but
I,
guess
that
is
just
a
nominal
thing,
but
I
guess
that
will
go
get
solved
today
or
tomorrow
by
tomorrow.
A
Okay,
so
I
have
a
discussion
item
here
and
we
have
Flory
already
on
the
call,
so
Flory
can
expand
out
on
it.
So,
basically,
we
are
proposing
to
have
some
form
of
visual
regression
testing
in
plan
stage,
at
least
in
the
past.
We
did
propose
it
for
entire
front
end
of
gitlab
after
we
introduced
it
in
gitlab
UI.
Once
we
introduced
Cyprus
to
gitlab
UI.
A
We
also
proposed
it
for
plan
for
gitlab
project
itself,
but
it
didn't
went
through,
but
in
the
past
we
ran
into
a
customer
escalation
around
roadmap,
where
some
of
the
bugs
were
very
visual
in
nature,
to
the
point
where,
if
we
had
any
form
of
visual
regression
testing
in
place,
those
bugs
could
have
been
avoided
like
this
timeline
bars
in
on
road
map
were
not
aligned,
as
per
the
dates,
some
things
which
are
not
easy
to
test
I
adjust
because
of
how
the
positioning
and
everything
works
on
roadmap,
so
I
brought
it
up
in
160
retro
as
well
that
this
is
something
that
we
should
really
think
about
at
least
so
plan
stage
and
all
the
features
within
plan
stage.
A
So
here's
the
proposal
and
flori
brought
it
up
in
front-end
Vision
discussion
as
well,
so
I
have
one
question
for
Ezekiel
here.
If
I
understand
correctly
value
stream
analytics,
which
uses
charts
heavily
I,
believe
that
is
also
one
of
the
features
that
can
leverage
visual
regression
testing
right
like
how
the
linear
regression
is
working,
especially
after
we
introduced
it.
I
think
in
past
update
like
whether
the
chart
is
being
rendered
correctly
or
not
like
all
the
bars
and
the
lines
are
everything
are
being
rendered
correctly
or
not.
D
Yeah
I
think
that
would
actually
make
a
lot
of
sense,
not
just
for
vdsa,
but
also
we've
got
a
whole
bunch
of
other
analytics.
So
there's
like
contribution
analytics,
merge
price
analytics
all
that
sort
of
stuff,
I.
Think
at
the
moment
we
tend
to
just
test
for
the
data
set.
That's
passed
into
each
Arts
is
correct,
but
don't
actually
test
like
the
rendered
visual
chart
itself.
So
that
does
make
sense.
D
D
E
Was
one
of
the
thoughts,
the
visual,
the
visual
regression
testing
that
we're
interested
in
on
like
much
bigger
features
than
just?
What's
in
storybook
like
for
us,
for
example,
it's
roadmap,
which
is
a
heavily
visual
thing
that
is
actually
really
hard
to
it's
really
hard
to
automate
that
it's
all
rendering,
as
expected
without
visual
regression.
So
we
do
when
it
comes
to
storybook
we've
done.
We've
introduced
Cyprus
gitlab
UI
for
integration
tests,
like
really
complex
components
like
to
look
at
search.
E
E
The
current
plan,
like
the
conversation
happening
in
the
front-end
Vision
working
group,
is,
and
people
want,
a
way
to
write
visual
regression
testing.
So
there
is
a
conversation
around
Cyprus
since
we
already
use
it.
It's
really
easy
to
like
just
bootstrap,
it
put
it
on
CI
and
it
started,
and
then
we
already
have
a
diff
tool
for
screenshots.
So
supposedly
that
should
be
really
easy
and
there's
been
I'm
trying
to
find
I.
E
E
The
goal
now
is
to
build
a
proof
of
concept
and
see
how
that
goes
and
try
to
sort
of
convince
other
people
to
get
on
board
and
adopted,
and
so
on,
but
yeah
a
few
teams
are
interested
in
just
like,
and
not
just
stories
like
just
features
that
are
heavily
visuals
like
things
with
graphs
and
things
like
that
that
you
can't
really
test
any
other
way.
D
Quick
question:
do
we
think
this
would
eventually,
from
a
front-end
perspective,
replace
feature
tests
or
sorry.
E
Maybe
augment
them.
I
did
say
that
in
the
conversation
and
the
issue
I
can
I
can
share
the
front-end
Vision
issue.
There's
a
lot
of
different
conversations
happening
all
that
the
issue
has
already
been
linked
by
a
shell,
but
the
the
goal
is
just
for
visual
regression
testing,
because
the
problem
is,
it
has
been
brought
before
to
use
a
JavaScript
library
for
end-to-end
tests
and
we
always
get
pushback
from
QA.
They
don't
want
to
learn
any
new
tools.
We
already
have
aspect.
We
have
all
the
factories
for
them.
E
It's
it's
easy
so
that
they
just
want
to
keep
that
they
don't
every
time
we
just
get
so
much
pushback.
So
the
goal
in
this
case
is
just:
we
have
end-to-end
tests
and
QA
in
Ruby
like
feature
specs,
and
then
the
the
Cyprus
folder
would
be
front-end
owned,
and
it's
just
for
visual
regression
testing.
So
if
you
write
super
like
the
files
would
probably
be
really
small,
it's
just
about
like
running
a
set
of
data
and
just
screenshot
diff
it
on
CI
done
nothing
else.
D
D
C
D
E
In
yes,
that's
that's
all
that
we
would
want
to
do
with
that
yeah,
because.
E
A
So,
given
that
capybara
already
generates
screenshots,
except
that
it
it
only
generates
when
the
test
fails,
I
wonder
if,
if
there
is
a
resistance.
E
So
that's
something
else
that
we
could
look
into
is
to
include
them
in
feature
tests
using
Ruby
and
feature
and
see
if
we
can
trigger
a
screenshot
and
do
a
diff
it's
better
in
the
sense
that
it
doesn't
introduce
another
library
and
a
separate
folder
and
a
separate,
completely
separate
system
to
maintain.
But
at
the
same
time
we
run
the
risk
of
it
being
messy
getting
lost.
It's
all
like
buried
into,
like
all
the
other
feature
tests
that
we
have.
What
is
visual
tested?
E
What
is
not
is
it
easy
to
find
not
necessarily
like
we
can
explore
different
options,
certainly,
but
I
think
there's
pros
and
cons
on
both
sides.
A
Because
the
advantage
that
we
would
have,
if
we
generate
the
screenshots
and
do
the
diff
comparison
via
our
specs,
is
that
we
get
all
the
set
of
features
for
free,
because
you
can
create
exact
scenario
by
using
the
actual
back
end
which
is
being
used
and
then
generate
the
screenshots
out
of
it.
So
if
there
is
a
change
in
a
backend
API,
then
we
don't
have
to
make
sure
that
our
regression
testing
Suite
is
also
updated
to
reflect
those
changes.
And
we
get
all
those
advantages
for
free
by
generating
the
screenshots.
E
Yeah
I,
it's
a
really
good
point
because,
like
Cyprus
was
really
easy,
storybook
gitlab
UI,
because
there
is
no
back
end,
truth
is
I,
don't
know
how
much
setup
will
be
required
on
the
product
to
have
a
page
that
renders
epics
on
roadmap
testing
I,
don't
know,
potentially
testing
permission
like
what
which
buttons
are
displayed
based
on
permissions.
E
You
have
different
user
profiles
and
different
levels
of
permissions
and
such
and
to
be
quite
honest,
I,
don't
know
how
easy
it
is
to
set
that
up
for
Cyprus,
because
it's
very
because
it's
so
user-centric,
it's
all
about
like
workflows
and
clicking
on
things
and
in
terms
of
setup.
It
could
be
massive
so
in
in
a
case
like
that
yeah,
we
should
probably
look
at
aspect
screenshots
as.
D
A
possible
I'm,
not
I'm,
probably
shooting
myself
in
the
thought,
but
as
a
possible
path
forward,
because
we
already
have
quite
a
lot
of
aspect,
feature
tests
for
mostly
VSA,
but
also
like
issue
analytics
and
a
few
other
Pages
like
that.
So
if
we
did
want
to
go
down
the
Cappy
bar
at
screenshot,
diving
path,
we
could
like
in
my
mind,
I
think
we
could
fairly
integrate
easily
integrate
that
into
our
existing
feature.
Tests.
D
I
think
it
could
be
something
worth
exploring
as
well,
because
it'll
probably
encourage
back-end
developers
to
also
utilize
it.
If
it's
already
there
just
throwing
some
shade
but
yeah
just.
A
B
A
So
it
also
gives
us
in
certain
scenarios,
although
cross
browser
compatibility,
doesn't
bother
us
as
much
as
as
it
used
to
a
couple
of
years
ago,
but
we
may
still
run
into
some
situations
here
and
there,
where
we
are
using
a
very
obscure
way
to
style
something,
and
it
is
not
consistent
across
the
browsers
and
that's
where
comparing
screenshots
between
these
two
different
Runners
would
really
help
and
I
believe
we
do
have
one
of
the
job
that
tests
the
entire
app
against
Firefox
I,
don't
know
whether
it
is
enabled
by
default
or
not.