►
From YouTube: Editor Group Backlog Refinement - 2020-12-16
Description
Bi-weekly backlog refinement session for issues related to the Editor group at GitLab
A
All
right
now
we
can
record
we'll
give
enrique
a
second,
but
this
is
the
editor
group
backlog,
refinement
meeting
for
december
15th
and
I
didn't
fill
out
the
agenda
with
any
high-level
topics
but
open
to
ideas.
If
there's
anything
in
particular,
you
want
to
talk
about
before
we
move
right
into
the
workflow
or
the
issue
list.
A
B
Yeah
I
took
a
stop
at
it,
and
so
the
problem
is
not
that
we
are
not
honoring
wiki
access
level,
but
when
we
create
a
project
through
the
api,
we
do
not
honor
any
access
level
attribute
at
all,
not
only
wiki
access
level.
So
you
cannot.
I
don't
know
you
cannot
disable
issues
by
default
when
you
create
a
new
project,
so
there
must
be
something
that
is
not
taking
all
the
access
level
attributes
and
create
the
project
with
them.
C
B
C
C
B
E
D
A
Yes,
so
I
I
agree,
I
mean,
if
there's
no
other
group
that
owns
api,
which
I
was
going
to
be
my
question
like
just
there's:
no
global
group.
You
know
why
not
us
right
like
we
are
all
get
lab.
We
should
be
good
citizens
to
the
api
and,
if
there's
a
bug
related
to
wiki,
but
we
can
fix
it
for
everybody
else.
That's
having
this
problem
then
sure
I'm
just.
C
B
C
D
A
I
think
the
largest
visibility
visibility
of
a
wiki
you
know
at
time
of
project
creation
is
not
necessarily
the
highest
priority
right
like
if
it's
not
populated
with
any
content,
and
it's
just
set
to
the
wrong
access.
It's
not
harming
anything,
but
if
it
goes
overlooked
and
you
start
adding
sensitive
data
in
there
or
something
like
that,
yeah,
I
think
chad's
point
is
right
on.
A
A
A
A
B
A
A
A
A
A
A
C
A
It
so
yeah
just
to
describe
my
understanding
too.
That's
what
I
understood
it
was.
You
know.
Basically,
we
have
our
readme
rendered
here
in
nice,
markdown
output,
but
for
python
files
they
don't
use
readme.markdown,
but
they
would
like
something,
alternatively,
to
point
to
that
in
init
file
rendered
instead
and
then
it
goes
on
to
describing
the
issues
like.
Maybe
this
has
some
cascading
logic
around.
B
A
B
Yeah,
I
think
source
code
I
mean.
I
remember
there
is
some
method
in
the
repository
class
that
says
readme
file,
in
which
you
cache
the
readme
file
of
the
of
the
repository.
I
think
there
we
should
update
the
logic
and
say
if
this
project
is
pythons,
look
as
well
for
this
specific
file,
if
no
readme
is
found.
A
A
A
A
A
Oh,
let's
see
this
I'm
going
to
skip
over
the
settings,
one
real,
quick!
I
want
to
talk
about
this
one
because
we
haven't
talked
much
about
static
site
editor
and
this
one
just
needs
a
little
bit
of
work
so
to
give
some
context
because
it
came
up
in
the
in
the
comments
here.
The
static
site
editor
is
available
to
any
project
in
theory
that
uses
markdown
as
their
content
and
can
send
the
right
url
path
to
the
static
site
editor.
A
A
A
Our
work
on
the
template
was
part
of
our
first
nbc
and
we've
gone
through
and
made
a
few
tweaks,
but
we've
added
some
new
features
since
including
a
new
configuration
file
that
allows
you
right
now
only
to
define
the
the
directory
that
you
want
to
put
uploaded
images
and
assets.
So
when
you
upload
it,
you
can
upload
an
image
from
the
static
site,
editor
and
in
order
to
put
it
in
the
right
place.
A
There's
a
configuration
file.
This
template,
though,
doesn't
have
a
pre-populated
configuration
file,
so
this
issue
was
was
simply
to
sort
of
update
the
template
just
to
reflect
that
there
is
a
configuration
file.
We
can
use
the
default
of.
I
think
it's
just
source
images
or
something
like
that
and
and
leave
it
there,
but
I
feel
like
it
should
reflect
in
here
that
you
know
the
static
site.
Editor
configuration
file
should
be
represented
there,
so
people
can
access
it.
D
So
this
should
be
almost
no
work,
because
we've
already
figured
out
how
the
config
file
works.
So
there's
this
other
project,
we
called
static
site,
editor
unfiltered,
which
was
where
we
had
when
there
was
a
static
site,
editor
dedicated
team.
We
would
dog
food
that
by
updating
our
status
on
things,
but
even
though
we're
not
doing
that
anymore,
it's
still
important
as
a
place
where
we
can
dog
food
stuff.
So
for
these
config
file
changes,
I've
already
implemented
them
in
there
and
made
sure
that
they
work.
D
So
this
is
really
just
a
matter
of
taking
what
is
already
there
and
putting
it
in
the
template.
Repository
for
when
people
create
a
new
project
like
eric
said
that
it
gets
created
and
probably
adding
you
know
some
more
inline
documentation
around
that,
because
that
was
our
original
plan
to
make
the
original
template
file
sort
of
self-documenting.
D
D
A
D
A
A
A
D
A
I'm
glad
so.
This
is
how
I
think
too,
so
this
category
strategy,
static
site
editor,
needs
some
attention.
It's
not
up
to
date.
In
that
we
are
not.
We
are
already
viable,
so
I
can
move
all
these,
but
ideally
what
I
would
have
for
every
one
of
our
categories
is
these
sort
of
thematic
buckets
of
work
in
this
case
that
one
is
around
configuration,
so
that
is
the
customize.
A
The
statics
editor
configuration
behavior,
that's
the
the
primary
goal
is
to
to
make
it
more
customizable,
I
guess,
and
then
in
there
are
the
actual
user
stories
and
the
the
work
to
be
done.
So,
yes,
these
are
improvements
and
features,
but
I
would
prefer
to
bucket
them
thematically
within
a
category
strategy
so
that
we
can
link
to
them
more
clearly
as
far
as
like
tracks
of
work
that
we
might
pick
up
or
potentially
like
align
them
to
okrs
or
just
higher
level
goals
with
each
category
and
then
in
there.
A
If
there,
if
there
aren't
ones
that
relate
specifically
to
a
work
stream
or
theme,
then
I
think
there's
like
gonna
definitely
be
a
sort
of
catch-all
like
improve
the
user.
Experience
of
the
static
site
editor
or
improve
the
performance
of
the
web
ide,
or
something
like
that
where
we
can
just
kind
of
bucket
general
improvements.
D
B
A
A
In
our
release,
post
related
to
the
work
enrique
did
to
split
the
commits
for
formatting
changes,
separate
from
the
intentional
changes
in
the
static
site
editor,
which
is
a
incremental
iterative
improvement
towards
this,
which
I
referenced
in
the
release
post
and
needed
to
write
a
little
more
detail
about
so
keeping
them.
You
know,
together
in
in
those
related
epics,
you.
B
C
Eric
I
have
a
question
about
this
epic
and
like
this,
this
organization
of
the
epics,
so
we
were
heading
to
another
epics
and
we
cannot
look
as
enrique,
rightfully
states
that
we
cannot
assign
issues
to
more
than
one
epic.
So
does
this
epic
that
you've
created
replaced
the
epics
that
we
we
were
putting
things
into
previously
and
what
and
if
yes,
what
do
we
do
like?
A
Yeah,
so
I
mean
I,
I
do
think
we
have
so
the
ideal
solution
would
be.
You
could
have
a
multiple
app
so
that
you
could
track
different
sort
of
relational
concepts,
but
with
this
structure
I
we've
basically
what
I
imagine
is:
we've
created
sort
of
transient
buckets
for
us
to
do
some
organization
and
then,
when
they
do
fit
a
theme
like
this,
I
can
move
them.
I
don't
think
you
have
to
worry
about
moving
them
to
the
related
buckets.
Ideally,
the
issues
show
up
on
our
issue
board.
A
You
know
it
doesn't
matter
what
epic
they're
in
the
end
goal
would
be
to
be
able
to
use
something
like
gitlab's
roadmap
feature
and
show.
You
know
that
we're
working
on
epics
in
a
in
a
more
like,
targeted
and
sequential
way
and
be
able
to
project
out
a
little
further.
That's
why
I
would
prefer
sort
of
thematic
or
like
feature
driven
epics
to
hold
the
issues,
so
we
wouldn't
ship
necessarily
a
an
epic
called
customize.
A
A
A
The
complete
maturity
of
the
static
site-
editor,
in
my
mind,
won't
be
achieved
until
there's
some
flexibility
around
configuration
and
you
can
make
it
work
with
multiple
types
of
projects.
So,
however,
we
define
success
for
that.
Epic
isn't
necessarily
going
to
be
closed
by
one
work
stream
or
one
issue,
certainly
not
one
issue,
but
within
that
theme
there
might
be
eight
or
ten
epics
worth
of
work,
and
one
of
those
ethics
might
be
something
we
work
on
for
a
milestone.
A
One
of
those
epics
might
need
to
have
sub
epics
of
their
own,
but
ultimately,
I
think
the
way
this
ladders
up
is
in
a
perfect
world.
We
would
have
projected
and
organized
ourselves
around
the
category
maturity
and
say
all
of
these
are
complete.
Now,
let's
run
a
category
maturity,
score
card
and
and
see
if
we
can
validate
that
we're
ready
to.
You
know
graduate
to
the
next
level
in
this
case.
We
we
did
it
a
little
early
and
I
haven't
moved
these
in
to
complete,
which
is
fine,
and
I
can
just
do
that.
A
A
The
the
place
where
we
can
just
keep
all
of
them
organized
and
then
talk
about
our
higher
level
group
strategies
and
priorities
in
this
case
in
here
I
would
reference.
You
know
we're
supposed
to
have
50
of
our
time
for
the
near
future,
dedicated
to
settings
in
nav-
and
you
know
like
these.
Other
categories
are
kind
of
on.
B
D
I'm
just
gonna
jump
in
there.
What
what
I
think
could
happen
there.
I
I
agree
to
dennis's
point:
there
could
be
an
existing
structure
like
of
nested
ethics
that
don't
necessarily
fit
into
this
structure.
I
still
think
this
structure
is
good
because
it
gives
us
a
perspective
of
like
what
we're
delivering
what
our
okrs
are
the
category
maturity.
But
in
that
case
I
think
we
could
still
put
them
in
this
structure,
but
if
there
was
some
organization
that
is
still
valuable
for
it,
because
efforts
are
treated,
you
can
only
pick
one.
D
C
I'm
just
a
bit
worried
that
technically
like
when
we
were
creating
those
those
epics.
Previously,
we
already
had
the
the
issue
that
we
cannot
keep
an
issue
in
two
different
topics:
right,
for
example,
my
issues
for
editing
light.
I
cannot
keep
them
in
the
editor
like
maturity,
epic
and
I
have
to
move
them
here
now
we
have
to
move
them
somewhere
else
and
we
don't
even
have
the
editor
light
category
in
the
hq
issue,
so
I'm
just.
C
D
I
think
editor
light
is
actually
a
good
example
of
why
this
I
I
like
this
structure
from
a
pm
and
company
perspective,
because
editor
light
is
really
it's
a
technical
implementation
detail
that
will
span
multiple.
You
know
product
areas,
okrs
and
deliverables.
So
if
we
have
to
pick
a
way
to
structure
our
top
level
view
of
it
to
me,
it
makes
sense
that
from
this
structure,
which
reflects
how
you
know,
management
is
expecting
us
to
deliver
work
and
how
we're
going
to
be
judged
on
category
maturity.
D
And
if
we
have
to
group
things
like
editor
light,
you
know
because
episode
tree
and
not
a
dag,
we'll
use
labels
for
that.
If,
if
they
need
to
be
grouped
and
if
it
has
to
be
like
a
hierarchy
of
labels
or
something
we
come
up
with
to
capture
like
the
technical
direction
of
things,
that
sort
of
a
parallel
view
of
it,
as
opposed
to
this
one,
which
is
like
what
are
we
actually
delivering
as
a
team
to
the
company
and
the
product.
B
C
D
C
E
C
A
So
all
I
would
say
is,
I
would
probably
name
this
something
different
than
just
general
improvements.
This
might
be
viable
maturity
or
something
like
that.
You
know,
or
you
know,
okay
quarter,
one
whatever.
We
call
that
that
parent
epic
would
would
get
moved
into
one
single
source
of
truth,
like
you
said,
and.
A
Like
toolbar
for
editor
light
is
a
great
thematic
epic
right.
It's
got
work
incrementally
eventually
we
will
have
a
toolbar
for
editor
light
like
that.
I
don't
think
you
need
to
change
this.
I'm
just
saying
we
probably
would
move
this
under
that
that
hierarchy,
so
that
we
can
keep
one
single
source
as
far
as
like
priority
for
what
to
work
on
next
and
what's
going
to
bring
the
most
value,
I
think
we
need
to
just
have
a
conversation
about
that.
A
Given
the
time
that
you
have,
I
think
stretch,
labels
are
a
good
way
to
build
that
little
backlog
if
you
have
time,
but
obviously,
if
there's
something
you're,
passionate
about
like
editor
light
or
if
there's
a
a
desire
to
to
just
switch
context
for
some
reason
to
to
work
in
a
different
area
or
address
some
tech
debt,
which
certainly
would
be
a
bucket
within
each
categories
label,
just
a
like
general
tech
debt,
I'm
not
recommending.
We
change
that.
A
C
A
Yeah
and
honestly,
we
need
to
I
need
to
work
on
whether
or
not
that
is
a
formal
category
or
if
it's
an
implementation,
detail
how
we
organize
that,
whether
I
mean
it
can
have
an
epic
it.
That's
not
nothing
formal.
We
can
just
call
editor
light.
It
can
be
called
editor
light
improvements,
whatever
we
want
to
call
it
about
how
we
communicate
it.
Outwardly,
though,
is
is
what
I'm
what
I
need
to
still
resolve,
but
yeah,
I
think
we're
I
think,
we're
on
the
same
page.
This
is
certainly
a
work
in
progress.
A
This
is
meant
to
be
the
single
source
of
truth.
I
don't
want
you
having
to
go
between
multiple
places.
I
need
something:
that's
a
little
more
product
level
user
facing
like
thematically
organized
and
I
don't
think
we
should
keep
things
in
two
places
with
epics.
We
can't
keep
things
in
two
places,
so
I
would
prefer
some
buckets
that
represent
user
value
and
then
within
those
individual
work,
streams
or
features
or
or
buckets
of
technical
debt
that
we
can
pull
from.
D
Right-
and
I
was
like
is
in
terms
of
editor
light,
it's
it's
important,
it's
critical
to
all
of
these
things,
but
it's
critical
to
more
than
one
thing
from
an
outward
user
facing
and
management
looking
down
perspective.
So
that's.
If
that's
the
view
we
have
like
we
have
to
somehow
in
this
convenient
way
as
possible
group,
the
editor
light
via
different
mechanism
than
epics.
If
that's,
what
we're
using
them.
D
D
A
Oh,
I
mean
I
need
to.
I
need
to
get
ahead
of
you
all
you
you
move
faster
than
than
me,
so
I
need
to
get
a
better
backlog
of
well
written
issues.
We
have
plenty
of
stuff
from
web
ide
and
snippets
and
stuff
like
that,
but
I
need
to.
I
need
to
get
a
ahead
of
the
prioritization,
so
we
know
what
we
should
work
on
next,
okay.
Well,
this
one.
A
B
A
A
Yeah
that
does
sound
pretty
obscure,
but
I'm
all
for
easy
wins.
I
we're
going
to
have
a
lot
of
work
coming
up
and
I
guess
we
can
talk
about
the
settings
in
that
next
in
the
in
the
next
issue.
I
think
we're
going
to
be
wrapping
up
a
lot
of
the
solution-
validation.
I
don't
want
to
over
promise-
or
you
know,
over
book
ourselves
with
with
these
quick,
wins
and.
A
A
D
D
A
A
A
Issues
cool:
let's
talk
about
this
user
menu,
one
which
I
brought
into
here,
mostly
because
michael
pinged
me
on
slack
somewhere,
it's
an
issue.
I
haven't
opened
up
my
800
emails
today
to
see
where
the
in
context
he,
but
he
was
asking
you
know
what
needed
to
be
done
to
oh
in
our
planning
issue.
Is
this
the
same
2260
yeah?
So
these
are
related
these
these
two
so
rethink
the
navigation
bar
user
menu.
A
A
A
D
A
I'm
going
to
ping
michael
on
this
and
see
if
this
proposal
needs
to
be
updated
at
all,
but
I
believe
this
is
the
most
accurate.
It's
awesome
I
would
like
if
it
doesn't
get
picked
up
in
the
hackathon.
I
think
then
13
nine
would
be
a
great
time
to
get
this
done
or
if,
if
it
really
is
a
one
point-
and
you
finish
up
or
are
waiting
for
a
review-
and
you
want
to
pick
it
up
in
13
8,
I
won't
complain.
D
A
D
A
Yeah,
that's
a
good
point.
Don't
don't
need
to
do
that
dance
every
time
and
I
will
forget
every
time
and
we'll
have
to
do
the
same
thing
where
we
leave
and
join
again.
Thank
you,
okay,
so
yeah
this
is
pretty
straightforward.
I
think
this
is.
This
is
an
example,
though
some
of
the
settings
work
that
I'm
expecting.
We
start
picking
up
in
the
in
the
coming
milestones
right.
So
we've
been
thinking
a
lot
about
these
little.
A
A
I
don't
know
lower
impact
really
because
we
didn't
want
to
disrupt
baseline
measurements
from
the
ux
team
and
we
also
were
still
working
on
solution
validation
for
some
of
the
more
like
significant
issues.
So
this
is
a
a
good
example
of
one
of
the
ones
that
michael's
been
working
on.
We'll
also
have
some
related
to
the
top
nav
in
general,
like
the
projects
and
groups
button,
but
I
didn't
quite
get
around
to
finalizing
an
issue
for
us
to
refine.
That
might
be
a
good
one.
A
And
clearly,
other
people
have
been
thinking
about
it
for
months
and
months,
so
good
to
know
that
it's
a
quick
win,
we've
got
a
couple.
Let
me
see
we
go
till
the
top
of
the
hour.
We've
got
a
few
minutes,
let's
just
clear
out
this
last
one
for
for
snippets.
I
put
this
in
here:
oh
dennis
dropped,
but
he
created
the
issue.
B
B
B
D
A
I
think
maybe
then
this
would
be
a
good
epic
to
run
through
in
our
next
issue
refinement
a
couple
of
these.
We
have
already
scheduled
for
13.8.
I
think
they
were
stretch
or
not
necessarily
labeled
deliverable,
so
hopefully
they
get
picked
up.
But
if
not
we'll
talk
about
wrapping
up
the
work,
I'm
I'm
just
a
big
fan
of
clearing
the
deck
here
and
making
sure
that
we
don't
drop
anything.
That's
important,
so
I'll
just
try
and
understand
exactly.
A
A
So
I
think
that's
it.
I
will
see
you
all
in
a
day
or
so
yeah
tomorrow
for
our
milestone,
kickoff
and
if
you
can
make
it
this
afternoon,
on
my
time
chad
usually
tries
to
join,
but
our
product
in
ux
weekly
is
today
as
well.
So
lots
of
team
meetings
today
and
I'll
see
you
then
thanks
for
joining
and
thanks
for
giving
the
input
and
feedback
see.