►
From YouTube: PWA Studio Community Meeting 24 January, 2020
Description
Open discussion on Server Side Rendering as a solution for SEO with Progressive Web Applications.
A
All
right
so
good
morning,
everybody
happy
Friday
again
welcome
and
thanks
everyone
for
joining
for
another
community
sink
for
PWA
studio.
We
have
pretty
good
turnout
today
and
I'm
guessing
it's
because
of
the
content
we're
covering,
which
is
a
pretty
hot
topic.
So
first,
let
me
start
by
saying
typically
during
these
be
what
we
do
is
we
tend
to
kind
of
stew
tours
demoing.
The
recent
work
that
the
team
has
completed
during
our
priests,
previous
I,
would
say
sprint,
but
we
don't
do
sprints,
so
Kanban,
iteration,
I,
guess,
and
we
demo
that
word.
A
We
take
questions
from
the
community
and
over
the
last
few
months
we've
been
thinking
about.
How
do
we
make
sure
that
the
community
is
more
engaged?
What
we're
doing
has
better
feedback
channels
with
the
team
to
either
ask
questions
point
out
specific
opportunities
or
gaps.
They
see
the
PWA
studio,
and
this
was
a
conversation
that
I've
been
actually
recently
had
with
Jordan
Eisenberger,
who,
as
we
all
know,
is
the
community
maintainer
for
PWA
Studios.
A
So,
as
a
part
of
that
conversation,
we
had
talked
about
hey
and
maybe,
as
a
part
of
these
recurring
meetings
going
forward.
We
should
set
our
X
aside
some
time
to
essentially
do
a
community
corner
where
Jordan
as
a
community
maintainer
has
an
opportunity
to
present
a
topic.
Present
may
be
a
solution
present
some
work
that
the
community
is
doing
to
the
larger
audience
and
it
gives
the
community
an
opportunity
through
Jordan
to
kind
of
have
to
own
a
piece
of
this
agenda.
A
A
Actually
have
that
be
the
primary
topic
for
today,
given
the
nature
of
I,
think
this
conversation,
and
so
for
the
first
time
I
will
introduce
Jordan
on
the
call
to
kind
of
lead
us
through
this
topic
of
server-side
rendering
and
how
it
relates
with
PWA
studio.
We
have
seen
on
the
line
to
join.
We
have
Zeppelin
here
and
so
I'll
turn
over.
You
guys
can
get
it
either
started
there.
Yes,.
B
So
if
you
want
to
express
your
concerns
or
solutions
about
what
we
should
do
with
the
evil
SSR
problem,
this
is
the
time
to
speak
out
and
I.
Guess
I
just
want
to
hand
it
over
to
to
James
and
maybe
can
talk
a
bit
about
what
we
are,
where
we're
standing
right
now
with
SSR
in
in
studio
and
where
we're
planning
on
going.
C
Well,
I,
first
of
all
have
been
less
than
involved
in
the
conversation
that's
gone
on
so
far
in
my
PWA
community
chat
and
that's
partly
because
I'm
working
on
cool
stuff,
you
guys,
will
see
and
partly
because
sometimes
I'd
rather
listen
and
talk,
believe
it
or
not
and
just
speak
to
the
I.
Think
the
overall
point
that
you
guys
have
made
and
I
know
it's
not
just
Shane.
That
Shane
has
put
it
really
concisely
and
succinctly
is
full
SSR
seems
good.
C
C
C
And
so
it's
not
just
like
throw
one
tech
giant
in
another
to
say.
Google
is
moving
away
from
SSR
for
their
search
results
in
ranking
and
the
those
parts
of
the
kind
of
wider
social
graph
that
are
still
using
SSR
are
still
important,
but
they're
not
doing
search
ranking
with
it
they're
just
kind
of
gathering.
What
metadata
is
necessary
to
like
put
together
a
media
object
like
Facebook.
C
Whatever
so
getting
in
a
little
detail,
we
believe
that
server-side
renderer
is
not
going
to
be
worth
the
money
it
takes
to
implement
and
support
in
a
very
short
time,
but
we
are
realistic
people.
We
know
also
that
ecommerce
has
its
own
pressures
and
partners
as
well
as
the
merchants
have
kind
of
fiscal
responsibility
to
not
take
too
many
crazy
risks.
C
C
C
I
would
like
to
come
up
with
a
way
that
we
can
gather
the
data
that
proves
it,
which
is
what
I
know
that
you
guys
really
need
in
a
way
that
does
not
terribly
negatively
impact
customers
or
take
too
many
risks,
and
one
thing
that
I
think
is
really
helped
me
think
of
ways
to
do.
That
is
the
debut
of
Jordan's
store
eleganza,
which
leverages
render
bots
for
server-side
rendering.
C
What
I
like
about
that
is
that
it's
it
gets
to
what
the
merchant
needs,
which
is
a
really
pixel,
perfect
high
fidelity
server-side
render
the
pages
themselves
and
it
doesn't
improve
too
much
on
the
actual
development
of
the
app
I
preferred
it
to
react.
Server-Side
render
for
that
reason,
yes,
I
know
that
react.
Ssr
is
doable
and
capable,
and
pretty
fast,
but
I.
C
Think,
in
my
experience,
certainly
when
you're
working
at
an
agency
model
when
you
are
looking
on
comps
and
tried
to
get
them
visually
rice
and
you're,
trying
to
get
performance
metrics
in
the
in
terms
of
first
content
full
and
meaningful
paint
right,
sometimes
you
end
up
colliding
with
the
needs
of
the
server-side
render
to
load
the
application.
All
the
way
like
it's,
not
just
writing,
isomorphic
components
that
don't
use
the
window
object,
etc.
C
It's
also
that
your
app,
if
it
progressively
loads
it
can
be
hard
to
know
how
to
server-side
render
it
and
I
know
that
it's
doable.
But
not
everyone
is
not.
Everyone
is
JH,
so
I
prefer
the
idea
of
a
render
tron
approach,
because
real
quick,
my
proposal
would
be
that
even
the
future
SSR
is
a
needless
expense.
C
If,
if
we
can
show
that
they
get
the
same
rankings
with
that
which
costs
way
less
money
and
is
always
simpler
deployment,
then
we
can
start
bringing
people
aboard
and
what
what
I
think
we
could
do
is
create.
That
could
do
that,
but
then
put
render
tron
on
it
as
part
of
the
initial
deployment.
Maybe
this
isn't
for
a
merchants
full
experience
if
they're
their
home
site,
where
all
of
their
ranking
stuff
goes
and
all
the
reputation
score
goes.
C
Maybe
it
could
be
a
microsite
or
entry
into
another
markets
or
region,
but
but
my
idea
would
be
that
you
use,
render
Tron
or
pre-render
and
get
the
site
to
where
you
want
it
to
be,
and
then
all
right
off
see
what
happens,
because
the
act
of
turning
it
off
is
very,
very
low
impact
structurally
and
IT
wise.
You
just
turn
it
off
and
you
let
the
server-side
minimal
SSR
that
you've
implements
at
work,
and
you
see
if
the
rankings
persist.
In
my
view,
they
may
even
rise.
C
So
that's
the
vision
I
have
of
starting
to
prove
this
in
a
way
that
doesn't
sacrifice
too
much
client
risk.
That's
basically
the
thesis
that
I
come
to
here
with
and
then,
if
you
want
to
talk
about
the
particulars
of
why
I
think
this
and
what
we
would
do
in
studio
to
support
this
methodology.
I'm
all
yours.
C
B
C
B
D
B
C
Sorry,
yeah
I
think
we
can
test
this
only
by
gathering
enough
data
that
we
start
to
convince
people.
It's
like
it's
a
hill
to
climb
and
that's
why
I'm
saying
I
wouldn't
take
a
client
who
is
maybe
debuting
their
entire
site
as
a
redesign,
their
whole
online
presence,
because
that's
a
lot
of
risk
to
take.
If
they
take
six
months
and
achieve
good
rankings
and
ratings,
they
won't
want
to
risk
turning
off,
render
Tron
and
losing
their
rankings
and
ratings
in
there
they're
only
revenue
stream.
E
B
E
Sure
so,
I'm
probably
less
bothered
about
the
lightsabre
five-year
plan
because,
as
a
working
developer
for
clients
right
now,
I
need
just
five
answers
that
can
get
sliced
live.
We've
just
launched
another
one
recently,
it's
very,
very
large
b2b,
and
for
that
particular
client
and
I
know.
This
is
all
kind
of
anecdotes.
But
if
we
do
they
had
an
external
huge
SEO
company
come
in,
they
need
this
be
able
to
crawl
the
site.
There's
no
two
ways
about
it.
We
also
helped
another
site,
big
site
launch.
E
We
didn't
do
the
front
end,
but
we
we
recommended
render
to
onto
them,
because
they
came
back
to
us
and
said:
we've
done
the
react.
Application
and
all
the
people
are
trying
to
get
this
into
production
are
telling
us.
We
can't
do
it
until
we
can
crawl
the
site
so,
regardless
of
like
what
the
beautiful
future
is
with
Google
and
being
able
to
crawl
these
sites
without
any
SSR.
That's
not
for
me.
That's
not
a
relevant
conversation
right
now
and
I.
Don't
think
it
was
for
a
couple
of
years.
E
I
think
it's
definitely
and
valid
so
that
kind
of
brings
down
to
the
next
bit,
which
sounds
like
a
lot
of
people
assume
and
rightly
or
wrongly
and
I-
don't
know
everyone's
experience.
So
don't
take
this.
You
know
I'm
sort
of
guessing
here,
but
to
me
it
sounds
like
if
you
can
spin
up
a
render
Terron
proxy
and
have
everything
going
through
that
to
serve
to
boss.
E
You
can
add
the
two
or
three
lines
to
a
component
to
make
it
work
and
render
as
a
string
and
react
so
I
think
what
I'm
getting
at
here
is.
The
two
scenarios
are,
you
need
HTML
and
if
we're
saying
that's
the
case,
because
we
need
to
get
slides
into
production,
then
we've
got
two
other
approaches,
so
you
have
to
have
HTML
one
way
of
getting
hTML
is
to
run
render
tron
and
one
is
to
render
react,
components
and
I.
E
To
say,
we've
got
a
lot
of
experience
now
doing
this
and
the
making
of
components
able
to
be
rendered
and
on
the
server
his
room
is
we
found
not
not
huge
tags,
that's
all
now
that
and
the
benefits,
obviously,
and
by
the
way
Jordan
you
said,
I'm
an
advocate
for
SSR
I'm,
actually,
not
an
advocate
for
SSR
and
I
was
just
talking
to
Alex
Russell
recently
about
this
is
I'm
just
an
advocate
for
as
fast
as
possible
websites,
I
guess
and
we
launched
that
one
we
want.
We
launched
one.
E
E
So
that's
just
really
all
I
wanted
to
say
is
that
I
said
I,
think
sites
and
clients
are
gonna,
want
HTML
delivered
in
payloads
for
the
foreseeable
future,
whether
it's
one,
two
or
five
years
and
all
on
all
I
wanted
to
say
in
that
chat.
The
other
day
is
that
we
we
want
to
be
more
involved
with
Magento
and
Magento
is
pwh
studio
project.
We
really
want
to
do
that,
but
we
we've
seen
it
from
sort
of
first-hand
experience
that
it's
not
that
much
work
to
just
make
these
make.
E
If
you're
gonna
run
render
tron,
if
I
have
to
show
you
my
node
server,
that's
running
SSR,
it's
one
handle
in
Express
and
we
have
all
the
other
requests
going
handled
by
the
load
balancing
for
the
hit
there,
but
I
just
kind
of
wanted
to
put
this
idea
out
there,
that
is
it
really
complex
to
do
server-side
rendering
in
react
haze
it
do
you
have
to
render
the
entire
page.
That's
both
the
answer
to
both
of
those
is
now
you
can
selectively
render,
etc,
etc.
E
Okay,
so
that's
all
I
wanted
to
come
and
say
really
because
I
think
a
lot
of
when
I
talk
and
I
hear
like
work
working
developers
in
the
community
when
I
say
work
and
I
mean
like
for
clients.
You
know
they're
all
gonna
want
this
trust
me
like
they
need
HTML,
whether
it's
for
one
two
or
five
years,
I,
don't
know,
but
they
need
it
all
right.
F
Like
shades
that
every
every
agency,
who's
picking
up,
PW
a
studio
and
would
want
for
as
SS,
are
rendering
I
think
and
because
that's
what
the
clients
asked
for
and
that's
I
think
for
it,
for
you
guys
it's
it's
also
a
a
big
marketing
thing,
I!
Think,
because
every
if
you,
if
you
have,
if
you
start
a
project
new,
then
you
dude,
you
have
to
you
have
to
question.
F
C
G
What
I
guarantee
understand
is
currently
Google
pushes
us
to
have
PVA
applications
and
they
try
to
solve
the
crawling
issue
for
I
think
almost
a
year
or
two
years
for
JavaScript
applications
and
currently
ranking
getting
better
every
month.
If
you
have
a
full
JavaScript
application
and
currently
I'm
not
pretty
sure
if
a
server
branding
rendering
we
are
required
to
have
it
or
it
may
be
a
requirement
from
our
customer
because
most
are
getting
more
and
more
applications
without
server
rendering
and
Dave
rank.
E
I
think
there's
a
big
difference
and
we've
seen
this
over
the
last
year
between
just
using
the
term
ranking
as
though
you
know
like
Google
can
build
up
a
ranking
of
your
product
over
time
versus
the
crawl
ability
of
your
site.
So
it's
why
I
almost
wanted
to
frame
the
conversation
to
be.
You
have
to
first
decide.
Do
you
need
to
be
able
to
deliver
HTML,
forget
server-side,
rendering
and
render
Tron
to
get
a
site
into
production?
E
And
if
you
go
and
watch
the
talks
from
the
Google
engineers
who
work
on
search
that
headless
crawl
isn't
every
day
he
gets
queued
up
and
I'm
sure
over
time
it
will
be
it'll,
be
less
and
less
queued,
but
the
idea
that
you
can
change
a
site,
a
thing
that
something
on
your
site
and
it
be
reflected
in
30
minutes-
is
just
non-existent.
If
you're
completely
headless,
you
come.
If
you
don't
have
any
content
there.
You've
gotta
wait
until
Google
ass.
E
It
looked
at
your
site
and
said:
oh,
this
is
really
JavaScript
powered,
so
I'm
gonna
cue
you
up
to
be
rendered
on
the
next
time.
Headless,
Chrome's
free,
we're
gonna,
send
it
through
okay.
So
all
the
sites
I've
worked
on,
we
need
almost
immediate
feedback
and
that
that's
why
I
say
don't
don't
say:
SSR
versus
render
tron
say
right
now
to
get
into
production.
Do
you
need
to
be
able
to
deliver
HTML
or
not,
and
then
because
then
then
the
answer
becomes.
Then
the
question
becomes
sorry.
Well.
E
C
I,
ask
you
something
Shane
absolutely.
You
said
something
that
I
really
wanted
more
detail
on.
Maybe
we
can
do
it
later,
but
you
mentioned
that
when
you
are
doing
SSR
for
your
app,
you
don't
have
to
render
the
whole
thing,
and
that
was
one
of
my
concerns.
One
of
my
that
was
one
of
my
main
concerns
with
doing
at
least
using
react.
C
Html
out
of
the
box,
which
is
a
synchronous
method
on
the
on
the
type
of
application
of
the
PWA,
is
because
you
know,
as
people
have
observed,
like
we're
writing
tests,
you
need
to
figure
out
like
business
cases,
for
when
the
page
is
done
loading.
You
can't
just
like
wait
for
a
particular
event.
So
can
you
go
into
like
some
detail
about
how
you
organize
your
applications
so
that
you
for
each
given
type
of
page
or
entity?
You
know
how
much
to
load
it
and
get
to
probability,
and
then
you
stop.
E
C
Well,
yeah
I'm
just
saying
like
if
if
this
sounds
and
looks
really
good,
then
that
pushes
me
in
your
direction,
because
the
main
the
main
thing
I
should
say
and
Lars
I
want
to
clarify
this
with
you
is
that
I
still
believe
that
SSR
is
necessary.
It's
the
question
is
what
kind
and
Jordan
you
rat
on
me?
What's
the
point?
Is
s
are
so
we
definitely
need
to
deliver
HTML
as
the
language
of
the
web.
C
How
much
I
when
I
say
I,
don't
know
if
SS
are
with
you
know,
the
full
application
is
worth
the
money
in
the
future,
I
mean
like
every
pixel
or
every
Dom
element
we're
in
it
used
to
be
true
that
you
want
to
give
both
bots
in
humans
the
same
thing
or
you'll
get
you'll
get
dinged
for
you
know
for
a
user
agent
sniffing.
But
now
the
idea
is
it's
the
same
content
just
presented
in
a
different
structure.
So
for
us
all
right
is
in
an
increasingly
pluggable
way.
Just
with
upward.
C
You
can
render
a
minimal
page
with
content,
maybe
h1
tags
etc.
But
the
nice
thing
about
that
is
it's
cross-platform
that
not
nice
thing
about.
That
is
that,
even
if
it's
a
small
amount,
it's
a
different
render
pipeline
it's
through
this
template
thing
instead
of
react.
What
you're
saying
is
it
could
do
at
least
a
partial
render,
with
react
alone
right
and
that
that
would
be
nice,
because
that's
less
code,
so
I
would
be
I
would
be
interested
in
that
yeah.
E
We
were
both
able
to
give
HTML
and
reduced
JavaScript,
so
it
means
you
have
to
be
a
bit
smarter
about
certain
things,
but
in
reactive
it
really
can
be
as
simple
as
you
know.
If
anything
is
behind
a
it
can
be
a
boolean,
for
example,
in
a
component
that
says,
were
you
rendering
on
the
server
or
not
and
then
just
return
null,
and
that
will
stop
that
piece
from
being
server-side
rendering
right
beside
rendered.
E
Sorry
so
again,
I
don't
take
up
any
more
of
a
call,
but
I
could
I
come
happy
to
demo
the
site
we
just
launched,
which
is
a
great
example
of
this,
where
it's
extremely
lazily
hydrated,
and
that
means
that
we
just
deliver
the
HTML
needed
for
the
search
engines
and
for
all
the
SEO
agencies
that
we
work
with,
and
then
we
we
very
much
are
conservative
about
how
much
we
hydrate
on
the
client
and
we've
got
the
flame
charts
to
prove
em
blah
blah
blah.
So
it's
it's
cut.
E
It
kind
of
feels
like
the
best
of
both
worlds.
At
the
moment-
and
it's
not
again
you
when
you
say
it's,
it
sounds
more
work
or
is
it
as
much
work
as
having
to
run
render
tron
in
production
which
I
don't
know
Jordan
come
fill
us
in
on
that
I've
not
done
it
before,
but
yeah.
That's
that's
where
that's
where
we're
coming
from
and
then
when
I
brought
up
angular
and
reacts
the
reason
I
brought
that
up
is
not
because
they're
pushing
you
to
render
the
entire
web
application
with
every
Dom
node
every
single
time.
E
Also
yeah
I'm
one
less
thing
when,
when
Google
is
saying
to
people
like
AWS
building
applications,
just
don't
bother
with
server-side
rendering
I
can
almost
guarantee
is
because
99%
of
them
take
that
performance
here.
So
what
they're,
essentially
they're,
not
saying
don't
server-side
render
they're
saying
every
time
we
see
people
do
it.
The
performance
gets
worse.
Yeah.
E
C
Very
much
so
I
appreciate
it.
The
more
I
understand
about
the
partial
hydration
process,
the
better
my
concern
is
always
just:
can
it
be
maintainable,
so
I
want
to
give
Jordan
C
time
to
talk
about
making
the
red
Neutron
thing
easier,
but
I
also
want
to
ask
you
about
the
possibility
of
making
this
stepped
approach
easier?
Is
this
something
that
you
feel
like
you
could
abstract
into
libraries
or
tooling,
so
that
you
don't
have
to
be
I?
Think
the
word
you
used
was
smart.
E
H
E
Bit
right,
you,
the
rest
of
your
application,
doesn't
hardly
change
at
all
and
that
that's
really
why
why
we've
gone
with
it
again
on
this
next
client
and
while
we're
gonna,
probably
do
it
again
on
the
next
one
as
well,
because
getting
the
routing
bit
right
is
hard
granted,
it's
not
extra
code,
but
you
have
to
think
about
things
a
bit
differently.
Okay,
once
that
bit
was
solved,
we're
like
oh
well,
just
something
hidden
behind
a
lazy
loaded.
You
know
like
react,
dot
suspense!
E
C
E
Well,
only
for
the
gyro
is
over
yeah,
so
the
component,
the
component
that
you
guys
use
this
this
sorry,
the
same
query
that
you
guys
use.
We
just
do
that
before
we
even
try
and
render
anything
which
I
think
you
may
also
do
usually
then
yeah,
sorry
yeah,
but
so
we
do.
We
always
do
that
so
that
we
know
which
page
will
render
in
and
then
we
just
yeah,
then
we
go
and
we
go
from
there
really.
E
C
E
G
E
C
B
So
you're
totally
right
doing
random
tron
is
not
easy,
especially
if
you're
doing
it.
The
first
time
we've
invested
a
lot
of
hours,
and
today
my
colleague
Derek
gave
me
a
slack
and
he's
like
you
know,
we're
going
to
open
source
our
render
tron
solution.
He
called
it
SEO
snap,
which
is
probably
a
name
that
could
still
change
but
I.
Think
it's
a
good
one
for
now.
So
I
just
want
to
share
my
screen
real,
quick.
Let
me
check.
F
B
So
everything
is
I,
think
in
one
docker
container
and
just
gives
you
it
spins
up
some
servers
and
stuff
and
then
for
because
eleganza
told
me
like
I
need
a
dashboard
where
I
can
see
all
the
index
URLs
and
stuff
like
that.
You
also
get
that
in
our
in
our
package.
So
this
is
something
that's
still
in
I,
guess
of
our
maybe
even
data
and
that
we
are
going
to
ship
next
week
and
we
hope
you
guys
yeah.
B
E
F
Maybe
maybe
I
can
add
something
to
this
too,
and
we
also
use
a
prevent
a
solution.
It's
called
pre-render
IO
and
it's
it
it's
software
as
a
service
solution,
so
you
don't
have
to
host
it
yourself.
I
think
Brenda
Tron
is
also
available
as
as
as
a
software
service,
but
I'm
not
sure
about
that.
But
we
we,
as
I,
said
we
use.
This
is
the
solution
and
we
are
we're
fairly
happy
with
it,
because
it's
really
easy
to
set
up.
F
You
just
have
to
route
your
router
bots
from
directly
from
nginx,
for
example,
to
the
Tudors
and
to
the
service,
and
you
get
warmed,
cache
and
dashboard,
and
something
like
like
I,
see
on
the
screen
right
now.
You
get
you
get
there
two
for
free
and
not
for
free.
Sorry
about
that.
But
and
it's
it's
sounds
really
similar-
that's
similar
to
that.
So
maybe
someone
couldn't
and
we
have
we,
we
use
it
in
productions
and
it's
fairly
stable.
Yes,
yeah.
B
A
lot
of
control
over
the
code
because
we
are
planning
on
like
introducing
a
SMS
for
when
you
have
a
lot
of
500
codes
and
stuff
like
that.
So
just
doing
it
ourselves
and
having
full
control
over
all
the
caches
and
stuff
like
that,
and
just
enables
us
to
integrate
more
and
more
features
into
this.
And
yes,.
A
A
C
My
main
concern
with
anything
like
that
is
how
much
static
pre-rendering
needs
to
be
done.
I
mean
we
would
absolutely
have
made
PW
a
studio,
a
flavor
of
Gatsby
if
we
knew
that
we
were
only
dealing
with
like
four
digit
numbers
of
catalog
products,
but
we
are
dealing
with
six
and
seven
numbers
of
catalog
products
and
we
don't
want
them
feel
like
we
want
to
build
that
many
HTML
files.
So
that's
the
issue.
I
know
that
next
Jas
does
a
lot
of
server-side
render.
C
But
it's
you
know
it's
designed
basically
for
websites
that
either
do
simple
crud.
You
know
like
a
real
site,
or
you
know
brochure
where
there
are
great
advanced
version
of
next
sites
that
are
totally
better
than
that.
But
but
our
experience
was
it
didn't
really
fit
the
e-commerce
use
case
and
I,
don't
think
it
does
still.
F
I
A
I
would
say
that
high
level,
we
are
still
very
much
committed
to
the
open
and
transparent,
with
our
backlog,
we've
just
trying
to
figure
trying
to
figure
out
this
an
internal
tooling
system
in
the
automation
or
manual
process.
So
that's
been
a
relatively
new
thing.
That's
happened.
We
haven't
obviously
talked
about
on
this
call,
but
we
are
working
on
that
in
the
next
few
weeks
of
making
sure
that
we're
cleaning
up
the
backlog
we're
making
all
of
our
work
visible.
A
Obviously
we
we
demo
everything
during
these
calls
we're
very
transparent,
but
working
on
next
during
these
calls,
so
we'll
get
that
cleaned
up.
If
you
have
any
questions
about
what's
coming
up
next,
what
we're
working
on
we're
always
happy
to
answer
those
so
feel
free
to
ping
us
and
slack,
and
you
know
we'll
give
you
the
kind
of
in-depth
detailed
run-through.
H
Yeah
I
would
say
two
things
on
top
of
that,
we're
growing
up
really
as
a
you
know,
as
a
proper
product
with
intensity.
This
is
how
much
is
it
to
corroborate
ratings,
so
I
think
we're
looking
at
ways
that
we
can
still
be
as
transparent
as
we
have
been
relative
to
them.
I
think
the
other
part
too,
is
part
of
2020
priorities.
You
know
we
want
to
look
at
Parker,
LED
contribution.
H
We
see
that
there's
a
lot
of
value
and
things
like
SEO
staff
and
some
of
the
things
that
changing
the
clock
image
just
in
this
call
alone,
much
less
other
key
aspects
of
functionality
like
localization
and
then
others
that
we
talk
to
other
partners
that
have
been
interested
in.
It
really
helped
these
accelerate
this
as
a
viable
option
for
the
vetting
so
be.
F
G
A
G
My
main
point:
there
is
currently
it's
very
hard
to
start
with
contribution
and
the
project
I
picked
last
week,
outdated
ticket
and
Centreville
pull
request
their
invest
three
or
four
hours
for
making
disprove
fest
and
then
I
get
an
answer
on
my
pool
quest
year.
Sorry,
this
ticket
is
already
outdated,
we've
reflected
it
completely
and
sorry
for
that.
G
But
we
we
try
to
have
a
different
favorite
of
of
this
kind
of
component,
and
so
we
completely
were
affected
and
from
here
I
try
to
start
with
contribution
there,
because
I
really
like
the
project
and
I
really
like
react
and
try
to
do
things
there.
But
it's
not
so
easy
to
start
from
there
and
I
had
already.
A
Next
few
weeks,
as
we
this
process,
if
you
have
right
now,
you
ask
yourself
this
always
feel
free
to
reach
out
to
myself
James
Jimmy
any
of
the
team
here,
and
we
can
actually
point
you
in
the
right
direction.
On
on
where
we
would
like
contribution.
We
do
have
some
X
some
some
things
cleaned
up
at
the
backlog
and
we'll
get
there.
A
So
we
are
at
time
and
I
want
to
be
respectful
to
everybody
else's
time,
so
I'd
say
thank
you.
Everybody
for
joining
today,
I
think
was
great
conversation.
We
have
some
action
items
to
follow
up
on
some
conversations
to
follow
up
on
and
again
we
look
forward
to
the
future
community
sinks,
where
we
will
actively
include
this.
Apart
of
this
type
of
community
corner
community
corner
topic
during
the
during
the
call.
So
thanks
everyone
mash
legs
subscribe,
if
you
like
it
recording,
has
ended
yeah,
that's
how
we
always.