►
From YouTube: CI/CD UX Meeting - 2021-10-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).
A
And
this
is
the
cicd
ux
meeting
for
october
20th
2021
a
couple
of
one
actually
announcement
that
why
I'm
gonna
voice,
I'm
gonna,
have
a
new
ux
researcher,
starting
on
october
25th,
so
yay
and
will
do
you
know
exactly
where
the
person
is
going
to
be
located.
I
know
that's
in
the
u.s
specific
time
zone
that
maybe
you
have
more
info
than
I
do.
B
I
don't
have
too
much
more
info,
I
haven't
been
told
exactly
which
researcher
is
going
to
be
over
the
verify
group.
I
do
know
that
there's
two
researchers
coming
in
one
is
named
ben
and
one
is
named
erica,
I'm
not
sure
where
ben
is
based
out
of,
but
I
know
erica,
I
think
lives
in
like
the
portland
area
in.
I
think
washington
state.
A
Okay,
awesome
well
we're
gonna
hear
more
from
from
adam
than
in
the
coming
weeks.
So,
but
that's
soon
that's
next
week,
thanks
for
sharing
and
general
announcement,
just
from
myself,
I'm
doing
some
housekeeping
on
our
research
backlog
for
solution
validation,
but
also
the
that
sorry
problem,
validation,
ux
debt,
nux
scorecards.
So,
on
the
first
link,
I
organized
the
scorecards
for
stage
group
before
they
were
all
in
the
main
epic.
So
just
a
heads
up
next
time
you
create
a
scorecard.
A
Please
place
it
within
your
stage
group
epic,
also
when
tracking
problem
validation,
make
sure
you're
adding
the
problem.
The
ux
problem,
valid
solution,
validation
label
and
also
I
created
this
tracking
epic
for
each
stage
group.
A
So
I'm
trying
to
find
a
way
for
us
to
not
only
look
at
the
issues
but
stay
on
top
of
what's
next
and
when
that's
going
to
be
scheduled
so
that
we
can
have
more
opportunities
to
talk
about
items
that
overlap
with
teams
across
ci
cd.
So
the
second
one
is
an
experiment.
A
Please
try
it
out.
Let's
see
if
it
works,
let's
see
if
it's
too
much
process,
I'm
keeping
track
of
these
things
or
not,
and
the
last
one
is
a
cic
ux
adapt.
We
have
a
if
you
haven't
seen
it
yet.
We
have
a
periscope
dashboard
with
all
the
data
for
our
teams
adjusting
created
for
me
for
release
verifying
package,
and
it
shows
the
number
of
open
issues,
but
also
the
time
it
takes
to
close
our
ux
steps.
A
So
I'm
looking
at
these
issues,
this
board
in
particular,
but
also
I
want
to
start
tracking
the
working
progress
and
what's
next
for
ux,
that
since
now
with
the
q4
we're
going
to
for
verify
in
particular
where
you
have
a
ux
step
and
you
export
card
recommendations
as
part
of
the
product
kr
for
verify
so
try
to
keep
track
of
those
so
that
we
have
a
baseline
for
the
upcoming
milestones
thoughts.
Questions
comments,
please
feel
repeat
the
whitening.
C
Yeah,
this
is
really
good
effort,
thanks
diana
for
organizing
all
of
this.
It's
something
that
I
tell
myself.
I
will
do
one
day,
but
I
never
do
so.
Thank
you
very
much,
it'd
be
really
cool.
If
we
could
have
one
place
where
we
could
have
all
of
these
issues
and
links
like
organized
somehow,
but
I
don't
know
where
that
could
be.
Maybe
we
could
have
like
a
google
doc
that
will
link
in
our
ci
cd
slack
and
like
pin
it
there
or
have
it
inside
the
topic,
or
something
like
that.
A
Yes,
I'm
working
on
a
handbook
update
that
will
have
a
list.
That's
actually
I'm
going
to
find
here
and
link
it
for
you
after
I
finish
speaking,
I
want
to
document
this
in
the
handbook
and
say
that
how
we
are
contributing
to
the
kpis
and
I'm
listening,
I'm
listing
all
these
epics
within
the
themes
or
how
we
are
influenced
you're,
helping
us
the
ux
department
achieve
the
the
fy
22
direction.
So
the
handbook
is
the
first
thing
I
thought
we
could
start
this
information.
D
No
problem
yeah,
I
was
going
to
suggest
we
could
at
least
have
the
the
links
to
the
to
the
boards
or
the
searches
for
for
ux
dev
issues
for
each
one
of
the
groups
after
the
tables.
So
so
the
tables
show
the
work
in
progress
what's
being
done
what's
being
completed.
But
then,
if
you
go
into
the
links
with
the
searches
we
have
all
of
them
to
look
at.
A
That's
a
great
idea:
the
periscope
board
right,
okay,
yeah
cool
I'll
update
the
issue,
descriptions
yeah
and
please
update
them.
When
you
have
a
chance,
I'm
gonna
start
checking.
I'm
gonna
try
to
check
beginning
of
the
milestone
right.
So
when
the
teams
do
the
planning
and
also
meet
and
milestones
to
see
how
we
are
moving
forward
with
the
items,
but
also
to
see,
if
there's
anything
that
needs
a
an
update
right,
cool
kind
of
cat
is
really
walking
in
front
of
the
character.
E
A
It
should
be
solution,
validation.
Thank
you,
gina,
for
we
actually
have.
I
think,
a
wax
research
tracker
for
the
stage
groups
will.
Maybe
you
are
a
bit
more
up
to
date
on
that,
for
the
the
drama,
validation
issues.
B
I'm
not
too
familiar
with
that.
I
just
know
that
we
have
templates
for
problem
validation
and
solution
validation.
A
All
right,
thank
you.
That
would
be
awesome.
I
know
that
I
know
that
we
have
the
prioritization
issues
for
first
stage
group,
I'm
going
to
link
here
the
other
one
for
release.
A
B
Okay,
so
just
a
couple,
quick
updates,
so
just
the
other
day
I
reviewed
daniel's
research
questions.
I
appreciate
you
know
daniel
for
including
me
on
that
and
getting
some
or
wanting
to
get
some
feedback.
So
I
really
appreciate
that
sounds
like
you've
been
able
to
do
a
couple
dry
runs
and
that's
you've
been
able
to
make
a
lot
of
progress
with
that.
So
really
happy
to
hear
about
that.
I
think
I
also
helped
out
gina.
B
I
forget
if
it
was
like
a
week
or
two
ago,
with
a
user
testing
study
that
she
launched
was
able
to
provide
some
feedback
on
her
screener
and
her
just
study
like
overview
and
set
of
questions
and
then
outside
of
that
for
the
release
team.
I'm
helping
kevin
chu
he's
basically
put
together
like
a
list
of
clients
that
we
could
potentially
talk
to
for
some
questions
around
release,
in
particular
around
like
why
people
are
not
using
get
lab
for
release
and
using
other
kind
of
competitor
tools.
E
B
D
All
right,
thanks
for
that,
will
yeah.
So
on
my
side,
yes,
like
will
mention,
he
helped
me
a
lot
with
research
questions
this
time
for
the
solution,
validation
more
recently
on
the
designs
for
the
environments,
page
thanks.
Everyone
who
left
comments
and
feedbacks
on
on
the
thread
really
appreciated.
It's
a
really
complex
design.
D
We
started
solution
validation.
Last
week
I
had
two
dry
runs
that
went
really
well
like
the
users
had
had
it
very
easy
to
to
go
over
the
questions
and
the
prototype
like
nothing
broke
along
the
way.
So
I
counted
those
two,
as
as
actual
tests
ordered
three
more
but
then
in
the
meantime,
we'll
have
left
some
some
comments
on
the
script,
so
we
improved
a
couple
of
things.
D
Usertesting.Com
is
super
fast,
so
we
already
have
the
five
tests
all
done
so
this
week,
I'll
take
the
time
to
analyze
and
wrap
it
all
up
in
parallel,
the
the
the
actual
issue-
maybe
it's
nice
for
me
to
to
share
my
spring-
will
quickly.
Here
I
broke
down
the
design
already
in
in
front
and
components.
D
The
the
usability
testing
is
meant
to
capture
like
the
biggest
red
flags,
but
since
we
have
a
lot
of
feedback
already
from
the
team,
I
have
lots
of
confidence
in
this
design.
So
we
proceeded
to
break
down
the
the
actual
design
in
front
and
components,
so
the
folder
growing
from
the
outside
in
the
folder,
the
environment,
the
environment,
part
of
the
folder,
the
deployment
and
even
the
badges.
There
will
definitely
be
a
lot
of
smaller
conversations
in
each
of
these
to
see.
D
Okay,
what
we
adopt
straight
away
from
pajamas,
what
really
needs
to
be
customized
a
little
bit
and
where's
the
middle
ground
that
so
so
yeah
keep
you
up
to
date
on
this
conversation
whenever
relevant
so
yeah.
On
top
of
that,
for
this
milestone
milestone,
we
have
one
more
issue
to
deploying
by
improved
deployments
and
also
tackle
group
level
environments,
which
is
the
big
issue
that
we've
been
working
towards
so
really
excited
to
work
on
that.
C
Really
great
work
on
this
district
design
daniel
it's
super,
complex
and
you're,
taking
on
a
pattern
that
it's
not
that
easy
to
move
forward
with
it
because
of
the
existing
problems
right.
So
I
think
you're
really
tackling
some
of
those
challenges
really
well,
and
I
was
wondering
if
you,
if
you
have
any
tips
around
setting
up
a
user
testing
prototype
for
this
and
the
scenario
share
since
you
said
that
your
dry
run
test
went
so
well
for
me.
C
Usually
I
always
find
some
weird
twists
and
turns
and
have
to
change
things
so
yeah.
If
you
have
any
tips
to
share
around
user
testing
how
to
create
successful
testing
script
and
prototype,
please
do
I'll
be
doing
it
next
week.
So
that
would
be
helpful.
D
So
for
for
this
issue,
specifically
this
redesign,
it's,
it
doesn't
really
add
any
new
functionality
on
the
page,
it's
all
about
like
reorganizing,
what's
already
there,
so
I
made
sure
that
the
the
script
and
the
questions
really
focused
on.
Can
you
find
this
piece
of
information?
Can
you
find
that
piece
of
information?
So
what
is
the
status
of
the
environment
production?
D
What
is
the
commit
id
of
this
specific
deployment
right,
just
like
where's,
waldo
kind
of
kind
of
test
like
find
all
the
pieces
that
we're
looking
for
just
to
make
sure
that
this
information
is
findable
and
it's
understandable
and
the
new
designs
are
easy
to
navigate.
So
for
me,
that's
that's
the
the
easiest
test
to
set
up
because,
like
you,
don't
have
new
concepts
or
new
tasks
that
the
user
has
to
absorb,
and
I
think
that's
what,
in
my
experience,
is
what
works
best
for
unmoderated
tests
right.
D
You
don't
have
any
new
mental
model
or
new
workflow
that
first,
the
user
has
to
understand
and
they
then
they
have
to
act
on
because
then
there's
like
a
thousand
things
that
could
go
wrong,
not
to
say
that
I
wouldn't
do
a
usability
testing
like
that.
But
I
think
this,
if
you
go
low
level
like
as
as
simple
as
possible,
on
undo
this
task
and
find
this
information.
I
think
there's
a
highest
chance
of
success
for
a
mother
test.
C
So
so
it's
did,
you
show
them
static,
mockups
or
a
clickable
prototype
to
complete
some
tasks.
D
They
are
clickable,
but,
but
in
like
I
try
to
keep
it
as
simple
as
possible,
so
they
are
clickable
in
a
way
that
you
can
open
the
folder
and
then
open
the
environment
and
then
open
the
deployment.
But
it's
all
very
linear,
like
just
drilling
down
into
the
hierarchy.
D
I
even
like
simplified
a
couple
of
things.
I
didn't
add
two
tips
that
kind
of
thing,
because
it
would
be
too
much
so
keeping
the
prototype
simple,
like
not
too
big
stuff.
F
Yeah-
and
I
also
went
through
the
the
comment
that
you
had
put
there
and
after
the
feedback
that
we
have
provided,
you
have
really
haven't
done
a
lot
of
work
there
and
I
just
wanted
to
drop
that.
I
will
be
conducting
a
solution-
validation
for
the
webline
index
page,
but
this
time
I'll
be
speaking
with
users,
because
even
though
we
have
mostly
rearranged
stuff,
but
we
also
want
to
get
a
better
hang
of
like
what
are
users
using
those
pages
for
because
that
jtbd
in
itself.
For
us,
it's
not
100
clear.
F
So
we
want
to
in
that
research
itself,
also
kind
of
validate
the
jtpd
that
we
have
associated
with
those
pages,
as
well
as
get
some
insights
around
how
they
are
using
identifiers,
so
yeah.
And
if
I
get
any
insight
which
I
think
I
would
that
might
help
us
in
the
list-
redesign
work.
I
will
share
it
in
that
issue
and
with
the
team.
D
All
right
I'll
hand
it
over
to
katie
not
sure
if
hannah
wants
to
voice
some
of
her
comments.
A
Yeah
I'll
voice
over
her
comments,
I
think
also
it's
a
good
discussion
here,
getting
questions
around
how
to
involve
the
team
in
early
stages
of
the
research
and
design
process
right.
F
Yeah
sure
I'm
kind
of
a
little
lost
on
the
agenda
yeah.
So
first
thing
I
had
I've
kind
of
split
my
item
into
two
parts
because
I
wasn't
sure
like
if
katie
is
looking
at,
I
mean
seeking
feedback
interviews
from
the
developers,
the
development
team
she
works
with,
or
the
ux
team
or
both
in
general.
So
I
have
added
tips
for
the
ux
team.
F
I
mostly
use
the
slack
channels
unless
it
is
someone
from
cicd,
because
we
have
these
recurring
meetings
and
also
we
are
very
much
active
on
each
other's
issue
that
gets
easier.
But
if,
if
there's
something
that
I
would
want
eyes
from
the
larger
ux
team,
then
slack
is
the
best
place,
especially
the
co-working
and
the
research
channels
and
in
case
she's,
looking
at
involving
devs
from
the
beginning.
F
So
one
thing
that
I've
learned
is,
I
mean
unless
you
know
your
team
very
well,
and
you
understand,
like
who's,
going
to
pick
up
what
kind
of
work
you
should
always
loop
in
the
engineering
managers,
because
they
make
a
call-
and
they
put
you
in
touch
with
the
right
developer.
Who
would
have
knowledge
around
that
area?
And
it
gets
pretty
smooth
after
that.
A
I'm
gonna
voice
over
what
what
I'm
writing
here.
I
think
what
she
asked
about
right
if
the
team
is
interested
or
giving
visibility
in
the
work,
I
think
in
general
it's
important
to
use
multimodal
communication,
maybe
particularly
especially
for
her
katie
right
that
she
has
in
a
completely
different
time
zone
than
her
teammates
and
have
standing
discussion
points,
discussion,
items
related
to
the
the
ongoing
design
work,
but
also
the
research
and
the
results
right.
A
So
not
wait
until
the
end
or
once
we
get
over
we'll
go
over
some
insight
to
share
that
with
the
team,
but
have
a
cadence
to
bring
that
up
with
discussion
with
the
product
managers,
but
also
the
team
in
general
and
the
last
thing
the
planning
issue.
We
know
that
the
planning
issue
is
not
just
for
for
engineers.
A
So
if
the
the
upcoming
research
or
the
upcoming
validation
items
that
you'll
be
working
on
are
in
the
planning-
and
they
have
some
dependency,
for
example,
with
a
developer
that
needs
to
help
set
up
an
environment
or
that
needs
to
review
a
scenario.
Those
tasks
should
be.
You
know
in
the
in
the
planning.
I
need
to
be
awaited
by
the
the
teams.
A
They
need
to
be
aware
of
that
so
katie,
if
you're,
watching
this
later
on,
have
a
look
at
how
other
designers,
maybe
here
in
our
team,
are
doing
planning
and
how
that
that
issue
looks
today
to
see
how
they
are
communicating
the
the
upcoming
research
and
making
the
team
involved
in
these
initiatives
so
over
to
daniel.
D
Yeah,
you
and
vitika
said
all
the
good
stuff
already,
but
one
thing
I
would
like
to
add
here
is
that
having
some
redundant
redundancy
in
your
communication
helps
so,
of
course,
it's
always
a
fine
line
between
being
redundant
and
being
a
little
bit
annoying.
But
if
you're
sharing
a
design
or
requesting
for
feedback
on
the
group
channel,
it
might
be
worth
also
mentioning
on.
Like
the
weekly
group
meeting,
you
know
just
reinforce
and
because
some
people
pay
more
attention
to
slack
some
people
pay
more
attention
to
other
channels.
A
Great
input,
great
feedback
next
point
also
on
katie,
is
that
her
team
is
used
to
synchronously
doing
the
time
reviews
at
a
meeting
that
happens
once
a
month
and
she's
asking
how
you
do
design
reviews.
How
do
you
get
her
feedback
from
your
teams
in
a
way
that
works.
C
Yeah,
so
I
mostly
do
design
reviews
asynchronously
in
issues
and
actually
I
don't
call
them
design
reviews.
I
think
that
that
kind
of
feels
a
bit
like
I'm
presenting
designs
and
then
gathering
feedback
in
like
a
formal
way.
What
I
try
to
do
instead,
usually
is
just
have
ongoing
communication
with
the
engineers
and
the
product
manager
and
constantly
get
feedback,
and
that
I
think
that
works
better
for
stay
in
touch
with
the
team
and
really
having
closer
collaboration.
This
way.
C
A
monthly
ux
plus
front
end
sync,
where
we
kind
of
talk
about
more
like
vision
and
things
like
that
to
really
align
on
bigger
things
and,
of
course,
then,
there's
also
our
weekly
meetings,
but
sometimes
I
participate
synchronously,
sometimes
asynchronously
and
it
still
works.
Another
thing
I
really
rely
on
dole
my
product
manager
to
sometimes
communicate
my
design
proposal
or
ask
questions
or
host
a
discussion
in
the
weekly
meeting
if
I'm
not
attending.
C
So
I
might
add
some
my
points
and
links
to
issues
to
the
agenda
and
ask
dov
to
voice
it
and
lead
the
discussion
and
then
there's
a
recording.
And
then
I
can
ask
follow-up
questions
asynchronously
to
the
participants
who
who
were
part
of
the
discussion,
so
that
allows
me
to
kind
of
have
more
engagement
with
the
team
without
having
to
stay
up
late
for
the
meeting.
So
that's
also
a
good
hack
and
also
helps
your
product
manager
really
dive
deeper
into
the
design
proposal.
F
It's
all
right,
so
my
point
is
not
very
different
from
what
nadia
mentioned
and
I
just
like
added
a
recent
example,
but
most
of
the
discussions
that
we
have
in
pipeline
execution.
It
happens
in
the
issues
and
the
mrs,
so
we
have
very
extensive
discussions
there
and
that
actually
yields,
because
there's
so
much
of
historical
context
when
you
have
to
revisit
those
issues-
and
you
know
exactly
why
those
decisions
were
taken.
So
it's
always
the
best
place.
E
Hi
thanks,
I
was
going
to
say
that
my
my
responses
align
with
nadia
and
vitka,
but
we
do
have
these
their
bi-weekly
meetings.
I
believe
for
our
team
on
rauner
and
a
lot
of
those.
I
I
try
to
provide
design
like
updates,
I
guess
to
the
team
just
because
they're
not
always
aware
of
what's
going
on
on
the
design
side,
and
sometimes
those
also
turn
into
them
giving
feedback.
E
So
there
are
times
that,
like
that,
where
we're
talking
synchronously
about
the
designs,
but
most
of
the
time
I
try
to
just
keep
it
to
the
design
management
threads.
A
Hi
anna,
if
you
want
to
voice
yours,
was
that
me?
Oh,
I
thought
it
was
real
yeah
I'll,
just
a
voice
that
sun
jung,
amelia
and
alexis.
They
are
async
design,
reviews
champions
so
part
of
a
stage
group
how
they
look
at
the
work.
They
are
doing
how
they
are
communicating-
and
I
also
linked
here
the
handbook
page-
that
talks
about
design
reviews
and
has
a
couple
of
examples
of
issues
where
the
design
critique
of
the
time
review
was
done.
A
Async
for
reference,
so
look
into
that
and
for
package
in
particular
they
used
to
do
the
think
big
sessions.
I
know
that
they
still
do
monthly,
but
they
used
to
do
think
big
and
take
small
sessions.
Maybe
this
is
something
for
us
for
katie
to
look
into
and
see
how
she
can
continue
with
that.
With
that
ritual
with
her
team,
I
think
that's
always
to
get
that
feedback
in
a
more
structured
way,
yeah
and
will
you're
next.
B
Yeah,
just
to
build
off
of
what
you
were
saying,
even
though
sun
jung
does
a
lot
of
like
async
work.
B
She
did
include
me.
I
think,
in
the
first
month
that
I
had
started
at
get
lab
one
of
the
research
projects
involved,
basically
creating
something
from
scratch,
and
she
had
kind
of
taken
a
stab
at
it
and
put
something
together,
but
I
was
able
to
meet
with
her
and
the
pm
synchronously
and
we
just
kind
of
threw
out
ideas,
and
she
just
like
on
the
fly,
was
able
to
create
something
and
then
make
it
more
polished
like
after
the
fact.
B
So
that
was
another
way
that
I
thought
was
kind
of
helpful
to
get
some
insight
into
that
design
process,
even
though
it
was
not
pixel,
perfect
or
anything.
It
was
really
good
to
see
how
she
you
know,
works
kind
of
on
the
spot
and
makes
those
quick
adjustments.
D
D
The
two
caveats
is:
whenever
a
problem
is
too
big,
too
complex
and
there's
like
bunch
of
back
and
forth,
to
understand
that
a
20-minute
sync
meeting
with
the
pm
or
the
dev
that
has
the
most
knowledge
on
it
is
super
super
powerful,
like
he
can
save
you
days
of
discussions
just
sitting
down
and
having
them
expose
a
problem
and
some
example
in
like
15-20
minutes.
D
So
so
that
has
been
really
useful
for
me
and
similarly,
if
your
solution
is
too
large
and
complex
and
it's
hard
to
get
feedback
on
it,
just
recording
a
five-minute
bloom,
video
and
sharing
with
the
team
helps
communicate
something
that
maybe
would
need
many
paragraphs
of
text
to
show.
So
that
also
helps
people
absorb
your
your
your
content,
better.
A
C
Yeah,
so
I
wanted
to
share
a
couple
issues
that
we've
been
working
on
on
the
pipeline
authoring
team
and
they
all
relate
to
one
problem.
So
many
of
the
gitlab
ci
users
want
an
easy
way
to
retry
their
downstream
pipelines
from
the
main
pipeline.
So
if
you
have
a
very
complex
pipeline
configuration,
you
might
have
many
downstream
pipeline
plugging
into
your
main
pipeline.
So
the
main
pattern
triggers
all
of
those
downstreams
and
currently
there's
no
easy
way
for
you
to
retry
the
downstream
pipelines
without
having
to
go
into
those
pipeline
pages.
C
So
you
would
have
to
actually
click
into
each
downstream
pipeline
to
retry
it.
So
we
created
three
issues
to
address
this
problem
or
like
different
aspects
of
this
problem
in
three
iterations.
First,
we
will
be
adding
a
retry
button
to
the
trigger
job
page
currently
trigger
jobs.
Unlike
other
jobs,
don't
have
the
retry
button,
so
we
will
bring
the
retry
button
to
the
trigger
job
page.
C
We
will
also
add
another
option
to
trigger
jobs,
to
retry
the
downstream
pipelines
from
there.
So
we
will
have
a
split
button
to
retry
the
job,
with
two
options
available.
So
you
can
click
through
into
this
issue
to
see
what
it's
going
to
look
like,
and
then
we
will
bubble
up
that
action
into
the
pipeline
graph.
C
The
reason
why
we're
going
to
add
the
action
to
the
pipeline
graph
last
is
that
our
thinking
thinking
is
that
the
job
page
needs
to
be
the
source
of
truth
for
job
actions,
so
this
is
kind
of
like
the
lowest
level
page
for
the
job
and
everything
needs
to
stem
from
it.
If
we
show
some
some
information
about
the
job
in
the
ui,
you
should
still
be
able
like
in
some
other
place.
You
should
still
be
able
to
find
it
in
the
job
page,
so
we're
starting
with
the
job
page.
C
For
that
reason,
which
also
makes
the
implementation
a
bit
easier
as
well,
just
because
it's
easier
to
change
something
in
the
job
page
layout
than
in
the
pipeline
graph
and
yeah.
These
issues
had
lots
of
upvotes
from
our
customers.
C
So
we're
excited
to
address
these,
and
it
also
aligns
with
our
plans
to
make
downstream
pipelines
more
usable
and
just
generally
improve
the
user
experience
around
downstream
pipelines,
because
usually
the
users
who
are
heavy
users
downstream
pipelines
are
our
large
enterprise
customers
that
we
really
want
to
track
and
make
it
much
easier
for
their
teams
to
interact
with
gitlab
ci.
So
let
me
know
if
you
have
any
questions
or
comments,
feel
free
to
comment
in
those
issues
and
just
bring
me
async.
F
I'm
muted
all
right.
I
have
somewhere
two
very
light
topics.
The
first
one
is
about
the
community
event
that
I
did
it
was.
F
It
was
a
strange
but
nice
experience
to
I
mean
interface
with
the
indian
gitlab
community
or
would
be
indian
good
lab
community
for
the
first
time
there
are
many
new
people
who
were
introduced
to
gitlab
through
the
event,
and
hopefully
we
will
see
some
converts
from
there
and
it
was
good
to
understand
like
what
kind
of
temperament
they
have
around
the
product
and
what
is
it
that
we
can
like
that?
F
We
should
be
talking
more
about
promoting
more
in
regards
to
the
product
that
could
attract
more
community
members,
and
the
second
one
is
something
that
I've
already
shared
in
the
slack
channels,
which
is
a
recording
of
good
practices
for
reviewing.
Mrs
one
thing
I
wanted
to
highlight
that
jose
has
some
very
interesting
ideas
on
doing
a
series
around
these
reviews,
like
the
practices
around
reviews
and,
if
there's
anything
in
specific,
any
problem
that
you
are
facing,
and
you
feel
that
has
not
been
covered
in
the
video.
Please
let
us
know
so.
E
Gina
thanks,
I
will
just
go
quickly
through
this,
the
one
more
of
like
discussion,
point
that
I
had.
If,
if
you
all
have
it
have
time
to
look
through
it,
there
is
a
really
large
community
contribution
that
was
for
runner
recently,
and
it
was
so
big
that
it
was
touching
a
lot
of
areas
of
gitlab.
E
So
I
was
trying
to
break
it
down
to
solve
it
for
these
different
levels,
because
it
affected
projects,
groups
and
instances,
and
what
I
ended
up
doing
was
like
separating
those
out
into
additional
issues,
and
I
asked
the
contributor
to
break
up
the
mr,
but
I
guess
there's
still
ongoing
discussion
about
how
that's
going
to
work.
E
My
question
that
came
out
of
it,
though,
was
if
how
how
we
determine
what
things
live
in
settings
today
versus
how
if
it
should
stay
on
the
main
like
table
screen.
For
example,
there
is
like
this
configuration
option
that
they're
trying
to
add,
and
it
will
take
up
a
lot
of
room
with
runners,
because
it's
you
know,
runners
today
lives
in
settings
and
it's
like
really
squished
down,
there's
not
a
lot
of
room
today.
F
Sure
so
I
I
looked
at
the
issue
from
this
agenda
and
I
have
been
thinking
about
it.
So
I've
written
something,
but
I
don't
want
to
verbalize
that
I'll,
probably
change.
My
comment,
I
mean
the
points
there
are
valid,
that
there
are
just
three
permission:
levels
that
actually
have
the
access
to
change
anything
related
to
runners,
so
you
don't
have
to
get
deeper
than
that.
It
just
stops
there.
The
other
one
like
as
a
designer.
F
The
question
that
you
should
be
asking
is
this
solution
is
like
what
pro
problem
is
it
catering
to
like?
I
see
this
mostly
being
applicable
and
useful
for
the
instance
runners,
because
they
want
a
higher
security
and
higher
control,
but
is
it
valid
on
more
specific
runners
like
do?
Do
we
even
need
to
implement
this
at
the
group
and
project
level?
F
Do
users
want
that
kind
of
control
with
the
specific
runners,
or
would
they
rather
just
go
and
quickly
register
a
new
one
and
that
won't
bother
them
so
and
as
far
as
the
like,
where
it
should
be
placed,
I
think
settings
is
the
place
for
adding
any
kind
of
configuration,
because
that's
what
we
have
been
doing
in
ci
cd
so
far,
so
any
kind
of
configuration
it
goes
into
the
settings
and
we
just
try
to
match
the
language
of
the
existing
sections
in
the
settings.
F
So
I
mean,
if
you
see
that
there's
kind
of
a
section
that
talks
about
limitations
like
adding
any
kind
of
limitations.
It
should
probably
be
placed
under
that,
but
I
have
this
strong
feeling
that
this
particular
solution
is
most
useful
only
for
instance
runners,
and
should
I
mean
this,
the
configuration
should
be
accessible
to
admins.
I
mean
you,
you
can
totally
like,
take
it
or
leave
it,
but
that's
just
my
opinion.
E
Yeah,
no,
I
think
you're
right,
I
was
gonna
say
I
think,
that's
what
why
I
tried
to
separate
them
in
the
first
place
and
tackle
instance,
runners
first.
The
thing
is
that
this
request
is
coming
specifically
for
those
who
need
it
for
the
for
project
runners.
I
think
right
now,
because
there
are
like
admins
for
projects
technically
they're,
not
in
the
same
way
that
we
have
the
admin
view,
but
they
act
as
admins
pretty
much
so
they
would
need.
E
A
role
is
it
yes,
so
they
would
need
that
type
of
like
configuration
from
a
ad
from
a
project
level,
so
they're
like
responsible
for
maintaining
runners
on
a
project,
so
they're
considered,
like
the
admin
of
their
project,
got
it
yeah,
but
that's
one
request,
so
I
mean
it's
it's
hard
to
it's
been
hard
for
me
to
like
go
through
this
and
provide
feedback.
I
would
say,
because
it's
coming
specifically
from
one
customer.
A
Yeah
and
then
just
a
sidebar
here
on
the
community
contributions,
they're,
tough
and
usually
I
think,
that's
what
we're
seeing
right.
They
come
with
a
very
complex,
weird
package,
but
it's
also
important
that
we
let
the
community
know
that
this
is
how
we
build
gitlab
right.
That's
how
we
contribute.
We
go
for
the
envy
team
and
break
things
down
and
if
the
problem
is
too
complex
or
it's
only
solving
one
specific
problem,
one
specific
use
case-
we
need
to
look
broader.
A
So
I
think
this
process
is
uncomfortable
and
it
will
continue
being
uncomfortable
because
these
people
are
not
working
the
gitlab
way.
So
I
think
what
you
did
here.
Gina
was
really
awesome,
breaking
it
down
and
asking
this
broader
question
right
and
the
second
sidebar
is
that
michael
lee
and
pedro
they
did
the
my
the
follow-up
on
my
efforts
and
settings
last
year
or
this
year.
I
don't
know
anymore,
that
was
last
year
and
catherine
did
that
research.
A
So
if
you're
looking
for
more
information
about
what
is
the
criteria,
why
or
how
we
move
things
to
the
group
settings
or
the
project
settings?
Look
at
these
insights
and
reach
out
to
either
michael
pedro
for
more
information.
I
think
they
can
also
help
you
in
that
sense.
I'll
give
you
some
guidelines
right
about
behind
the
rationale
for
moving
things
into
settings.
E
Okay,
thank
you.
For
the
sake
of
time,
the
other
stuff
is
just
updates,
so
I'm
gonna
I'll
skip
through
that.
A
We
had
a
full
agenda,
so
if
we
didn't
get
to
your
point
or
if
you
want
but
discuss
more,
please
the
cat
is.
Please
continue
the
discussion,
I
think
and
nadia.
I
think
your
point
that
you
added
after
below
the
cut
line.
I
think
it's
a
good
one
for
us
to
follow
up
async,
so
I'll,
discuss
that
one
so
about
an
awesome.