►
From YouTube: Community Engineering Hangouts - DevDocs
Description
Community Engineering Hangouts.
The aim of these hangouts is to update the community on all our progress and demo some new tools and features. For this live stream we have the following agenda.
1. News and updates from the Community Engineering team,
2. Overview of all the goings on with the Magento DevDocs team,
4. Live Q&A section,
During this hangout we will be showing you some of the progress on our DevDocs project.
Feel free to join in, comment and ask questions. The aim of these hangouts is to provide a platform for Magento to give the community regular updates but also for the community to give feedback to Magento.
For any more information feel free to reach us at engcom@adobe.com
A
This
time
we
are
talking
all
about
dock
and
I
am
very
lucky
to
have
the
part
of
the
amazing
dev
talks
team
with
us
who
are
going
to
show
us
everything
that
is
to
know
about
their
docks
and
I
believe
a
little
bit
about
the
upcoming
merchant
box
and
with
regards
to
open
source
and
contributing
of
those.
So
if
I
don't
want
to
take
up
moon
anymore,
other
time,
I'm
gonna
pass
it
over
and
yeah
I
hope
you
enjoy
and
remember.
A
B
B
Am
sure
you
Spangler
hi,
I'm,
Leslie,
silly
and
then
off
camera
we
have
Jeff.
Matthews
is
also
one
of
our
managers
here
and
Leslie
is
also
manager
and
leads
up.
The
merchant
docks
which
we're
gonna
have
some
awesome
news
about.
So
let's
jump
right
in
and
like
David
mentioned,
ask
your
questions,
we're
happy
to
answer
them
as
we
go.
We
have
a
PowerPoint
and
some
demos
to
provide,
but
we're
willing
to
go
off-script.
If
someone's
got
something
juicy,
they
want
to
know
about
documentation
all
right.
So
let's
do
this
thing.
Okay,.
B
So,
of
course,
you're
talking
to
the
documentation
team.
This
is
an
entire
group
that
covers
dev
Docs
as
well
as
merchants
Docs.
What's
Merchants
ducks?
That's
all
our
user
guides.
So
here's
our
quick
agenda,
we're
gonna,
give
you
a
tour
talk
about
contribution
a
little
bit
on
our
processes.
We
have
new
wiki's
posted
that
kind
of
go
over.
All
this
gonna
go
over
the
new
merchant
experience
for
content,
which
some
of
you
have
noted
on
Twitter.
Thank
you
very
much.
We're
also
going
to
talk
about
some
special
achievements.
B
D
All
right
so
I
want
to
give
you
a
quick
tour
of
dentox.
Our
site
has
a
lot
of
features.
Some
of
them
are
probably
invisible
to
you.
Sometimes
it's
hard
to
navigate
to
certain
areas,
so
I'm
just
gonna
do
a
quick
run-through
to
kind
of
educate.
You
want
some
of
those
features
so,
first
and
foremost,
we
have
our
version
switcher.
D
It's
super
easy
to
switch
between
versions.
Here,
click
it
and
go.
You
can
tell
which
version
you
are
on
as
soon
as
you
click
it
has
it
up
there
at
the
top.
2.3
is
our
default
version
at
service
recent
recent
version
search.
You
can
do
search
in
two
different
places
on
our
site
right
here,
the
very
middle
of
the
homepage.
D
And
it
takes
you,
it
gives
you
a
pre-populated
list
of
topics
you
may
want
to
see
super
easy
up
top.
We
have
our
main
menu
navigation.
Everything
cloud
is
in
one
place,
I'm,
including
release
notes,
which
I
think
is
important
to
mention.
We've
got
our
setup,
mostly.
The
installation
guides
config
guides
development,
everything
from
back
in
front
end
API
testing.
All
you
want
to
know
about
enough.
Yeah
functional
areas
is
an
important
area.
D
It's
where
you
kind
of
navigate
to
other
dock
sets
like
order
management
like
page
builder.
Sometimes
it
may
be
a
little
bit
difficult
to
find
these
areas.
First,
just
go
to
your
functional
areas.
You'll
see
them
all
in
one
list
super
easy
to
navigate
scrolling
down.
We
obviously
have
our
our
focus
areas
here.
Everything
you
need
for
setup,
which
is
also
kind
of
mimicked
in
the
top
navigation.
D
D
All
right
there
we
go
okay
back
in
action,
so
another
important
thing:
everyone
needs
to
be
able
to
look
at
quickly
easily
or
release
notes
in
what's
new.
We
have
them
in
our
release.
Information
section
here,
release
notes
is
a
really
richly
populated
area.
You
can
get
to
commerce
and
open
source
really
easily
from
the
net
left,
nav
or
also
right
here
on
the
page.
We
also
have
a
link
to
inventory
management,
graph,
QL
and
page
builder
release
notes.
So
we
try
to
make
these
easily
accessible
from
multiple
areas
in
our
documentation.
D
What's
new
just
gives
you
kind
of
an
overview
of
the
changes
that
we've
made
on
our
site
regarding
documentation,
we
leave
out
things
like
punctuation
grammar
spelling
fixes,
but
we
give
you
all
the
important
information
here.
Just
click
through
you
can
see
the
date
that
it
was
added
what
kind
of
update
it
and
we
even
have
an
RSS
feed.
So
you
don't
even
have
to
navigate
to
this
page
to
see.
What's
going
on
super
easy.
D
Contributor
guide
now
we
know
everyone
loves
to
contribute
your
contributions,
but
there
are
some
guidelines.
Some
things
to
follow
some
things
to
know
our
contributor
guide
contribution
guide
page
has
the
information
for
contributions
and
if
you
click,
Doug,
Docs
it'll
take
you
right,
and
so
you
get
hub
to
view
all
of
the
information
for
documentation.
Contribution
super
helpful
super,
easy
links
to
everything
you
need
to
know.
D
So
if
you've
been
contributing
to
code
or
dogs,
you
know
you
may
want
to
steer
your
face
here.
You
can
easily
sort
the
contributions
at
the
top.
We
have
regular
contributors
solution
partners,
maintainer
z'
you
can
sort
by
month
by
quarter
by
year.
Here's
your
drop
down
here.
Click
into
anybody's
get
hub
profile.
That's
listed.
D
D
Send
your
message:
you
can
add
an
email,
we
suggest,
you
add
an
email.
So
if
you
have
issues
with
their
documentation
or
questions,
we
can
respond
to
you.
We
can
get
in
touch
with
you
and
get
more
information
or
help
you
troubleshoot.
What
you're
doing
thanks
for
sending
your
feedback.
So
we
monitor
all
the
feedback
that
comes
in.
We
try
to
take
action
on
things
that
we
we
can.
You
know
change
quickly.
We
create
backlog
issues
for
things
that
we
want
to
track.
We
try
to
stay
on
top
of
it.
D
D
B
Okay,
so
really
quick,
oops,
some
reason
it
started
with
the
beginning
back
to
where
we
were
so
sure.
You
gave
us
a
great
kind
of
insight
to
how
to
look
at
the
documentation,
how
to
see
what's
been
contributed,
and
then
you
know
where
to
go.
But
a
lot
of
questions
come
up
at
contribution
days,
sometimes
through
slack,
like
you
know
what
is
doc
contribution
now
for
merchants
and
some
partners
and
and
product
folks,
that's
easy!
It's
what
the
heck
is
this.
B
If
I,
google,
it
can
I
find
something
that
tells
me
what
it
does,
but
for
developers
we
wanted
to
give
some
insights
on
when
you
might
need
a
doc
contribution.
Maybe
it's!
You
know
you
already
found
something
in
the
docs,
as
you
were
working
on
your
certification
test
for
Magento
or
when
you
know
you're
teaching
some
groups.
You
know
in
your
organization
or
customizing
some
work
as
a
partner
for
a
merchant,
and
you
find
things
that
aren't
quite
right.
So
you
may
enter
an
issue.
B
You
may
use
the
feedback
mechanisms
and
click
the
little
happy
frowny
face
at
the
bottom
and
provide
a
here's,
a
link
to
the
page,
and
this
is
just
wrong.
Some
of
you
are
even
better
and
say
you
know
this
code
snippets,
odd,
here's
a
way
of
maybe
fixing
it
or
we
could
use
more
info
on
this
item.
So
we're
going
a
step
further
and
starting
to
really
help
everyone
who
does
code
contributions
understand
when
you
contribute
code.
Are
you
actually
hitting
the
doc,
for
example,
some
of
you
that
are
working
in
Magento
core?
B
You
know
providing
count
of
updates
to
magenta
to
codebase,
you
may
add,
or
modify
a
feel
you
may
add,
or
modify
an
option
into
a
field.
For
example,
we
recently
added
elasticsearch
support,
and
then
we
changed
some
of
the
options
listed
to
show
that
well
we
had
update
the
docs
for
that.
That's
real
important.
Maybe
you
added
a
CLI.
You
know
a
command
line
item
or
added
or
change
some
of
the
functionality
for
some
of
those.
A
good
example
is
MSI
now
known
as
Magento
inventory
added
a
whole
bunch,
a
slew
of
reservation.
B
Cl
is
for
232
and
that
required
documentation,
so
they
new
added
a
ticket,
and
we
got
that
documented
and
anything
that
deals
with
api's
graphically.
Well,
please,
that's
a
doc.
Let
us
know
we
have
an
incredible
group
working
with
Kevin
Harper
on
that,
as
well
as
their
Warren
was
helping.
So
thank
you
very
much
for
those
contributions.
You
find
a
bug.
You've
worked
on
it
and
it
may
be.
You
might
want
to
update
the
doc
because
you
changed
a
method
or
you
added
a
module
for
it.
Let
us
know
our
code
samples.
B
We
always
welcome
those
and,
of
course,
module.
Read
nice
there's
not
many,
so
we
could
really
use
those.
But
how
do
you
contribute
well?
A
lot
of
folks
have
had
some
fear
of
contribution
and
it's
a
lot
easier
than
you
think
you
could
contribute
using
the
tried-and-true
developer
method
of
using
git.
We
have
tons
of
information
walking
through
this.
We'll
show
you
some
of
those
guides.
You
basically
just
want
to
fork
the
dev
Doc's
repo
or
the
new
to
come
mercs
repo.
Coming
soon.
You
want
to
create
a
branch
you
want
to
work
on
it.
B
Typically,
on
your
local
we're
gonna
walk
through
Don's
gonna.
Give
you
an
incredible
overview
of
how
to
set
up
your
IDE
and
text
editors
for
this
once
you
edit,
the
content,
it's
actually
just
normal
plain
English,
with
a
little
bit
of
tiny
formatting,
it's
not
even
as
taxing
and
say
HTML,
it's
like
writing
a
gist
if
you've
written
a
gist
or
a
readme,
you're
good
to
go
with
working
in
our
dev
Docs.
You
just
then
push
your
branch
fill
out
the
PR
content.
B
We
please
ask
you
to
do
that
and
then
we
review
it
with
our
side.
The
only
test
we're
running
right
now
are
links
we're
going
to
expand
on
that
and
then
literally
within
a
week,
you
may
see
your
stuff
live,
that's
faster
than
everyone
else
right.
If
you
are
not
a
fan
of
get,
maybe
you're
new
to
it
or
you
just
want
to
edit
one
tiny
file.
B
We
also
have
wiki's
that
go
over
all
this
and
I'll.
Show
you
those
in
a
second
but
say
you're
like
nah
I,
don't
want
to
contribute
I'm
a
little
scared,
or
maybe
you
want
to
be
really
awesome
and
get
like
double
awesome
points
in
our
book,
and
you
want
to
create
an
issue
to
match
with
your
PR,
which
would
be
fantastic
if
you've
been
watching
changes
going
on
in
community
engineering,
we've
added
a
streamlined
issue,
backlog
project
in
all
of
our
special
projects,
there's
also
a
backlog
for
community
engineering.
B
B
Okay,
you
see
my
slides
yeah,
okay!
Well,
my
apologies!
Let
me
go
back
here,
so
you
see
the
slide,
it's
an
awesome
slide
and
when
you
should
write
content,
I
talked
about
that
a
moment
ago,
I'm
really
sorry
and
how
to
contribute.
Look.
It's
real
simple
with
these
cool
little
diagrams,
there's
wiki
guides
for
this
show
them
in
a
moment.
B
So
here
we
are
the
backlog,
okay,
so
the
ready
for
grooming,
that's
where
the
doc
team
is
going
to
look
at
each
of
the
these
maintained
errs
can
also
provide
feedback
and
research
and
information
once
we
feel
there's
enough
information
in
the
ticket
it'll
move
to
ready
for
development.
If
it
has
a
good
first
issued
tag,
it
automatically
goes
there
if
you're
a
contributor,
you
just
come
here,
grab
directly
from
ready
for
development
or
a
good
first
issue.
The
moment
you
claim
it.
B
B
Don't
want
to
take
up
a
lot
of
time,
though,
and
head
over
to
our
next
wonderful
person,
which
is
going
to
be
Luke
myself
again,
it's
Friday,
but
if
you're,
if
you're,
watching
this
recording,
it's
a
Friday,
pardon
me
okay,
so
we
have
a
ton
of
dock
projects
available
for
you
to
take
part
in
the
developer
Docs,
which
Sheree
did
an
incredible
overview
with
we're,
always
looking
for
content
there.
We
have
a
dev
Docs
repo
that
provides
all
the
issues
like
I
showed.
We've
got
that
backlog.
B
B
We
also
are
going
to
have
additional
projects
coming
up.
I
know:
there's
some
Adobe
integrations
that
may
also
welcome
documentation
contributions.
We
look
for
tutorials
code.
Examples,
general
overviews,
anything
you
feel
like
you
have
the
knowledge
and
you
want
to
help
us
impart
it
to
the
world.
Please
join
in
and
then
for
merchants
content.
That
is
our
user
guide.
We're
about
to
have
this
fantastic
overview
on
this.
B
D
D
They
tend
to
be
a
little
bit
bigger
than
your
normal
issue
and
then
maybe
issues
that
we
need.
Assistance
on
these
are
a
high
priority
for
us
we've.
Also,
given
you
a
generous
amount
of
points
for
working
on
one
of
these
issues,
our
20
points,
which
is
pretty
stellar
and
that's
on
top
of,
if
you've
done
a
major
update
or
an
editorial
change
or
whatever
that's
on
top
of
those
points.
So
you
get
a
plus
20
points
on
top
of
whatever
you
would
normally
get
I
want
to
show
you.
D
We
just
created
a
Most
Wanted
project
that
allows
you
to
easily
just
pick
shoes
right
from
the
project.
You
don't
have
to
look
for
the
label.
You
don't
have
to
search
for
anything,
simply
go
to
github
click,
the
project's
tab.
We
have
a
Most
Wanted
project,
pre-populated,
currently
with
7,
to
do
items.
D
Simply
just
pick
one
check
it
out,
navigate
your
own
start
working,
so
we
have
some
ideas
to
help
motivate
you
besides
the
points,
if
you
do
a
special
achievement
every
month
for
a
whole
quarter,
we're
gonna,
send
you
some
swag
I
can't
tell
you
what
that
is.
Yet
it's
a
surprise,
but
you're
gonna
be
happy.
We
also
call
you
out
on
Twitter.
We
know
that
you
like
to
beat
your
own
chest.
Tell
everyone
about
all
the
great
work
you've
done.
We
want
to
recognize
that
we
want
you
to
feel
like
that.
D
Your
your
work
is
warranted
and
needed,
and
it
is-
and
we
love
it-
that's
why
we
created
this
project.
That's
why
we
created
a
special
achievement
label.
Essentially,
we
need
your
help.
We
want
your
help
and
we
want
to
make
it
easy
for
you
to
nab
those
issues.
You
can
also
easily
go
to
the
issues.
Tab,
click,
the
labels,
drop
down,
search
for
the
label,
select
it
and
they
also
just
appeared
on
the
list.
D
If
you
have
any
questions
about
the
special
achievement
label
hit
us
up
on
twitter
at
Magento,
duck
docks,
we're
gonna,
be
promoting
it.
A
little
bit
more
in
the
coming
weeks,
so
you'll
likely
see
specific
issues
highlighted
specific
call-outs
for
help.
If
you
see
something,
that's
up
your
alley,
don't
be
afraid
to
Navitus
tweet
back
at
us,
I
manage
that
Twitter
account
I'm
on
this
side
of
things.
So
if
you
want
to
talk
about
any
of
it
just
to
us
up,
that's
our
special
achievement.
D
E
E
Later
on,
oh,
this
is
my
first
community
livestream,
so
I'm
excited
to
be
here.
My
name
is
Leslie
telling
I
am
one
of
the
dock
managers
here
at
Magento,
and
my
specific
focus
has
been
on
the
merchant
documentation
to
bring
it
up
in
step
with
our
dev
Doc's.
You
will
have
an
enjoying
really
good
depth,
docs
experience
in
the
past,
and
we
want
to
make
that
happen
for
you
for
the
merchant
docks
as
well.
So
we,
this
is
a
very
long-term
project.
E
Our
primary
project
objectives
have
been
to
improve
the
overall
merchants
experience,
enable
community
contributions
yay
and
provide
for
publishing
scalability
for
ourselves
and
to
be
able
to
get
those
contributions
and
be
able
to
publish
them
quickly
and
also
in
the
course
of
all
that,
getting
higher
quality
merchant
annotations,
so
we've
hit
our
biggest
and
first
major
milestone,
and
that
is
we
did
launch
our
markdown
Jekyll
docks
for
the
2.3
user
guides.
This
was
deployed
for
the
2/3
to
GA,
released
on
Tuesday,
very
excited
about
that.
E
In
case
you
haven't
noticed
you
can
go
check
it
out.
It's
all
generated
out
of
markdown
source
files.
It's
currently
in
a
private
git
repository
managed
by
the
Adobe
infrastructure
da
just
so
that
we
can
spend
a
little
time
working
things
out,
working
out
the
workflows,
making
sure
everything
works
just
as
exactly
as
we
want
it
to
and
then
and
it
also
we've
built
in
support
for
all
the
CIC,
be
publishing
and
everything
that
deaf
Doc's
uses
and
the
hata
feedback
with
the
smiley
face,
which
is
shree's
favorite
feature.
E
We
do
also
have
our
own
little
selector,
but
instead
of
a
version
selector,
we
have
an
addition
selector.
So
if
you
want
to
go
between
the
open-source
guide,
the
commerce
guys
are
the
b2b
side.
You
can
do
that
right
here.
Are
you
seeing
and
then
we've
got
a
lot
of
the
same
navigational
features
we'll
be
expanding
this
as
we
go
in
and
we
kind
of
address
our
information
architecture
going
forward.
E
A
lot
of
this
is
going
to
kind
of
grow
and
change
according
to
customer
feedback,
but
in
the
meantime
we
just
are
really
excited
that
we
can
provide
just
an
overall,
better
look
and
feel
for
everybody
going
forward,
and
so
what's
next,
we
are
in
the
process
of
while
we've
still
got
it
in
our
private
repository
of
creating
get
issues
and
a
backlog
items
for
people
to
work
on
both
internally
and
in
from
our
community.
We're
going
to
be
testing
all
of
those
workflows.
E
We
wanted
to
support
contributions
not
only
from
our
great
dev
community,
because
we
know
they
also
have
great
merchant
dock
contributions
to
make.
We
also
want
to
encourage
non
developers
to
be
able
to
contribute
to
this
documentation,
so
we're
going
to
test
some
workflows
and
try
to
enable
people
to
feel
comfortable,
even
just
editing
directly
and
getting
up
like
Laurie
was
mentioning
it's
a
really
easy
bard
across
to
be
able
to
will
have
that
same
link.
E
E
Work
on
we're
going
to
institute
all
of
those
best
practices
here
as
well,
so
we
are
planning
to
launch
this
into
a
public
repository
in
September,
yay,
very
exciting,
and
just
what
you
want
to
do
when
summer
is
coming
to
an
end
right,
and
that
is
it.
I
am
I
hope
that
everybody
is
going
to
be
pretty
excited
about
that.
The
Birdie.
B
E
B
C
C
Generate
the
text,
but
we
use
some
common
editors
like
Adam
and
Visual
Studio
code,
because
Magento
is
a
PHP
based
app
there's
a
lot
of
phpstorm
users,
but,
like
I
said
it
doesn't
really
matter
what
it
is.
But
I'm
going
to
show
you
a
couple
and
show
you
how
the
editing
workflow
works
through
these
editors,
like
they
do
every
day
here.
C
The
main
thing
that
we
work
in
is
Visual
Studio
code,
and
this
is
a
free
open-source
editor
for
Microsoft,
with
a
big
ecosystem
with
extensions
and
things,
and
this
is
kind
of
what
many
of
us
use
every
day
in
our
dev
Docs
editor
and
my
general
day
kind
of
looks
like
this
and
markdown
or
in
Visual
Studio
code
with
the
dev
Doc's
repo
open,
but
I
also
wanted
to
talk
about
before
we
get
started
with.
That
is
the
extensions
that
we
use
that
really
make
big
differences
in
our
days.
C
C
We
have
here
for
for
a
repo,
and
then
we
have
some
git
github
pull
requests
and
get
lands.
These
are
all
and
a
git
helpers
that
give
us
insight
into
our
PRS
and
such,
and
you
can
see
those
here
where
I
can
see
all
the
PRS
that
are
assigned
to
me
and
I,
told
those
PRS
indirectly
or,
if
they're
assigned
to
me
on
github
they'll,
show
up
in
this
list,
and
so
it's
a
quick
way
to
get
to
files
that
are
kind
of
in
your
wheelhouse.
C
Whether
they're
waiting
for
your
review
assigned
to
me,
created
by
me,
it's
very
helpful
and
thus
get
lens
shows
you
kind
of
where
you
are
in
the
repos,
because,
though
this
is
a
little
more
complex
than
most
because
of
the
way
we
you
set
our
multi
repo
setup.
Here,
we
pull
in
a
lot
of
repos
to
build,
get
Docs
and
you
can
kind
of
see
the
state
ran
to
kind
of
give
you
a
sense
of
where
you
are
in
the
repo.
This
other
get
one
here.
The
source
control
forget.
C
This
is
very
helpful
because,
when
you
make
edits
stay
on
this
file,
any
kind
of
you
save
a
file
it'll
show
up
in
a
changed
file
and
then
from
there
you
can
stage
it.
You
can
make
your
commit
messages
here
and
then
push
it
to
the
server.
So
I
spend
a
lot
of
my
time
and
all
day
here,
pushing
and
pulling
and
syncing
from
here
you
can
stash
within
this
du
commits
undo,
commits
as
a
very
helpful
window
that
we're
in.
C
C
The
main
the
one
we've
talked
about
because
we
spend
all
day
working
in
markdown,
is
the
markdown
linter,
and
what
that
does
is
is
it's
a
set
of
rules
that
are
kind
of
in
the
markdown
world
that
we
to
check
syntax
or
linting,
so
in
the
conversion
process,
when
we
run
it
to
our
build
process,
we
convert
markdown
to
HTML
and
we
need
to
make
sure
everything's
kind
of
lined
up
and
literally
in
the
right
way,
so
that
conversion
process
process
happens
smoothly.
It's.
C
C
What
we
see
in
git,
if
we're
in
the
editing
view-
and
it
looks
like
this-
so
here's
the
raw
markdown
and
a
lot
of
you
that
I
think
directly
in
this,
so
we're
going
to
talk
about
this
more
later,
so
this
is
kind
of
what
we
see
here
and
all
looks
well
and
good.
But
if
you
spend
some
time
with
the
markdown,
linter
you'll
see
the
errors
that
are
inherent
here
in
this
in
this
file.
C
C
In
here
spell
check
and
markdown,
and
when
we
see
green
underlines,
those
are
errors
and
if
we
hover
over
them,
we'll
get
a
little
pop-up
and
I'll
tell
you
what
the
error
is.
So
this
was
blank
lines
are
around
headings
generally.
The
idea,
when
you're
doing
editing
in
markdown
there's
spaces
between
everything.
So
we
can
look
at
this
and
go.
There
should
be
a
space
between
all
headers
and
that
cream
it
that
will
go
away,
we'll
also
see
and
the
problems
tab.
C
If
you
open
your
your
command
panel
down
here,
here's
also
a
list
of
the
errors.
These
the
markdowns-
and
these
are
spellcheck
words
errors.
You
can
see
here
there's
a
lot
of
hard
tabs.
If
you
see
hard
tabs
in
here,
that's
legacy
code,
so
this
is
coming
over
from
earlier.
Can
conversion
projects
and
legacy
code,
the
tabs
are
generally
not
wanted
in
markdown
it'll
work,
but
we
try
to
get
rid
of
them.
So
we
can
see
here
we
have
quite
a
few
hard
tabs
in
here
and
in
Visual
Studio
code.
They
show
up.
C
C
There's
other
errors
such
as
ordered
lists
like
this:
they
should
all
be
ones
and
then
the
conversion
process
takes
care
of
the
numbering
automatically.
So
I
spent
a
lot
of
time
kind
of
doing
this,
and
now
that
green
arrow
is
gone
away,
because
both
errors
are
gone
from
that
line,
so
that
one
line
had
two
errors,
and
so
this
is
very
helpful.
I'm
doing
this
all
day
as
checking
these
marked
out
linting
and
getting
rid
of
these
little
lines
and
then
in
a
perfect
file,
this
problem
should
be
down
to
zero.
C
C
Anyone
can
install
it
and
get
it
and
use
this,
and
this
will
generally
raise
the
quality
of
submissions
before
they
get
to
us,
which
is
kind
of
what
we're
trying
to
do
is
ensure
that
the
PRS
are
high
quality
when
they
get
to
us,
and
that
saves
us
time
and
back
and
forth,
and
so
we
can
get
things
merged
quicker.
So
we
do
have
some
exceptions
and
things
that
we
can
and
we
published.
These
will
have
these
in
contribution
guides
where
you,
so
you
can
kind
of
follow
along.
C
There
are
things
like
first
heading
should
get
top
level
heading.
That's
one
rule
that
we
don't
really
use,
or
we
have
an
exception
for,
and
that's
talking
about
these
headers
here
the
title,
the
h1
tag
we
get
from
a
title
tag
up
here
at
the
top,
so
we
don't
have
to
have
that.
So
if
we
were
checking
against
it,
it
would
show
up
as
an
error,
but
so
now
we
can
exclude
those
kind
of
rules
and
we'll
publish
the
exclusions
that
we
use,
so
we
rock
and
a
bottom.
C
So
when
we
get
good
a
markdown
and
we
see
or
when
visualize
the
errors
that
are
showing
up
here,
it
makes
a
lot
easier
to
edit
it.
And
that
means
when
you
come
back
here
and
in
kind
of
the
normal
workflow,
if
you're,
just
making
one-off
edits
within
github.
Now
you
can
see
that
these,
how
the
errors
kind
of
pop
up-
and
you
can
see
these
big
spaces,
but
we're
going
to
talk
about
this
more
a
little
bit.
C
C
E
C
So
part
of
the
reason
I'm
telling
you
this
is
because
we
have
steps
in
the
pipeline
that
will
do
this
checking
in
our
testing
environment.
So
these
checks
are
gonna
happen
in
our
build
process
anyway,
and
they
will
start
breaking
builds
or
we
will
have
to
go
back
and
fix
these
errors
to
all
the
tests
and
get
the
green
check
and
be
able
to
merge.
C
So
in
the
future,
all
yours
will
run
through
these
linting
gauntlets,
and
so
the
sooner
you
start
and
knowing
the
rules
and
knowing
how
to
get
rid
of
all
the
errors
that
will
smooth
the
process
coming
up
so
they'll
be
linting
is
in
the
pipeline.
Spell-Checking
is
in
the
pipeline,
and
the
last
one
that
we
gonna
do
is
image
optimization,
which
we'll
talk
about
a
little
bit,
we're
trying
to
come
up
with
a
way
to
have
images
optimized
before
they
get
into
the
github
kind
of
ecosystem.
C
You
say
before
they're
into
a
PR
into
a
commit,
and
that
has
to
do
is
file,
size
and
repo
size,
binary
files
like
that
take
up
a
lot
of
space
and
the
github
repo
and
if
they
start
smaller
the
whole
repost,
a
smaller
that
checking
will
come
in
in
the
coming
months,
I
think
and
so
we're
gonna
publish
ways
where
we
can
get
images
optimized
before
online
optimizers
and
other
ways
of
optimizing.
So
we
keep
the
codebase
manageable
and
that's
a
link
to
this
file
that
I've
been
showing
you
in
the
different
different
views.
C
So
we
talked
about
I
surmise
that
a
lot
of
you
spend
a
lot
of
time.
Editing
the
one
offs
directly
in
github
through
the
get
up,
UI
and
I
have
some
examples
of
kind
of
how
to
look
at
this
Barre
code
and
see
kind
of
see
through
the
code
and
see
the
errors,
and
so
I
have
some
examples
here
of
pages
from
the
repo
where
this
is.
C
E
C
C
Here's
the
tabs
that
show
up
as
big
gaps
between
either
the
number
for
the
ordered
list
or
the
or
star
for
the
unordered
list.
I
showed
you
an
example
have
an
ordered
list.
It
should
be
all
ones
and
then
we
on
the
on
the
back
side,
handle
the
automatic
number
generation.
So
you
don't
have
to
keep
editing
those.
C
So
now
we
can
see,
we
already
have
one
two,
three,
four
five
ones.
There's
another
error,
this
code
block
generally
you
can
the
basic
rule
is
you
need
a
space
between
each
type
of
content,
so
there
needs
to
be
a
space
between
code
blocks
here
and
the
code
around
it.
So
it
needs
to
be
a
blank
line
here.
I
see
that
if
you're
in
a
code
block
right
here
in
a
bash
code
block
this
doesn't
need
to
be
indented
that
far
over.
C
So
this
can
come
way
back
in
and
we'll
talk,
maybe
I
can
show
you
windmark
down
preview
out,
there's
very
help.
We
have
tools
that
help.
You
know
when
you've
indented
correctly,
so
you
can
make
sure
that
these
are
going
to
show
correctly
in
the
end
result.
So
here's
another
one
where
you
need
a
space
between
the
code
block
and
the
number.
So
why
I'm
showing
you
this
is
because
a
lot
of
times
you're
going
to
want
to
make
a
change
to
some
code.
C
C
So
this
is
part
of
getting
higher
quality
submissions
in
as
early
as
possible,
find
these
recognize
the
errors
and
fix
them
as
early
in
the
pipeline
as
possible.
Saves
work
for
everybody,
but
here's
another
example.
If
you
look
at
this,
you
can
already
see
the
ones
that
we
did
last
time.
There's
the
ordered
list
that
have
the
numbers
in
should
all
be
one
single
space
after
lists
spacing
around
code
blocks.
C
If
you're
in
a
code
block
this
indentation
comes
way
in
here's,
where
a
missing
code
block,
where
we
have
three
ticks
but
no
type
of
code
block,
and
what
these
do
is
tell
us
what
kind,
how
to
color
code
what's
within
the
blocks,
for
instance,
the
it's
a
bash
type
like
this.
That
adds
the
dollar
sign
at
the
start
of
the
line,
but
it
won't
copy
it
when
you
select
the
line
and
then
you
would
use
terminal
for
output
where
you
don't
want
that
little
dollar
sign.
C
So
these
are
very
specific
for
code,
coloring
and
readability.
So
you
can
see
that
there's
a
missing
code
block
there
if
you're
in
a
code,
block
this
space
and
come
in,
because
this
just
pushes
out
the
width
of
the
page
unnecessarily,
it's
just
extra
whitespace
up.
It's
not
needed
here's
another
space
around
code
blocks.
C
Now
you
can
see
here
in
these
code
blocks
down
below
this,
my
sequel
user,
one.
It
doesn't
have
a
code
block,
but
it's
kind
of
double
indented
and
when
you
indent
this
kind
of
code
enough,
it
will
turn
into
a
kind
of
a
generic
code.
Block
and
I'll
show
you
how
you
can
preview
that
in
the
editors
and
then
one
more.
C
Give
you
a
chance
to
look
for
some
errors
again
we're
changing
content-type
generally,
you
want
to
space
them.
There
lot
of
white
space
here
and
a
code
block
pull
that
in
here
are
some
more
tabs
or
maybe
they're
just
two
spaces,
but
these
should
be
one
one
or
two
spaces
between
the
bullet
type
and
the
content.
C
C
E
C
Can
see
it
will
convert
the
headers
for
you,
you
can
ensure
that
those
are
right.
It'll.
Do
the
bullets
properly!
Here's
an
example
of
the
indentation
where,
if
the
indentation
is
correct,
you'll
get
the
code
block
around
it,
but
if
it's
off
by
one
it
won't
do
it.
So
this
is
very
helpful
for
keep
adding
spaces
and
eventually
you'll
know
when
you're
at
the
right
place
and
again,
if
it's
especially,
if
you're
trying
to
do
a
code
block
within
lists.
C
Go
even
further
so
here
I
have
to
get
rid
of
the
two
tabs
and
then
I
keep
coming
in
and
gets
six
and
then
you
know
when
it
switches.
Now
your
your
formatting
is
correct,
so
these
previews
are
very
helpful
or
kind
of
visualizing
your
markdown
again
it
doesn't
do
a
lot
of
the
ending
styles.
It
just
does
pure
kind
of
markdown
formatting,
but
it's
a
helpful
way
to
to
have
it
an
atom.
We
also
have
it
as
well
packages,
markdown
preview,
toggle
preview
and
you
can
stay
making
sure
you're
right.
C
This
was
a
little
interesting
page
because
you
can
see
there's
some
there's
some
things
that
happen
that
are
interesting
notice
in
line
to
hear
this
CD
and
then
to
kind
of
a
generic
web
server
on
the
preview.
It
doesn't
show
up
and
that's
because
it's
thinks
this
is
a
tag
and
it's
not
handling
it
correctly.
But
if
we
space
it
in
enough
and
that
converts
to
a
code
block,
then
we'll
be
able
to
see
the
whole
line,
that's
funny
the
same
file
in
Visual
Studio
code
handles
it
correctly.
C
So
we
can
see
here,
it's
it's
doing
it.
So
it's
just
an
interesting
little
difference
between
editors,
but
these
previews
I
meant
on
these
previews
a
lot
too
just
to
make
sure
that,
because
markdown
is
so
formatting
specific,
this
is
a
very
helpful
feature
that
not
we've
been
surprised.
How
many
people
didn't
know
it
was
there
so
free
feature
for
you
and
that
I
think
is
awesome.
B
Thank
you,
doctor
and
I
know.
There
was
a
lot
of
info
quickly.
So
when
you
watch
this,
you
might
want
to
pause
here
and
there,
but
towards
this
end,
what
we
wanted
to
wrap
up
with
is
some
resources,
and
then
you
know
check
in
on
some
questions
that
may
be
coming
in
so
I'm
going
to
go
ahead
and
share
my
screen
again,
it's
median
folks.
So
to
help
out,
we
have
added
a
new
wiki
area
to
the
dev
Doc's.
B
Also
when
the
merchant
content
repo
goes
live,
it's
also
going
to
have
its
own
wiki,
and
this
is
to
help
out
with
all
these
kind
of
questions
and
thoughts,
for
example,
although
that
incredibly
interesting
information
about
how
to
format
your
your
markdown,
we
do
have
templates
and
content
available
in
the
dev
Doc's
in
the
contribution
guide
that
Sheree
had
pointed
out,
but
we
also
now
have
some
of
just
the
the
high
level.
What
you
need
to
know
to
just
get
started
documented
in
here
really
quick,
fast,
easy
information,
some
of
it
in
a
code
format.
B
That
way,
you
can
just
literally
see
what
it
should
look
like
when
you
type
also
with
some
of
these
IDE
s.
If
you
use
something
like
Adam
or
Visual
Studio
code,
there
are
tricks
and
settings
you
can
enter
just
for
markdown
in
specific
markdown
extensions.
That'll
do
all
of
this.
For
you
and
that
way
the
linter
doesn't
go
crazy
on
you
and
you
feel
awesome
and
you
get
more
gold
stars
from
us.
We
also
included
some
really
quick
info
on
like
how
the
heck
do
you
put
an
image
in
here.
B
We
we're
cool
with
images,
maybe
not
all-
of
the
images
but
tried
to
give
some
insights
on
how
those
go
in
what
they
look.
Like
also
note,
this
one's
always
a
biggie
people
wondering
how
do
you
put
a
note?
You
might
see
very
different
examples
of
code
around
it.
It's
because
some
notes
get
really
huge
and
some
are
small.
This
is
the
easy,
quick
throw
it
in
and
type
whatever's
right
immediately
after
this
info,
and
you
can
change
info
to
tip
or
warning
you're
good
to
go
and
then
links
to
all
the
extended
descriptions.
B
Also
in
the
wiki.
We
have
our
pull
request
process
that
I
had
hinted
at
earlier.
This
gives
you
the
very
clear
walkthrough
for
maintained,
errs
contributors,
the
team
itself
on
how
to
submit
your
PR,
but
goes
in
a
little
deeper
into
additional
pieces
like
what's
new.
You
may
have
been
like
what
the
heck.
Why
do
you
guys
add
that,
at
the
end,
when
the
PR
is
going
through?
Well,
it
automatically
adds
that
to
our
what
needs?
B
What's
new
page
of
changes,
sort
of
like
a
walking
change
log
on
a
weekly
basis,
so
we've
provided
some
info
in
there
as
well
as
how
we
are
reviewing
these
P
of
bars.
What
happens
in
this
black
box?
We
actually
use
a
project
and
we're
going
to
start
adding
some
Automation
behind
it,
but
for
right
now
it's
a
little
manual
and
we
work
with
maintain,
errs
and
you'll
you'll
be
able
to
go
to
this
project.
It's
not
hidden,
it's
not
a
big
secret.
We
add
your
PRS
here
to
this
backlog.
We
pull
them.
B
We
start
to
review
them.
Maintain
errs,
provide
their
insights.
Writers
also
provide
some
reviews
that
goes
into
the
needs
right
or
approval.
If
we
are
all
a
good
sign
off,
it's
ready
to
go,
we
put
it
into
Jenkins
testing
right
now,
we're
only
testing
links.
This
is
something
we
do
on
our
side
and
then
once
it
passes,
we
merge
it.
It's
done
and
automation
will
automatically
run
the
publication
process
and
update
Deb
Docs
within,
like
I,
think
it's
every
hour,
it's
running,
so
it's
a
very
fast
turnaround
and
the
moment
you're
merged.
B
You
get
points
added
to
yourself,
as
well
as
your
partner
and
you'll
notice.
Some
of
these
partners.
It
works
just
like
in
she,
come
as
behind
the
scenes,
so
it
takes
all
the
questions
out
of
it.
We
also
included
tips
for
making
incredible
PRS,
and
you
know
what
really
helps
us
and
how
to
get
in
contact
with
us
and
also
Don,
who
was
just
giving
us
this
great
information
on
I
des
and
and
such
he
manages
the
small
changes
we
all
help
and
support
him,
but
he
really
is
the
mastermind
behind
this.
B
We
provided
a
little
bit
of
info
here
and
we'll
be
expanding
on
that
I'm
sure
over
time
for
the
backlog.
You
noticed
that
new
piece
that
new
project
I'll
go
ahead
and
show
you
what
it
looks
like
large
and
in
charge
and
again
works
just
like
all
the
others,
and
if
you
go
here
to
the
menu
there's
a
guide
or
you
can
just
you
know,
click
over
here
in
the
wiki
we
walk
through.
What's
going
on,
this
info
is
great
for
our
maintain
errs
and
our
contributors
as
well
as
each
other.
B
As
we
start
working
in
this
awesome
new
piece,
let's
see
what
other
great
things
either.
There's
of
course
the
contributing
information
and
everything
Cherie
has
already
pointed
out,
I'm
not
going
to
beat
that
that
horse.
There
you've
seen
it.
You
know
it's
there.
We
try
to
also
work
with
all
of
the
architects
to
ensure
that
those
contribution
guidelines
are
updated
based
on
code.
What
you
need,
so
you
know,
send
contributions.
B
You
can
help
out
with
that
as
well.
There's
a
community
group,
that's
working
on
coding,
standards
and
architecture.
We
work
with
them
on
their
PRS
to
also
update
all
the
documentation,
so
I
think
that's
a
crazy
amount
of
awesome
information.
Let
me
go
back
here
and,
of
course,
all
of
that
information
is
in
this
slide
deck.
We
will
be
posting
this
slide
deck
and
a
link
to
the
recording
in
the
dev
Doc's
community
engineering,
DEP
Doc's
channel.
There's
a
you
everyone's
welcome
to
join
that
channel.
We
also
have
a
merge,
Doc's
channel.
B
If
so,
you're
gonna
see
a
lot
of
traction
and
movement
and
that
as
we
get
closer
to
going
high,
so
you
don't
have
to
memorize
these
links.
You
don't
have
to
pause.
The
video
just
go,
look
at
the
slide.
Deck
and
it'll
have
also
all
of
those
incredible
links
and
info
that
Donna
is
providing
the
previews
that
we
had
on
the
new
merch
content
and,
of
course,
you
can
always
find
us
on
Twitter
and
in
the
dev
Doc's
channel.
I'll
also
add
the
merged
axes
on
there
too.
A
Awesome
yeah.
Thank
you.
Everyone
for
sharing!
It's
really
really
cool
I,
like
how
I
love
how
merchant
docks
is
being
open
sourced.
That
was
the
only
question
was.
Can
we
contribute
to
mention
dockside
like
yes?
Yes,
you
can.
Oh
so
yeah
Jeff
has
answered
that
pretty
well
so
yeah,
looking
like
in
September,
there
will
be
open
source
for
emerging
docs,
and
so
you
can
contribute
back
to
those
I'm
super.
Looking
forward
to
that
the
amount
of
people
that
have
asked
when
they
saw
how
well
their
dogs
was
working
was
like.
A
Can
we
do
this
for
merchandise
I'm
like
oh
I,
will
do
my
best
and
it's
it's
so
good
to
see
that
coming
out?
So
that's
that's
amazing
and
yeah.
So
thank
you
so
much
for
joining
us
in
demoing
em.
So
we
have
some
time
for
questions.
So
if
anyone
has
any
questions,
feel
free
to
drop
them
in
the
the
live,
chat
and
I
will
get
those
across,
but
I
actually
wanted
to
raise
a
question.
A
So
I
mentioned
it
a
few
times
always
mentioned
a
few
times
that
we
have
and
some
maintainer
z'
involved
in
the
project
or
in
the
m
and
the
document
side
of
stuff.
So
I
just
wanted
to
ask
if,
firstly,
if
someone
was
interested
in
becoming
a
maintainer,
is
there
a
process
behind
this,
or
is
it
more
like
and
you'll
be
reached
out
to
from
the
dev
Doc's
team,
and
also
is
there
a
place
where
you
can
see
dev
dr.
maintain
those
and
stuff
like
that
yeah.
G
Hey
this
is
Jeff
Matthews
manager
for
deaf
dogs.
I
can
take
that
question
so
yeah.
We.
We
certainly
encourage
people
to
contact
us
directly
if
they're
interested
in
becoming
maintains.
Likewise,
we
may
reach
out
to
community
members
and
ask
them
to
be
maintained.
So
I
guess
the
short
answer.
Your
question
is
yes
to
both.
There
is
a
bit
of
a
process
that
we
do
have
documented
on
the
website
you
can.
G
On
Twitter
and
but
we
do
partner
closely
with
community
engineering
to
sort
of
go
through
a
light
vetting
process.
So
it's
not
instantaneous
and
we
do
sort
of
look
through
your
contribution.
History
and-
and
you
know,
partner
with
community
engineering
on
getting
getting
that
vetting
process
taken
care
of
and.
B
G
So
there
may
require
updates
to
our
guidelines
for
maintains
and
setting
expectations,
especially
some
maintainer
x'
only
wants
to
focus
on
merchant
documentation
and
vice
versa,
for
death
Knox
documentation.
So
it's
it's
really
good
that
you
bring
it
up
and
I
think
that
yeah
now's
the
time
to
start
having
those
conversations.
While
we
prepare
to
open
source
merchant
documentation,
so
it's
on
the
to-do
list,
yeah
yep.
A
Awesome
cool
and
then
okay,
there's
still
no
questions
in
the
left
s.
So
I
will
leave
this.
As
my
last
question,
so
I
wrote
some
notes,
those
doing
it,
and
so,
unless
you
have
any
questions
that
come
in
in
the
next
few
moments,
this
will
be
I,
guess
the
last
one
and
it
was
if
you
are
doing
co-contribution
and
you
think
this
needs
this
needs
Docs
as
well,
but
I'm
not
comfortable
with
it
myself.
Is
there
a
flag
or
someplace?
B
So
I'll
show
you
right
now.
If
you
can
see,
my
screen
should
be
sharing
so
we're
in
dev
Docs
we're
in
the
repo,
and
you
hit
a
new
issue.
We
have
an
option
for
community
engineering
issue,
so
what
this
specific
ticket
is
for
is,
if
you
are
entering
a
code,
PR
to
say
magenta
or
some
other
repo
you
can
go
in
here,
start
filling
this
in
put
your
link
to
your
PR,
the
link
to
the
the
code.
B
You
know
issue,
you
can
change
this
from
magenta
to
say:
PWA
I'm
sure
they
have
their
own
process,
but
just
you
know
we
can
always
move
tickets
around
fill
it
all
in.
Maybe
we
even
have
options
here
like
did
you
affect?
Like
not
Did,
you
touch
the
court
mean.
Did
you
touch
the
admin
interface?
You
know,
did
you
add
a
high
command?
Did
you
maybe
add
or
change
an
endpoint?
B
B
When
you
come
over
here,
believe
there
was
one
for
admin
access
this
one
I
just
who
was
reached
out
to
by
one
of
the
awesome
developers,
and
he
let
us
know
he's-
got
a
PR,
that's
in
progress,
so
we
filled
out
this
this
issue
with
him.
He
even
provided
screenshots,
which
is
like
really
awesome.
They
he
wants
help
with
not
only
documentation
but
how
to
move
this
content
from
the
UI
into
the
docs
and
then
getting
help
with
maybe
some
UI
content.
B
Problem
and
then
before
we
end
today,
I
know
this
isn't
going
to
make
sense
a
year
from
now
in
this
recording,
however,
for
right
now,
we
did
make
an
announcement
in
slack
we're
making
the
announcement
here
at
the
end
of
June,
the
2.1
release
line
will
no
longer
be
supported.
It's
hitting
its
end
of
life,
so
documentation
team
is
also
going
to
be
reacting.
We've
provided
all
this
info,
it's
in
slack,
it's
in
the
wikis
first
home
page
when
you
hit
wiki,
provides
all
the
information
you
need
to
know,
and
we
will
be.
B
A
Yeah
awesome:
well,
it
looks
like
there
are
no
nothing's
come
in
from
the
questions,
but
so
then
just
want
to
say
thank
you
so
much
for
sharing
this
information
with
the
community.
It
is
they're
gonna,
be
great
I'm,
very
much
looking
forward
to
see
how
the
docs
progress
and
the
Mochan
Doc's
and
it
off
with
contribution
as
well.
A
So
it
is
great
to
have
this
opportunity
and
to
hear
from
you
all
and
yeah
thank
you
for
watching
as
well,
either
watching
live
or
watching
back
and
yeah
feel
free
to
reach
out
to
anyone
and
that
you've
seen
there's
the
dev
Doc's
Magento,
dev,
Doc's
Twitter
or
in
the
slack,
and
we
they'll
be
able
to
help
you
out
wherever
possible.
I
hope
this
has
got.
You
excited
for
documentation,
contribution
and
I
look
forward
to
seeing
how
how
much
great
stuff
comes
in
after
this
yeah.
So
thank
you
once
again.