►
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
Yeah
great
idea,
yeah
yeah,
so
we're
thinking
about
what
we're
going
to
work
on
over
the
next
couple.
Milestones
like
the
big
items
and
initially
the
big
one,
was
editing
Branch
rules
but
in
the
same
kind
of
sphere.
There
is
this
other
push
for
better
group
level
settings
so
that
organizations
can
set
up
their
teams
rather
than
going
through
of
projects
to
ensure
that
the
same
Mr
rule
are
approval.
Rules
are
set
up
so
with
the
approval
rules.
A
I
know
the
one
big
ones
is
like
that
minimum
number
of
approvers
kind
of
getting
that
set
up,
that's
like
if
we
can
get
that
that
will
make
a
lot
of
people
happy.
Everything
else
is
kind
of
like
extra
icing
on
the
cake,
like
you
know,
setting
up
approval
groups
or
teams
that
could
be
used
across
projects,
that's
good
yeah.
So
what
I
don't
have
a
strong
opinion
on?
You
know
whether
Branch
rules
should
go
first
or
actually
I
do
have
a
strong
opinion.
A
If
I
had
to
pick
between
these
two
I
would
choose
supporting
the
group
level.
U
mer,
Crest
approval
rules,
the
things
that
I
see
are
kind
of
blocker,
not
blockers.
A
It's
just
things
to
be
mindful
of
is
that
merch
request
approval
rules,
don't
really
exist
in
the
group
level
yet,
and
a
lot
of
the
designs
that
I've
explored
so
far
explored
it
with
the
concept
of
Branch
rules
being
in
existence
and
the
full
breath
of
it
of
editing
so
kind
of
extending
the
rule,
the
concept
of
Branch
rules
to
the
group
level.
A
That
being
said,
you
know
if
we
decide
to
go
with
this
first,
switching
that
over
so
that
you
know
we
just
use
the
existing
merch
request,
approval
framework
I
think
that's
doable.
One
thing
that
I
am
aware
of,
but
I
don't
know
how
we're
going
to
solve
this.
Is
these
group
level
rules
will
be
at
the
root
level,
and
then
that
means
it
applies
to
every
single
project.
A
There's
talks
of
you
know
how
do
projects?
How
can
I
opt
out
of
it,
and
the
idea
of
exceptions
like
I,
have
many
different
ideas
on
how
to
do
exceptions.
I
know
the
security
policies
already
have
this
idea
of
exceptions
that
they're
trying
to
work
out,
but
I
think
the
first
iteration
here
is
is
a
very
All
or
Nothing,
so
I
think
the
uptake
of
this
feature
will
be
be
like
you
know.
If
you
use
this,
it's
going
to
apply
for
everyone
and
then
yeah.
B
A
Don't
like
it
don't
use
it
right
now
and
then
we'll
work
on
adding
exceptions
in
the
future,
but
I
think
that's
the
one
thing
that
we
need
to
be
mindful
as
we're
implementing
this
is
that
one
day
we
will
need
to
give
way
to
opt
out
at
a
project
level
or
potentially
even
at
a
branch
level,
but
that
could
be
yeah
doesn't
need
to
be
implemented.
Today.
C
Was
just
going
to
ask
you
Sean
I
mean
from
my
perspective
it
might
be
just
easier
because
you're
Michael
was
saying
that
if
we
just
cover
what
a
minimum
number
of
approvals
will
be
fine.
If
we
just
move
the
whole
framework
of
approval
rules
to
the
group,
it
might
be
easier
than
picking
off
particular
parts
and
then
making
that
available
in
the
group.
So
we
might
just
aim
for
the
whole
thing
and
just
move
the
entire
thing
at
once.
First,
the
back
then
the
front
an
app
make
sure
that
it
works
there.
C
B
C
But
if
we
just
move
the
entire
app,
as
is
we
just
have
to
make
sure
that
it
works
for
that
context,
those
paths,
those
kinds
of
things
for
the
the
back
end
I,
expect
there
to
be
just
some
sort
of
like
assignment
of
behavior
or
something
like
that
to
that
model,
but
or
just
supporting
a
different
model
that
it
attaches
to.
There
might
be
some
other
differences
in
terms
of
searching
users
and
groups,
because
you
would
be
S.
Would
you
search
groups
from
other
groups?
How
does
that
work?
C
A
Yeah
I
think
that's
going
to
open
up
some
other
can
of
worms
of
how
come
I
can
see
this
person,
but
I
can't
see
another
person
right
right,
but
I
think
that's.
C
For
the
first
aim
would
be
the
port,
as
is
yeah
and
then
and
then
we'll
go
from
there.
A
A
So
there's
many
different
designs
on
that.
So
that's
something
that
I
can
solidify
and
update
the
issue
description
with.
But
that
is
something
to
be
aware
of,
because
yeah,
you
would
want
to
know
that
at
the
project
level,
that
all
protective
branches.
C
I'm
guessing
those
are
in
the
Commons
right.
The
designs.
A
You
mentioned
yeah,
so
there's
a
whole
bunch
of
different
approaches.
The
most
simplest
one
is
to
put
a
padlock
on
the
all
protective
branches,
Rule
and
say
this
is
inherited
from
the
group
level.
The
more
elaborate
one
is
to
display
what
those
rules
are,
but
also
mention
that
this
is
set
from
the
group
level.
So
you.
B
Can
see
the
yeah
so
so
with
so
with
the
simple
with
the
padlock
approach,
so
you
know
we,
we
add.
We
add
a
a
way
to
to
add
these
settings
at
the
group
level
and
then
the
project
just
looks
and
sees
that
they're
there
and
just
applies
them
to
to
each
project
and
they
can't
be
changed
in
the
first
iteration
right
and,
if
you
so,
and
so,
if
you
wanted
to
have
current
behavior,
you
just
have
nothing
at
the
group
level:
correct,
yeah,
okay,
so
did
I.
B
Guess
it
feels
kind
of
biggish
and
I'm
just
wondering
if
we
should
break
it
into
at
least
two
issues
and
and
the
first
issue
could
be-
let's
get
it
going
at
the
group
level,
but
it
doesn't
necessarily
do
anything
yet
and
and
then
the
second
issue
could
be.
You
apply
it
at
the
project
level,
which
would
include
the
UI
changes.
A
I
I
think
for
this
to
roll
out.
Both
of
those
things
need
to
be,
in
effect.
B
Level
yeah,
sorry,
I,
wasn't
I,
wasn't
clear,
I
guess
I'm
trying
to
work
out.
What
can
we
get
into
16.5
and
we
we
could
I
think
I,
don't
know,
talked
to
an
engineer
but
sounds
like
I'm
in
the
back
end.
We
might
need
to
create
new
tables.
I,
don't
know
how
we're
can
do
that,
but
you
know
basically
store
the
rules
at
the
group
level
and
then
the
whole
thing
is
just
feature
flagged
off
until
we
do
the
second
part
where
it
actually
works.
C
We
might
even
need
more
more,
so
it
might
even
be
more
than
two
issues.
Yeah
I
I
think
it's
best
to
start
off
with
the
front
and
back
issue
to
move
it
because
it
could
be
pretty
straightforward.
Then
we
go
from
there.
A
C
If
we
do
find
some
hurdles,
we're
probably
going
to
be
if
the
back
end
is
really
involved,
work
maybe
start
with
the
back
end.
Then
the
front
end
ships
the
front
end
to
the
group
level
on
the
next
one,
but
starting
with
the
joint
issue,
could
be
making
sense
and
then
the
other
one
would
be
at
moving
things
to
updating
the
project
level.
B
A
Yeah
I
can
update
the
issue
description
by
the
end
of
the
week.
I'll
probably
have
to
talk
to
some
designers
about.
What's.
A
Happy
to
approach
with
that
I
think
the
approach
that
I
might
take
is
that
I'll
do
it
with
the
context
that
Branch
rules
editing
doesn't
exist
yet,
and
this
is
just
like
taking
the
existing
merge
request
approval
rules
framework
where
it's
project
with
multiple,
like
branches
defined
versus
like
Branch
rules,
where
it's
like
Branch
Centric,
but
all
protected
branches
is
like
kind
of
same
in
in
those
scenarios.
So
I
think
that's
should
be
fine.
Yeah
cool.
B
A
B
Then
we'll
we'll
improve
on
it.
When
we
do
Branch
rules,
you
know,
and
you
know,
and
from
the
back
end
you
know:
we've
we've
been
burning
down
our
bugs.
You
know
I,
think
we've
got
more
capacity
now
to
do
Feature
work,
but
yeah
anyway
we're
going
to
have
a
new
PM
soon,
so
that
that
person
will
set
the
direction
yeah.
Okay,
awesome.
So
so
this
is
in
16.5
sounds
slide.
C
C
To
the
editing
source
code
rules,
I
needed
some
clarity
there
in
particular,
I
was
looking
at
the
so
there's.
Definitely
Parts
here
that
are
updated.
Like
implementation
plan.
Is
it
a
year
old
yeah?
Are
the
mockups
updated
Michael,
the
ones
in
the
description.
C
Okay,
so
essentially
it's
going
so
that
first
Target
Branch,
what's
explain
me
what
that
first
part
is.
C
C
Okay,
the
reason
why
I
ask
is
because
Phil
is
developing
a
feature
that
is
exactly
that:
Target
Branch
rules.
C
A
C
A
C
C
C
Cool
apart
from
that,
essentially
from
my
from
from
what
I
can
see,
then
the
idea
is
that
we'll
go
and
potentially
go
one
box
at
a
time
and
just
add
the
ability
to
add
it
in
terms
of
like
work,
breakdown
could
be
just
an
iterative
approach
to
cover
each
one
of
those
with
editing.
Yeah
I
love
the
drawers.
It's
just
super
nice,
contextual
way
to
make
changes
and
super
quick,
and
so
that
that
makes
sense.
A
So
I
have
another
crazy,
crazy
idea
here
like
hit
me.
So
this
is
editing.
Branch
rules,
as
in
like
the
the
full
Beast
of
like
Branch
rules,
was
like
this
will
complete
it
Natalia's
issue
last
week
with
with
the
dropdowns
on
protected
branches
like
like
there's
like
issues
like
from
two
years
ago,
where
I'm
trying
to
change
how
we
edit
protective
branches
so
like
personally
I
hate
the
drop
downs
for
like
the
last
two
years,
and
maybe
that's
why
I
joined
source
code,
but.
A
Happen
so
like
I
I,
see
I,
see,
there's
a
potential
thing
like
if
we,
if
we
want
to
do
Branch
rules
and
commit
to
it,
that's
cool
and
we
move
towards
that.
Another
path.
I
see.
Is
that
like
if
we
do
approach
editing,
Branch
RS
as
a
drawer?
Potentially
we
could
introduce
editing
protective
branches
today
as
a
drawer
and
just
kind
of
lift
this
UI
that's
being
explored
in
Branch
rules
and
do
that
for
protected
branches.
B
A
Focus
on
making
the
better
experience
for
branch
rules,
and
that's
fine
too,
but
yeah
I,
like
I,
just
wanted
to
raise
that
this
could
be
like
another.
C
C
Chance
of
updating
the
protected
branches
in
place
where
they
are
right
now,
alongside
the
work
that
we're
doing
in
moving
things
into
this
area,
because,
while
we're
updating
the
other
boxes,
we
can
have
another
engineer,
update
the
way
that
it's
being
protect
rendered
on
the
protected
branes
today
would
update
there
by
the
time
that
they
hit
that
box.
It
would
all
be
already
be
updated
and
then
eventually
be
depending
on
how
complex
it
is,
but
it.
A
C
New
UI
I
guess
but
yeah.
B
Goan
go
ahead,
I
was
just
going
to
say,
you
know
it's
probably
we
should
get
Derek
on
this
discussion
and
or
maybe
maybe
it's
even
something
we
might
consider
delaying
till
we
get
it
I
think
the
new
p
is
well.
You
know.
B
Soon,
I
don't
know
what
what
not
perod
would
be
involved,
but
yeah.
A
B
A
A
Before
I
put
my
foot
down
so
with
that
with
that
kind
of
kind
of
mentality,
I
think
what
would
be
helpful
here
is
perhaps
from
an
engineering
standpoint
just
to
like
recheck
the
implementation
plan
and
just
see
the
scope
of
the
change
so
that
if,
if
there's
an
opport
like
like,
if
we
feel
like
this
thing
is
too
crazy
or
like
you
know,
or
if
we
say
like
you
know
what
this
seems
doable
we're
going
to
dedicate
two
or
three
Milestones
to
get
this
done.
A
But
I
think
when
we
did
the
read
only
view
of
stuff.
It
took
a
little
bit
longer
than
we
expected
so
I
think,
especially
because
we
were
learning
so
much
right,
like
we
were
learning
about
wild
cards
and,
like
all
the
different
rules
over
the
years
and
documenting
them.
A
So
I
feel
like
that
there
might
be
dragons
as
we
approached
the
editing
which,
which
we
know
from
last
week's
Natalia's
issue
is
just
like
this
magical
drop
down
with
like
no
one
and
numbers
that
changeed
randomly
and
so
yeah
that
that
was
the
reason
why
we
didn't
just
want
to
lift
and
shift,
and
we
wanted
to
you
know,
address
those
kind
of
issues
with
a
better
experience.
I
think
we're
in
that
better
experience
now,
but
yeah
I
think.
A
C
So
Michael,
do
you
know
what
would
be
really
helpful?
I
was
looking
at
the
pages
themselves
and
when
I
look
at
the
screenshots
that
you
have
there
on
the
description
you
have
Branch
protections,
then
you
have
allowed
to
merge
a
lot
to
push
and
merge.
You
have
merge,
request
approvals
and
Status
checks,
so
I
feel
like
I
was
looking.
The
edit
I
was
looking
the
way
that
we
edit
the
I,
guess
protected
Branch
screen
and
we
do
it
all
in
one
widget.
C
C
A
C
A
C
If
I
go
to
production,
so
like
the
branch
rules
overview,
this
is
how
it's
displayed
so
matches
pretty
accurately
oops
matches
pretty
accurately
one
with
the
other
easy,
but
when
I
go
to
protect
branches
like
this
is
a
whole
widget
for
a.
A
C
That
I
guess
this
that
and
that
yeah
well.
So
there
was
one
way
of
doing
this
with
this:
the
edits
triggers
a
drawer
or
whatever,
with
the
same
widget
for
all
three
of
these
things
and
you
edit
the
same
thing
at
the
three
points.
That's
an
easy
front.
End
pull
potentially
back
end
because
it's
just
moving
what
we
have
today
yeah,
but
if
you
want
individually
like
a
screen
to
just
edit
the
allow
to
merge
one
screen,
just
which
I
think
it's
the
idea.
Yes,
another
one
for
a
lot
to
push
a
merge.
A
B
A
Back
to
the
issue,
the
next
section
there
is
allowed
to
push
and
merge
so
push
and
merge
is
kind
of
different
because
that
introduces
deploy
Keys,
that
you
can
add
and
search
for
yeah
yeah.
C
I,
like
that,
this
makes
this
layout
makes
this
page
already
mobile,
ready
or
mobile
first
I
guess
because
it
just
grows
which,
whatever
with
but
then
the
content
is
narrow,
yeah
the
toggles.
This
is
for
the
L.
First
push:
that's
just
the
little
things
there
yeah.
B
Good
good
Michael
I
had
a
question
about
code
owners
with
this
yeah
just
reminded
me.
So
if
I
correct
me,
if
I'm
wrong,
but
currently
code
owners,
if
you
have
the
file
in
the
repository
it's
applied,
but
we
in
this
change
we're
introducing
the
option
to
to
have
that
turned
on
or
off.
C
Maybe
should
we
surface
that
to
the
Epic
or
how
so
my
my
concern
is
that
there's
a
lot
of
updated
information
so,
for
example,
I
thought
that
that
implementation
plan,
all
those
issues
were
updated
completely.
Oh.
C
Y,
we
have
the
we
have
the
history
of
the
description
anyway.
So
if
you
want
to
pull
it
back,
go
there
yeah,
so
yeah,
essentially
just
make
sure
that
whatever
is
in
the
description,
is
up
to
date,
so
that
we
can
then
start
breaking
it
down.
I
think
this
is
a
big
chunk
of
work
that
we
want
to
be
careful
about.
C
So
what
I
would
probably
suggest
is
having
a
spike
in
the
next
Master
165
to
have
an
engineer,
go
through
all
the
things
or
would
you
want
to
start
building
the
edits
right
away
in
165
Sean?
Were
you
ready
to.
B
Start
off
implementing
right
away,
yeah,
no
well!
That
was
kind
of
where
I
kind
of
started
with
this
was
like.
We
got
this
implementation
plan,
which
I
and
I
guess
the
first
part
is:
are
these
independent?
Can
these
be?
You
know,
first
of
all,
is
this
the
order?
And
secondly,
can
they
be
done
one
at
a
time
or
or
are
there
multiple
pieces?
There
is
a
discussion
about
this,
but
I
got
a
bit
lost
in
a
discussion.
B
Actually
you
know,
should
we
be
doing
like
one
and
two
together
or
something
like
that
or
or
can
we
just,
for
example,
assign
ad
Branch
rule
in
16
and
get
someone
to
do
it
or
the
whole
thing
can
be
again
feature
flagged,
so
the
I
guess
the
question
is
yeah:
are
these
steps
Atomic
iterations
and
can
should
we
just
be
doing
them
or
are
they?
Are
they
multiple
pieces
together
that
need
to
go.
A
So
from
what
I
see,
I
think
they
can
be
separated
and
the
reason
I
say
that
you
can
be
separated.
Is
that
the
current
way
we
display
Branch
rules
today,
when
you
click
into
view
details
for
the
blocks
that
don't
have
the
editing
experience?
We
kick
you
back
to
the
old
experience
so
because
of
that
yeah
there
could
be
a
new
editing
experience
for
you
or
you
get
kicked
back
to
the
old
one,
which
is
it's
fine.
B
A
Separated
I
think
if
we
were
going
to
tackle
anything,
my
preference
would
be
doing
the
hard
things
first.
So
that's
Branch
protections
because
that's
the
thing
that
is
the
most
drastic
change
status
checks
is
like
like
for,
like
the
current
experience
like
nothing
too
crazy.
There
merch
request
approvals
similar,
but
I.
Think
merch,
request
approvals
is
like
the
most
interesting
in
terms
of
inheritance
and
all
that
kind
of
stuff.
But
that's
a
later
Pro.
That's
something
separate,
but.
B
Yeah,
so,
okay,
so
in
that
case
like
should
we
schedule,
hang
I'm
just
going
back
to
the
Epic.
This
first
issue
add
Branch
R,
which
is
and
in
16.5,
because
it
does
seem
really
clear
or
it
doesn't
I
guess.
I
thought
I
thought
we
need
to
kind
of
have
number
two
as
well
at
least
be
fully.
A
A
B
B
A
B
B
C
At
the
I
was
looking
at
the
third
issue,
the
ad
wrench
protections
and
I
wouldn't
want
I,
wouldn't
want
to
tackle
that
in
one
go,
we
would
have
to
go
one
by
one,
so
that
in
itself
is
at
least
three
issues
for
the
protections.
Let
me
just
see:
where
is
it
protections?
We
have
one
for
lot
to
merge,
lot
to
push
and
merge
toggles.
C
So
those
are
three
issues
on
that
one
particular
and
again,
since
the
work
itself
is
not
necessarily
trivial,
because
we
have
to
create
a
new
way
of
editing
into
the
drawer
or
something
which
I
think
it's.
What
would
all
want
is
since
we're
doing
this
at
least
have
some
sort
of
like
Evolution
and
and
Improvement
so
I
feel
like
it's
definitely
worth
pausing
there
and
having
an
engineer
go
through
even.
B
A
C
Just
the
first
three
go
through
the
whole
list
and
break
it
down
into
further
implementation
issues,
because
some
of
these
might
even
be
epics
like
for
the
branch
protection.
Branch
protection
should
be
a
sub
epic.
We
can
remote
it
and
then
take
care
of
it
there
and
then
just
have
three
issues
out
that,
because
that's
you
make
everything
easier
for
us
to
implement
and
done
at
the
end
and
to
organize
everything
that.
C
B
Good
so
yeah
absolutely
agree
on
Ed
complexity
of
an
add
Ranch
protections.
But
do
we
want
to
have
add
Branch
rule
already
in
place
or
you
know
as
one
piece
so
I
guess?
Are
we
looking
for
the
spike
we
focusing
on
the
first
three,
but
maybe
looking
at
the
whole
thing.
C
But
it
doesn't
make
sense
to
have
that
visible
until
you
have
everything
in
there
right,
yeah
so
it'll
be.
We
can
implement
it,
it's
behind
a
feature
flag,
but
it's
not
red
out
yet
I.
B
Mean
in
fact,
okay,
so
in
fact
yeah
all
of
this
really
CU
yeah
we
well
delete,
could
be
optional,
but
status
checks
could
be
optional,
but
it
doesn't.
It
won't
really
be
a
full
feature
unless
we
have
one
two
and
three,
and
maybe
four
right
like
like
when,
when
do
we
turn
it
on
I.
A
What's
there
right
now
with
the
better
thing
right
so,
like
oh,
add
a
branch
rule,
oh
okay,
we
can
do
that
properly
now,
so
we
can
remove
the
Overflow,
the
Overflow,
where
we
tell
you
to
create
a
protected
branch,
and
we
have
this
alert
that
jumps
you
back
to
Branch
rules
so
yeah
that
can
go
once
we
have
this
flow
going.
Oh,
we
have
Branch
protections.
That
means
you
can
edit
it
right
there.
So
then
cool
we.
B
A
Because
we
already
have
this
kind
of
idea
already
in
the
product
like
the
general
flow,
but
we
are
kicking
people
to
different
experiences.
What
we're
doing
now
is
just
replacing
it
with
like
editing,
while
you're
on
the.
A
Page
so
yeah
definitely
feature
flag,
but
like
yeah
once
it's
ready,
then
we
can
like
enable
it
like
like
bit
by
bit
so
I
ra,
so
not
like
one
giant
feature
flag
for
everything
is
more
like
cool
stat,
edits
status
checks
in
Branch
rules
called
as
a
feature
flag.
Edit
merge
request
approvals
but
yeah.
If
something
requires
like
something
much
more
fundamental
or
new
tables
or
whatnot,
yeah
I
think
that
might
require
bigger
feature
flag,
but.
B
B
There,
okay,
so
in
that
case,
I
think
maybe
best
thing
is
to
create
a
new
issue.
That's
just
the
spike
and
and
and
a
sign
it
to
a
backend
engineer.
But
do
we
want
to
also
sign
it
to
a
front
end
engineer,
Andre,
yeah,
okay,
correct
so
I'm
think
I'm
thinking,
Joe,
I'm,
not
sure
unless
he
says
I
don't
want
to
work
on
it
anymore,
but
you
know
he's
got
the
context.
B
B
Okay,
so
I
I'll
create
a
new
issue,
then
and
and
and
we'll
add
a
spike
to
this
Milestone
and
but
we're
still
going
to
continue
with
the
allow
group
level
Mr
approvals
as
as
is
yes
right.
Yes,.
C
That's
separate
thing:
cool
awesome,
I
would
I
would
definitely
prefer
it.
This
way,
I
mean
if,
if
you
feel
like,
we
can
get
started
on
like
the
ad
Branch
ruls,
because
we
have
capacity
to
fill
I
wouldn't
but
I'm
F
I'd
rather
have
sit
down
and
like
look
at
the
whole
Spike
first
and
like
make
sure
that
we
start
off
right,
because
then
we
can
parallelize
later,
if
everything's
scoped
down.
B
Yeah
look
I,
think
I.
Think
the
you
know
it's
a
big
feature
and
I
think
giving
us
some
serious
lowlevel
thought
will
save
us
time
in
the
long
run.
Yeah.
B
C
B
Yeah,
okay,
I'll
link
it
to
the
I'll,
create
the
spark
issue
and
Link
it
to
the
spark
issue.
Yep
cool.