►
Description
Chris Balane (Senior Product Manager) and Daniel Fosco (Senior Product Designer) get together to review the epic to Foster environment and deployment adoption, and plan for next steps.
See more:
Epic – https://gitlab.com/groups/gitlab-org/-/epics/6821
Meeting Notes – https://docs.google.com/document/d/1jqHhwoC1BYbe31osVyGraOySsSqZR6gadrZPjcdWjwY/edit#heading=h.768jx874zfxm (internal)
A
So
this
meeting
is
a
brainstorm
for
how
we
can
improve
adoption
of
environments
through
in-app
notifications
in
the
product.
So
we
already
have
an
epic
for
this.
With
a
few
suggestions
that
we'll
go
over
but
yeah,
we
will
try
to
come
up
with
other
ones
in
the
process
as
well
before
we
we,
we
move
down
the
list.
The
first
thing
that
I
actually
want
to
propose.
A
Chris
is
first
to
rephrase
this
a
little
bit,
especially
the
in-app
notifications,
because
I
think
in-app
notifications
are
one
thing
we
can
do
to
increase
adoption
to
foster
adoption,
but
it's
not
the
only
thing
and
there's
a
bunch
of
suggestions
that
they're
not
exactly
notifications,
so
I
will
tentatively
rephrase
it
to
faster
environment.
B
Definitely
I
think
when
we
wrote
this
originally,
we
were
thinking
about
how
we
haven't
been
leveraging
that
that
tactic
specifically,
but
really
the
goal
here,
is
to
increase
adoption
through
the
application
and
getting
users
that
are
using
one
part
of
the
application
to
continue
to
adopt
environments
and
other
release
functionality.
So
perfect.
A
And
I
think
it's
important
to
add
deployment,
even
though
our
customers
can
deploy
using
lab
ci
without
using
environments,
and
they
go
together
very
strongly.
So
I
think
there's
opportunities
for
us
to
foster
environments
themselves
and
then
deployments
themselves,
but
they're
always
talking
to
each
other.
A
So
the
first
thing
that
that
we
had
actually
the
first
issue
that
we
worked
on
in
this
in
this
area.
For
this
epic
was
this
one
in
project
guidance
for
deployments
in
the
web?
Ide.
That's
not
the
one
that's
open
here,
and
that
was
done.
That
was
essentially
it's
a
simple
execution.
A
It's
basically
this,
and
this
is
an
in-app
notification.
I
think
that's
that's
where
the
name
original
name
of
the
epic
came
from.
So
if
you
have
a
yaml
file
that
doesn't
have
deployments
detected,
we
suggest
that
we
have
that
in
the
product
already
there
is
a
a
secondary
step
to
do
the
same
thing
in
the
single
file.
Editor,
the
one,
the
current
implementations
on
the
web
ide.
So
let's
go
over
some
of
the
suggestions
that
we
have
here.
A
I
think
this
this
first
one
you
you
were
mentioning
right
before
we
started
recording
like
some
some
small
low
hanging
fruit.
We
can.
We
can
adopt
in
this
in
this
epic
and
I
think
these
first
ones
are
really
low
hanging
fruit,
just
listing
the
environments
that
we
have.
We
already
have
the
releases
here
so
for
a
given
project.
We
have
these
this
many
environments
and
if
you
click
it,
you
go
to
the
environments
page.
A
I
guess
this
one
would
show
only
if
you
have
environments,
if
you
don't,
we
would
have
an
empty
state,
perhaps
down
here,
there's
a
good
example
here.
So
here
where
you
can
see
the
you
can
go
straight
to
the
readme,
to
the
change
log
to
the
cicd
configuration
and
then,
if
you
don't
have
integrations
configured,
it
shows
this
dashed
button
as
an
empty
state.
So
we
could
have
configured
environments
as
well.
So
if
you
have
environments
they
show
up
here,
if
you
don't,
then
you
have
an
option
to
configure
them
down
here.
A
A
We
have
this
really
good
suggestion
from
jamie
as
well
that
that
goes
along
with
the
the
issue.
We
have
to
better
connect
releases
and
and
deployments
and
environments,
and
I
think
this
is
a
great
example
where
they
can
help
each
other
right.
Maybe
a
specific
customer
uses
releases
a
lot
to
save
specific
versions
of
their
application
and
specific
assets,
but
then
they
deploy
using
something
else.
A
A
So,
if
you
don't,
maybe
we
have
a
good
empty
state
opportunity
here
linking
to
the
docs,
but
if
you
do,
then
we
can
show
if
a
release
is
deployed
to
which
environment
that's
deployed.
How
long
it's
been
there,
you
know
maybe
status
of
the
pipeline
there's
a
lot
of
opportunities
here.
The
empty
state
would
help
in
issue
adoption,
but
at
the
same
time,
if
I,
if
once
you
adopt,
you,
have
really
good
visibility
here,
that's
one
more
reason
that
you
would
adopt
it
in
the
first
place.
A
So
I
think
that
you
talk
to
each
other
really
well
and
feel
free
to
interrupt
me
at
any
time
chris.
If
another
idea
comes
up
or
if
you
have
any
thoughts
on
these
and
yeah,
here's
a
more
specific
suggestion,
also
from
jamie
right
like
create
or
view
deployment
from
the
release
itself.
A
I'll
be
honest,
I
think
the
way
our
releases
and
our
environments
product
work
is
a
bit
counter-intuitive
in
the
sense
that
they
have
a
lot
of
overlap
with
each
other
because
they
were
created
at
different
different
stages
of
gitlab
existence.
For
with
different
focuses
so
now
we
have
the
opportunity
to
bring
them
closer
together
and
even
though
some
users
will
only
use
releases,
some
users
will
only
use
environments
and
they
can
be
used
for
different
things.
I
think
they're
more
powerful
if
we
bring
them
closer
together.
A
So
jamie's
suggestion
to
create
a
review
deployment
would
take
the
user
to
the
to
the
lab
ci
on
the
on
the
pipeline.
Editor
the
emo
file-
and
I
already
have
a
snippet
with
a
suggestion
on
how
to
how
to
set
that
up.
So
that
would
be
really
good.
A
A
We
currently
don't
have
a
lot
of
those
and
I'm
I'm
unsure
if
this
view
here
this
screenshot
is
a.
Is
it
like
a
view
for
for
how
it
could
look
like
in
the
future?
But
if
you
go
to
new
project,
we
have
these
templates
here
right.
Some
of
them
already
have
deployment
setup
embedded
right,
so
I'm
more
familiar
with
the
static
side.
So
you
know
if
you
have
hugo
or
jack
you.
A
I
know
some
of
these
facilitate
deploying
to
a
certain
target
already
we
have
them
here,
netlify
as
well,
that
helps
you
deploy
into
network,
but
we
don't
have
anything
specifically
tailored
to
deployment
right.
Maybe
you
don't
care
too
much
about
which
framework
framework
you're
using
to
your
project.
You
just
want
to
start
a
project
that
deploys
a
target,
so
we
can
definitely
help
help
users
more
more
closely
with
this,
and
this
would
would
also
be
a
huge
collaboration
with
the
pipeline
authoring
group
that
is
already
working
on
these
interfaces.
A
B
We
could
even
have
yeah
like
a
template
for
the
sort
of
typical
environment
setups
like
a
dev
staging
in
production
and
maybe
have
that
you
can't
put
out
of
the
box.
So
all
one
click,
the
the
users
and
their
teams
have
have
all
these
environments
set
up
and
then
that
combined
with
all
of
the
other
sort
of
like
kind
of
nudges
we
were
talking
about
earlier,
I
think,
would
lead
to
the
more
environment.
Adoption.
A
Yeah
absolutely-
and
the
focus
here
is-
is
in-app
changes
right,
so
it
changes
the
ui,
but
obviously
there's
things
to
documentation
and
and
other
other
assets
other
avenues
we
can
use
to
to
foster
this
adoption,
and
this.
This
idea
of
having
having
better
deployments
templates
in
ci
cd
reminded
me
of
of
your
initiative
to
have
like
better
examples
for
how
how
our
product
is
set
up
right.
So
if
we
either
documentation
or
in
the
gitlab
blog
then
come
up
with
content
that
shows
users
hey.
This
is
how
you
deploy
to
gte.
A
This
is
how
you
deploy
to
ecs.
This
is
how
you
configure
your
environment
set
up
for
all
of
these
use.
Cases
like
you
were
mentioning
it
also.
It
will
help
a
lot,
and
I
think
it
should
be
in
this
epic-
maybe
maybe
not
as
an
initial
focus,
but
then
we
can
break
it
down
later,
perhaps
as
something
that
will
contribute
towards
the
same
goal.
A
I
I
made
a
suggestion
back
then,
here
of
an
empty
state
in
the
environments
page.
It's
I
don't
think
it's
not
necessarily
as
strong
as
adding
an
entry
point
elsewhere,
because
the
user
has
to
go
to
the
environments
page
to
see
the
empty
state,
but
we
can
definitely
have
clear,
clear
use
cases
being
shown.
The
empty
states
that
direct
to
specific
points
in
the
documentation
so
how
to
protect
your
production,
how
to
visualize
your
deploys
with
you
know,
maybe
some
illustrations
that
that
shows
the
user.
A
Oh,
this
is
what
it
would
look
like,
and
this
is
the
value
that
I
would
get
out
of
this,
so
it
it's
definitely
a
good
good
option
as
well.
Yeah.
B
Daniel
actually
on
that
that
do
we
being
relatively
new
here,
I
do
we
do
any
sort
of
like
I
forget.
What
do
we
call
those
in
the
apps
kind
of
like
that?
B
A
Yeah
from
other
people,
so
this
this
is
what
we
have
in
terms
of
like
the
the
plane.
Onboarding
right
like
you,
either
go
to
the
documentation
or
you
go
here
and
it
takes
you
to
the
documentation.
So
it
is
something,
but
it
can
definitely
be
improved.
I
think
the
documentation
for
environments
is
pretty
good
in
explaining
the
concepts
and
and
the
general,
the
general
gist
of
it,
and
how
to
get
started.
But
we
can.
We
can
do
a
better
job
at
helping
the
user
visualize.
A
What
it
looks
like
when,
when
they're
successfully
using
it
right,
so
that
that
goes
over
what
you
mentioned
right,
like
us,
some
kinds
of
step
by
step
onboarding-
and
there
are
initiatives
for
this
across
the
lab-
that
we
can
connect
with
other
groups
that
are
doing
it
but
yeah.
We
also
have
a
slow,
low
hanging
fruit
to
improve
this
one
for
sure,
then,
the
last
suggestion
here
that
you
brought
from
ali
was
detecting
deployed
jobs
in
in
the
cia
and
the
yaml
file
and
nudge
users
to
use
an
environment.
A
B
B
Yeah
and
just
to
jump
from
there
yeah,
I
think
it's
a.
I
agree
as
when
you,
when
you
mentioned
that
one
earlier
this
chat,
I
realized
the
connection
to.
I
think
it's
very
similar,
similar
messaging,
something
like
it
seems
like
you're
deploying
deploy,
safer
or
in
a
better
way,
some
some
sort
of
language
or
messaging
to
encourage
using
environments
here
right
now
it
looks
like
it's
still
just
where
does
the
learn
more?
I
guess
it
goes
to
the
documentation.
I
imagine
or
I
I.
B
Because
I
think,
like
I
wonder
if-
and
this
is
definitely
more
effort
but
having
a
a
way
to
click
and
and
then
have
the
ui
or
the
yaml
file-
add
and
actually
like
for
us
to
create
a
an
actual
environment
from
there
right.
B
A
Yeah,
let's,
let's
remind
me
to
add
an
action
point
at
the
end-
to
reach
out
to
to
nadia
from
pipeline
altering,
because
I
know
if
they
don't
already
have
this
functionality
to
like
paste
the
snippets
they
are
working
on
it.
A
To
some
extent.
I
don't
know
if
it
pastes
the
snippet
or
just
adds
it
to
the
clipboard
and
lets
you
know.
But
it's
it's
something
that
we
can
work
towards
and
I
think
makes
a
lot
of
sense.
B
A
It
would
yes,
so
let
me
see
where
was
my
environment
yeah?
So
if
I
go
here
new
environment
again
very
easily,
something.
A
No,
it's
easy
to
create,
but
at
the
same
time,
if
I'm
on
the
web
id
edit
in
my
ml
file
and
then
I
see
an
option
to
add
an
environment,
I
would
expect
it
to
be
added
from
the
yaml
file.
But
I.
A
We
don't
wanna
that
that
raises
the
question:
do
do
the
environments
that
I
created
from
the
ui?
Are
they
reflected
on
the
ammo.
A
That's
that's
interesting
right
because,
to
a
certain
extent,
it
would
be
kind
of
like
how
do
you
say
out
of
sync
right,
yeah.
B
A
I
expected
the
ammo
to
be
a
source
of
truth
for
for
environment,
but
I
guess
that's
not
necessarily
the
case.
Oh
yeah,
because
the
ml
file
is
a
recipe
that
once
it
runs,
if
you
have
an
environment
listed
there,
it
will
be
created.
A
B
A
If
it's
listed
here,
it
doesn't
mean
it
exists,
it
only
means
it
will
be
created
according
to
these
instructions.
That's
right,
yeah,
right
all
right,
so
that
that
was
the
last.
Let
me
see
if
I
added
you
know
I
just
kind
of
listed
out
in
text
format
them
all
here.
Do
you
have
any
other
suggestion
that
came
up.
B
This
is
a
pretty
good
list
already
in
just
reading
reading.
Through
this
again
yeah,
I
think
maybe
any
of
the
other
suggestions
are
some
of
the
details
and
you
know
details
that
fall
under
one
of
these
items
like
I,
I
just
did
a
you
know
a
couple
weeks
ago
I
made
it
my
own
test
project
and
I
checked
out
code.
I
made
an
update.
B
I
ran
a
pipeline
I
created,
and
I
I
there
was
sort
of
a
kind
of
a
logic
jump
for
me
from
like
from
the
ci
piece
to
doing
anything
related
to
release
or
deployment.
B
So
I
think
that
that
area
is
is,
is
probably
the
best
place
to
focus,
so
I
think
like
educating
like
like,
for
example,
I
didn't
know
I
had
to
create.
I
didn't
know
how
to
I
had
to
create
an
environment.
I
didn't
know
how
to
I
kind
of
have
to
stumble
my
way
through
and
then,
even
after
I
created
an
environment,
I
didn't
really
know
what
to
do
with
it
right.
A
A
No,
not
from
my
side,
I
I
did
think
of
one
more
suggestion
that
that
mapped
to
the
work
that
we
were
doing
with
deployment
approvals
to
to
to
better
show
the
the
approvals
right
in
the
in
the
pipelines
list,
but
I
think
that's
far
too
much
into
you
already
having
environment
set
up.
So
so,
even
though,
like
it's,
it's
a
feature,
improvement
and
official
edition.
So
in
theory
it
will
also
help
drive
adoption,
but
it's
too
too
down
the
line.
So
I
don't
think
it
necessarily
impacts
for
this
epic.
B
B
So
I
think
that
seems
that's
probably
that's,
probably
the
first
area.
We
should
explore
just
people
knowing
and
discovering
environments
learning
about
what
they
are
and
then
and
then
it's
thinking
about
how
do
we
make
it
easier
for
them
to
use
so
yeah.
A
Right
yeah,
I
think
amazing.
It
makes
a
lot
of
sense
to
have
this
distinction
and
and
making
sure
that
also
for
both,
we
have
really
good
tracking
for
the
further.
You
know
the
badges
on
on
the
on
the
project
home
for
for
environments,
we
track
how
many
people
are
seeing
that
for
clickable
elements
we
track
how
many
people
are
clicking
that
and
try,
at
least
in
the
aggregate
map,
the
interactions
with
the
with
the
changes
we
made
to
to
adoption
of
environments
right
right.
B
Later
on,
just
to
drop
this
thought
just
later
on,
and
then
it's
not
the
focus
now
but
later
on.
We'll
we'll
want
to
think
about
like
when
we
measure
it
we'll
want
to
see
how
people
start
to
adopt
it,
but
also
how
how
much
we
want
to
like
retention
right.
How
many
people
continue
to
use
environments,
because
it's
a
useful
concept
and
feature.
B
We
I
believe
we
have
the
raw
material
like
the
data
to
be
able
to
do
that.
I
don't
know
if
we've
looked
at
that,
I
have
personally
not
looked
at
that
since
I've
been
here,
I've
looked
at
it.
I've
looked
at
a
height
sort
of
a
higher
level.
Just
because
I
look
at
you
know,
we
look
at
monthly,
active
users
and
smile,
and
it
continues
to
increase,
so
that's
good,
but
yeah.
I
think
we
want
to
zoom
in
on,
like
as
we're
developing
new
features.
B
We
want
to
zoom
in
a
little
bit
more
on
that
to
make
sure
people
are
retaining
yeah.
That
makes
sense
yeah
thanks
for
adding
that
now
cool.
Okay,
let
me
share
my
screen.
B
So
yeah,
I
let
me
know
when
you
can
see
it.
B
Nope,
I
think,
you're
on
mute
now
yeah.
I
can
see
it
cool
yeah,
so
this
I
started
a
using
one
of
the
templates,
actually
that
we
were
just
talking
about.
I
think
it
was
one
of
the
the
rails
template
I
created
at
test
projects
that
was
pretty
pretty
smooth
and
really
easy
to
do,
which
is
great.
B
You
know
I
was
able
to
I'm
kind
of
trying
to
remember
what
I
did
back
back
a
few
weeks
ago,
but
in
general
really
easy
to
make
updates
able
to
see
pipelines
and
see
the
status
I
did
run
into
an
error.
I
can't
remember
exactly
why,
but
I
remember
trying
to
use
the
ui
and
then
oh
okay,
that's
what
it
was
something
about.
B
I
didn't
have
a
credit
card
loaded
into
my
into
my
account,
and
so
when
the
pipeline
tried
to
run,
I
think
automatically
just
from
the
sort
of
step-by-step
guide.
It
failed,
so
kind
of
had
to
debug
a
little
bit
and
figure
that
out,
but
anyway
I
was
able
to
run
it,
and
so
because
it
was
a
the
project.
Template
already
had
a
ciaml
file,
but
what
I
was
pointing
out
to
daniel
just
earlier
is
that
even
after
having
set
this
up,
it's
a
little
unclear.
B
You
know
just
from
from
from
viewing
what's
in
the
product
itself
today,
it's
not
exactly
clear
what
to
do
next
in
terms
of
setting
up
a
release
or
setting
up
an
environment,
and
I
think
this
is
the
area
where
you
know
there's
a
lot
of
opportunity
for
us
to
educate,
to
having
products
guidance
to
maybe
be
more
kind
of
pointed
and
maybe
opinionated
about
what
steps
station.
You
know
a
user.
A
team
should
do
next
to
deploy.
B
B
Is
to
be
really
maybe
aggressive
is
the
wrong
word,
but
really
kind
of
just
highlight
that
the
first
thing
you
should
do
is
to
try
to
deploy
this
project
to
production
just
to
test
it
out
right.
So,
like
you
know,
it's
kind
of
an
extreme
thing
we
could
do,
but
you
could
imagine
ways
and
in
multiple
areas
throughout
the
ui
here
that
help
and
guide
the
user
to
be
able
to
do
that
really
quickly.
A
Yeah,
I
totally
agree
with
that.
It
is
tricky
to
be
opinionated
at
gitlab,
in
the
sense
that
we
have
so
many
different
customers
with
so
many
different
use
cases.
A
So
so
it's
hard
to
say
like
what
should
we
suggest
specifically,
but
we
should
definitely
suggest
something
right
like
set
up
an
environment
in
a
certain
way
and
then
try
to
find
the
the
sweet
spot
where
we're
suggesting
something
that,
at
the
very
least,
for
a
first
set
up
makes
sense
for
most
of
our
users
and
if,
if
like,
we
have
any
way
to
to
slice
that
into
if
you
have
certain
configuration
a
certain
size
of
organization.
I
don't
know
if
we
can
do
that.
A
B
And
that
that's
that's
a
great
way
of
putting
it
daniel,
like
I
think
it
was
a
dead
end.
I
I
hit
you
know,
I
I'm
a.
I
have
a
software
background.
You
know
I
kind
of
understand
that
the
basics
and
sort
of
the
next
steps
after
running
a
pipeline
and
testing,
but
you
know
it
wasn't
obvious
to
me
and
that
I
think
that's
what
we
want
to
do.
It
wasn't
obvious
for
me
what
to
do
next,
even
in
terms
of
using
the
other
release
functionality.
B
So
again,
like
you
said,
suggesting
to
create
a
new
environment.
If
we
don't,
if
we
know
that
they
don't
have
one,
because
that's
probably
a
best
practice
that
we
wanna,
we
wanna
convey
yeah
and
then,
of
course,
we
also
want
them
to
use
our
features
and-
and
things
like
that,
so
that's
sort
of
what
I
was
getting
at
earlier
and
I
think
you
know
this
conversation
will
do
a
lot
to
the
ideas
we
talked
about
today.
We'll
do
a
lot
here
to
help
increase
that.
A
Yeah
makes
sense,
so
I
added
one
more
item
in
the
in
the
dock
that
reads:
once
you
set
up
a
pipeline,
it's
unclear
what
to
do
next,
set
up
a
release
set
up
environments,
how
to
actually
deploy
right
right,
because
that's
that's
the
pain
point
I
also
went
through
when
I
right
after
I
joined.
I
was
tasked
with
with
doing
a
test
setup
to
understand
the
product
deploying
to
aws
and.
B
A
Was
tough
and
at
various
points
in
the
process
my
pipeline
was
green,
like
I
had
finished
all
the
steps
that
I
had
so
far,
but
I
still
I
was
still
unsure
like
to
which
extent
is
my
setup
correct
and
to
which
extent
it
is
actually
doing
what
it's
supposed
to
do,
because
just
because
the
pipeline
isn't
broken
doesn't
mean
my
entire
setup
is
is
done
so
I
think
it's
not
necessarily
the
scope
of
environments,
but
it's
also
having
having
the
the
understanding
that
the
user
completing
the
steps
is,
might
not
be
enough
to
for
them
to
reach
their
goal
and
how
we
can
actually
assist
them
in
reaching
their
final
goal,
which
is
having
the
code
running
in
an
environment,
a
real
environment
somewhere
that
they
can
access
through
the
gitlab
interface.
B
Actually,
this
is
sort
of
a
wild
idea,
but
just
as
you
were
saying
that
I
kind
of
I
I
think,
you're
right
in
terms
of
you
feel
like
another
area
of
opportunity,
is
in
some
way
helping.
B
Helping
our
customers
stand
up
those
environments
either
for
the
first
time
or
you
know
or
changing
those
over
time,
and
I
wonder
if
there's
a
an
opportunity
for
git
lab
in
some
way,
whether
it's
technology
or
even
you
know,
someone
doing
this,
and
maybe
we
do
this
already,
but
like
reviewing
those
sort
of
environment,
setups
and
pipelines
like
you
know,
this
is
sort
of
a
silly
idea,
but
something
like
you
know,
let's
say
someone
like
a
release
engineer
a
deployment
kind
of
platform
person
standup
sets
up
their
their
yaml
file,
they're
in
their
targets,
and
then
you
could
almost
imagine
like
something
like
in
git
lab,
like
review
my
review,
my
pipeline
or
review
my
you
know
kind
of
my
setup
right
to
make
sure
they're
on
the
right
track,
because
I
think
because,
like
you
said
like
that's,
that's
very
difficult.
B
That
was
difficult
for
us
and
we
work
here
and
we
should
you
know
we
should
have
access
to
all
of
that
expertise.
But
I
can
imagine
someone
sort
of
someone
new
to
gitlab,
maybe
new,
to
devops
yeah.
A
B
And
you
know
maybe
something
to
like
think
about
just
for
a
future
feature,
but
that'd
be
pretty
cool.
I
think
yeah.
A
Currently
working-
and
this
is
what's
not
working-
this
is
what's
hard
for
me
right
and
then
we
bring
those
those
insights
back
into
into
this
conversation,
but
yeah.
I
absolutely
agree
that
it
would
be.
It
would
be
really.
Nice
have
a
magic
button
where
a
person
fixes.
B
A
That
that
points
back
to
the
to
the
work
that
pipeline
authoring
is
doing
with
the
deployment
templates,
the
cic
templates,
where
at
some
point
the
idea
is
to
have
a
broader
pool
of
templates
that
that
the
community
can
can
contribute
to.
So
your
idea
might
seem
farfetched,
but
I
don't
think
it's
that
much
good.
A
All
right,
so,
I
think
we're
good
to
to
start
wrapping
this
up
into
action
points.
What
do
you
say.
A
I
would
say
the
first
thing
is
just
create
issues
for
the
main
points
or
points
and
add
into
the
to
the
epic
that'll
be
the
first
thing
and
then
from
there.
We
just
schedule
for.
A
B
Because
I
think
it
would
probably
be
great
to
get
and
jinya
jaime
and
others
have
been
already,
I
think,
contributing
which
is
fantastic.
But
I
think
once
we
create
the
issues,
we
could
get
edge
feedback
on
the
ideas
and
sort
of
idea
of
scope.
Just
because
it's
great
for
you
and
me
to
discuss
some
of
these
ideas.
But
then
definitely
we
want
to.
We
want
to
get
the
team,
but
I
skipped
that
step
for
sure,
no,
no
good
and
then
yeah.
B
For
me,
I
think
we
want
to
estimate
like
impact
and
prioritize
so,
and
I
can
help
with
that
as
well.
Cool.
A
Yeah,
I
think
one
one
like
horizontal
effort
within
this
epic
is
the
the
tracking
making
sure
we
have
a
consistent
tracking
strategy
right
that
we
can
reapply
for
each
one
of
these
small
changes
we
could.
We
could
reach
out
to
the
to
the
growth
team
to
see
like
what
they
what
they
are
currently
doing
in
terms
of
experimentation.
I
don't
think
these
necessarily
have
to
be
experiments.
A
It
could
be,
could
not
be
in
it.
It
depends
on
on
on
how
high
traffic
also
like
these.
A
These
specific
features
are
right,
depending
on
where
they
are
located,
but
it
would
be
nice
to
have
them
as
experiments,
if
not
just
having
a
structure
of
wrapping
it
in
a
feature
flag
and
then
wrapping
it
into
a
what's
called
snowplow
event
tracking
right
so
for
for
each
badge
for
each
button,
you
know
how
many
people
are
seeing
it,
how
many
people
are
clicking
it,
and
then
we
can
aggregate
these
interactions
and
compare
them
against
against
adoption.
B
Definitely
yeah,
that's
perfect,
yeah!
I
I
I
don't
know
much
yet,
but
this
is
a
good
opportunity
to
collaborate
with
the,
like.
You
said,
with
the
growth
team
with
gila
and
team.
B
My
understanding
is
that,
especially
if
we
decide
to
use
in-app,
like
specifically
in-app
notifications
for
some
of
these,
I
think
there's
a
it
seems
like
there's
already
like
a
foundation
for
for
doing
experimentation
with
that
and
and
hopefully
measuring.
Hopefully,
that
includes
measuring
as
well.
B
So
that's
something
yeah,
that's
something
I
can
follow
up
on
with
the
team
as
well,
and
maybe
we
could
collaborate
on
the
issues
once
we
decide
on
which
ones
we
wanna
yeah.
I.
A
Think
to
to
be
honest,
even
for
for
for
the
ones
that
are
not
like
notifications
like
this
one,
we
should
we
should
collaborate
with
the
create.
Is
it
create
team
to
handles
projects
repositories?
A
B
A
All
right,
cool,
so
I'll
I'll
I'll
defer
to
you
to
create
the
issues.
If
that's
okay,
yeah
yeah,
feel
free
to
bring
me
each
one
of
them
and
I'll
help
filling
up
details
and
and
the
ux
proposal
for
each
one
of
them.
That
kind
of
thing
perfect,
all
right,
that's
good
cool!
So
if,
if
you
don't
have
any
other
points,
I
think
we
can
wrap
up
the
recording.