►
From YouTube: Create:Editor - Milestone 13.12 Kickoff Team Meeting
Description
We talk through all the latest updates and what we are going to work on during this Milestone
A
So
welcome
to
the
kickoff
meeting
for
milestone.
13
12.,
that's
exciting
cool.
Let's
start
with
like
some
highlights
from
the
last
milestone-
and
this
is
definitely
good
things
to
celebrate,
so
we
should
be
very
happy
off
so
first
of
all,
big
thanks
to
fran
and
jeter,
so
for
jumping
on
all
the
database
incident
issues
and
helping
out
where
they
can
was
not
easier.
So
it
came
out
of
nowhere.
A
It
was
like
a
lot
of
extra
communication
overhead
and
a
lot
of
actions
needed
so
like
even
denise
jumped
in
or
so
really
appreciated,
like
early
on
to
help
discovering
some
things
just
helping
out
with
comments,
it
was
like
everybody
who
chipped
in
is
a
like,
really
big.
Thank
you
yeah.
It
was
very
welcomed
by
the
whole
company
and
we
all
know
that
it
was
a
big
distraction,
but
you
all
did
it
like
really
really
good,
so
appreciate
it.
Thank
you
and
then
I.
B
C
A
Perfect
yeah
participation
trophy
that
sounds
great
big,
shout
out
also
like
to
the
whole
team
and
just
like
for
me
very
personally.
I
think
you
all
did
like
a
really
good
job
or
so
and
helping
us
being
ready
for
the
14-0
release
right
because,
as
eric
mentioned,
or
so
it's
like
really
ambitious
goals
that
we
have
here.
I
think
over
the
course
of
last
milestone.
You
all
did
like
really
an
excellent
job,
especially
great
on
it's
like
this
experiment,
right,
you've
gotten
a
lot
of
like
self
recognization
cell
phone.
A
A
Thank
you
and
I'm
perfect.
I'm
personally
super
happy
that
we
have
the
1312
release,
because
it
all
gives
us
a
little
more
breathing
room,
a
little
more
confidence
in
what
we're
doing
so
thanks
for
hanging
in
there-
and
I
think
you
did
like
marvel
this
job
there-
and
the
next
point
is
something
that
eric
definitely
wanted
to
shout
out
to
the
team
I'll.
Let
you
talk
eric.
D
A
No
cool
all
right,
then,
let's
jump
to
the
em
and
product
led
part,
so
so,
first
of
all,
overall,
the
theme
for
this
milestone
will
very
much
be
like
the
koni
continuation
of
where
we
left
off
in
the
last
milestone,
maybe
you've
seen
eric's
like
kickoff
video.
I
think
it's
a
great
summary
of
where
we
stand.
What
we're
going
to
do
so,
that's
good
to
see.
A
Let's
start
with
the
content
editor,
so
we're
going
to
continue,
of
course,
on
the
content,
editor
mvc
and
still
aim
for,
like
14
0,
to
release
it
on
the
wiki.
So,
first
of
all,
what
we
have
so
far
is
already
like
a
current
implementation
of
it,
which
is
kind
of
working
pretty
well.
The
first
demo,
which
is
very
nice
and
there's
been
like
some
late
developments.
A
I
think,
as
late
of
as
yesterday,
that
we
decided
to
kind
of
probably
re-prioritize
or
so
to
upgrade
the
content
editor
to
use
tip
tab
v2
because
they
released
their
beta
yesterday
and
yeah.
As
enrique
says,
this
is
hot
off
the
press
I'll.
Let
enrique
talk
a
little
bit
more
about
this,
because
this
will
be
even
very
exciting
thing
for
us
to
smash
them.
E
E
So,
yes,
it's
a
it's
a
it's
a
huge
improvement
and
we
are
taking
advantage
that
we
are
in
in
the
very
early
stages
of
the
content
editor
to
make
the
upgrade.
We
don't
have
many
couple
points
with
the
top
one
and
that
allow
us
to
do
it
quickly.
I
shared
a
a
nurse
request
in
the
document,
an
infomercial
quest
where
we
are
making
the
upgrade,
and
it
was
very
quick.
A
F
Yeah,
but
eric
also
I'm
anticipating
your
verbal
answer,
but
I
know
that
it
looks
like
tip
tap.
V2
is
beta
and
just
raising
the
concern
of
like
hey
like
what
what's
our
risk
mitigation
look
like
there,
because
that
does
add
some
risk
to
maybe
adopting
this
earlier.
Do
you?
What
do
you
all
think
sounds
like
eric?
Has
a
response.
D
Yeah
I
mean
I
don't
know
what
the
code
base
actually
looks
like,
but
I
did
have
been
trading
emails
with
the
tip
tap
team
to
let
them
know
or
we're
excited
to
use
their
product,
and
just
yesterday
I
emailed
them
to
congratulate
them
for
the
v2
public
beta
and
in
one
of
the
emails
they
indicated
that,
in
their
opinion,
v2
is
already
more
feature:
complete,
more
stable,
more
test
coverage
and
in
a
better
place
than
v1,
even
in
its
full
release
was
so
I
don't
know
what
their.
Why
they're
calling
it
beta?
E
D
Cool
and
I'll
just
jump
to
my
next
question
or
our
next
point,
which
is
related
because
we
could
probably
just
ask
them
in
the
email
response
that
I
got
late
yesterday.
They
indicated
they're
open
to
have
a
call
and
chat
about
their
roadmap
and
maybe
get
some
ideas
of
where
they
should
head
they
had.
They
said
they
have
a
very
like
deep
backlog
of
stuff
to
work
on,
but
they're
open
to
feedback
from
our
team.
D
They're
very
excited
that
we're
using-
and
I
imagine
we're
ultimately
going
to
be
one
of
their
higher
profile,
consumers
of
it.
So
I
think
they
would
take
our
feedback
into
consideration
as
with
that
weight.
So
I
think
enrique,
it
would
be
great
if
you
were
willing.
We
can
schedule
that
and
anybody
else
that
wants
to
join
that'd,
be
a
great
question
to
ask
them
and
see
if
we
can
help
in
any
way.
E
D
A
Awesome
perfect,
thank
you
all
details.
Then,
let's
jump
to
the
next
point:
the
top
navigation
consolidated
menu.
That's
the
other
major
thing
that
currently
paul
and
jetta
working
on
so
so
far.
We
seem
to
be
super
well
on
track,
or
so
with
what
we
have
planned,
and
I
think
what
I
understand
so
we
plan
to
be
release
ready
with
kind
of
1312,
which
is
kind
of
very
kind
of
confirming,
but
we'll,
of
course,
like
use
the
extra
timer
so
to
really
polish
test
everything
or
so,
and
we're
not
going
to
rush
anything.
A
The
good
news.
What
I
heard
also
after
talking
in
the
backlog
refinement
session
yesterday,
is
that
we
plan
to
enable
the
feature
flag
very
early,
at
least
for
our
team
internally,
that
we
can
like
start
consuming
it.
There's
a
lot
of
work
going
to
happen
on
polishing
the
mobile
version
and
the
responsiveness
of
this
kind
of
thing,
but
yeah.
It
gets
me
excited
and
feels
very
good
at
getting
confidence
level.
A
F
Do
you
want
to
add
anything?
Chad?
Oh,
were
you
pointing
at
me
or
no
it's
it's
going
good.
It's
been
anticipation
that
this
needs
to
be
out
as
early
as
possible,
because
14-0
needs
to
be
the
great
feature,
flag,
enablement
and
I'm
assuming
though
we
don't
want
to
necessarily
remove
the
feature
flag
in
14l,
because
that's
when
on-premise
customers
are
actually
going
to
have
it
on
and
if
there's
anything
that
catches
on
fire,
we
still
want
to
have
the
ability
to
shut
it
off.
F
So
I
would
expect
the
removal
of
the
feature
flag
to
be
like
a
14-1
thing,
but
it
should
be
on
by
default
14l,
which
means
we
need
to
have
it
on.com
pretty
soon.
But
thankfully
it's
been
a
pleasure
working
with
chad
and
this
is
going
fairly
well,
so
I
expect
it
to
come
to
a
master
branch
near
you
all
right.
A
Right
and
then
we
are
back
at
the
third
big
column
or
pillar
color,
of
what
we
tried
to
ship
here
is
140.,
the
left,
sidebar
and
one
thing
I
just
want
to
highlight,
or
so
to
the
rest
of
the
team.
If
you're
like
not
super
familiar
with
the
left
sidebar
in
this
case,
it's
not
that
we
talk
about
like
one
left.
A
So
this
is
definitely
a
super
big
undertaking
and
denise
and
fran
are
working
super
hard
on
this
one
to
get
it
done.
The
admin
song
is
just
something
that's
likely
not
going
to
make
it
or
so,
and
it's
the
thing
that
you
just
want
to
just
de-prioritize
and
say:
okay,
if
this
is
not
going
to
shift
in
40
note
it's
fine,
because
admin
is
something
that
only
a
very
limited
amount
of
users
kind
have
interact
with
on
a
daily
basis,
and
it's
fine
if
this
comes
in
a
little
later.
A
But
all
the
other
three
are
very
much
like
on
track.
I
would
say
the
big
thing
here,
what
a
highlight,
or
so
that
fran
is
working
really
hard
on,
is
like
a
bigger
refactor,
because,
alongside
not
only
doing
the
styling
aspects,
we
try
to
do
updates
on
the
information
architecture
of
the
whole
sidebar.
A
So
this
will
be
a
big
theme
of
this
kind
of
milestone
where
we
say
we
try
to
put
the
refactor
in
place
to
make
it
somehow
kind
of
like
easier
to
switch
around,
because
currently
we
need
to
be
aware
that
a
lot
of
other
teams
are
contributing
to
the
sidebar
very
actively,
because
everybody
wants
to
release
something
in
14-0
and
want
to
make
their
changes.
So
it's
like
basically
trying
to
build
something
on
constantly
changing
ground
right
now.
A
What
fran
is
doing,
so
it's
like
a
not
easy
task
or
so
so
will
be,
will
be
interesting
for
us
to
see
and
we'll
probably
have
to
reassess
where
we
are
and
he's
the
master
friend
himself
we
made
it,
which
is
cool.
Denise
will
pick
up
a
lot
of
the
stylings.
This
milestone
already
ahead
of
like
the
original
plan,
so
we
did
like
some
shift
around
and
yeah
there's
like
a
lot
of
things.
A
A
A
I
just
want
to
say
do
a
good
glimpse
of
how
this
whole
thing
will
kind
of
look
or
so
and
to
make
sure
that
we
don't
wait
for
a
magic
flip
to
happen
on
the
14-0
release
only
here,
so
we
really
want
to
see
that
we're
going
in
the
right
direction,
and
maybe
we
need
to
pull
some
resources
down
the
road
or
so
to
make
it
happen
or
so,
but
we'll
see
yeah,
denise
fran.
Anything.
You
want
to
add
to
this
one
that
the
team
should
be
aware
of
I've.
I've
fran
is
nodding.
C
Was
like
no
front
doesn't
have
anything
to
that
right.
Of
course,
okay.
My
turn
again.
I've
added
the
information
at
the
to
the
open
agenda
place,
but
probably
it
belongs
here.
So
we
had
a
call
with
fran
earlier
today
and
there
is
some
slight
change
changing
plans
from
what
we've
discussed
yesterday.
C
C
We
don't
use
the
feature
flag
for
the
for
the
refactoring,
so
there
are
two
interesting
moments
to
keep
in
mind.
First,
the
first
two
menu
items
you
see
on
the
gitlab.com
are
already
refactored
they're,
not
styled.
They
are
refactored,
they
come
from
the
refactored
menus,
all
the
like,
starting
from
with
the
third
item.
Those
are
the
the
old
ones
sort
of
yes.
So
yes
mushy,
though
yeah
so
we
this
is.
C
C
So
we
do
not
want
to
deal
with
mapping
all
those
changes
to
the
refactored
thing,
so
what
fran
is
doing
now
is
playing
with
fire
and
he's
doing
refactoring
right
in
master,
so
that
if
any
group
needs
to
make
changes
to
the
refactored
menu,
they
will
do
this
in
the
refactored
code.
If
they
need
to
do
the
changes
in
the
menu
that
is
not
refined,
yet
they
will
make
those
changes
and
those
changes
will
be
picked
up
by
front
when
front
gets
to
refactoring
that
or
another
menu.
C
So
that's
that's
the
good
part
about
the
feature
flag
and
our
approach
to
this
thing.
The
second
part
is
that
we
will
still
have
the
feature
flag,
but
what
will
be
covered
by
the
feature
flag?
Is
the
restructuring
of
the
menu
so
like
removing
some
items
from
the
menu
reorganization
of
the
things
or
something
like
this?
C
C
So
the
end
user
won't
be
able
to
set
to
to
tell
apart
whether
a
menu
is
refactored
or
not.
This
will
give
us
more
time
to
properly
plan
the
refactoring
of
the
of
all
the
panels,
but
we
won't
all
be
able
to
deliver
factored
in
14.0,
while
still
keeping
this
this
sort
of
picture
of
the
new
design
for
for
all
of
the
menus
and
those
things
will
be
covered
by
the
feature
flag,
but
we
will
flip
it
on
for
our
group
once
at
least
any
styling
changes
are
in
master
dash
main
whatever.
F
C
That's
the
that's
the
beauty
because,
like
it's
in
the
beginning,
we
thought
that
refactoring
will
be
done
first
and
then
we'll
get
to
the
styling.
But
since
we
realize
that
not
all
the
panels
will
be
refactored,
but
we
still
have
to
provide
the
styling
in
the
corner.
It
would
be
very,
very
odd
to
deliver
different
styling
for
different
panels
right,
so
we
will
have
to
provide
the
styling
for
the
old
panels
anyway.
G
What
one
one
more
thing,
so
the
also
the
main
idea
regarding
the
refactor
was
well.
The
main
idea
is
that
the
code,
the
okay-
this
is
recording
the
code,
is
tangled.
Okay,
let's
let's
say
like
that.
So
at
some
point,
hopefully
in
the
short
future,
one
team
is
going
to
get
this
from
us.
So
this
way
we
can
provide
something
useful
and
they
can
migrate
the
other
menus
in
case
we
don't
have
time
or
they
come
early
or
whatever
we
can
give
them
something
that
they
can
pick
up
and
start
from
there.
C
A
Awesome
awesome
and
yeah,
I
think,
we'll
also
maybe
work
on
smaller
things
that
come
our
way,
but
this
is
the
main
things
that
we're
going
to
focus
on
if
you
have
any
kind
of
other
distractions
coming
your
way,
please
feel
free
to
kind
of
deflect
them
always
like
to
me
and
eric
we're
very,
very
happy
to
help
on
this
front.
Just
so,
let's
see
how
we
can
like
all
pull
together
resource
as
much
as
we
can
or
so.
D
I
don't
know
about
more
important,
but
I
I
also
I
didn't
write
this
in
the
agenda.
I
want
to
acknowledge
that
this
kickoff
is
unusual
and
I
have
already
become
accustomed
to
the
gitlab
way
of
releasing
iteratively
and
it
feels
unusual
to
be
working
on
these
larger
projects
and
especially
three
simultaneously,
where
the
kickoff
is
really
just
like
we'll
just
keep
doing
what
we're
doing
and
we'll
probably
have
the
same
kickoff
call
next
time,
which
is
we'll
just
finish
up
what
we've
been
doing.
D
I
in
previous
jobs
was
very
comfortable
working
on
quarterly
goals.
Right,
like
these
are
quarter
long
projects
and
we'll
get
them
done,
and
maybe
they
slip
a
month
or
two
afterwards
as
well.
That's
not
how
gitlab
works,
and
I
got
accustomed
to
that
very
quickly.
So
this
feels
a
little
unnatural
in
the
cadence
of
our
kickoffs
to
be
discussing
these
three
large
projects
that
aren't
necessarily
going
to
ship
in
the
next
release,
but
I'm
still
very
excited
about
them.
D
There
was
a
call
that
I
watched
between
michael
and
mike
about
like
past
explorations
of
the
web
ide
things
have
just
been
percolating
in
my
head.
I
wanted
to
share
this
little
diagram
and
I
didn't
want
to
wait
three
weeks
for
our
next
monthly
meeting.
So
if
you
wanted
to
be
shift,
focus
and
think
past
14-0,
when
we
we
can
free
up
our
time
again
to
work
on
the
source
editor,
I
think
this
is
a
direction
I'm
trying
to
stall.
I
find
the
button
to
share
my
screen.
D
I
think
this
is
the
direction
we
could
head
and
I
I
shared
this
with
roman
right
before
this
meeting,
because
we
had
a
one-on-one
and
he
said
it's
very
similar
to
thoughts
that
he
had
a
long
time
ago,
and
that
made
me
feel
better
about
sharing
it
because
at
least
I'm
not
oversimplifying
or
or
way
off
base,
but
also
acknowledging
that
this
isn't
like
a
unique
perspective.
It's
just
it's
my
understanding
of
where
we
could
go,
and
maybe
I
can
highlight
where
I
think
we
should
focus
first
but
anyway.
D
All
your
changes
to
the
clipboard
open
up
the
web,
ide
paste
them
into
the
right
file
and
you're
losing
your
context,
you're
losing
your
momentum.
Maybe
this
is
through
an
mr
as
well
so
generally
like.
This
is
oversimplified
I'm
open
to
feedback
on
this,
and
you
can
you
can
correct
me
if
any
of
these
don't
make
any
sense,
but
the
way
I'm
thinking
about
it
is
that
we
have
this
sort
of
core
code
editing
component
right.
This
is
the
source
editor.
A
lot
of
this
is
source
editor.
D
D
There's
like
a
gutter
where
we
could
put
comments
and
decorate
lines
of
code
with
vulnerabilities
from
security
scans,
and
things
like
that.
But
this
is
like
you
know
the
core
single
file
editing
view
it.
It
goes
to.
It
follows
that
sometimes
you
might
want
to
compare
that
to
like
a
different
version.
So
we've
got
the
diff
view
here,
where
you
can
compare
so
we'd
have
sort
of
like
a
module
or
an
extension
for
diff
viewing
and
then
preview
right
now
loosely
related
to
our
live
preview
feature.
But
we
have
markdown
preview.
D
This
is
relevant
to
sort
of
our
approach
that
we
were
starting
to
think
about
with
the
static
site
editor.
Where
there's
you
know,
information
about
the
file
that
we
could
abstract
from
it.
Maybe
you
know
we
learn
a
lot
about
the
file
based
on
the
file
extension
or
whether
it's
configured
you
in
the
repository
with
the
editor,
config,
etc,
and
that
could
inform
what
context
these
files
are
opened
anyway.
I'm
getting
too
specific.
This
is
mostly
supposed
to
be
general,
so
the
other
sort
of
comp,
the
other.
D
So
something
like
a
a
reusable
component,
there
could
could
be
helpful
across
multiple
categories,
but
you
know
I
can
think
of
at
least
two
that
our
group
would
end
up
using
it,
and
then
I
think
this
is
what
this
is.
What
I
was
responding
to
this
was
the
spark
of
the
the
desire
to
write
this
out
or
diagram.
This
out
was
like
this.
D
This
sort
of
like
commit
action
module
which,
in
the
discussion
that
michael
was
having,
I
think
they
were
talking
specifically
around
like
the
web
id
and
explorations
around
them
the
commit
flow
and
how
it
fits
into
the
the
file,
the
the
proposed
file
tree,
refactor
and
and
whether
or
not
we
have
like
a
way
to
show
similar
to
vs
code
like
just
edited
files,
or
something
like
that.
Anyway,
this
module
could
be
used
in
many
places.
D
If,
if
you
can't
write
to
the
repo
like
it
should
be
aware
of
that,
and
instead
of
saying
commit,
maybe
it's
a
suggestion
flow
or
a
an
action
that
lets
you
create
a
patch
file
or
something
like
that
right.
If
we
can
build
something,
that's
reusable,
it
could
be
re-skinned
to
be
used
on
the
static
site,
editor
or
whatever
that
evolves
into
it
could
be
used
on
the
pipeline
editor.
D
It
could
be
used
in
many
places
around
the
product
so
pulling
that
out
as
its
own
sort
of
area
of
development,
a
framework
that
we
can
build
a
component
that
we
can
contribute
back
to
the
code
base
would
be,
I
think,
extremely
valuable.
I
think
our
biggest
immediate
opportunities
is
this
one
and
the
file
view
and
state
management,
because
I
think
those
will
have
immediate
benefits
to
the
user
experience
and
to
the
health
of
the
code
base.
D
So,
if
we're
bringing
this
back
to
like
reality,
I
would
prob
you
can
expect
us
to
probably
start
having
conversations
about
which
areas
we
should
focus
on
and
what
kind
of
technical
approach
we
should
take
and
what
kind
of
user
value
we
can
deliver
in
those
areas
as
a
part
of
the
refactor
as
part
of
re-imagining
what
those
components
are.
But
I
think
those
are
the
two
bigger
areas
of
interest
and
then,
with
the
source
editor
itself.
B
In
terms
of
the
get
actions,
especially
given,
what
just
came
up
them
saying
how
slow
the
static
site
editor
is
to
create
an
mr,
I
think,
there's
a
lot
of
opportunities
for
optimizing
and
rethinking
this
on
the
backend,
because
the
reason
it's
so
slow
is
because
we're
doing
these
chatty
individual
api
calls
like
open
a
branch,
make
a
commit
make
another
commit
open.
Emr
like
just
have
a
single.
B
D
B
D
B
D
That's
a
good
point,
yeah
and
and
just
to
elaborate
on
the
context
in
in
the
slack
thread.
It
came
up
that,
let's
just
say
an
executive.
I
don't
want
to
throw
one
on
the
bus
because
it
was
a
fair
point
of
feedback
said
that,
should
it
really
take
25
seconds
for
me
to
edit
like
one
line
and
create
an
mr
and
the
answer
is
like
it
shouldn't,
but
there
are
valid
reasons
why
it
does.
D
D
Yeah-
and
I
think
that
the
I
mean
this
might
be
over
simplifying
the
the
end
goal
also,
but
when
I'm
thinking
about
our
opportunity
for
contextual
editing
or
improving
the
experience
for
users
who
may
need
more
from
their
editing
experience
as
they
go
along
editing
right.
The
big
barrier
for
me
is
the
decision
point
between
opening
the
single
file
editor
and
the
web
ide,
and
the
fact
that
they
can't
like
transition
between
the
two.
I'm
not
saying
we
throw
away
the
web
ide.
F
G
G
D
Yeah,
okay,
we've
got
we've,
we've
got
a
prime
area
of
naming
conventions
ahead
of
us,
but
yeah
that
anyway,
that's
what's
top
of
mind.
For
me,
I
know
we're
all
very
focused
on
14-0
and
delivering
these
things
for
st
settings
and
navigation.
It
won't
be
our
entire
roadmap
for
the
rest
of
the
year.
So
I
did
want
to
get
this
out
and
let
you
know
I'm
thinking
about.
What's
next.
F
B
D
D
C
But
getting
getting
back
to
track
with
boring
stuff
when
it
comes
to
the
in-context
editing.
The
source
code
group
is
is
on
track
and
they
are
doing
that
already
now
with
not
like
full
full
size
blown
thing
but
with
with
sort
of
in
context
editing
when
you
click
the
button
and
you
do
not
get
really
reloaded
page,
but
you
just
flip
to
the
editing
of
the
document,
so
it
will
work
for
the
for
the
code
code
based
files.
So
far,
there
are
some
performance
applications.
C
D
Think
yeah
thanks
for
highlighting
that
I
actually.
That
was
another
reason
I
wanted.
This
came
up
again.
I
had
drawn
this
a
week
or
so
ago,
and
it
reminded
me
when
we
had
that
conversation
in
the
issue
about
the
work
they're
doing
there
and
how
they're
trying
to
get
it
so
that
they
can.
You
can
just
like
switch
into
the
source
editor
quickly,
which
I'm
all
for
and
obviously
I
you
know
we
talked
in
slack
and
you're
involved
in
the
conversation,
so
we're
doing
the
right
kind
of
collaboration.
There.
G
D
I
I
think
that
is
the
potential
yeah
we
could.
Maybe
I
mean
you
guys
would
have
to
tell
me
if
that's
not
realistic,
but
I
think
that
would
have
been.
That
would
be
my
goal
yeah
to
to
have
a
shared
component
now
that
that
issue
in
particular,
I
think,
ended
up.
It
ended
up
being
an
area
of
the
repository
that
I
that
I
thought
it
wasn't
like.
I
thought
we
were
talking
about
the
merge
request
tree
view.
D
C
D
F
But
if
they're
using
the
same
state,
we
could
have.
From
the
mr
view,
I'm
now
able
to
look
at
files
and
maybe
comment
on
files
that
weren't
changed.
That
would
be
really
sweet
so
that
I
can
holistically
review
completely
in
the
gitlab
ui
a
code
change.
So
I
think
right
now
they
do
share
the
same
presentational
component,
the
mr
treat
file
tree
and
the
web
id
file
tree,
but
the
data
is
coming
from
completely
different
places.
F
D
A
Cool
okay,
I
think
we're,
I
think,
right
time,
we're
at
time
yeah.
Absolutely
there
was
good
discussion
or
so,
and
I'm
seeing
already
a
lot
of
excitement
on
people's
faces,
which
is
great
thanks
for
sharing
your
insights.
Eric
cool
was
this
that
or
so
I
think
we
have
an
exciting
milestone
and
an
exciting
future
ahead
of
the
other
team.
So
everybody
have
a
lot
of
fun
thanks
for
being
here.
Thanks
for
all
the
good
conversations
and
comments
and
I'll
see,
you
soon
cheers.