►
Description
Himanshu, Chad, and Enrique discuss the collaboration strategy for delivering the Rich Text Editor scaffolding and the Wiki edit page Vue migration in 13.10.
They also go over the milestone requirements to share a common understanding of what the team will deliver in the milestone,
A
A
I
mean
setting
up
a
strategy
for
testing
the
features
in
data
or
creating
all
of
the
directory
structure
and
all
of
the
basic
organizations
that
we
are
going
to
follow
to
develop
data,
and
that
also
includes
some
development
guidelines
and
the
the
goal
of
this
office
agenda
is
first,
we
gonna
be
the
data
team
is
trying
to
to
make
madison
work,
more
collaborative,
not
creating.
Having
like
each
engineer
working
on
isolation
for
for
each
deliverable.
A
A
We
have
two
high
level
goals,
but
we
are,
we
actually
have
to
define
what
is
the
the
scope
of
what
we
are
going
to
be
delivering
and
if
we
actually
can
deliver
those
goals
within
a
single
milestone
and
besides,
that
we're
gonna
be
perhaps
like
taking
those
big
high
level
goals
and
breaking
it
down
into
smaller
implementation
issues
and
also
setting
dris
so
yeah.
Let's
start
with
the
with
the
general
conversation
of
you
know
how
we
can
collaborate
over
the
coming
weeks.
A
I
was
discussing
with
romer
or
actually
asking
him
for
advice
on
how
we
can
you
know,
set
the
collaboration
because
we
are
not.
Perhaps
we
are
not
going
to
be
doing
implementation
work
together
for
both
the
working
migration
and
the
treacherous
excitatory
folding.
So
I
was
wondering
how
we
could
be
on
the
same
page
on
both
areas.
A
He
told
me
that
perhaps
one
that
one
thing
that
we
could
do
is
like
having
a
catch-up
meeting
every
week,
perhaps
at
the
start
of
the
week,
and
we
can
spend
10
or
15
minutes
sharing
knowledge
of
how
we
are
doing
that's
one
of
the
I
one
idea.
So
what
do
you
think
himachal?
What
else
would
we
do
to
to
catch
up
and
be
on
the
same
page.
B
Yeah,
so
one
way
to
do
it
is
like
we
can
maybe
bear
program
on
both
the
things,
but
I
would
say:
let's,
let's
start
working
on,
let
both
of
us
start
working
on
one
of
the
issues.
So
let's
say,
for
example,
I
work
on
migration
to
view
and
you
work
on
the
scaffolding
so
that
when
we
go
to
pair
programming
sessions
it
like
we
don't
waste
a
lot
of
time
in
setup
and
everything.
B
A
B
B
B
A
B
B
B
A
How
do
we
scale
the
appearing
sessions?
We
are.
Perhaps
that's
that's
something
that
can
be
more
like
like
that,
that
it
can
happen
more
organically
and
we
can
come
up
with
a
prayer
session
during
the
the
rest
of
the
week
right.
It
doesn't
have
to
be
like
something
that
should
happen
at
the
same
time.
Every
week.
A
A
B
I
think
the
other
questions
would
I
mean
the
document
looks
good.
The
questions
would
come
more
as
we
go
on
and
implement
this
one
by
one.
So
right
now
and
I
don't
really
have
any
questions,
but
when
we
get
to
implementing
it,
I
think
it
will
become
more
clear,
maybe
probably
face
some
challenges
or
something.
A
B
A
A
A
You
can
open
the
the
bubble
extension
here,
so
one
of
the
first
differences
that
are
very
that
is
very
noticeable
is
that
extension
will
like
the
way
that
packages
are
handled
is
that
in
tita
version
one,
there
was
a
single
mpm
package
that
contained
all
of
the
extensions
now
in
the
tiptop
v2.
Each
extension
will
be
an
independent
npm
package.
A
So
what
changes
in
version
two
is
that
they
don't
use
inheritance
anymore.
They
use
this
mark.create
method.
This
is
written
in
types
in
typescript.
That's
the
reason
that
you,
you
know
we
can
see
generics
and
all
of
that,
but
that
shouldn't
affect
us,
because
you
know
it's
that's
at
the
end,
transpile
to
the
aerospace
and
but
they
they
don't
use
inheritance
anymore.
A
They
don't
use
computer
computed
properties
anymore,
but
if
you
notice
they
are
using
the
same
schema
syntax
and
they
are
using
also
basically
like
the
same,
the
the
same
content
within
those
methods.
It's
like
it's
very
similar
to
the
v1
extensions.
The
only
thing
that
changes
is
like
you
know
the
way
that
the
class,
the
extension
is
defined,
the
extension
api.
B
B
So
can
we
like
if
we,
for
example,
we
are
planning
on
releasing
wrist
text
editor
for
wikis
and-
and
we
know
that
wikis
are
not
very
prominent
right
now
and
we
can
do
it
behind
a
feature
flag
anyway.
So,
given
that
tape
tap,
would
release
this
in
the
next
three
or
four
releases
or
months,
and
given
that
our
list
x,
editor
would
also
go
live
behind
a
feature
flag.
So
is
it
safe
to
use
the
next
version
directly
here.
A
So
right
now
the
the
version
of
the
the
the
green
version
that
they
have
released
is
well
first,
this
request
repository
is
not
even
public,
so
I
have.
They
gave
me
private
access
to
their
private
super
story
where
they
are
implementing
the
tiptop
picture,
so
they
have
published
some
npm
packages
of
all
of
these
extensions,
but
it's
not
official,
so
we
don't
even
have
like
actual
access
to
there
to
the
new
tiptop
packages
to
you
know
to
escape
the
project.
A
It's
not
going
to
be
it's
not
going
to
represent
like
well,
it's
going
to
be
a
significant
effort,
but
I
think
that
is.
I
consider
that
a
safe
decision
to
start
with
v1
and
then
migrate
and
scale
with
eric
summit
port
to
migrate
from
b1
to
whichever,
like
considering
that
all
of
the
body
of
the
extension
is
the
same.
B
Yeah,
and
also
second
thing
is
like
like:
are
they
actually
offering
any
advantages
in
the
version
two
that
that
that
would
be
useful
to
us?
Otherwise,
I
don't
think
it's.
It
should
be
a
very
high
priority
to
migrate
as
soon
as
v2
is
released.
So
I
think
we
can
do
it
much
later
on
when,
when
it's
much
more
stable,.
A
A
B
Okay,
I
think
it
makes
sense
because
it
since
v2
is
not
even
public.
So
it's
it's
out
of
the
question
for
us
to
use
v2
right
now,
so
we
don't
really
have
a
choice
here
so
yeah.
I
think
it's
okay
for
us
to
go
with
v1,
I
think
yeah.
So
we
can
move
forward
in
the
plan
now
yeah,
that's
about
it.
I
don't
really
have
any
other
questions
sounds
good.
Thank
you.
Congratulations.
A
C
A
A
A
So,
from
a
general
point
of
view,
we
are
like
when
they,
when
they
tour
initializes.
Let's
say
that
the
the
user
tries
to
edit
an
existing
wiki
page
by
default.
Tiptap
won't
know
how
to
render
the
markdown
that
is
well
by
default
itself,
doesn't
know
how
to
render
markdown
or
interpret
markdown.
So
what
we
do
is
like
is
that
we
send
that
mark
down
to
the
g,
not
markdown
api
and
that
the
deluxe
markdown
api
will
produce
html.
B
B
C
That
you
can-
or
especially
if
you
don't
have
as
robust
of
integration
testing,
because
what
you're
talking
about
is
actually
getting
the
api
generating
some
pictures
and
saving
them.
That's
a
like
a
vcr
like
approach
that
you
use
in
ruby,
and
you
know
I
can
see
an
automated
test
or
a
scheduled
job
in
the
ci
suite
that
does
that,
like
on
a
daily
basis
or
whatever,
and
then
commits
those
fixtures
to
the
repo-
and
this
is
what
I
was
talking
about
before-
to
have
a
golden
master
or
characterization
type
test.
C
B
C
C
Yeah-
and
I
wouldn't
use
capybara
for
that
anyway,
like
there's
no
reason
to
have
the
browser
involved
that
would
just
make
it
flaky
and
unreliable
just
have
a
job
that
all
it
does
is
hit
the
api
and
do
it.
You
can
have
a
little.
You
know
retry
logic
around
it.
We
already
have
code.
We
can
steal
like
that
in
the
www
repo,
actually,
because
sometimes
the
api
flicks
out,
but
you
just
try
it
with
like
a
a
progressive
back
off
and
they
could
be
reliable
enough.
B
C
A
C
C
A
So
the
anyone
shows
up
if
at
some
point
during
the
myself,
we
want
to
switch
and
say:
hey,
I'm
going
to
start,
like
you
know,
creating
the
the
infrastructure
in
the
history
book
and
we
want-
and
I
want
to
switch
to
do
some
work
migration
work
in
the
wiki.
We
can
also
do
that
now.
The
the
deliverable
is
like
very
big
in
scope,
and
I
think
that
we
have
to
actually
do
something
like
break
it
down
in
more
manageable
bits.
B
A
B
B
So
I'm
not
sure
like
can
there
is
text
editor
be
used
outside
of
its
component
usage
like
we
do.
We
also
need
to
like.
Typically,
a
component
is
just
some
some
markup
and
you
can
pass
some
attributes
to
it,
but
this
text
editor
is
probably
going
to
be
a
little
bit
of
more
work
than
that,
so
we
need
to
like
we
offer
configurability
and
how
how
to
develop
extensions
and
all
those
things.
B
I
think
those
should
go
in
this
documentation
here
in
the
front
and
guidelines
how
to
develop
extensions,
how
to
like
basically
create
like
work
on
the
risk
test,
editor
itself,
so
yeah.
Think
of
it
like
two
things.
Creating
this
thing
and
using
this
thing
so
usage
documentation
should
be
in
the
in
the
storybook
and
like
developing.
It
should
be
in
the
documentation.
B
B
A
B
A
A
A
So
what
I
think
that
we
should
like
do
here
is
defining
the
the
scope
of
the
of
the
migration.
I
was
looking
at
the
at
the
code
of
the
of
the
wikipedia
form
I
saw
that
it
is
implemented
with
with
hamo
it
is.
There
is
a
a
very
old
american
nato
that
we
are
using
there,
and
I
guess
that
the
the
the
goal
is
like
taking
all
of
that
and
implementing
india,
so
I
you
have
experience
with
this
with
with
this
part
of
the
application
right.
Imagine.
B
Yeah
a
little
bit,
it's
not
actually
a
lot
of
code.
What
I
would
say
is
this
is
going
to
be
very
similar
to
the
migration
we
have
done
with
the
snippets,
so
in
also
in
snippets
also,
you
can
have
like
any
kind
of
file.
I
think
snippets
is
much
more
complicated
because
you
can
have
any
kind
of
file
and
you
can
have
multiple
files
as
well,
but
the
common
part
here
is
that
both
of
them
can
include
a
markdown
file
in
a
preview.
B
B
B
B
B
A
A
B
B
B
B
It
does
a
lot
of
things
like
taking
care
of
the
form
and
also
the
sidebar,
so
yeah.
Potentially
we
could
break
it
down
into
like
if
you
want
to
edit
the
whole
wiki
page,
convert
it
to
view,
so
you
could
possibly
like
do
it
in
maybe
in
two
or
three
parts
like
sidebar
is
one
separate
issue
and
the
form
is
separate
issue
and
the
the
magnum
input
is
a
third
issue
that
you
could
bring
potentially
now
with
these
three
issues,
I
think.
A
A
B
B
B
B
A
Right
yeah,
they
completely.
I
repeat
that
I
think
that
from
what
I
look
at
the
humble
template,
the
wiki
forum,
for
it
is
very
straightforward
and
then,
but
you
know,
within
the
form
we
have
the
environment
text
area
and
that's
a
the
complicated
part,
so
breaking
down
that
into
in
two
parts
sounds
very
some
sort.
Are
you
constantly
great?
So
I
think
that's
that
that
answered
these
questions,
that
these
questions
as
well
about
delivering
the
migration
which
has,
like
you
know
in
multiple
mass
request,.
A
And
what
about
do
you
think
that?
Well
you
said
that
you
think
that
this
is
like
something
that
you
estimate
that
we
can
achieve
during
a
single
management
right
or
perhaps
we
we
can
just
create
the
solutions,
and
I
started
working
on
it
and
started
by
the
markdown
text
area
and
after
that
we
can
see
how
it
fits
within
the
the
minus
one
scope
right.