►
From YouTube: Editor Group Monthly - 2021-01-14
Description
Monthly meeting of the Create:Editor group
A
Hello,
everyone-
it
is
january
14th,
and
this
is
the
editor
group
monthly
meeting.
So
diving
in
I
dropped
a
few
direction
item
updates.
I
figured
we'd
just
go
through
the
agenda
and
some
of
them
I
already
know
the
answers
to,
but
I
just
figured
I'd
give
a
chance
for
you
know
you
to
address
the
whole
group
and
give
updates
paul.
I
had
a
couple
firsts
for
you
if
you
wanted
to
run
through
them.
B
A
There
yeah
and
for
the
record,
slipping
because
of
that
dependency
is
not
a
big
deal.
I
just
need
to
know
for
release
post
writing
so
I'll
push
that
out
to
next
release
and
we'll
monitor
the
infrastructure
issue
closely
and
yeah.
If
anything,
we
can
do
to
help
move
that
along.
That
would
be
great.
Let
me
know
if
there's
any
people
I
need
to
to
bother
on
slack
or
something.
B
Yeah,
I'll
probably
be
you
know,
pinging
them
once
a
week
which
sounds
like
it's
a
you
know,
just
acceptable
level
of
nagging
so
and
then
the
next
issue
about
the
web
id
is
showing
a
warning
message.
When
user
opens
id
and
can't
push
code,
I
saw
the
comment
you
left
on
the
issue
that
so
currently
the
way
the
issue
is
written.
B
B
Users
may
be
able
to
push
code,
but
it
has
to
be
a
signed
commit
and
the
web
ide
will
not
sign
your
commits.
So
that
would
be
problematic
and
then
I
would
imagine
there's
another
a
number
of
other
business
use
cases
we
may
have
where
the
user
can
push
code,
but
maybe
can't
still
use
the
web
id
or
something.
So
that
is
a
bit
of
scope.
Change,
that's
not
going
to
affect
the
original
proposal.
B
I
don't
think
it's
going
to
be
handled
by
the
condition
we're
checking
for
the
way
this
is
originally
implemented,
but
I'm
going
to
double
check
that
scenario
since
you
brought
it
up
and
I'll
check
it
today
and
leave
an
update
on
that
comment.
So
if,
for
that
specific
scenario,
it
should
be
a
quickish
fix,
but
I
imagine
it
won't.
It
won't
be
in
the
13.8
release,
but
we
might
not
have
to
create
a
whole
separate
issue
for
it.
B
A
Thank
you.
I
I
came
across
that
and,
as
I
mentioned
in
the
agenda,
as
were
having
that
discussion,
I
remembered
that
we
had
had
slated
that
small
improvement
and
and
hoped
that
maybe
we
could
mimic
the
behavior
at
least,
if
not
have
the
same.
You
know
code
path
solve
for
both
problems,
but
yeah.
Please
keep
me
updated,
I
don't
mind
making
another
issue
and
doing
it
later,
but
if
it
is
something
you
can
just
knock
out
while
you're
in
there,
then
certainly,
let
me
know
cool.
C
C
C
So
technically
we
trimmed
down
the
the
implementation
of
the
editor
for
led
wrapped
it
into
the
editor
light
extension,
and
now
we
have
performance
boost
as
well
like
between
14
and
25,
on
the
page
load
on
the
editor
web
id
load
and
the
implementation
work
that
has
to
follow
this
poc
with
real
tests,
and
things
like
this
has
been
planned
and
linked
to
the
original
issue.
Most
of
those
issues
are
assigned
for
13.9
and
some
preparation
work
has
been
merged
right
now
in
13.8,
so
yeah
we
are
doing
good
there.
C
C
That's
that
was
like,
I
didn't
expect
it
either.
I
had
a
hope,
because
not
because
editor
light
is
so
much
more
much
more
performant
than
the
original
web
id
implementation
is,
but
simply
because
I
I've
spent
some
time
digging
into
what
we
do
in
web.
Ids
editor
implementation
and
found
a
lot
of
things
that
technically,
like
we
create
huge
objects
that
we
do
not
use
really.
So
we
just
consume
a
lot
of
memory
for
things
that
that
are
not
used
anymore.
C
I
I
assumed
these
were
the
artifacts
from
like
the
very
very
first
implementations
of
the
editor,
so
it
was
a
really
nice
feeling
to
just
get
rid
of
those
and
still
see
the
things
working
fine.
So
that's
that's
the
main
thing
like
we
do
not
create
large
objects
that
we
not
use.
That's
the
main
cause
of
the
performance
boost,
I
guess,
but
otherwise
it's
still
the
same
monaco
under
the
hood.
A
D
Hey
so
my
internet's
been
a
little
bit
flaky,
so
let
me
know
if
I'm
turning
into
a
robot,
so
yeah
spam
spam
spam
spam.
The
this
is
one
of
those
pulling
a
thread
on
this
sweater
thing
and
early
on.
You
know
I
talked
to
to
charlie
about
it
and
on
the
back
end,
and
she
like
set
the
the
stage
for
it,
because
when
I
picked
up
this
issue,
it
was
like
what
what
do
we
even
need
to
do
here.
D
It's
really
unclear
and
I
spent
a
lot
of
the
holidays
just
trying
to
wrap
my
head
around
where
all
this
code
is-
and
she
said-
oh
yeah,
this,
this
stuff
is
still
not
in
good
shape.
It's
so
all
over
the
place.
It's
good
that
you're
continuing
these
three
factors,
so
the
status
of
it
is
the
proof
of
concept,
is,
is
done
it.
It
works.
D
Friends,
been
giving
lots
of
good
comments
on
the
specific
to
the
the
snippets
back
in
implementation,
but
that's
good
and
paul
helped
me
a
lot
with
the
front-end
view,
implementation
and
I
think,
that's
really
in
a
good
spot.
It's
very
it's
modern.
It
uses
the
native
javascript
capture
api.
It
uses
pajamas,
it's
pretty
clean,
but
trying
to
clean
up
the
back
end.
It's
basically
a
ton
of
of
legacy
code
death.
That's
coupled
to
the
old
rest
controller,
centric
implementation
that
issues
still
use,
but
both
it
and
snippets
have.
D
Even
though
it's
still
unrest,
they
move
forward
to
a
view
world
and
most
of
that
code,
I
think,
is
not
needed
and
could
be
moved
over
to
this
modern
approach,
even
with
the
still
rest
implementation
and,
as
you
can
see
in
the
dock
there,
as
I'm
exploring
this
there's
some
really
concerning
things
that
I'm
finding
that
in
my
list
of
heuristics
that
I
go
through
in
my
head,
like
is
this
code
that
I
care
about.
Is
this
something
I
really
needs
to
be
refactored?
It's
like.
D
Is
this
going
to
get
used
in
other
places
in
the
app
does
this
have
security
implications
like
all
of
those
things
are
like?
Yes,
so
I'm
taking
the
time
to
refactor
this
and
with
darva
yesterday
and
of
course,
when
roman
comes
back,
I'm
going
to
say:
hey,
I'm
going
deep
on
cleaning
up
a
lot
of
this
stuff.
D
Now
that
I
can
see
what
needs
to
be
done
and
then
also
one
of
the
files
I
was
working
on,
I
was
just
having
to
look
at
the
history
and
there's
like
an
actual
page
in
the
docs
that
is
about,
like
instance,
variable
cop
that
and
this
cop
is
disabled
and
in
our
live
docs.
It
points
to
this
piece
of
code
and
says
this
is
bad.
It
really
should
be
cleaned
up
and
I'm
like
yeah.
Probably
I
should
do
that
before.
I
start
refactoring
it
further,
so
it's
just
more
pulling
a
thread.
D
So
that's
where
this
is.
As
I
said,
the
poc
is
done
and
I
could
say:
okay,
I'm
just
gonna
ram
that
in
put
some
minimal
test
coverage
and
call
it
done
or
I
could
say
it
took
me
a
good
week
and
a
half
two
weeks
to
wrap
my
head
around
this
stuff.
I'm
gonna
make
it
better
and
try
to
kill
off
a
lot
of
code
debt.
D
So
that's
what
I'm
leaning
towards
now
and
aside
from
that,
there's
still
this
just
dribbling
of
dri
stuff,
like
the
ongoing
timeouts
on
about
gitlab.com
and
there's
movement
from
sid
and
on
down,
if
they're
off
site
of
getting
somebody
else
to
take
that
over.
But
that's
not
a
ton
of
time.
But
it's
also
for
me
personally
getting
interrupted
and
dealing
with
that
stuff,
really
messes
with
my
ability
to
get
into
flow
and
deep
work,
which
I
I
have
to
do
trying
to
wrap
my
head
around
these
three
factors.
D
E
So
we
we
delivered
the
the
small
proof
of
concept
of
searching
inside
the
the
project
settings
general
page,
so
this
was
implemented
as
a
reusable
component
of
your
component
that
we
can
easily
include
in
the
other
settings
pages.
So
yesterday
I
organized
with
the
help
of
eric
some
epics
with
issues
to
integrate
that
component
into
other
settings
pages.
So
yeah,
that's
that's
about
it.
A
Thanks
for
creating
all
those
issues
by
the
way,
they're
gonna
be
very
helpful
for
tracking
the
work
and
it
was
a
lot
of
them,
but
then
we
have
a
lot
of
setting
fees.
I'm
I'm
looking
forward
to
this.
The
goal
would
be
to
try
and
get
as
many
of
these
as
we
can
in
13.9,
given
how
relatively
straightforward
it
is
to
add
them
on
the
page.
A
I
was
looking
at
it
and
I
was
trying
to
think
if
it's
worth
me
even
trying
to
help
out
on
a
couple
just
still
to
learn
the
process,
but
I
I
don't
want
to
slow
anybody
down.
Luckily,
it
looks
like
we
can
sort
of
do
this
in
parallel
and
submit
mrs
for
one
or
many,
depending
on
what
you
want
to
pick
up.
A
F
F
I
am
dealing
with
the
same
issue
for
group
wikis.
The
problem
is
that,
even
though
we
can
reduce
a
lot
of
the
code
that
was
refactored
before
they
are
quite
specific
because
they
are
a
repository
container,
but
not
because
it's
really
the
wiki,
they
don't
have
a
repository.
So
we
cannot
really
extrapolate
directly
the
same
approach
that
we
have
with
with
projects,
for
example.
D
I
have
a
question
sure
so,
given
so
I
keep
hearing
these
themes
of
like
there's
the
the
main
you
know,
project
repositories,
but
then
there's
like
wikis
have
their
own
repository
and
snippets
have
their
own
repository,
and
that
came
up
yesterday
in
terms
of
like
the
the
editor
light
like.
How
do
we,
you
know,
have
it
work
the
same
way
across
these
things?
D
Is
there
like
a
larger
effort,
and
I
don't
have
any
context-
I've
just
seen
your
issues
go
by
to
like
make
a
a
different
facade
in
front
of
these,
where
it's
less
of
an
impact
that
they
are
different
repos
and
have
to
be
handled
one
off,
or
is
that
even
possible,
I'm
just
throwing
it
out
there?
I
don't
know.
F
The
problem
is
that
we
are
dealing
with
a
ton
of
legacy
code,
so,
for
example,
if
you
go
even
even
for
projects,
if
you
go
to
your
gdk
installation
repositories
directory,
you
will
see
that
there
you
have
a
directory
called
hash
in
that
hash
directory.
You
have
all
the
project,
all
the
yes
as
you,
you
will
have
several
directories.
Each
directory
represents
a
project
and
inside
each
directory
you
will
find
you
or
you
can
find
several
repositories
you
can
find.
You
can
find
the
project
repository.
F
You
can
find
the
design
management
repository
and
also
the
wiki
repository
so
in
projects
in
the
wiki
container.
We
have
sorry
in
the
project
container.
We
have
three
kinds
of
repository
who
are
totally
independent
because,
depending
on
which
repository
you
are
accessing,
for
example,
we
have
even
different
policies
to
access
it
because
we
have
different
visibility
levels,
but
the
legacy
code
here
is
that
before
these
hash
directories
we
used
to
store
projects
by
their
path,
and
then
we
try
to
migrate
them.
But
still
we
have
to
support
this
whole
system.
F
We've
got
because
we
still
have
clients
that
has
this
whole
system.
So
it's
not
really
intuitive
and
there
are
also
several
representations
of
this
of
these
repositories.
For
example,
to
give
you
a
bigger
picture
so
projects
the
project
directory
inside
the
product
directory,
you
will
find
the
project
repository
the
design
management
repository
and
the
wiki
repository
okay
for
snippets
each
snippet,
each
snippet
directory,
which
is
stored
in
a
different
place
than
than
projects.
It's
each
snippet
only
have
one
repository.
F
It
doesn't
matter
if
the
snippet
is
a
personal
snippet
or
a
project
snippet,
it
only
has
one
repository
and
now
we
recently
or
the
former
knowledge
team
implemented
group,
wikis
and
group
wikis
are
following
the
former
approach.
So
in
your,
if
you
create
a
group
wiki
in
the
repositories
directory,
you
will
find
a
directory
called
groups,
so
that
group
directory
is
intended
to
store
the
wiki
directory
and
any
other
repository
attached
to
groups.
F
D
F
Important
important
repositories-
and
you
have
to
deal
also
with
the
scenario
where
those
repositories
belong,
to
really
big
companies
that
doesn't
stop
at
all
working
so
because
they
have
used,
they
have
employees
working
different
time
so
so
that
migration
can
be
quite
troublesome.
So
it's
really
hard
to
find
avacade.
D
F
D
Yeah,
which
is
what
I'm
trying
to
do
for
the
the
spam
related
stuff,
because
I'm
thinking
we're
going
to
want
to
use
this
in
other
areas
of
the
app
eventually
like
this
is
something
that
we
want
to
clean
up
and
make
it
not
take
two
weeks
of
staring
at
the
code,
at
least
for
me,
to
start
to
wrap
my
head
around.
It.
F
No
yeah,
I
mean,
I
think,
you're
doing
great,
because
I
don't,
as
I
I
told
you
in
a
comment.
I
hate
that
we
introduce
concerns
or
modules
that
depends
on
objects
that
are
already
defined
in
the
context
or
because
you
cannot
really
move
them
straight
forward
because
they
are
dependent
of
the
context.
So
I
think
it's
great
that
kind
of
refactor.
A
Okay,
well,
thanks
for
all
the
updates,
I
want
to
keep
mine
short,
which
I
said
last
time
and
then
used
up
all
the
time,
but
I
just
want
to
give
one
strategic
product
update
on
the
rich
text
editor,
mostly
because
we
just
had
a
really
great
review
of
our
opportunity
canvas
on
monday
and
it
went
really
well.
We
got
some
great
feedback
from
the
design
and
product
leadership
and
not
that
that's
really
a
way
to
get
formal
approval
like
we
have.
A
It's
not
just
for
static
site
editor
and,
in
fact,
as
the
as
the
note
in
the
agenda
mentions,
the
the
strategy
I
would
like
to
take
is
not
to
worry
too
much
about
static
site
editor
in
the
near
future,
at
least
like
maybe
this
quarter
right.
So
I
think
our
our
primary
goal
right
now
is
to
get
the
foundations
in
place
and
potentially
start
with
wikis,
although
that
is
open
to
discussion.
If
anybody
has
strong
feelings
that
it
would
be
easier
or
quicker
or
more
valuable
to
do
it
elsewhere.
A
My
my
feeling
is
that
wikis
are
they
have
enough
users
that
we
will
be
able
to
get
feedback
quickly?
The
use
case
is
slightly
more
narrow
as
far
as
editing
and
committing
markdown
changes
within
the
wiki
format,
and
it
certainly
would
be
something
that
wiki
users
could
derive
value
from
and
have
been
asking
for
for
a
long
time.
So,
while
we're
not
charged
as
a
group
to
invest
heavily
in
wiki
right
now,
it
does
seem
like
the
best
playground
for
us
to
to
test
this
mvc.
D
A
Exactly
and
I
I
feel
like
it's
also
going
to
be
less
disruptive
to
users.
If
there
are
rough
edges
right
like
we
can
put
it
behind
a
feature
flag
and
then
we
can
roll
it
out
and
then
people
could
you
know
we
can
default
it
to
not
be.
We
can
make
it
not
the
default
at
first
and
people
can
opt
into
it
or
something
like
that.
We'll
figure
out
the
deployment
strategy,
but
the
the
wiki
seems
like
a
great
place
to
start,
knowing
that
we
would
likely
move
towards.
A
Monthly,
active
users
right
now
is
that
there
would
be
a
not
insignificant
amount
of
work
to
reach
feature
parity
with
the
current
static
site
editor
after
implementing
the
editor
itself.
So
we've
built
a
few
features
into
the
static
site,
editor
that
we
would
have
to
replicate
or
port
over
and
even
a
milestone
or
two
of
that
to
slow
us
down
from
getting
feedback
is
probably
not
worth
it.
Ultimately,
this
editor
is
the
path
for
the
static
site
editor
to
gain
adoption
and
to
grow
outside
of
just
supporting
middleman.
A
A
Going
back
to
the
agenda
to
make
sure
I'd
hit
all
my
points,
so
I
talked
to
roman
about
this.
I
want
to
carve
out
some
time
in
the
upcoming
milestone
to
get
our
real
iteration
plan,
our
deployment
strategy,
ethics
and
issues
all
nice
and
organized,
and
so
that
we
can
start
writing
the
first
real,
mrs
in
1310,
I'm
not
going
to
hold
anybody
right
now
to
estimates
on
we
haven't
committed
to
when
it
would
ship
or
anything
like
that.
But
we'd
like
to
you
know,
move
pretty
fast.
A
I
think
it'll
be
one
of
our
top
priorities.
As
a
group
over
the
next
quarter,
we
will
still
have
to
balance
settings
and
navigation
work,
probably
still
about
half
of
our
time
on
that
and
all
of
our
other
categories
or
will
not
be
forgotten.
But
this
is
one
of
the
more
important
strategic
efforts
over
the
next
few
few
months,
a
few
milestones
and
yeah.
I
I
don't
know
questions
about
that
or
are
any
any
other
comments
related
to
moving
forward
with
it.
E
I
I
fully
support
the
day
of
using
the
the
wikis
as
an
entry
point,
and
I
think
that,
given
that
the
issue
description
and
nursing
course
description,
pictures
are
not
part
of
our
stage,
it's
probably
a
great
idea
to
start
building
a
rich
taxator
that
already
supports
the
good
luck.
Flavor
markdown
before
we
start
suggesting
other
stages
to
adopt
the
rich
text,
editor
yeah,
I
I
left
a
link
to
the
gitlab
flavor
markdown
documentation.
D
To
enrique's
point
not
focusing
on
the
static
side
of
the
editor,
and
instead
focusing
on
that
eliminates
a
lot
of
other
areas
of
complexity.
We
have
like
it's
not
get
lab,
flavor
markdown
the
whole.
You
know
it's
a
jam
stack.
We
have
external
users
using
different
static,
static
site,
editor
or
deploy
tools.
A
Yeah
and
I'd
also
say
that
you
know
the
the
as
opportunities
to
extend
into
our
other
categories,
show
up
like
if
it
makes
sense
to
allow
people
when
they're
editing
a
markdown
snippet
to
use
this
or
opt
into
it
or
default
to
it.
I
think
we
could
explore
that
yeah.
I
think
I
think
the
the
static
site
editor
will
will
come
in
time,
but
we
need
to
get
a
good
foundation
for
the
just
the
editor
itself.
First,
and
this.
A
Yeah,
I
don't
think
anybody's
disagree,
so
we
don't
need
to
belabor
that
point,
but
yeah,
I'm
I'm
very
excited
about
this
and
I'll
link
to
the
opportunity
canvas
if
you
didn't
get
a
chance
to
review
it.
It's
kind
of
you
know
a
lot
of
product,
easy
stuff
and
strategy
related,
but
it
it
it
kind
of
puts
some
it
kind
of
quantifies.
A
A
C
C
So,
yes,
paul
made
the
really
good
point
about
people
willing
to
edit
the
things
while
they
are
reviewing
the
emerge
request,
and
this
is
exactly
what
we
discussed
yesterday
during
the
backlog
refinement
session.
So,
yes,
we
are
aware
of
that
and
we'll
just
keep
this
in
mind
and
as
like,
as
yesterday
as
mentioned
yesterday,
as
the
very
first
step,
we
can
just
start
with
hiding
those
tabs
like
when
you're,
because
our
url
already
tells
us
whether
we
are
reviewing
or
we
are
editing.
The
things
oh
thank
you
thank
you
eric,
so.
C
So
we
are,
we,
we
are
able
to
identify
whether
we
are
in
the
mr
view
mode
or
we
are
in
the
edit
mode.
So
when
we
are
in
the
edit
mode,
we
are,
we
just
hide
the
review
tab
and
when
we
are
reviewing
nmr,
we
hide
the
commit
tab
by
default,
but
since
the
state
is
still
there
once
the
user
goes
to
the
edit
tab
makes
the
change
and
we
identify
that
there
is
a
change.
We
do
show
the
commit
tab
again.
C
C
So
it's
just
just
the
the
review
tab
now
when
you're
editing
is
completely
broken
it
just
it's
just
not
usable
at
all
the
same
thing.
If,
unless
you
do
changes,
unless
you
make
changes
while
reviewing
nmr
the
commit
tab
and
the
whole
commit
button,
make
no
sense
at
all,
so
those
things
would
just
not
loading
those
by
default.
In
these
two
scenario,
scenarios
will
first
of
all
improve
the
performance.
It
will
improve
the
user
experience
in
my
opinion
so
that
that's
an
interesting
thing
to
to
discuss.
I
guess
yeah,
do
we
have
any
questions?
B
I'd
I'd
just
highlight
also
check
out
the
there's
an
earlier
issue
when
we
talked
about
this
some
months
ago,
check
out
issue
created
by
mike
nichols,
and
he
has.
He
has
a
different
proposal
too,
but
yes,
currently
us
having
two
file
trees
and
like
it
doesn't
make
sense
the
way
it
is
right
now,
but
we
would
want
to
make
sure
that
we
preserve
the
ability
to
to
view
diffs
and
view
mr
diffs
and
we've
talked
about
matches.
B
There's
other
comments
and
discussions.
We've
had
with
himachi
about,
like
being
able
to
like
right
click
on
a
file
and
say
view
diff
and
like
having
that
be
a
different
tab,
as
opposed
to
like
a
tab
on
the
actual
editor
pane,
like
you
would,
in
visual
studio
code
being
a
much
better
experience.
So,
yes,
I
think
anything
we
could
do
to
simplify.
B
C
C
So
once
we
switch
to
the
editor
light,
we
will
be
able
to
just
do
the
live
preview
or
like
to
do
even
live
div
preview
for
the
files,
while
you're
editing
or
doing
things
or
on
request
just
the
same
way
as
as
there
is
the
poc
of
live
preview
for
markdown
files
in
edited
light.
So
that's
going
to
be
like
we
will
be
able
to
provide
this
in
context
of
editing,
so
you're
editing
the
file
and
you
click.
Ok,
yeah.
I
want
to
see
the
div.
What
did
I
change
on
this
particular
file?
D
C
Technically,
yes,
when
we
hit
web
id,
we
have
the
the
id
router
sitting
and
dispatching
like
defining
whether
we
go
to
the
merch
request
review
mode
or
we
go
to
the
edit
mode
kind
of
thing.
So
we
know
what
scenario
we
are
following
early
on
in
the
process
so
based
on
that
we
can
set
in
any
flag
or
some
stay
store
state.
C
That
would
tell
us
what
elements
to
show
so
we
conditionally
show
and
hide
elements
on
the
page.
This
means
that
we
might
involve
the
conditional
loading
for
for
those
panels
conditional
loading
for
the
components
required
to
bootstrap
that
or
another
view.
So
that's
that's
technically
possible,
because
because
we
we
have
very
like
very
different
urls
for
merch
requests
for
you
and
for
editing
repository.
C
No
ideally,
obviously,
obviously
that's
that
shouldn't
be
the
case
like
the
only
thing
that
won't
be
available
to
the
users,
for
example,
when
they
edit
the
repository
files,
the
broken
review
tab
won't
be
available
to
them,
but
I
think
this
is
much
better
scenario
than
providing
this
for
you
and
it
does
nothing.
It
just
confuses
users.
B
H
C
B
No,
that
would
be
really
cool
thanks.
Thanks
for
resurrecting
the
the
discussion
dennis,
I
think
I
think
it's.
It
would
be
amazing
to
do
some,
some
bigger
cleanup
on
it
and
I
think
doing
that
would
even
make
it
more
attractive
to
more
users
being
like
okay.
This
looks
way
more
attractive
now,
and
that
sounds
exciting.
B
I
hardly
ever
see
community
contributions
for
editor
team
code
and
I'm
not
entirely
sure
where
that
why
that
is,
but
I
think
some
hypothesis
of
why
that
might
be
would
be
that
our
issues
may
lack
visibility.
Users
aren't
contributors,
aren't
seeing
them
or
the
issues
aren't
very
community
contributor,
friendly
or
community
contributors
start
picking
up
issues,
but
then
the
code's
not
friendly.
B
I
don't
think
it's
the
code's
not
friendly,
because
I
think
almost
most
of
gitlab
code
can
be
a
little
unfriendly,
but
community
contributors
still
contribute
to
it.
So
I
think
that
there's
something
to
gain
when
we
with
how
we
write
our
issues,
thinking
about
the
community
contributor
as
almost
the
primary
audience,
and
so
I'm
I
have
some
thoughts
in
this
I'm
going
to
create
an
issue
about
it,
but
I
want
to
bring
up
the
discussion
for
any
other
thoughts,
especially
because
my
perspective
is
certainly
limited.
D
I
think
it's
good
and
I
think
eric's
pushed
to
get
a
clear
hierarchy
of
epics
and
have
that
aligned
with
the
direction.
So
people
can
get
a
clear
view
of
like
where
does
this
fit
in
to
the
bigger
picture
and
know
where
they're
going,
even
though
the
code
is
always
going
to
be
the
state
that
it's
in
at
least
knowing
the
bigger
picture
will
help
people
be
more
approachable
to
it?.
A
B
I
kind
of
do
hope
this
does
too,
though,
is,
I
think
us?
Our
team
has
a
lot
of
context
for
like
oh,
we
want
to
do
this
thing
like
we
almost
already
know
where
it's
going
to
be,
but
I
hope
for
myself.
This
helps
me
like,
if
I'm
not
including
a
line
of
code
in
an
issue
like
like
I'm,
I'm
writing
an
issue,
probably
more
for
our
team,
which
I
think
is
an
anti-pattern
I'd.
B
Rather
do
the
investigation
include
some
lines
of
code
in
these
issues,
so
even
I
feel
like
we'd,
even
have
better
confidence
with
how
we
weight
things
and
when
we
weight
things,
it's
a
huge
disappointment
to
contribute
contributors
if
they
pick
up
a
weight
one
or
two
issue,
and
for
them
it's
actually
like
it's
a
weight
one
or
two
for
us,
because
we're
super
familiar
with
it,
but
for
them
like.
Maybe
it
was
you
know
they
just
discouraged
them
from
contributing
to
gay
lab
at
all.
B
E
I
don't
don't
have
hard
data
on
this,
but
a
pattern
that
I've
seen
in
community
contributions
is
that
users
are
usually
driven
or
motivated
to
make
a
community
contribution
when
they
use
a
picture,
or
they
really
really
desire
that
feature.
So
perhaps
something
that
we
could
do
is,
I
don't
know,
maybe
get
some
data.
What
are
they
the
features
that
they
really
want
and
organize
that
that
effort
in
a
way
that
they
they
could
contribute
in?
E
You
know,
in
small
improvements
or
in
an
incremental
way,
I'm
trying
to
understand
if
just
organizing
the
work
that
we
have
to
do
is
a
good
motivator,
for
you
know
any
community
contributor
to
just
say:
hey,
I
want
to
participate
on
this
or
we
have
to
to
provide
others
sort
of
you
know
or
try
to
understand
what
actually
is
what
what
is
driving
them
to
to
come
and
and
and
and
provide.
You
know
any
sort
of
value
to
the
application.
D
A
Thanks
for
bringing
this
up
paul,
I
think
the
just
to
bring
it
back
around
to
talking
about
the
rich
text
editor
and
our
growth
there.
I
think
my
impression
and-
and
my
hope
is
that
we'll
be
able
to
rely
pretty
heavily
on
our
community
contributions
once
that's
in
place
to
expand
the
the
reach
of
our
static
site
generator
to
support
other
syntaxes
and
static
site
editor
to
support
other
static
site
generators
and
syntaxes
same
thing
goes
for
the
wiki.
A
If
somebody
really
wants
ascii
doc
or
something
like
that,
and
and
we
build
it
in
a
way
that
they're
able
to
contribute
that
was
one
of
the
the
primary
goals
of
or
one
of
the
secondary
goals,
I
guess
of
our
of
our
architecture
was
building
in
a
way
that
we
can
lean
on
the
community
to
to
build
out
support
for
things
that
we
might
not
prioritize.
But
you
know
that
those
10
users
of
that
random
static
site
generator
that
are
really
passionate
about
it,
can
contribute
support.