►
From YouTube: Content Editor Weekly Catch up
Description
In this Content Editor weekly, Himanshu and Enrique discuss ways of improving asynchronous collaboration. We noticed that the only way collaboration is happening is synchronously in pairing sessions which is not transparent or efficient. We also talk about defining clear boundaries in our milestone goals to make easier individual progress over the week
A
A
So
we
are
gonna
now
talk
about
it
like
find
ways
of
alternative
to
keep
collaborating
and
be
on
the
same
page,
but
not
relying
so
much
on
comparing
stations
for
that.
For
doing
that,
so
I
wrote
a
more
detailed
description
of
the
problem
here
in
the
document,
but
I
think
that
the
main
difference
with
the
previous
milestone,
where
we
were
collaborating
as
well,
is
that
we're
implementing
the
wiki
for
migration
and
I
was
working
on
the
concentrator
scaffolding
and
we
didn't
have
that
much
necessity
of
interacting.
A
So
yeah
that
I
think
that
the
reason
this
is
happening
is
that
we
perhaps
haven't
dedicated
a
lot
of
time
to
discuss
this.
So
this
is
a
good
opportunity
to
do
so
and
I
feel
like
when
I
start
the
week
like
sometimes
I
like.
I
feel
that
I
don't
have
like
a
specific
goals
that
I
can
accomplish
on
my
own,
so
I
feel
lost
and
when
we
finish,
for
example,
appearing
session,
I
don't
know
what
to
do
after
that.
A
In
my
case,
it's
like
I
have
preparing
sessions
in
the
morning
and
I
have
the
entire
afternoon
to
continue
working,
but
I
don't
know
how
to
how
to
continue
my
progress.
So
I
want,
like
you
know,
like
final
way
of
addressing
that
so
yeah,
like
the
the
solutions
that
that
I
think
that
we
could
like
implement,
like
my
proposals,
are
like
using
this
meeting
to
define,
goals
and
know
like
okay
this
week.
A
So
if
we
can
merge
it
within
a
week,
we
know
that
we
are
unblocking
each
other
and
another
solution
is
that
if
we
have
fearing
sessions,
I
think
that
they
should
have
very
specific
goals,
so
they
are
not
like
that
stressful
and
if
we
like,
like
actually
like
focus
on
that
small
goal
like
accomplish
that
and
after
that
we
have
action
items
then
we
are,
we
are
like
doing
natural
progress
yeah.
Those
are
my
thoughts.
What
do
you
think
you
mentioned.
B
I
think
what
we
can
do
is
like
last
release.
What
we
were
working
on
was
two
separate
issues,
but
we
were
still
doing
paper
programming
sessions,
but
the
key
difference
was
that
both
of
us
were
responsible
for,
like
mainly
responsible
for
shipping,
one
feature
and
the
other
person
who
was
fair
programming
on
that
was
like
more
like
a
reviewer
or
what
you
would
say,
yeah
kind
of
a
reviewer
and
like
someone
who
I'm
not
sure
what
the
other
person
is
called.
One
of
them
is
called
a
driver
and
otherwise.
B
B
So
I
would
suggest
that
we
split
our
work,
but
that
doesn't
mean
we
would
reduce
the
collaboration.
It's
just
that
we
are
kind
of
assigning
a
dri
for
some
specific
work
to
each
of
us,
so
that
we
know
that
that
this
is
the
direction
we
need
to
go
forward
in
and
if
you
are
stuck,
you
can
start
to
do
a
pairing
session.
Perhaps.
B
B
Yeah,
we
are
not
focusing
on
the
toolbar
right
now,
because
that
is
a
focus
for
the
next
release
and
I
I'm
hoping
that
some,
some
of
the
wiki
specific
work
can
be
taken
care
of
in
this
release.
So
in
the
next
release
we
can
continue
this
same
dri
theory,
but
we
split
the
our
work
so
like
one
of
us
like,
I
am
supposed
responsible
for
power
mark
extension
and
then
you
can
work
on
the
toolbar
thing.
A
Because
that's
that's
the
point
of
collaboration
like
we
actually
like
take
every
week
and
every
work
that
we
are
doing
and
we
are
trying
to
actually
discuss
it
together
and
come
up
with
with
a
joint
solution
that
we
discuss
and
we
like,
like,
we
agreed
to
move
forward
in
that
way.
So
how
do
you
think.
C
B
B
Yeah,
and
also,
for
example,
last
release.
Last
week
we
did
a
pair
programming
session
and
we
come
up
with
a
paradigm
on
like
let's
say
how,
how
we're
going
to
like
create
what
were
the
serializers.
So
we
were
coming
up
with
a
paradigm
for
sterilizers
and
how
stabilizers
are
going
to
work,
and
we
would
create
that,
mr,
but
but
that,
wouldn't
really
that's
what
between
us?
That's
not
really
documented
how
we
came
to
that
conclusion.
B
A
That's
true,
that's
true.
I
completely
completely
agree.
I
think
that,
like
varying
is
good
when,
when
you
actually
feel
like,
like
that,
asynchronous
communication,
perhaps
is
like
taking
too
long
because
we
are
like
we
are
having
like
a
lot
of
back
and
forth,
but
perhaps
that's
not
the
case
for
us
like
we.
B
Yeah,
I
think
it
should
be
good
and-
and
I
don't
think
we
should
be
like
two
people
should
be
working
on
the
same.
Mr
I
mean
like
there
should
only
be
one
person
committing
to
the
mr
and
if
the
other
person
wants
to
do
something
they
can
suggest
patches,
so
that
that's
what
I
want
to
do
like
we,
we
should
have
like,
like
like,
like
that.
You
can
be
clear
who,
who
the
dri
hair
is.
B
So-
and
you
can
work
on
that-
and
I
think
that's
quite
important
as
well
to
to
shift
to
the
release,
and
even
if
you
don't
have
some
things
like
like
alerting
user,
when
this
message
between
the
former
dispose
of
the
ux
thing
yeah,
I
think
it
should
be
okay,
and
this
is
going
to
be
behind
the
feature
flag
anyway.
So.
B
A
B
B
A
A
A
There
are
two
issues
here:
there
is
one
that
is
about
implementing
the
continuator
and
supporting
common
mark
and
implementing
the
ui
of
the
content
data,
and
then
there
are
two
issues
that
are
about
like
in
integrating
the
the
content
editor
in
the
in
the
wiki
page
cool.
So
we
just
have
to
to
assign
these
two.
B
B
I'm
not
sure,
though
I
mean
if
it
is
just
implementing
code
from
if
that
would
be
straightforward,
I'm
not
sure,
but
yes,
so
we
also
need
to
split
like
maybe
evenly
between
both
of
us
yeah.
If
you,
if
you
can,
if
you
figure
this
one
out
and
then
you
can
work
on
the
toolbar
now
we
can
work
on
the
toolbar
together
I
mean
because.
D
B
B
A
A
B
B
D
A
A
A
B
B
B
B
A
B
Mean
we
will
be
working
together
anyway,
because
we
do
need
some
coordination
to
make
sure
that
integration
of
of
creator
works
properly.
I
mean
we
need
to
be
sure
that
we
are
on
the
same
page
about
how
we
organize
stuff,
because
you're
going
to
be
modifying
same
piece
of
code,
although
in
a
different
folder,
and
I'm
also
going
to
use
like
like
adding
support
in
the
same
file
like
two
markdown
from
background.
B
A
B
A
B
A
Yes,
I
I
think
that
what
what
we
should
be
careful
of
is
that
when
we
are
dri
like
we
allow
each
other
to
have
like
a
meaningful
participation
on
each
other's
work
like
we
cannot
go
like
to
to
either
extreme
like
there
is
extreme
an
extreme
where
we
are
both
responsible
for
for
the
same
thing,
and
we
are
not
making
progress
because
it
feels
like
we
have
to
work
together
on
it.
But
there's
the
other
string
where,
like
we
have
so
much
ownership,
that
the
other
person
cannot
like
make
a
meaningful
contribution.
A
B
B
A
B
A
Cool,
so
do
we
should
we
move
on
to
the
to
the
next
item:
yeah,
okay,
so
about
dcmr.
So
last
time
that
we
were
working
on
this,
we
were
discussing
the
the
serializer
strategy
and
I
created
a
patch
for
a
proposal.
So
first
based
on
the
on
the
previous
discussion,
we
are
mixing
here
both
two
concerns,
because
there
is
a
concern
of
how
the
the
contentator
handles
the
the
the
markdown
serialization
and
then
there's
a
wiki
integration.
B
A
B
B
Yeah,
I
think
I
think
we
are
over
complicating
this
by
trying
to
make
it
very
future
proof
and
right
now
we
are
really
sure
that
it's
going
to
be
dealing
with
only
only
markdown,
and
I
don't
think
there
are.
There
are
going
to
be
any
other
kind
of
stabilizers,
except
that
the
api
endpoints
might
be
a
little
different.
C
B
I
think
we
can
simplify
it
a
little
bit
further.
I
don't
think
we
really
need
a
stabilizer
at
all,
so
what
we
can
do
is,
let's
not
call
it
a
serializer.
Let's
just
create
a
wrapper
around
the
the
editor
that
it
provides.
You
provides
you
and
add
serialize
and
answer
like
functions
on
top
of
that,
and
then
you
can
give
it
a
call
back
like
you're
already
doing
right
now,
but
you're
giving
callbacks
to
the
fertilizer,
I
would
say
just
create
a
rapper.
I
mean.
B
B
A
B
Exactly
that,
that's
why
that's
my
point,
so
you
don't
need
the
serializer.
You
don't
need
to
create
a
new
system.
That's
just
redundant
information.
Just
give
information
to
create
editors.
It's
already
a
wrapper
function.
We
just
give
it
to
html
and
one
more
function
like
we
can
give
it
more
more
data
as
we
feel
necessary
yeah.