►
From YouTube: Solution Validation Variables table layout changes
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
Hey
all
I
am
ritika
the
senior
product
designer
for
pipeline
security,
team
and
I
am
back
with
an
update
on
how
we
did
in
the
solution,
validation,
research
that
we
recently
ran
for
this
new
layout.
A
We
had
created
consolidating
the
two
tables
on
the
variables
for
variables
on
the
project
setting
Page
by
two
tables,
I
mean
we
currently
show
like
both
a
table
which
kind
of
lists
the
variables
which
are
created
at
project
level
and
right
below
that
there
is
another
table
that
shows
the
ones
which
are
inherited,
and
these
can
be
inherited
from
any
of
the
parent
levels.
A
And
the
reason
that
we
felt
the
need
to
like
pursue
this
was
when
there's
a
division
between
like
inherited
and
project
variables.
So
it's
very
difficult
to
understand
the
relationship,
the
hierarchy
and
like
which
are
the
ones
which
are
currently
most
relevant
for
this
particular
project
which
the
users
are
on
so.
But
there
were
still
like
a
lot
of
blind
spots
that
I
wanted
to
cover
before
we
like
made
a
decision
on
developing
that
any
further
and
I
think
it
was
a
really
great
step
to
go
with
this
research.
A
So
we
spoke
with
nine
participants
and
it
was
a
really
great
mix
of
both
small
and
large
organizations,
because
what
we
discovered
was
their
working
styles
with
variables,
specifically
it's
very
different
and
like
very
contrasting
contradicting.
But
there
are
still
like
a
few
things
that
both
of
these
subsets
agreed
on
and
like
talking
about
some
improvements.
A
That's
going
to
benefit
both
kinds
of
users,
yeah
and
jumping
into
the
insights
that
we
got
from
this
research
I
would
start
off
with
the
actionable
ones
and
then
I'll
slowly
move
to
the
learnings
that
we
had
because
there's
a
quite
a
lot
of
those.
A
So
the
first
one
says
allow
enforcing
group
variables
at
project
levels
and
why
this
is
a
requirement
is
because
in
large
organizations,
or
sometimes
even
in
small
ones,
some
variables
which
are
more
critical
for
let's
say,
for
example,
the
kubernetes
credentials
for
the
Clusters.
They
are
set
at
group
level
and,
of
course,
like
there's.
A
lot
of
reason
behind
that.
A
That
could
be
for
compliance
for
security
to
make
sure
that
nothing
breaks,
especially
for
the
deployments,
but
there's
no
way
for
them
to
enforce
this
on
the
levels
below
that
like
for
subgroups
or
projects,
and
they
can
easily
be
overridden.
A
There
are
scans
in
place.
Yes
for
detecting
those,
so
there's
a
very
manual
process,
that's
being
adopted
for
by
all
the
organizations
today
and
there's
no
automated
method
of
keeping
a
check
on
this.
So
I
think
it
would
make
a
really
helpful
feature
if
we
work
on
this
other
one
is
add
an
indicator
if
a
variable
is
being
used
by
your
project
and
like
even
in
the
new
design
that
we
had
there's
a
list,
we
have
alphabetized
it.
A
We
try
to
be
like
we
try
to
be
as
make
it
as
usable
as
we
could,
but
still
there's,
no
like
very
clear
indicator
of
what
are
the
variables
which
are
currently
being
used.
So
it's
all
right
if
it
exists
at
groups,
are
group
level,
but
which
is
the
one
which
my
project
is
using
right
now,
so
they
want
those
ones
to
be
more
prominent
in
the
table.
A
So
it
doesn't
take
a
lot
of
mental
processing
to
understand
that
which
are
the
like
most
critical
ones
here
and
there's
a
lack
of
sorry.
I'll
first
go
to
the
actionable
ones,
so
next
one
says
improve
the
representation
of
groups
and
charging
projects
on
the
wearable
list
View
in
this
design.
What
we
experimented
with
was
like
providing
tooltips,
but
it
seems
like
this.
This
is
the
kind
of
information
that
users
would
appreciate
to
be
on.
A
The
very
first
level
because,
like
this
is
this
list
can
go
really
long
on
tune?
Tooltip
can
really
hurt
the
scannibility
of
this
list.
A
Another
one
is
encourage
users
to
select
relevant
in
environment
while
adding
a
variable
so
especially
for
the
groups
that
sort
of
are
responsible
for
managing
variables.
It
becomes
very
like
tiresome
to
make
sure
that
there
are
no
variables
lingering
around
in
projects
and
groups
which
are
not
usable,
which
were
just
probably
created
for
some
testing
purpose
and
knowing
which
ones.
Those
are
it's.
A
Currently,
it's
really
difficult
and
it
requires
a
lot
of
human
interaction
like
they
have
to
speak
with
the
users,
because
there's
no
way
they
can
get
to
see
like
if
this
is
still
being
used
somewhere
and
how
critical
that
use
cases.
So
there
was
a
suggestion.
There
was
a
there
were
a
few
suggestions
that
when
we
are
allowing
users
to
add
a
variable,
if,
through
certain
queues
on
the
UI,
we
could
urge
them
to
also
select
the
relevant
environment
and
not
just
rely
on
the
key
name
for
identification.
A
One
thing
that
we
have
already
open
in
relation
to
this
is
the
issue
for
adding
description.
That
would
definitely
be
very
helpful.
A
So
we'll
see
like
how
much
of
how
much
addition
we
need
to
make
to
that
existing
proposal
now
coming
to
I
think
that
was
it.
That
was
there
were
four
actionable
ones
and
then
now
coming
to
learnings.
So
the
first
one,
the
first
learning
that
I
had
from
this
research
was,
is
a
decent
amount
of
lack
of
visibility
into
history
and
usage,
and
it's
making
managing
variables
really
hard
for
the
responsible
roles
responsible
teams.
A
There
is
no
audit
Trail,
like
this
hardly
much
information
about
who
edited
a
variable
at
what
point
in
like
I
also
mentioned
before.
There's
no
information
about
like
when
this
was
last
used,
there's
a
place
which
is
not
related
to
cicd,
where
some
information
is
available
but
like
coming
to
the
variables
page,
there's
hardly
any
information
that
can
be
dug
out
regarding
the
usage
and
history
of
a
variable.
A
The
next
one
is
users
need
to
know
which
variables
are
recently
used
to
make
confident.
Decisions
is
something
that
I've
been
teaching
upon
in
the
other
insights
as
well.
So
I
won't
spend
a
lot
of
time
on
this
one,
but
yeah
like
there's,
no
clear
indication.
If
this
was
recently
used-
or
this
has
just
been
like
existing
since
a
long
time-
and
that's
it
there's
no,
it's
it's
not
required
anymore.
A
The
unusability
of
variable
features
are
not
very
well
aligned
with
the
rest
of
the
product
and
they're,
not
super
intuitive.
There
are
certain,
like
today,
I
learned
moments
that
we
Jocelyn
and
I
had
during
the
interviews
and
I
thought.
I
would
just
make
a
list
of
those
so
that
we
have
those
in
mind
and
even
like,
create
small
issues
to
fix
it.
So,
first
of
all,
there's
no
confirmation
before
deletion
of
a
variable.
A
It
just
goes
away,
then
a
wild
card
that
we
that
uses
end
up
creating
from
the
drop
down
while
adding
a
variable.
Apparently
it
lingers
forever
like
it
doesn't
go
away.
I
don't
have
like
a
lot
of
information
on
that,
but
this
was
a
feedback
from
one
of
the
participants.
A
Then
the
variables
are
something
that
are
used
in
every
task,
so
I
mean
most
of
the
users
without
even
like
asking
being
asked
a
direct
question
about
the
navigation
part,
they
pointed
out
that,
first
of
all,
why
is
it
so
hidden
so
like?
We
have
to
be
sure
that
we
think
of
a
better
place
to
locate
these
and
yeah.
We
have
to
make
progress
on
that
front
as
well,
and
there
are
variables
defined
on
the
CI
on
the
UI
and
on
the
CI
file.
A
A
We
do
have
like
a
new
page
in
the
documentation
which
is
about
usage,
so
probably
we
can
just
expand
there.
Then
by
default
variables
are
expanded
and
it
should
be
per
use
case.
So
apparently,
we
receive
feedback
that
it's
not
always
I
agree
to
have
variables
being
expanded
by
default
like
that
checkbox
being
checked
by
default.
It
should
rather
be
a
decision
to
do
that
because
it
could
have
certain
security
concerns
attached
to
it.
A
Then
there's
no
pagination,
even
when
the
list
runs
like
really
long
and
I
learned
that
the
limit
that
we
have
a
variables
has
200
and
for
large
organizations
they
actually
reach
like
pretty
close
to
the
Limit
as
what
we
saw
as
an
example
and
like
it's
just
a
really
long
list
on
that
page
and
that
pushes
all
the
other
setting
options
like
so
much
below
the
holding
it.
It's
not
a
great
experience.
A
Next
one
is
variables,
are
higher
in
criticality
that
are
higher
in
criticality
are
stored
at
group
level.
It's
just
like
something
that
we
ask
questions
around
like
what
do
you
store
at?
What
are
the
examples
of
variables
that
you
store
at
product
level
versus
group
level,
so
everything
that's
a
little
more
critical
and
is
kind
of
enforced
organization,
writers
of
course
stored
at
the
group
level?
A
Then
users
have
scans
in
place
to
detect
any
value,
Bypass
or
variable
overriding
at
group
level.
Teams
have
their
own
like
workflows
in
place
that
are
on
job
definitions
in
place,
to
kind
of
look
for
any
bypassing
or
variable
value
that
shouldn't
happen
and
when
they
do
that,
they
kind
of
then
get
in
touch
with
the
person
responsible
to
make
any
corrections,
and
it
would
just
be
very
helpful
to
automate
this
entire
process.
A
Then
I
still
like
think
that
we
need
more
information
around
this,
but
users
require
more
regular
control
over
access
to
variables,
so
some
feedback
that
we
got
was
that
why
just
get
lab
limit
the
association
of
variable
to
environments,
because
sometimes
it
can
be
beyond
that?
Sometimes
it
just
can
be
like
like
twofold,
as
in
there's
a
this
variables
to
be
used
for
a
smoke
test
which
is
for
this
particular
environment.
A
So
we
do
not
like
provide
control
at
a
more
granular
level,
but
rather
we
just
like
make
associations
strictly
with
environments
and
even
with
with
environments.
What
we
are
doing
currently
is:
we
don't
allow
customization
of
like
creating
custom
access,
so
let's
say
for
production
if
somebody
they,
if,
if
an
organization
wants
only
a
bunch
of
users
to
have
access
to
edit
a
variable,
that's
for
the
production
environment
and
so
on
is
it.
This
was
I.
A
Think
I
wanted
to
keep
it
five
minutes,
but
that
was
definitely
not
possible,
but
yeah,
a
lot
of
learnings
and
a
lot
of
work
that
we
need
to
do.
The
next
step
for
me
is
to
create
issues
for
each
one
of
these,
and
that's
it.
Thank
you.