►
From YouTube: Create:Editor Product/UX Weekly - 2021-02-24
Description
Weekly Editor group sync between Product, Design, and UX Research
A
All
right,
hello,
everyone
formally-
this
is
the
february
24th
2021,
editor
group,
product
design,
ux
research,
sync
meeting,
and
we
missed
one
last
time
and
we
have
some
async
notes
to
go
back
on,
but
I
think
we
should
just
jump
right
into
the
agenda
here.
A
A
Four
year
it
was
created
four
years
ago.
It
was
on
the
wiki
backlog
and
it's
a
fairly
large
backlog.
I
haven't
gone
through
every
issue,
so
it
was
not
on
my
radar,
but
I
was
interested
to
read
the
feedback
and
the
different
customers
who
have
indicated
strong
desire
to
have
a
merge
request
flow
within
the
wiki,
which
previously
had
been
kind
of
cited
as
like
a
benefit
of
the
wiki.
A
So
you
just
start
editing,
you
hit,
save
and
it's
published
and
you
don't
have
any
kind
of
delay
or
build
time
or
anything
like
that,
adding
a
merge
request
flow
and
potentially
like
a
ci
pipeline,
build
and
etc.
Like
has
been
part
of
our
potential
future
strategy,
but
one
of
the
things
I
thought
could
hold
back
adoption
of
the
future.
So
it
was
just
interesting
to
see
that
people
actually
wanted
this
and
they're
making
some
good
points
in
the
issue
on
why
they
would
want
it.
A
A
For
that
you
know
if,
if
we
do
end
up
either
requiring
merge
requests
or
making
it
like
our
default
and
then
you
have
to
turn
them
off
or
something
like
that,
maybe
we'd
actually
make
people
happier
and,
and
maybe
the
the
you
know,
the
underlying
mental
model
will
be
more
aligned
with
our
other
repositories
and
and
standard
feature
sets.
So
I
don't
know
just
some
something
I
came
across
today.
I
thought
I'd
bring
up.
B
B
I
surfaced
it
out
too
much,
because
I
really
like
this
idea
and
like
I
have
some
thoughts
about
how
this
could
work,
and
I
bet
you
do
too,
because
you
probably
read
it
more
than
I
have
where's
the
best
place
to
like
put
some
of
these
things,
because
the
issue
itself
this
this
one
that
you
linked
in
the
four
year
old
one
is
like
there's
lots
of
external
eyes
on
it,
and
I
just
wanted
to
like
send
check
stuff
with
you
before
I
put
stuff
in
there.
A
It's
a
good
question-
and
I
mentioned
before
we
hit
record
that
I
was
trying
out
notion
again
and
actually
this
was
one
of
the
things
that
I
was
trying
to
gather
my
thoughts
around
and
and
kind
of
map
out
a
little
internal
knowledge
base
for
our
potential
knowledge
based
product.
But,
like
the
I
guess,
my
my
gut
reaction
would
have
been
create
a
private
issue
and
we
can
collaborate
on
that
async.
But
that's
probably
against
our
transparency
values.
I
don't
think
that
there's
any
reason.
A
We
can't
be
transparent
about
the
fact
that
we're
thinking
about
this,
so
maybe
in
the
wiki
epic,
the
wiki
category
strategy,
epic.
We
should
just
create
an
issue
and
and
say
like
we're,
gonna.
A
A
B
B
A
A
Yeah
yeah,
I
have
a
lot
of
thoughts
and
I
I
think
it's
time
to
start
consolidating
them
and
vetting
them
a
little
bit,
but
I'm
not
sure
I'm
not
sure
the
best
format
without
committing
to
it
right
like
well.
I'm
still
not
sure
we're
going
to
do
this,
so
it's
not
like.
We
want
to
write
implementation
issues
or
anything.
A
And
for
for
context,
catherine
and
anybody
else,
who's
watching.
This
is
all
just
related
off
of
an
ongoing
conversation.
We've
been
having
about
the
future
of
wiki
and
how
it
relates
and
overlaps
with
the
strategy
that
we
had
for
static
site
editor.
What
types
of
projects
were
going
to
benefit
from
the
static
site
editor?
What
makes
them
different
from
a
wiki
and
knowing
now
we're
getting
some
hard
data
and
we
have
to
validate
and
make
sure
we're
counting
correctly.
A
But
you
know
we're
getting
a
sense
that
the
wiki
is
actually
more
widely
used
than
we
thought,
and
maybe
we
could
invest
in
the
future
of
wiki
and
and
sort
of
combine
our
strategies
together
to
like
have
some
knowledge
based
type
product.
That
is
a
little
more,
a
little
more
aligned
to
our
tool
set
in
that
it's
based
on,
like
an
actual
repository
with
a
pipeline
and
merge
requests
and
it's
generated
from
static
files
using
a
static
site
generator.
A
And
then
our
rich
text
editor
could
be
put
on
top
of
that
and
we'd
get
very
close
to
what
our
ultimate
goal
was
for
the
static
site
editor,
but
also
be
able
to
maybe
convert
a
large
portion
of
the
wiki
users
over
to
that
product.
So
that's
the
general
hypothesis,
but
it
needs
to
be
validated
in
so
many
ways
before
we.
A
But
I
listed
some
of
the
other
priorities
that
we
have,
or
I
have
over
the
next
few
milestones.
The
number
one
is
is
working
on
the
mvc
for
the
rich
text
editor.
So
we
are
starting
that
in
1310
and
I
hope
in
the
next
three
milestones
we'll
have
an
mvc
in
the
wiki.
It
might
be
behind
a
feature
flag.
It
might
not
be
fully.
A
You
know
ready
for
production
work
or
you
know,
it'll
be
limited
in
some
way,
but
that's
a
that's
a
major
priority
for
us.
I
think
that's
a
strategic
initiative
for
the
whole
group
and
we'll
we'll
probably
be
moving
as
fast
as
we
can
on
that
and
similarly,
we
just
finished
working
on
changing
that
web
ide.
So
it
uses
editor
lite,
which
is
the
underlying
code
editor
now
for
snippets
single
file
editor
and
web
ide.
A
So
we
want
to
continue
to
extend
that
implementation
and
start
like
adding
extensions
to
editor
light
that
make
all
three
of
those
categories
better.
So
one
example
we
had,
I
think,
on
the
backlog
would
be
like
or
actually
I'll
give
an
example.
That's
not
on
the
backlog,
because
it's
easier
to
wrap.
My
head
around,
but
an
example
that
is
possible
now
would
be
our
security
scanning
features,
output,
a
flat
file.
A
We
could
write
an
extension
that
takes
that
flat
file
and
then
decorates
the
lines
of
the
code
that
are
problematic
with
from
the
security
scan.
So
we
could
say
you
know
the
the
code
quality
report
shows
that
this
this
line,
or
these
lines
are
potential
vulnerabilities
and
badge
them
in
the
web
ide
and
in
single
file
editor
with
only
having
to
do
the
work
more
or
less
once
you
know,
because
we
would
extend
the
same
editor
to
do
that.
So
that's
an
example
of
what
we
could
be
doing.
A
I
don't
think
that
one
is
going
to
happen
this
quarter,
but
it's
extensions
like
that
that
we
would
be
working
on
and
then
there's
some
performance
and
sort
of
reliability.
Ux
work
on
the
web,
ide
that
I
want
to
see
carried
forward
over
the
next
quarter.
I
think
that
aligns
with
our
quarterly
goals
as
a
company
and
our
okr,
so
we're
just
going
to
try
and
keep
moving
on
that,
making
it
a
little
more
delightful
and
a
little
more
streamlined.
A
And
the
settings
and
nav
priorities
are
the
the
top
menu
that
nav
are
consolidating
those
three
menus
into
one
and
finding
a
really
good.
A
A
So
that's
that's
probably
the
number
one
priority
for
me
on
settings
in
nav
and
then
the
other
ones
like
redesigning
and
reorganizing
the
left
navigation
to
be
a
little
more
intuitive
and
something
that
michael,
is
just
noting
in
the
agenda
and
also
is
a
hot
topic.
The
like
reorganization
of
the
idea
for
landing
pages
and
whether
or
not
there's
a
top
level
link-
and
you
know
consolidating
the
experience.
A
There
is
a
huge
priority
and
just
in
general,
improving
the
settings
organization
and
picking
a
I
would
say,
a
priority
is
picking
a
direction
between
whether
we
have
a
single
consolidated
settings
view
versus
contextual
settings
like
spread
out
throughout
the
left,
nav
or
within
the
product
itself.
I
don't
think
we
I
don't
think
we
would
be
able
to
in
the
next
few
milestones
completely
implement
whatever
changes
we
would
want
to
to
make
there.
A
But
I
do
think
michael
was
just
reviewing
a
proposal
with
us
yesterday
to
just
like,
take
a
little
step
towards
that
and
and
start
figuring
out
whether
moving
settings
in
context
with
the
features
themselves
in
the
left.
Nav
would
be
an
improvement
that
we
would
want
to
make
so
finding
a
way
to
iterate
towards
a
decision
there
in
the
next
few
milestones
is
definitely
a
priority
yeah.
C
I
know
right
it
I'm
sure
it's
probably
difficult
to
do
a
timeline
for
most
of
these,
but
I'm
curious
with
the
effort
to
combine
the
top
nav
menus.
So
I
guess
the
work
is
beginning
in
1310.
Do
you
have
like
an
estimate
of
when
it
might
like
actually
launch
or
be
live
in
production.
A
A
C
C
I'm
not
sure
what
would
be
most
useful
to
you
or
something
that
you
want
to
share
with
leadership.
But
those
are
just
some
things
that
you
can
think
about
and
we
can
plan
a
study
for
it
that
could
either
occur
before
it
launches
or
kind
of
like
before
and
after
over
time.
We
kind
of
think
about
what
the
goals
are.
There.
A
Definitely-
and
I
think
that
having
a
baseline
is
going
to
be
important
to
measure
improvement,
I
was
kind
of
just
thinking
right.
You
know
at
the
very
least
some
of
the
the
research
that
michael
already
completed
in
the
validation
of
this.
A
A
Anyway,
yeah
we
should
come
up
with
a
little
more
concrete
measurements
and
make
sure
we
have
a
baseline
and
at
least
some
existing
research
around
it
and
then
measure
after
it's
done,
so
that
we
can
show
that
it
was
an
improvement
or,
if.
C
C
Yeah
we
do
have
some
research
on
the
existing
experience,
but
probably
doesn't
cover
the
full
scope
of
everything
that
we're
changing
with
the
consolidation.
So
we
might
want
to
do
additional
research
to
kind
of
cover
the
the
full
scope
of
everything
as
a
baseline,
but
we
do
have
kind
of
like
some
some
tasks
that
users
were
completing
related
to
adding
a
new
group
or
looking
for
what
are
some
of
the
other
actions
there
exploring
projects
or
things
like
that.
So
we
do
have
some
data
on
their
success
rate.
A
Yeah
and
I'll
I'll
give
that
a
little
more
thought
and
put
really
our
success
criteria
I'll
make
sure
that's
captured
in
the
epic,
and
we
can
work
on
work
on
that
together,
work
on
a
script
for
for
testing,
and
then
you
know
along
the
way,
we'll
we'll
figure
out
what
the
level
of
effort
is
and
and
when
we'd
be
targeting
this
for
completion
and
then
we'll
take
it
from.
C
B
I'll
go
because
my
points
are
pretty
quick
and
now
I'll.
Let
catherine
finish
off
this
show,
but
on
my
side
just
to
address
some
of
the
points
that
eric's
already
been
talking
about.
Mine
is
all
mostly
around
the
left,
nav
and.
B
Interaction
questions
around
the
left
nav
by
clicking
on
the
titles
and
how
they
click
on
which
page
they
land
on
things
like
that.
So
that's
been
my
focus
for
this
week
and
probably
for
the
early
next
week
as
well,
so
I
should
land
on
some
decisions
there
and
these
decisions
are
interesting
because
it's
not
really
so
much
something
new
we're
introducing
it's
more
like
just
coming
and
aligning
and
making
a
decision
on
which
direction
we
want
to
move
forward
with
so
I'll
link
you
all
on
it
and
I'll.
B
I
don't
think
we
need
to
solution
validate
them
because
they're
already
there
in
the
world,
but
it's
it,
might
be
good
just
to
get
kick
the
tires
and
perhaps-
and
there
might
be
some
points
in
the
in
the
direction
that
you
feel
like
there's
not
enough
confidence
and
yeah.
We
can
take
that
forth
for
solution,
validation
if
needed
be,
but
yeah.
That's
on
my
side.
C
Sounds
good
so
then
yeah
and
then
on
my
side.
I
just
put-
I
guess
I'll,
go
with
my
second
point
that
right
now,
I'm
currently
in
the
phase
of
wrapping
up
the
analysis
of
like
the
navigation,
design
and
information
architecture
of
competitor
and
similar
products,
so
I'll
be
creating
an
issue
that
kind
of
walks
through
the
structures
and
the
design
patterns
that
I
see
in
similar
products,
and
then
I'm
also
working
on
creating
issues
for
recommended
improvements
and
so
a
lot.
C
Some
of
these
will
be
broader
explorations
and
probably
follow-up
research,
while
others
might
be
more
specific
changes
because,
basically,
at
a
high
level,
what
we
learned
from
a
lot
of
the
benchmarking
research
and
the
test
data
and
other
survey.
Data
is
kind
of
like
some
main
points
around
one,
managing
the
amount
of
information
that's
being
shared
with
users.
C
So,
like
the
overwhelming
amount
of
items
in
the
left,
sidebar
and
figuring
out
where
to
go
next,
those
sort
of
things
around
wayfinding
and
then
also
the
way
that
we're
communicating
and
organizing
the
information
so
making
that
clear
to
our
users
and
make
sure
that
it
aligns
with
their
mental
models.
And
we
saw
the
most
problems
with
this
with
analytics
settings
and
operations.
C
So
I
just
listed
some
things
that
I'm
thinking
about
underneath
my
point
and
I'll
just
kind
of
continue
to
flush
it
out
and
create
issues
and
then
probably
put
them
in
an
epic
or
we
have
a
couple
epics
floating
around.
Actually
that's
making
it
a
little
bit
tricky
I'll,
choose
one
of
those
ethics
and
add
the
issues
there,
but
you'll
also
notice
that
some
of
them
have
already
been
taken
on
by
other
groups.
B
It's
not
a
real
point,
it's
more
like
a
read-only
point
like,
like
I
said,
some
of
these
things
overlap
with
some
of
the
work
that
I'm
looking
at.
It
actually
makes
a
lot
of
my
stuff
easier,
so.
C
I
think
we're
going
to
have
a
lot
of
collaboration
opportunities,
because
one
thing
that
has
been
really
challenging
in
even
just
some
of
the
reviews
of
other
sites
that
I've
done
so
far
is
like
the
scope
of
the
content
that
we
have
on
gitlab.
It
makes
it
very
difficult
to
balance
not
having
too
many
menu
items,
but
also
not
having
really
broad
vague
categories.
C
So
that's
something
that
I
think
I
need
to
dig
deeper
into
in
terms
of
the
competitor
analysis,
but
also
understanding
how
other
touch
points
can
help
with
this.
Like
does
the
home
page
alleviate
some
of
that?
The
way
we
organize
content
on
the
home
page
and
where
people
go
from
there
and
then
there's
kind
of
like
a
standard
set
of
things
in
the
left,
sidebar
that
people
need
to
access
more
frequently
are
just
some
of
the
things
I'm
starting
to
think
about.
B
C
C
Yeah,
so
that's
definitely
an
interesting
one,
because
I
I
did
a
card
sort
and
honestly
the
cards
were
almost
led
to
more
confusion,
because
there
was
so
much
variation
in
in
how
people
were
organizing
the
content.
I
was
like
this
right
here
with
the
problem,
all
the
variations
in
their
expectations,
but
the
activity
feed
wasn't
really
strongly
grouped
with
anything.
C
So
I
definitely
think
it
doesn't
necessarily
need
to
live
under
the
project
overview,
but
I'm
not
sure
where
else
on
that
left
side
where
it
would
live.
It's
like
most
associated
with
the
project
overview
out
of
really
all
the
other
items,
but
it's
still
kind
of
its
own
standalone
thing.
It's
a
it's
a
tricky
one,
but
I'm
wondering-
and
I
left
a
comment
I
think
on
your
issue-
that's
around
simplifying
the
navigation
of
the
was
it
the
project
overview
details
and
the
group.
The
project
name
thing
on
the
group
landing
page.
C
B
C
B
Yeah,
the
page
would
still
live
within
the
thing,
but
it's
just
like
an
access
point,
so
the
access
point
is
through
again
at
the
top,
and
then
there
could
be
a
button
on
that
widget,
I'm
just
going
to
call
it
a
widget
for
now
that
takes
you
to
like
the
details,
activity
page
for
that
project.
That
could
be
one
path.
Yeah,
it's
worth
exploring.
C
Yeah
yeah,
that's
what
that's
what
came
to
mind
today.
The
one
on
the
group
overview
page
is
very,
what's
the
word,
I
don't
know
very
high
level
or
perhaps
not
the
events
that
would
be
most
relevant
in
a
project,
but
that's
also
something
we
could
do
validation
around
and
explore
what
users
kind
of
are
wanting
to
see
on
a
project
overview
page
and
a
broader
effort
around
improving
that
page.
But
I
think
there
are
some
opportunities
there.
C
Another
opportunity,
I
think,
is
potentially
reimagining
the
way
that
we
display
the
project
files
on
that
overview
page.
I
don't
know
if
it's
potentially
a
collapsed
section
or
something
like
that,
but
I
feel
like
a
lot
of
the
real
estate
is
going
towards
files
right
now
well
in
projects
that
have
a
lot
of
files.
B
C
A
A
I
think,
honestly,
the
the
iterative
changes
between
what
michael's
proposing
and
the
issues
that
that
he
listed
with
just
cleaning
up
the
uli
and
some
of
the
patterns
on
the
left,
nav
and
just
like
the
work,
you're
researching
and
the
other
groups
are
already
doing
to
kind
of
rearrange.
C
Yeah,
because
from
what
I
saw
in
a
lot
of
the
card,
sorting
data
and
tree
testing
data-
is
that,
as
you
might
expect-
or
maybe
not
things
like-
merge
requests
with
wiki
issue
boards
they're
like
they're,
easily
findable,
the
names
are
strongly
associated
with
the
content
and
they
they
work.
C
We
could
have
an
optimal
ia,
but
I
also
think,
for
the
sake
of
you,
know,
keeping
things
in
place
and
where
people
expect
to
find
them.
Currently,
it
might
be
fine
to
just
keep
them
the
way
they
are,
but
we
did
see
analytics
operations
and
settings
those
kind
of
like
hot
spots,
where
there
was
a
lot,
a
lot
more
confusion
and
lower
success
rates.
So
those
are
areas
to
do
a
lot
more
exploration.
A
Cool,
well,
that's
it
for
the
agenda.
I
don't
have
anything
additional
michael.
You
have
any
other
closing
thoughts.
A
Cool
well,
as
always
great,
to
see
you
both
and
see
you
next
week
enjoy
your
fridays
off.