►
Description
Don’t miss out! Join us at our upcoming hybrid event: KubeCon + CloudNativeCon North America 2022 from October 24-28 in Detroit (and online!). Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Sharing Knowledge: Writing Good Docs for Quick Approval - Jared Bhatti, Waymo
The goal of this talk is to increase your ability to write good documentation that gets approved quickly. Good documentation has a profound impact on the visibility, quality, and inclusivity of open source projects. Documentation creates a shared understanding of work, helps onboard new developers, and improves the overall quality and reliability of the project.
Based on Jared's experience leading Kubernetes SIG Docs from 2016 to 2020, this presentation walks developers through best practices for creating inclusive, accessible, high quality documentation in pull requests designed for quick approval. This demonstration includes how to structure documentation using content templates, write with clarity and technical accuracy, and avoid common pitfalls that trap PRs in prolonged reviews.
A
Hi
everyone,
my
name,
is
jared.
Welcome
to
valencia.
It's
really
nice
to
be
here.
The
last
time
I
was
at
a
kubecon
was
was
in
copenhagen,
so
it's
so
good
to
see
so
many
faces
here.
I'm
here
to
talk
about
sharing
knowledge,
writing
good
docs,
for
quick
review
and
for
folks
who
are
following
along.
I
posted
a
bitly
link,
it's
public,
it's
bitly,
slash!
A
A
I'm
a
software
engineer
by
training,
but
I've
been
a
technical
writer
for
almost
20
years
now
and
the
majority
of
that
has
been
at
google.
My
focus
primarily
has
been
on
open
source
documentation,
with
a
pretty
heavy
emphasis
on
kubernetes,
so
I
helped
lead
the
initial
kubernetes
docs
team.
I
was
one
of
the
first
docs
chairs
as
part
of
sig
docs
in
kubernetes,
and
I
hope
lead
that
group
for
about
five
years
up
to
about
20
20..
A
They
want
there
to
be
clear
processes
and
policies
for
documentation
and
it's
a
key
decision
making
factor
when
people
are
choosing
which
open
source
or
even
closed
source
project
they're
going
to
go
with
most
people,
most
developers
prefer
documentation
to
contacting
support
or
talking
to
an
actual
person.
They
want
content
that
they
can
search
that
they
can
understand
on
their
own
and
approach
at
their
own
pace,
and
most
developers
see
documentation
and
its
incompleteness
or
its
lack
of
existence
to
be
a
huge
problem
in
the
community.
A
So
I
want
to
talk
a
little
bit
about
a
story.
That's
pretty
common
to
my
experience
when
it
comes
to
reviewing
prs
from
the
community
for
kubernetes
and
from
various
other
open
source
projects
that
I've
worked
on,
and
this
is
a
story.
That's
about
speed.
It's
about!
How
quickly
can
you
get
a
pr
in
for
documentation,
because
this
is
what
most
of
us
are
focused
on
when
it
comes
to
writing
we've
already
written
the
code,
we
want
to
get
the
documentation
in.
A
So,
starting
out
tony's
written
his
code,
he
has
some
docs
that
he
wants
to
write
up,
send
it
out
as
a
pr
and
his
goal
is
to
do
this
as
quickly
as
possible.
Like
I
said
so,
what
does
he
do?
What
do
most
developers
do?
Well,
we
copy
and
paste
right.
We
find
a
good
document
that
we
like
we
grab
it,
throw
it
the
mark
down
into
it
into
a
new
file,
pull
out
some
of
the
content
that
exists
there
write
up
some
new
ones
create
a
new
pr
fire
it
off
now.
A
A
He
might
not
know
anybody
in
this
project,
so
he
sits
and
he
waits
and
maria
then
takes
a
look
at
the
pr
and
she
might
not
know
who
tony
is,
and
so
she
starts
reading
the
pr
and
she
thinks
what
am
I
supposed
to
do
with
this?
Who
is
this
person?
What
are
they
writing
about?
Maybe
the
documentation.
Pr
is
separate
from
the
code,
pr
that
tony
filed,
so
she
doesn't
know
that
this
code
already
exists.
A
What
is
this?
Why
are
you
writing
it?
What's
the
specific
focus,
why
did
you
use
this
template
for
your
documentation
and
tony
starts?
You
know
takes
a
step
back.
He
says
whoa.
Why
do
you
have
all
these
questions?
For
me,
I
thought
it
was
pretty
clear
from
what
I
wrote
based
on
my
knowledge,
of
the
feature
that
I
created
so
churn
happens
here,
and
this
churn
can
take
weeks
sometimes
months
to
solve
where
you
have
back
and
forth
between
the
pr
creator
and
the
pr
reviewer.
What
feature
is
like
wait?
A
A
A
So
he
takes
a
step
back
and
he
looks
for
some
documentation
about
how
to
submit
this
docs
pr
now.
Hopefully,
your
projects
have
some
of
this
documentation,
but
if
not
there's
a
link
for
kubernetes
process,
which
you
can
borrow
from
scale
down
to
whatever
you
need
and
if
you
need
to
scale
it
up
to
pass
to
what
kubernetes
does
just
grab
me
after
this
talk
and
we'll
chat,
I'd
be
really
interested
in
what
you're
building
in
this
process,
your
project
should
have
documented
how
to
submit
docs
pr.
A
What
flavor
of
markdown
you're
using?
Are
you
applying
any
specific
style
guide?
Are
you
using
the
cncf
style
guide?
Are
you
using
somebody
else's?
Are
there
any
templates
that
you're
using
any
tooling,
you
can
write,
maybe
half
a
page
even
less,
if
it's
just
a
small
project
or
a
readme,
just
hey
docs
go
in
the
same
repo
as
the
code,
here's
where
they
go,
but
if
you
have
a
larger
site
that
you're
using
then
having
a
document
that
lists
some
of
your
process
be
incredibly
useful
for
people
who
are
writing
docs
pierre's.
A
This
is
just
a
pet
peeve
of
mine,
so
I'm
just
going
to
toss
this
out
there,
but
tony
signs
the
cla.
So
this
is
something
that
holds
up
a
tremendous
number
of
pr's,
both
code
and
docs.
But
I
see
it
a
lot
more
on
the
dock
side,
where
somebody
comes
in,
they
make
a
docs
change,
they
don't
send
the
cla
and
then
suddenly
we
have
to
chase
them
down,
go,
find
them
on
twitter
or
slack
or
wherever
and
say
hey,
please
sign
the
cla.
So
we
can
merge
your
pr
and
sometimes
it's
really
hard.
A
Sometimes
sometimes
we
don't
find
people
so
prs
will
just
languish
without
the
cli
side.
So
please,
please,
please
sign
the
cla.
If
you
have
a
similar
process
for
your
project,
make
sure
it's
clear
that
people
do
that
next
step
create
an
issue
I
like
issues
because
they
help
track
the
documentation
that
we're
creating,
especially
if
it's
a
larger
documentation
set
or
a
larger
doc
that
you
need
to
write.
A
A
Who
is
my
audience?
What
do
they
already
know?
Maybe
this
is
a
new
feature
for
something
that
a
new
user
of
the
project
is
going
to
use.
So
it's
like
okay,
you
might
not
have
a
lot
of
context
for
this
project,
so
let
me
start
with
you're
a
developer
you're
coming
in
the
door.
Here's
the
project,
here's
my
new
feature
but
understand
what
your
audience
already
knows,
and
what
they're
going
to
learn
from
your
document
and
just
write
that
in
your
issue,
maybe
two
sentences.
A
In
addition,
if
you're
writing
more
than
one
document
you're
going
to
be
writing
an
extensive
set
of
documentation,
make
a
plan
just
make
a
checklist
of
here's.
Some
of
the
docs
I'm
going
to
create
I'm
going
to
create
a
procedural
guide
for
using
this
new
feature,
step-by-step
123,
how
to
use
it
and
create
a
conceptual
guide.
That's
like
here's.
What
this
feature
is
here's
how
it
works,
here's
some
of
the
considerations
you
should
have
when
using
it.
A
Maybe
you
split
that
up,
maybe
there's
an
additional
reference
regardless,
it's
useful
to
just
list
a
few
bullet
points
of
what
you're
going
to
build
in
this
issue
and
last
it's
a
good
place
to
cc
your
potential
reviewers.
So
maybe
that's
somebody
in
sig,
docs,
like
myself
or
maybe
it's
a
reviewer
on
the
project,
give
them
a
tap
on
the
shoulder.
A
A
You
should
be
writing
to
your
audience
when
you
write
your
pr
now,
there's
a
ton
of
books,
I've
written
a
book
myself
on
documentation
and
how
to
write
it
well
and
how
to
focus
your
content,
and
I'm
not
going
to
go
into
all
of
that
here.
But
let
me
give
you
one
golden
rule
for
writing
great
documentation
for
your
audience,
and
that
is
simply
to
write
it
in
second
person-
and
this
sounds
maybe
too
easy.
A
A
What's
better
is
this
feature
was
created
for
you
to
do
x,
whatever
it
is
state
it
from
their
perspective,
write
it
to
them,
write
it
to
you,
the
other.
The
other
points
in
here
are
very
useful
as
well.
I'm
just
gonna
gloss
over
those,
but
that
writing
in
second
person
is
the
most
useful
thing
you
can
do,
keeping
it
in
present
tense,
don't
focus
on
past
decisions
or
future
decisions
that
you're
going
to
make
like
your
user
documentation
is
not
a
great
place
to
put
in
your
roadmap.
A
So
just
like
don't
talk
about
your
next
feature,
release
in
six
months
like
keep
it
focused
on
what
the
user
can
do
right
now
in
this
moment,
with
what
you've
created
and,
of
course,
you
break
out
chunks,
keep
it
readable,
keep
it
skimmable
and
focus
on
like
existing
existing
templates
and
style
guides,
so
give
a
quick
example.
This
is
from
this
is
a
very,
very,
very,
very,
very
old
paragraph
from
the
nodes
page
in
kubernetes
and
I'm
not
going
to
read
the
whole
thing,
but
just
that
first
sentence.
A
So
this
paragraph
is
trying
to
do
a
lot,
but
it's
also
written
in
a
way
that
describes
the
person
doing
the
coding,
not
the
person
using
kubernetes,
so
just
to
call
out
a
few
specific
things
in
this
paragraph
that
you
can
apply
to
your
writing.
Look
for
places
where
you
say
we
try
to
get
rid
of
them.
A
Maybe
that
should
be
another
paragraph
for
another
page
like
look
at
places
where
you
can
simplify
but
start
with
looking
at
places
where
you're,
not
speaking,
directly
to
the
user,
so
here's
it
rewritten
kubernetes,
runs
your
workloads
by
placing
containers
into
pods
which
run
on
nodes
like.
Doesn't
that
feel
so
much
better
like
write
it
to
your
users,
start
with
you,
and
I
encourage
you
to
just
use
you
in
your
writing
all
the
time
when
you're
writing
developer
documentation.
A
So
when
you
send
your
pr
out
for
review,
the
most
important
thing
you
can
do
is
to
specify
what
kind
of
review
you
want.
Tell
your
reviewer,
what
you
want
from
them
set
some
context
in
addition
to
the
issue
that
you
created
that
tracks
your
document,
let
your
reviewer
know
hey!
I
know,
like
maybe
tony
knows
this
feature
incredibly
well.
He
wrote
it
himself.
He
doesn't
need
a
technical
review,
but
maybe
he's
uncertain
about
his
documentation
and
would
like
a
review
for
editing,
content
and
clarity
and
consistency.
Inconsistency.
A
So
it's
important
that
he
specifies
that
when
he
sends
out
the
pr
like
hey,
I
would
like
you
to
review
this
just
for
documentation,
clarity
in
kubernetes.
We
use
tags
to
track
this.
So
let's
say
you
wrote
a
networking
feature
and
you
want
somebody
from
networking
to
review
it.
You
would
tag
it
with
sig,
networking
or
sig
network,
and
somebody
from
that
group
from
that
sig
group
would
jump
in
and
review
the
documentation
make
sure
it's
accurate
from
a
networking
perspective.
A
What
we
call
a
technical
review
now,
if
you
want
a
docs
review-
and
you
just
want
somebody
from
the
docs
team
or
somebody
who's
knowledgeable-
about
content
to
review,
give
you
a
peer
edit
copy
edit,
what
you've
written,
then
you
might
tag
it.
Just
sig
docs,
all
of
our
docs
go
through
docs
review.
Not
all
of
our
docs
prs
go
through
technical
review,
but
most
of
them
do
and
we
focus
it
on
specific
teams,
because
we
set
the
context
of
what
kind
of
review
we
want
from
all
of
our
pr's
that
come
in.
A
And
from
the
reviewer's
perspective,
it's
important
that
you
have
a
rotation
for
reviewing.
Let
people
know
how
often
you're
going
to
be
reviewing
your
content.
Doc's
brs
come
in.
Are
you
doing
it
on
a
weekly
basis?
Are
you
doing
on
a
daily
basis?
Is
there
somebody
on
the
hook
for
doing
that,
creates
a
rotation
to
make
sure
that
these
pr's
are
reviewed
on
a
regular
cadence?
Otherwise
things
languish,
and
then
you
wait
till
there's
like
100
pr's
in
the
prq
and
then
you
finally
crank
through
them
all
and
it's
it's
exhausting.
A
You
know,
documentation
is
not
as
clear
and
consistent
as
what's
good
and
what's
not
so,
if
you
give
feedback
say
like
hey
here's,
this
sentence
is
unclear.
Here's
a
way
to
improve
it,
specify
exactly
what
you
want
and
if
you're
unsure
or
it's
just
a
nitpick
call
that
out
as
a
nitpick
hey
this
sentence
is
a
little
clumsy
just
a
nitpick
you
might
want
to
consider
fixing
it
doesn't
have
to
be
perfect.
The
goal
is
good,
docs
good
enough
docs.
A
We
do
it's
okay,
to
write
a
reviewer
guide.
We
have
one
for
kubernetes.
I
highly
recommend
people
apply
it
to
their
own
projects
if
they
want
to
borrow
it,
but
it
basically
says
here's
what
we
look
for
when
we
review
a
doc's
pr
and
there's
a
link
to
it
in
this
presentation.
If
you
grab
the
presentation,
please
have
a
look
and
then
last
you
know,
as
feedback
goes
back
and
forth,
it
doesn't
need
to
be
confrontational.
A
It's
fine
to
say
that
just
keep
it
conversational
and
keep
it
professional,
keep
it
constructive
and,
of
course,
like
once
you're
done
celebrate
merger
pr.
If
there's
any
cleanup
that
you
need
to
do,
do
it
close
your
issue,
easy
give
yourself
a
pat
on
the
back
you're
done
now
throughout
this
process.
This
might
sound
like
a
lot,
but
these
steps
shouldn't
take
you
very
long
to
do
so.
A
I
just
want
to
emphasize
that,
like
taking
half
an
hour
before
you
write
a
docs
vr
to
jot
down
an
issue,
make
a
plan
ping,
the
reviewer
cc
them
on
the
issue
before
you
start.
Writing
will
save
you
weeks
of
time
in
the
review
cycle
and
it
will
make
for
better
documentation
and
a
better
review
experience.
A
So
some
items
is
to
take
away
for
doc
writers
out
there
to
you,
know:
research,
the
doc
writing
process.
First,
like
take
a
look
at
what
is
available
for
you
to
write
your
docs
pr
before
you
start
writing,
write
things
create
an
issue
to
track
your
audience
and
what
they
need
and
any
plans
that
you're
making
for
your
content.
A
You
know,
sign
the
cla,
of
course,
but
understand
like
what
your
audience
needs
and
write
to
them.
Write
in
second
person
use
you
when
you're
writing
avoid.
We
avoid.
I
avoid
talking
about
the
design
decisions
that
you
made
and
speak
directly
to
your
user
and
what
they
need
and
specify
the
specific
kind
of
review
that
you
want
from
your
reviewers.
A
Do
you
want
a
technical
review?
Do
you
want
a
content
review?
Do
you
want
both
you
might
want
both
it's
totally
fine
to
ask
for
might
come
from
two
different
people.
You
might
add
two
people
to
your
review
totally
fine,
but
it's
important
that
you
be
explicit
about
what
you
want
from
your
reviewer,
so
they
know
what
to
provide
you
as
a
reviewer.
A
You
want
to
make
sure
that
your
process
for
making
doc
submissions
is
clear
to
people
who
are
writing
content
for
your
project,
write
a
process
for
people
to
follow.
It
doesn't
have
to
be
long
but
be
explicit
about
what
you
expect
templates
that
you
use
any
style
guide
that
you
use
any
sort
of
conventions
that
you
use.
A
A
Here's
some
additional
resources
for
folks.
I
know
I
mentioned
a
lot
like
templates.
If
you
don't,
you
have
templates
for
your
current
project
or
you're
debating
on
what
templates
to
use.
I
highly
recommend
trying
doxy,
which
is
a
set
of
open
source
templates
that
are
used
by
the
kubernetes
team
that
are
based
in
hugo.
A
If
you're
looking
for
a
community
to
tap
into,
let's
say,
like
you,
have
documentation
and
you're
looking
to
make
the
next
step
and
maybe
hire
somebody
like
me
to
work
on
documentation
for
you
or
you
have
questions
about,
say,
doc,
versioning
or
localization
translation.
Any
work
like
that.
That
might
be
significantly
advanced
from
your
expertise.
A
I
want
to
call
out
a
few
people,
zach
corlisson
and
jen
lamborn,
who
originally
proposed
this
talk,
but
due
to
unforeseen
circumstances,
couldn't
be
here.
So
you
have
me
in
front
of
you-
and
I
also
want
to
thank
the
sig
docs
group
within
kubernetes
for
all
of
their
work,
many
of
whom
I've
listed
here.
B
A
So
I'm
sorry,
what's
your
name
tim,
so
tim
asks
a
question
like
what's
my
opinion
of
document
driven
development
and
I
think
document
I
really
like
document
driven
developments
as
a
as
a
model
and
a
concept
I
do
think
documentation
should
exist
along
the
spectrum
of
developments
and
for
a
lot
of
the
work
that
I
do
within
like
closed
source
within
waymo.
We
start
with
internal
documentation,
about
design
docs
and
how
we
are
developing
autonomous
vehicle
technology
with
content
alongside
code,
and
I
see
that
model
working
really
well.
C
Hi,
this
is
vodka
from
acuity.
My
question
would
be
thanks
for
the
talk.
My
question,
like
the
maybe
the
context
you
mentioned,
that
you're
a
developer.
You
have
a
background,
a
technical
background,
but
not
every
technical
writer
is.
Has
this
developer
background,
so
my
question
would
be:
do
you
have
any
good
processes
or
stories
about
actually
the
technical
writers
working
with
developers
when
it
comes
to
some
complex
features
and
basically,
how
do
how
do
the
document,
people
who
write
documentation,
work
closely
with
developers?
C
A
I
think
developer
yeah
you're
right,
I'm
lucky
in
that.
Like
I,
I
was
a
software
developer
before
I
became
a
technical
writer
and
I
still
do
a
decent
amount
of
coding,
but
that's
not
every
technical
writer
and
I
encourage
people
who
do
documentation
or
do
technical
writing
to
get
knowledge
of
coding.
It's
important
that
you
be
able
to
understand
your
audience
because
you're
writing
to
them.
Now
they're
not
going
to
have
the
expertise
of
the
person
writing
the
feature
which
is
totally
fine.
A
A
So
there's
a
way
to
balance
that
back
and
forth,
and
I
think
I
do
think
I
work
very
closely
with
engineers.
I
sit
with
engineers.
I
learn
like
what
they're
building
and
I
write
from
that
perspective
and
I
encourage
people
who
are
doing
documentation
solely
as
profession
to
do
the
same.
So
thanks
for
the
question.
A
A
I
actually
think
it
like
writing.
Shorter,
concise,
simple
language
makes
it
easier
to
translate
into
other
languages
and
that's
something
that
we
focus
on
a
lot
in
kubernetes.
So
I
think
some
advice
that
I
would
have
is
to
you
know
beyond
the
fact
that
you
know
don't
get
imposter
syndrome
and
don't
feel
like
it's
holding.
You
back
is
to
look
at
other
doc.
A
Sets
that
you
like,
and
look
at
other
style
guides
that
you
like,
like
google
style,
guide
or
microsoft
style,
guide
and
see
how
that
applies
to
your
writing
and
how
you
might
improve
your
own
writing
over
time.
Also,
I
offer
developmental
feedback
to
people.
So
if
people
are
writing
documentation,
they
can
send
it
to
me,
and
I
will
say,
like
here's,
how
I
would
edit
it
based
on
if
I
was
in
a
hurry
to
publish
it.
But
here
is
a
bunch
of
suggestions.
A
I'm
going
to
give
you
to
improve
your
writing
over
time,
because
I
see
some
patterns
in
your
writing
that,
if
you
change
your
writing,
will
sound
more
natural
it'll,
be
it'll,
be
clearer,
it'll,
be
more
concise,
so
you're
always
welcome
to
ask
other
writers
for
developmental
editing.
That's
what
we
call
that
and
you're
welcome
to
ask
people
if
you're
writing
a
pr
for
sig
docs.
B
Hi,
thank
you
for
the
talk
and
my
question
is:
are
you
familiar
with
the
documentation
system
called
divio
and
if
not,
what
do
you
think
about
systems
in
general,
because
what
I
realize
in
my
everyday
work
is
that
people
come
to
documentation
for
different
reasons,
so
I
think
that
there
should
be
some
separation
between
or
some
some
different
styles
of
documentation
to
cater
to
those
needs.
Specifically,
how
do
you
do
that
in
in
your
work.
B
A
You
have
I-o,
no,
I
haven't
heard
of
it.
I
know
that
there's
a
number
of
documentation
systems
out
there,
especially
around
api
documentation
and
reference
documentation
and
cli
documentation,
and
those
tools,
help
auto
generate
a
lot
of
content
for
those
tools.
Like
reference
documentation,
that's
generated,
and
I
think
those
tools
are
great.
They
help
automate
a
lot
of
the
sort
of
technical
underpinnings
that
people
want
to
know
and
they
allow
you
to
be
documentation
complete
without
having
to
do
a
lot
of
human
written
content.
A
I
really
like
those
systems
that
said
I
tend
to
prefer.
Human
written
documentation
for
things
that
are
going
to
be
written
is
going
to
be
read
more
by
new
users
by
people
who
are
coming
to
the
product
and
want
to
have
a
more
human
experience,
so
I
prefer
markdown
for
for
that,
but
I
know
that
there's
a
number
of
tools
out
there
and
they're
constantly
changing.
I
know
stripe
recently
released.
A
Was
it
a
flavor
of
markdown
mark
that
I've
been
playing
with
that's
really
interesting?
So
there
are
more
tools
changing.
I
do
see
a
pattern
where,
where
projects
will
lack
documentation
and
people
will
come
in
with
the
idea
of
tooling
will
fix
the
problem,
and
I
would
highly
caution
you
against
that:
it's
better
to
create
content
first
and
then
introduce
systems
like
you're,
mentioning
that
help
automate
or
manage
your
documentation.
A
E
I
think
I
have
maybe
a
good
follow-up
question,
so
I'm
involved
in
a
project
that's
been
going
on
for
like
a
decade
and
we've
have
pretty
good
documentation.
I
think,
but
I
think
the
format
is
holding
us
back
from
doing
a
good
job
of
keeping
it
up
to
date.
So
it's
it's
currently
in
rst
and
sphinx,
and
we're
looking
at
porting
that
to
mark
down
on
mk
docs.
E
A
I
think,
with
30
pages
you
could
you
could
review
it.
I
would
do
a
copy,
editing,
review
and
migration.
It's
likely
from
what
you're
describing
you're
going
to
want
to
maybe
chunk
out
some
of
that
content
into
smaller
docks.
You
might
have
30
very
long
docks
and
you
want
to
chop
it
up.
I
wouldn't
do
that
re-architecture
at
the
same
time
that
you're
doing
the
migration,
so
I
would
migrate.
A
E
And
you
just
mentioned
that
you
have
to
be
careful
with
tooling
and
not
relying
on
tooling
too
much,
but
you
think
like
switching
to
a
new
format
like
mk
docs,
which
I
feel
is
a
lot
better.
I've
written
some
new
documentation,
mk
docs,
I'm
very
happy
with
it.
While
I
feel
with
rst
is
just
not
it's
not
easy
enough
or
maybe
live
preview,
while
you're
editing
doesn't
really
work
that
well
right.
Do
you
think
that
makes
sense
that
there's
new
stuff
and
it
makes
sense
to
make
a
big
jump
to
a
new
format.
A
A
So
I
would,
I
would
talk
to
some
of
your
users
and
say:
is
rst
and
spanx
holding
you
back
from
contributing
and
if
the
answer
is
yes,
then
I
think
you
have
a
great
signal.
If
the
answer
is
no,
it's
like
all
these
other
issues,
it's
complexity
of
the
project.
It's
like,
I,
you
know
not
a
large
enough
user
base,
all
sorts
of
other
things.
Then
maybe
you
should
step
back
and
say
this
is
an
art.
This
isn't
our
number
one
priority
to
fix,
but
there
are
tools
that
can
help
you
migrate
as
well.