►
From YouTube: Environments Dash Redesign Sync #2
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
C
So
Jake
I
think
in
our
last
meeting.
We
discussed
this
next
item
for
you
to
kind
of
go
through
some
of
the
issues
and
give
us
a
perspective
on
how
you
think
we
should
approach
some
of
the
stuff
from
a
technical
feel
like
it
makes
more
sense
to
coning
fix
things.
You're
teaching
lord
I
do
like
blow
it
all
up
and
redesign.
It
thing.
A
So
less
it
was
less
of
a
consideration
of
blowing
everything
away
and
just
kind
of
thinking
of
what
would
be
needed
for
each
one
and
then
maybe
after
I
kind
of
speak
to
all
of
them.
It
will
be
clear
whether
or
not
we
should
go
like
incrementally
into
each
issue
and
address
things
or
just
do
a
whole
redesign.
A
C
A
Yeah
no
problem
yeah
so
that
first
issue
in
the
epic
environments
dashboard
indicate
to
users
that
are
moving
adding
project
from
one
dashboard
view
affects
all
others.
So
I
I
really
like
the
proposal.
That's
already
there
just
giving
some
sort
of
messaging
indication
either
in
a
modal
or
in
some
UI
text
somewhere.
A
Long-Term
I
could
I
think
my
main
concern.
There
is:
will
that
add
hesitation
to
the
user
to
make
any
changes
like
if
we,
if
they
go
to
add
or
remove
a
project,
and
then
some
messaging
appears
that
says
that
this
will
affect
the
operations
dashboard.
Will
that
cause
some
some
mental
friction
and
a
moment
of
concern
hesitation,
and
it
will
probably
be
better
to
do
that
messaging
any
like
now
anyways,
because
that's
what
that's?
What
happens
when
you
add
a
remove
project,
so
it
will
at
least
add
some
clarity
there.
A
But
I
was
wondering
if
long-term,
should
we
really
decouple
these
dashboards
so
that
projects
aren't
synchronized
and
then
get
the
users
the
option
to
synchronize
the
dashboard,
and
then
I
found
this
other
issue,
which
was
to
investigate
the
jobs
to
be
done.
Differences
between
operations,
environments,
dashboard
and
I
was
almost
wondering
after
reading
that,
if
there
should
be
a
consideration
to
just
combine
the
two
at
some
point,
if
that
would
even
make
sense,
but
I
don't
really
have
the
any
research
to
back
up
whether
or
not
that
would
be
useful
or
not
for
users.
A
So
that
was
just
a
light
thought
really
so.
Moving
on
to
the
improved
add
project,
modal
I
think
this
one
definitely
wouldn't
require
us
to
blow
away
the
entire
dashboard
and
do
a
redesign
I
think
we
could
just
pre
populate
this
model
with
with
projects
from
your
group.
The
only
concern
I
really
had
about
this
from
a
technical
perspective
is
our
API
has
a
maximum
limit
of
100
projects
per
API
request,
so
we
would
have
to
do
some
sort
of
pagination
and
if
you
have
a
large
amount
of
projects,
this
could
possibly
cause
performance
issues.
A
So
that
was
just
something
to
keep
in
mind,
but
I
definitely
think
that
the
possibility
of
people
pre-populating
this
modal
to
add
projects
can
definitely
be
done
without
needing
to
do
a
huge
redesign,
and-
let
me
know,
if
anything,
doesn't
make
sense
as
I'm
going
through
these
so
now
I'm.
Looking
at
the
third
issue
in
the
epic
environments,
dashboard
error
message
is
incomplete,
feature
possibly
broken
this.
How.
A
Yeah,
the
feature
is
definitely
broken
because
we're
not
showing
the
the
invalid
project
name
at
all.
This
is
strictly
a
technical
issue.
I
looked
through
the
JavaScript
file
that
this
message
is
being
produced
from
and
somewhere
along
the
line.
The
name
of
the
project
just
goes
blank,
so
it
just
requires
some
technical
investigation,
the
front
of
a
probably
it
could
actually
be
dropped.
Looking
at
it's
a
I
think
only
one
NMR
would
be
needed
to
address
this.
A
We
could
probably
actually
drop
the
front-end
wait
till
one
I'll
do
that
right
now,
actually
and
yeah
this
this
I
mean
from
a
technical
perspective
of
fixing.
This
error
definitely
not
requiring
a
redesign,
definitely
just
a
technical
thing.
If
we
find
that
this
messaging
should
be
improved
at
all
other
than
just
fixing.
This
bug,
then
I
think
like
an
issue
can
be
open
to
address
the
UI
text,
but
other
than
that
I.
Don't
think
that
this
warrants
redesign.
A
A
So
it's
showing
the
number
of
environments
in
a
particular
group.
So
we
have
like
there's
a
group
called
sandbox
and
you
have
sandbox
one
sandbox
to
use
in
box
with
name
just
keep
going
to
show
that
number
of
environments
and
particular
group
the
card
will
show
the
latest
pipeline
of
the
environment
in
that
group
and
the
review
apps
will
link
to
the
latest
environment
that
had
a
successful
pipeline.
I.
A
B
The
initial
proposals-
one
thing
I-
was
thinking
about
this-
this
issue
Jake,
is
that
what
we
looked
at
in
the
unit
prototypes
is
actually
what
is
implemented
so
I'm,
not
sure
exactly
how
to
translate
that,
but
in
this
case,
I
feel
like
we
need
I
need
to
look
into
the
designers
together
with
you
and
see.
This
proposal
is
really
the
best
approach,
especially.
A
B
A
Yeah
I
mean
based
on
the
current
mock-up
I.
Don't
think
this
would
really
affect
imagination
because
we're
not
showing
multiple
projects
or
we're
not
showing
like
under
in
the
mock-up.
It
shows
that
development
has
like
346
environments,
we're
not
really
loading
346
environments,
in
this
view
we're
just
getting
the
number
of
environments
under
development
yeah.
B
A
Okay,
so
I'm
gonna
move
over
to
investigate
job
to
be
done.
Differences
between
operations
and
environments,
dashboard
and
I-
really
just
this
is
like
this
is
like
a
research
issue,
and
so
that's
like
I
tied
this
back
to
that
first
issue,
where
I
I've
made
the
thought
about
maybe
combining
operations,
environments,
dashboard,
I,
think
the
main
like
the
position
of
the
problem
here
basically,
is
that
there
needs
to
be
more
specific
difference
between
the
operations,
dashboarding
environments,
dashboard
and
what
persona
of
a
user
would
use
one
over
the
other
and.
A
Yeah
I
think
my
thought
here
was:
you
know,
collecting
some
some
research
based
on
the
issue
described
and
thinking,
maybe
in
terms
like
a
long-term
redesign,
how
we
can
either
make
the
differences
more
clear
or
combine
the
two
into
one
dashboard.
Maybe
it
doesn't
need
to
be
two
different
dashboards,
but
definitely
thing
more.
Research
is
needed
for
this.
One
I
didn't
write
any
comments
in
the
issue,
because
I
just
I
had
I
had
a
vague
notion
of
thoughts
for
this
really.
C
A
B
C
A
A
C
A
A
A
This
was
a
older
issue
and
I'm
wondering
if
we
can
actually
close
this
or
if
we
have
to
reposition
the
problem,
because
the
environments
dashboard
requires
the
silver
and
premium
plan
as
the
operations
dashboard
and
they're,
both
free
for
use
for
public
projects
on
get
lab
comm,
but
private
projects
need
to
belong
to
a
silver
and
premium
plan.
So
I
don't
know
if
this
issue,
it's
just
stale
and
just
needs
to
be
closed.
A
B
C
A
Sounds
good
yeah,
the
the
only
reason
why
I've
kind
of
like
hesitant
to
to
mention
closing
it
right
away
was
because
I'm
not
exactly
sure
what
happens
if
someone's
license
expires,
while
here
like,
if
someone
has
a
silver
or
premium
license
and
expires,
does
the
environments
dashboard
just
go
away?
I
think
that
can
be
that's.
C
A
Okay,
so
yeah
I'll
just
tag
you
for
closing
this
issue,
then
I
think
it's
just
just
a
stale
issue
and
then
so
the
next
two
are
the
next
two
issues
are
add:
query
record:
first,
two
specs
for
environments,
folder
and
dashboard
environments
serial
to
serializer
and
write
feature
spec
for
environments
dashboard.
These
are
to
beckon
issues
for
writing
tests
about
the
environments,
so
they
don't
really
require
any
designing
discussion
at
all.
These
are
purely
purely
back-end
test,
writing
and
then
the
last
we.
A
A
C
Okay,
perfect,
so
I
moved
those
issues
already
and
I
think
we're
good
on
that
front.
Thank
you
for
going
through.
All
of
that
I
appreciate
it.
It
was
good
context
to
hear
like
it
seems
right
now.
We
would
benefit
from
fixing
some
of
the
bugs,
as
is,
and
not
really
conducting
a
redesign
in
context
of,
like
other
features,
that
we
were
shipping
right,
because
a
redesign
would
be
a
huge
like
global
effort
for
our
team
right.
So
that's
helpful.
Thank
you
for
doing
that.
C
As
far
as
like
a
goal
review,
so
we
had
several
customer
calls
in
regard
to
the
releases
page
and
we
had
a
survey,
go
out
about
environments
and
how
people
are
using
environments
and
the
biggest
feedback
that
we
received
is
the
environments.
Dashboard
is
unusable
for
the
target
customer
and
it's
because
they
can't
see
and
manage
a
scale.
So
most
of
the
customers
that
are
premium
customers
are
not
like
a
one
project
shop.
Most
of
them
have
hundreds
of
thousands
of
projects
with
multiple
production
environments
per
project.
C
And
today
they
cannot
like
they're,
actually
there's
no
way
to
use
get
lab.
They
have
to
pull
the
deployment
data
API
and
load
it
into
grow,
Hana
to
view
data
aggregated
about
what
their
deployments
are
doing.
So
that's
how
customers
are
currently
using,
get
lab
for
deployments
that
scale
and
monitoring
it
or
evaluating
it,
and
they
check
their
gharana
dashboards
that
are
pulling
they
the
deployments
API
and
that's
it.
C
So
what
I'm
trying
to
help
support
with
this
effort
is
managing
environments
at
scale
and
understanding
like
your
health
and
status
of
your
deployments,
because
deployments
are
like
a
weird
object
and
get
lab
in
that
it's
an
environment
with
a
positive
pipeline
status
or
past
pipeline
status,
and
that
has
a
couple
of
other
like
calculations
that
determine
that
it
is
deployed
right.
So
I
I
want
to
find
like
cheap
ways
for
us
to
fix
the
solution
as
it
works
today
for
our
SMB
customers
or
our
individual
developers
that
are
using
get
lab.
C
A
So
I
think
that
the
notion
that
there's
an
issue
with
with
using
the
environments
dashboard
when
you're
a
company
of
massive
scale
is
that
I
really
kind
of
feel
like
it
has
to
be
broken
down
into
into
these
smaller
segmented
problems.
So
like
what
are,
what
are
the
exact
like
pain,
points
and
bottlenecks
in
the
environments,
dashboard
other
than
is
just
a
lot
of
projects?
Is
it
like
performance
loading,
everything?
A
Is
it
seeing
what
what
is
failing
is
again
is
being
able
to
quickly
index
and
find
the
project
that
you're
looking
for,
because
there's
so
many
projects.
How
do?
How
are
we
enabling
one
to
find
exactly
what
they
were?
Looking
for
so
I
think
segmenting.
The
actual
issue
of
a
large-scale
organizations,
problems
into
these
smaller
actionable
items
might
be
helpful
and
then.
A
And
then
I
kind
of
feel
like
it's,
you
want
to
be
more
about
removing,
what's
not
needed
from
them.
Is
there
anything
like
in
the
environments
dashboard,
that's
just
that's
just
kind
of
in
their
way,
that's
corrupt!
That
can
be
removed
and
that's
like
a
really
big
notion,
but
I
think
understanding
that
could
be
helpful.
C
We
know
for
sure
that
people
in
the
environments,
dashboard
aren't
always
clicking
the
view
app
view.
They
don't
really
know
what
that
means.
They
don't
know
why
that's
relevant,
but
we
do
know
that
that
is
an
indicator
of
a
deployment
when
you
see
a
view
app
so
like
that's
just
showing
that
it's
a
it's
a
live
environment
that
you
can
see
your
target
right.
So
if
there's
ways
to
and
by
taking
segmenting
the
problem,
are
you
looking?
C
So
because
we
have
some
of
those
today,
but
the
biggest
one
that
like
when
people
want
it,
the
environment
dashboard,
they
were
looking
for
to
answer
the
question.
How
are
my
deployments
going
right
now
like
that?
That
was
the
question
they
wanted
to
answer
and
then,
after
we
made
this
available,
the
question
has
changed
from
how
are
my
deployments
doing?
What
deployments
are
stuck
locked,
not
working
as
intended?
So
it's
like
how
can
I
be
actionable
after
now,
seeing
a
partial
representation
of
my
deployments.
A
Do
we,
I
I'm
not
really
100%
sure
we
do
this?
Do
we
do
anything
to
immediately
display
a
deployment
that
has
failed
when
you
go
to
Neiman's
dashboard
and
give
you
of
a
hundred
thousand
projects
and
project?
Eighty
thousand
fails.
Does
that
likely
show
up
and
some
immediate
view
I
feel
like
that
would
be
hopeful
so.
C
I
think
this
is
where,
like
the
post
deployment
monitoring
that
Ori
is
doing,
this
is
our
opportunity,
like
interface,
without
a
learning
mechanism,
and
maybe
it's
really
a
section
in
the
environments
dashboard
that
says
currently
failed
deployments,
and
maybe
it's
a
list
or
like
trying
to
think
of
a
cheap
MVC.
You
know
how
do
we
display
that
data
so
that
if
someone
is
running
hundreds
of
deployments,
how
can
they
see
like?
Is
it
a
counter?
You
only
fifty
failed
deployments
and
then
they
click
on
it
and
then
they
can
dive
into
where
to
go.
B
Wonder
like
if
people
can,
if
the
users
can
understand
this,
all
these
states
through
the
UI
the
way
it
is
right
now,
because
when,
when
you're
deployed
fail,
when
there's
like
an
alert,
an
error,
the
card
becomes
red
or
green
or
blue
or
whatever,
and
that's
how
we
signified
those
statuses
right
now,
but
would
then
yeah
to
act
on
that
and
knowing
exactly
which
environment
which
deployment
has
in
there
I
think
yeah,
there's
room
for
improvement
right
now
and
that's
we
make
everything
from
the
operations
dashboard.
That's
also
another
issue.
C
Yeah
I
think
fundamentally
I'm
struggling
with
this
commitment
to
just
redesigning
the
environments,
boy
you're,
breaking
it
from
the
operation
dashboard
like
my
guy,
is
saying
that
that's
what
we'll
need
to
do
in
order
to
accomplish
the
just
the
solution
that
our
customers
are
looking
for,
because
today
Ayana
it's
just
like
I,
don't
even
know
how
the
Opera
the
operations
doesn't
have
that
pagination
right.
They
don't
have
to
worry
about
the
limit.
The
limit,
stoppers
dashboard
doesn't
right.
I,
don't
know
how
like
how
are
they
able
to
avoid.
B
C
C
Okay,
so
I
think
from
what
I'm
hearing
Jake,
there's
probably
an
opportunity
on
the
product
side
for
us
to
before
we
undergo
a
significant
amount
of
changes
in
the
in
the
actual
dashboard
itself,
understanding
the
separation
between
the
operations,
das,
friendly
environments,
dashboard,
and
that
will
answer
a
lot
of
questions
like
on
the
on
the
product
side.
Like
are
these
people
as
coupled
as
we
thought
they
were,
and
if
they
aren't,
we
can
then
break
it
and
do
something
different
with
the
environments
dashboard.
C
A
So
I
think
it's
hard
to
speak
to
them.
Definitely
in
terms
of
technical
performance,
I'm
wondering
if,
because
the
environments
dashboard
requires
a
paid
plan,
if
it
would
be
possible
to
introduce
a
API
or
a
way
of
getting
the
data
that
they
need
in
a
more
performant
manner
like
if
so
our
API
smacks.
C
A
C
A
B
C
So
then,
Jake
on
your
front,
do
you
want
to
continue
going
through
the
issues
just
getting
a
grasp
of
the
landscape,
or
do
you
want
to
start
taking
like
a
technical
research
issue
for
this
project?
What
do
you,
what?
How
can
we?
How
can
we
best
enable
this
project
effort
from
the
technical
side?
What
do.
C
A
Definitely
think
that
low
a
low-hanging
fruit
tech
issue
like
that
that
flash
error
could
be
like
just
a
top
quick
priority,
followed
by
doing
like
a
project,
research
type
thing
and
trying
to
get
a
better
understanding
of,
like
you,
said,
the
landscape.
What
what
possible
larger
scale
issues
can
be
existing
in
the
environments
dashboard?
How
coupled
is
it
to
the
to
the
operations
dashboard.
A
Otherwise,
we
we
might
only
like
load
like
20
projects
and
if
it's
really
no
help
for
those
large-scale
customers,
anyways
so
I
think
something
like
that
could
be
maybe
thought
through
a
little
bit
more
and
maybe
put
on
the
backburner,
and
so
we
have
a
better
understanding
of
how
to
solve
it.
So
yeah,
just
to
clarify
I,
think
the
path
that
I
see
is
to
attack
the
low-hanging
fruit
issues
and
then
do
a
research
and
validation
type
thing.
C
Perfect
so
Jake
I'll
look
out
for
your
ping
on
that
flash
issue,
so
I
can
slap
a
release
p1
on
it
or
release
p2
on
it
and
get
that
prioritized
for
the
next
milestone.
And
then,
if
you
don't
mind
opening
that
technical
research
like
I,
don't
not
quite
sure
how
far
you
want
to
reach
into
that,
and
then
we
collaborate
on
what
you
should
be
researching.