►
From YouTube: Environments Dashboard Redesign #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
So
I
think
from
our
last
meeting
we
just
discussed
all
the
line
items
and
we
kind
of
made
a
decision
that
pion
and
I
need
do
some
more
research
on
the
experience
with
the
environment
dashboard
to
help
inform
our
path
for
on
a
couple
of
things.
So
I've
kicked
off
the
opportunity,
canvass
and
I
posted
a
recording
of
that
in
our
channel,
and
then
we've
already
scheduled
some
of
the
improvements
in
those
epics
for
future
milestones.
A
B
Think
my
action
items
out
of
last
time
was
just
to
update
what
could
be
prioritized
for
next
milestone.
I
think.
Maybe
it
was
also
moved
some
some
issues
to
a
technical,
technical,
epic
I
think
there
were
like
some
some
test
issues
that
didn't
really
that
they
were
for
back-end
and
testing
and
I
think
those
can
be
moved
to
the
technical,
epic
and
also
creating
a
sort
of
technical
evaluation
issue
to
get
a
better
understanding
of
our
environments
and
operations,
dashboard
and
just
the
landscape
and
what
problems
or
how?
B
How
we
can
address
some
problems,
and
those
wouldn't
just
give
me
more
context
to
those
and
I
think
finally
was
figuring
out
if
the
environments
dashboard
was
written
in
view
for
high
on
us,
so
that
we
know
whether
we
can
replace
the
parts
of
the
dashboard
with
already
created
components
from
from
pyjamas.
So
on
that
last
note,
hi
Anna,
yes,
the
environments
dashboard
does
look
like
it's
mostly
written
in
view,
so
I
do
think
that
we
can
utilize
a
lot
of
pajamas.
A
Did
move
those
two
issues
already
so
I
moved
them
right
when
we
called
them
out
in
our
last
meeting?
Okay,
perfect:
that's
a
good
update,
I
added,
an
item
to
our
agenda
today.
The
first
one
is
a
heat
map
issue,
so
this
is
like
a
quick
and
dirty
way
to
solve
one
of
our
biggest
pain
points
for
our
customers,
which
is
like
how
can
I
see
for
a
quick
snapshot?
Where
are
the
environments
at
in
the
in
their
lifecycle
like
from
the
last
pipeline
status?
Are
they
available
past,
canceled
or
blocked
and
I?
B
A
C
C
A
Sure,
a
high
level,
one
of
our
bigger
pain
points
from
our
customers,
are
being
able
to
create
and
organize
releases
across
multiple
projects.
So
we
have
a
released
from
a
project
that
contributes
to
a
production
environment.
They
an
end-user
would
view
as
let's
say
it's
a
an
e-commerce
website
and
I
want
to
purchase
something
as
an
end-user,
and
this
site
actually
has
four
or
five
micro-services
populating
it,
as
well
as
an
integration,
see
something
like
stripe
or
PayPal,
and
those
in
get
lab
have
four
different
projects
that
feed
into
that
one.
A
Customer
experience
well
as
a
release
manager,
all
I
really
care
about
is
the
continuity
of
experience
for
the
end-user
purchasing
shoes
on
my
website
and
today,
it's
very
hard
to
see
one
that
target
production
environment,
but
also
all
the
activities
that
are
going
to
go
into
the
end
customer
experience
when
I'm
corralling
a
bunch
of
micro
services
across
multiple
projects.
So
what
we're
trying
to
accomplish,
with
both
sharing
environments
and
creating
a
group
release,
is
aggregating.
A
A
C
C
C
Associating
the
existing
releases
that
we
have
now
at
the
project
level
in
a
group
of
you,
so
the
first
flow
would
be
the
user,
creates
a
new
group
release
or
a
new
bucket
with
these
existing
items.
We're
not
gonna
really
dive
into
all
these
details,
but
essentially
my
English
proposal
is
that
we
add
to
the
group
level
of
releases
page
in
there.
You're
gonna
see
all
these
buckets
and
we
added
how
you
add
this.
C
C
So
the
first
prototype
and
then
the
questions
I
want
to
from
you-
is
that
for
some
feasibility
and
also,
if
there's
anything
that
can
be
improved
in
this
role,
the
first
one
is
creating
a
new
group
release
or
assertion.
So
this
prototype
actually
shows
how
it
would
look
like
if
we
had
everything
at
the
group
level.
So
let's
say
you
give
a
name
to
this
item.
You
select
what
you
want
to
create
from
so
you
select
which
projects
so
let's
say
that
you're
doing
it
from
pajamas
and
from
gitlab
UI.
C
B
C
The
user
stood
potentially
at
the
same
ways
that
they
do
now
the
release
page
or
maybe
selecting
from
a
list
that
logs
from
the
target,
let's
say
so
imagine
you
have
a
blog
post
for
pajamas,
relieves
9.1
and
then
the
assets
are
going
to
load
here,
so
you
can
select
which
ones
you
want
to
your
milestone.
So
when
we
get
there,
you'll
be
able
to
select
which
look
milestone.
This
grouper
leaves
will
belong
to
you
and
then
some
sort
of
release,
notes
or
a
description
to
it.
C
B
C
A
C
A
Weird
because
when
you
look
at
a
group
release,
it's
not
really
a
release
at
all,
because
there's
no
repository
behind
it.
It's
just
an
aggregation
of
the
release
tags
from
again
as
a
release,
manager,
I
have
a
sea
commerce
website.
I
have
four
micro
services
that
are
populating
it.
That
is
not
the
codebase.
Isn't
with
that
release.
It's
just
all
the
adjacencies,
nothing
to
it
right.
B
You
know
so
I
think
I
think
now
like
when
you,
when
you're,
creating
a
release
like
its
associated
with
a
release
tag
when
you
create,
like
a
release
asset
you
have
to
with
our
API
as
it
currently
stands,
that
you
have
to
use
the
project
ID
and
a
release
tag
from
that
project.
So
this
is
more
creating
like
a
layer
of
interaction.
That's
poor
that
the
project
manager
and
better
like
enable
what
they
have
to
do
with
what
their
work,
but
doesn't
necessarily
tie
in
right
now,
with
our
like.
A
And
if
we
think
about
like
get
lab
and
how
we
work,
we
have,
we
could
leverage
this
relationship
pretty
nicely
because
we'd
like
a
runner,
the
pajama
is
like
we've
only
sub
projects
that
being
able
to
group
them
into
like
a
a
persistent
object.
That
shows
that
this
is
the
big
it
lab.
Org
release
we'd
be
really
meaningful.
Mm-Hmm.
B
Do
just
kind
of
processing
processing
in
real
time
right
now,
but
I
think
that
this
makes
a
lot
of
sense.
I
think
the
only
thing
that
I'm
wondering
is:
do
we
want.
B
Do
we
want
any
project
level
create
like
editing
or
creation
on
this
form
at
all,
like
do
what
we
want
project
milestones,
I
just,
don't
see
how
it
would
fit.
I
think
I'm,
just
thinking
and
processing
it
at
the
same
time,
but
I
think
this
looks.
This
looks
good
to
me.
This
makes
sense
for
creating
these
group
level.
Artifacts.
B
C
And
I
want
to
associate
this
say
here
to
a
higher
level,
am
I
able
to
create
a
group
release
from
the
project
view.
So
here
comes
a
bit
confusing
and
I
think
the
feeling
is
that
it
will
be
a
nice
and
easy
to
be
able
here,
for
example,
just
show
items.
So
here
is
a
it.
So,
let's
create
from,
we
could
potentially
say,
only
show
projects
that
have
releases
or
only
show
you
know
the
good
master.
B
B
Yeah
I
can
see
how
like,
when,
how
we're
sort
of
thinking
of
it
bi-directionally
like
do.
We
want
to
be
able
to
manipulate
project
releases
from
here
and
what,
with
a
project
release
form,
do
we
want
to
be
able
to
add
things
to
group
releases,
but
I
think
that
from
what
this
looks
like
right
now,
this
looks
totally
fine,
for
this
looks
great
for
creating
group
releases
with
group
milestones
associated
with
them.
A
B
C
Component
here,
actually,
that's
where
things
got
a
little
bit
complicated,
because
they
can
actually
extended
the
drop
down
component
to
have
like
two
sub
headers
when
you
are
creating
it's
in
the
release
in
this
form.
But
then
again
when
we
have
with
this-
and
you
have
I,
don't
know
like
what
it
lab
has.
C
Hundreds
of
project
milestones,
thousand
project
milestones
and
hundreds
of
group
milestones,
I
think
the
experience
becomes
a
little
bit
flaking
and
the
first
option
I
thought
that,
instead
of
showing
here,
you
know
some
headers
inside
the
drop-down
that
we
can
play
around
with
it.
Maybe
tab
navigation
where
we
select
one
thing,
one
of
the
other
options,
but
I
think
you
need
to
validate
this
because
it's
a
complete
new,
a
pattern
in
forum
selection,
wicked
love,
yeah,.
B
B
Is
it
guiding
them
to
pick
only
a
project
milestone
or
a
group
milestone
or
to
be
able
to
pick
both
at
the
same
time
and
then
also
yeah,
when,
when
we
end
up
with
multiple,
when
we
end
up
with
get
lab-scale
number
of
milestones,
how
do
we
handle
that
as
well?
But
I?
Definitely
like
the
intent
here.
A
lot
though,
and
and
the
UI
looks
really
nice.
C
Order
then,
when
you
create
a
milestone
where
I
have
to
I,
don't
know
edit
a
milestone,
but
I
don't
think
we
have
form
patterns
for
things
that
work
on
such
a
wire
skill
and
even
with
this
yeah,
we
use
a
table
component.
But
I
do
that's
been
more
complexity.
We
add
to
this
small
UI
interactions.
The
more
trachis
Donuts
is
going
to
become
to
make
them
I,
don't
know
just
easy
to
use,
but
that's
a
future
plan.
But
that's
my
my
gut
feel
me
here
with
selecting
yeah
on
a
project
level,
something
in
a
group.
B
B
Right
I
think
the
idea
is,
like
is
I,
mean
I,
think
when
I
saw
this
UI.
That
was
something
else.
I
was
kind
of
thinking
in
terms
of
I
was
like
in
the
you
know,
user
shoes.
Is
this
asking
me
to
pick
one
or
the
other
or
enabling
me
to
pick
both
in
terms
in
terms
of
project
milestones
or
group
milestones,
or
both
project
and
group
milestones
and.
B
C
If
it's,
if
it's
the
case,
then
we
don't
need
it
that
navigation,
you
can
have
just
two
in
mind
forms
or
you
just
need
a
bypass
one.
You
have
to
select
anything
if
you
don't
want
to
instead
go
to
your
group
milestone
and
then
in
the
future.
Let's
say
about
your
milestone
and
then
you
have
the
option
releases
in
anyone
that
releases
there
I
think.
C
B
C
C
The
overview
of
the
group
releases
page
right
so
you're
playing
around
with
what
this
page
will
look
like.
There's
a
lot
of
information,
but
essentially
once
you
create
this
bucket
at
the
group
level
you
select,
which
projects
project
releases
you
want
to
show
in
a
new
video,
would
be
a
simplified
release
that
page,
so
you
have
an
entirely
wave
to
it,
assets,
possibly
and
then
just
linked
to
the
project
releases.
So
it
does.
If
this
project
releases
are
associated
to
project
milestones,
you're
gonna
see
here
what
we
show
now.
C
C
A
So
if
it's,
if
there,
we
should
inherit
the
status
from
the
sub
projects
kind
of
like
how
milestones
do
it
today
with
issues
for
example,
and
we
don't
have
like
a
released
at
attribute
visible
in
the
UI.
So
this
means
that
it's
either
going
to
be
inherited
by
someone
who
has
curled
the
API
for
the
released
attribute
to
be
set
in
the
future
for
upcoming
or
it's
inherited
by
the
milestone
schedule.
So
I
think
that
that
should
all
be
inherited
from
the
project
relationships,
because
again,
group
releases
are
an
aggregator.
A
A
But
I,
like
the
way
that
you
have
like
upcoming
and
expired
I
think
expired,
might
be
a
challenging
word.
We
also
might
want
to
consider
a
pre-release
tab
so
for
users
who
have
a
release
tagging
draft.
If
we
support
that
in
the
future,
we
may
end
up
creating
a
group
release,
that's
a
pre-release
candidate
for
approvals
and
then
it
goes
through
like
the
approval
chain
and
it
deploys
and
it
becomes
an
active
release.
So
only
think
about
that.
Workflow
to
the.
C
Milestone
expires.
That's
I
like
that,
but
I
wonder
like
when
I
look
at
it
to
me
to
not
clear
what
the
correlation
of
the
milestone
you
know
between
the
milestone
and
the
Declaration
of
the
release,
because
you're
gonna
start
need
to
add
a
milestone
to
this
item.
If
you
don't
want
to
so
we
don't
really
belong
to
any
pockets.
In
that
sense,
yeah.
C
C
A
C
B
B
C
B
C
B
B
We
can
change
that
really
easily
I.
Think
the
idea
behind
hiding
it
when
there's
no
releases
was
just
to
reduce,
reduce
like
the
surface
area
of
elements
on
the
page
when
there's
nothing
to
link
off
to,
because
if
there's
your
releases
and
someone
clicks
on
that,
you
know,
there's
there's
no
real
information
that
that
they
would
be
getting,
but
I
can
see
the
reason
behind
always
showing
that
to
make
it
more
prominent.
So
that
can
be
that
can
be
change.
C
This
looks
really
pretty
much
like
the
old
it
hubs.
Are
you
lie
and
I
wonder
if
Jackie
also,
once
we
start,
you
know
adding
this
information
the
river
level,
if
you
want
to
add
something
here,
at
least
an
activity
releases,
you
know,
so
we
have
a
way
to
really
show
at
the
group
level.
Well,
the
versions
liberties
is
here.
It
is
boss.
A
A
Yes,
I
think
that,
as
we
support
this
at
the
group
level,
we'll
want
to
keep
it
consistent
with
the
experience
that
people
have
like
in
their
repository.
So
when
you
click
onto
the
groups,
click
into
the
projects
you
have
like
all
those
little
buttons
releases
is
in
that
button.
So
we'll
want
to
do
that
too.
You
want
me
to
create
an
issue
for
that.
A
That's
a
really
good
question,
because
releases
in
general
are
not
as
discoverable
as
they
could
be.
People
do
feel
like
they
have
to
go
into
the
project,
and
then
it's
not
even
in
the
repository
like
it
was
like
like
it
was
in
the
github
experience,
so
I
think
yeah
I
might
might
make
more
sense
to
either
follow
in
line
with
the
configure
team
is
adding
a
side
panel
option
for
at
the
group
level
called
operations.
C
A
A
A
So
now
we
can
transition
to
bi-weekly
I'm
open
to
still
meeting
weekly,
but
I
think
the
things
to
do
would
be
Jake
review
that
heat
map
issue
and
then
look
more
at
these
prototypes
and
give
feedback
back
to
that
support
releases
at
the
group
level
issue
I
did
bump
that
out
to
13.4
because
I
think
I
don't
know
if
we'll
having
a
runway,
deliver
and
13.3.
So
I've
done
that
for
actively.
B
Yeah
I
can
definitely
address
these
issues.
They
sink
I
think
that
I
mean
I,
don't
have
any
immediate
necessity
to
to
keep
discussing
so
I
think
that
moving
to
a
bi-weekly
schedule
works
well
for
me,
but
if
anyone
you
know,
if
it's,
if
it's
more
necessary
to
keep
it
weekly
for
anyone
else,
then
I'm
totally
fine
with
that
as
well.