►
From YouTube: Issue Refinement Session: Implementing a configuration file for the Static Site Editor
Description
We discuss the use case, technical considerations, and iteration steps involved in introducing a configuration file for the Static Site Editor.
A
So
hello,
everybody.
This
is
the
first
issue
refinement
session
for
the
static
site,
editor
that
I'm
hosting.
I
was
just
about
to
tell
the
team
that
the
session
is
totally
optional.
It
should
not
be
seen
as
a
synchronous
team
meeting.
This
is
one
of
those
that's
in
our
team
calendar
and,
if
you're
available
and
if
you're
particularly
interested
in
the
issues
that
I'll
be
focusing
on
refining
in
the
session
you're
more
than
welcome
to
join
and
collaborate
with
me
on
it.
So
this
is
an
open
session.
A
A
A
It's
a
bit
of
a
life
hack
for
me
to
get
better
at
these
as
well,
but
I
am
very
happy
to
have
you
all
on
the
call
with
me
today
so
as
posted
in
the
in
the
slack
channel
the
the
three
kind
of
like
main
things
I
want
to
look
at
today.
I
don't
know
if
I'll
get
all
of
them,
but
the
first
one
is
fleshing
out
the
some
further
considerations
for
implementing
the
static
site.
Editor
configuration
file.
A
You
know
our
vision
of
what
we
want
that
feature
to
look
like
going
forward.
Then
the
second
one
is
to
clean
up
the
the
reduce
wetland
com,
repo
size,
epic
and
it's
related
issues
so
related
to
well.
I
won't.
I
won't
make
the
con
the
official
connection,
but
there
could
be
a
relation
to
the
merge
trains
we're
getting
stuck
last
week.
So
much
and
the
fact
that
you
know
we
had
some
high
utilization
on
the
gitly
nodes
related
to
the
repo
size.
A
Chad
had
a
look
at
the
issue
that
was
reported
and
replaced
to
the
clone
of
the
catholic
flow,
the
gitlab,
the
wp
club
com
repo,
so
that
we
have
less
clones
of
that
repo
as
we
do
bolts
and
stuff,
but
what
he
he
made.
Some
good
points
yesterday
that
you
know
we
haven't
changed
anything
drastically
in
in
the
repo.
What
is
what
is
kind
of
like
causing
things
to
to
fall
over?
You
know
and
one
one
of
the
things
that
we've
known.
A
We
need
to
look
at
for
a
long
time,
but
we
put
on
the
back
burner
because
of
the
monitoring
every
structure
was
you
know,
reducing
the
the
size
of
that
repo?
So
I
want
to
have
a
look
at
that
and
then
lastly,
one
of
our
kind
of
like
secondary
objectives
in
this
milestone
is
to
to
look
at
converting
the
the
gitlab
handbook
from
middleman
to
frontman,
and
there
is
some
kind
of
like
prerequisite
steps
that
we
need
to
do
so.
A
There's
two
custom
extensions
that
we
wrote
for
for
the
handbook
that
we
need
to
convert
to
the
helpers,
because
frontman
doesn't
have
custom
extensions,
but
they
do
have
helpers,
and
so
I
want
to
have
have
a
crack
at
the
fire
trading,
converting
that
issue
to
an
epic
and
then
defining
some
issues
for
it.
Welcome
michael,
I
just
mentioned
I'll
recap
quickly,
for
your
sake.
I
mentioned
earlier
to
the
team
that
this
is
not.
This
should
not
be
seen
as
a
synchronous
call.
B
A
No,
I
I,
as
part
of
the
process
that
we
defined
on
our
handbook
page
enrique
kindly
suggested
we
should
do
like
a
a
heads
up
24
hours
ahead
of
the
time
for
the
team.
You
know
what
we
want
to
cover
in
the
sessions.
I
was
a
little
bit
late
to
to
that
today.
Well,
yesterday,
I
didn't
get
to
posting
that
so
I
I
I
essentially
I
looked
at
you
know
what
are
the
the
things
that
are
high
priority
to.
A
Yeah,
so
I
do.
I
would
like
to
to
get
a
little
bit
more
predictable
in
terms
of
this,
but
I
can
also
clear
easily
see
it
being
whatever
is
top
of
mind
the
day
or
two
before
the
surgeon,
so
also.
I
would
like
to
open
up
this
that
anybody
who
has
an
issue
that
they
would
like
to
you
know
refine
a
bit
further,
can
suggest
an
issue
or
an
epic
to
look
at.
You
know.
This
is
not
just
me
doing
it.
A
So
this
is
this
is
the
team
session,
and
you
know
I
don't
even
have
to
run
this
station
all
right
with
that
said
out
of
those
three
implementing
the
static,
siding
configuration
file,
reducing
the
webcam,
repos
and
migrating
the
gitlab
handbook
from
middlemen
to
frontman.
Is
there
any
preference
to
which
one?
We
start?
Anybody
have
a
specific
interest
in
in
any
one
of
them
chad,
you're
kind
of
like
linked
to
all
three.
So
your
vote
doesn't
count.
A
A
Geez
I
wrote
this
badly
it's
important
for
yeah,
so
to
accommodate
various
static
site
generators
and
project
customization.
It's
important
that
you
know
we
have
the
static
site.
Editor
feature
needs
to
have
the
understanding
of
the
environment
that
the
that
the
project
is
configured
in
you
know
our
our
strategist
we've
been
to
use
the
conflict
convention
over
configuration
approach
to
say
that
you
know
we'll
use
sensible
default
and,
where
needed,
we'll
expose
those
defaults
to
configuration
for
the
user
to
override
we
held
off
as
long
as
we
can
on
this.
A
You
know
the
celia
actually
did
the
initial
r
d
on
this
many
moons
ago.
You
know
three
months
ago,
actually,
where
we
had
a
look
at
these
things,
and
we
said
we
would
hold
off
on
on
it
as
long
as
we
we
could,
but
we
have
now
reached
that
point
where
we
need
to
to
really
kind
of
like
get
it
in
place,
and
you
know
pretty
much
the
the
problems
we
need
to
solve.
You
know,
and
it's
very
much.
The
persona
is
probably
a
software
developer
with
development
team
lead.
A
You
know,
and
and
I
phrase
that
as
a
software
developer,
I
want
to
override
the
static
site
editor's
default
configuration,
so
I
can
ensure
it
works
correctly.
With
my
project
structure.
We
know,
for
instance,
that
the
handbook
itself
has
a
specific
structure
and
it's
in
a
mono
repo
structure
and,
and
so
just
out
of
the
back.
A
That
could
be
kind
of
like
fairly
different
to
what
you
know
you
would
have
if
you
have
a
single
repo
with
a
project
in
it
out
of
the
box
and
then
also
as
a
software
developer,
I
want
to
override
the
static
site
there
is
default
configuration,
so
I
can
customize
the
behavior
of
the
static
site
editor
down
the
line.
I
can
totally
see
you
know
us
being
able
to
specify
which
formatting
options
is
available
in
the
toolbar.
You
know
which
headings
you
know.
A
Maybe
maybe
you
never
want
somebody
to
be
able
to
choose
an
h1,
because
from
from
an
seo
point
of
view
you
know
you
should
only
have
one
h1
on
the
page
most
of
the
time.
There's
this
caveats
to
that,
but
you
know
so
essentially
down
the
line
as
we
want
to
move
to
a
more
mature
or
lovable
maturity
level.
For
our
feature,
you
know:
we'd
want
to
bring
in
more
configuration
options
and
the
ability
for
somebody
to
to
customize
it.
A
B
So
one
of
the
things
that
I've
brought
up
frequently-
and
it
came
up
in
the
meeting
yesterday-
is
as
being
a
software
developer
persona.
There's
things.
For
example,
I
want
to
be
able
to
edit
the
raw
markdown,
regardless
of
how
good
you
make
the
wizzy
wig
experience
or
make
a
a
front
matter.
Editing
form
like
because
that's
the
most
efficient
way
and
I
looked
at
the
the
sasha
software
developer
persona.
B
It
doesn't
seem
like
there's
anything
that
gets
directly
at
that,
even
though
I
feel
that's
a
common
concern.
The
last
one,
which
is
I'm
concerned
that
by
taking
longer
than
expected
on
the
task,
I
may
be
judged
or
seen
as
blocking
others
work,
but
that's
not
really
it
and
I
feel
like
maybe
that's
something
missing
from
the
persona,
because
I
feel
like
that,
would
that's
sort
of
a
common
concern
of
a
lot
of
software
developers
like
don't
get
in
my
way.
B
A
Michael
you
can
chip
in
if
I'm
articulating
this
wrong.
I
think
one
one
of
the
key
things
that
we
want
to
achieve,
or
one
of
one
of
the
key
things
that
stands
out
from
you
know
like
what?
What
is
it
that
we
support?
Why
aren't
we
going
the
route
of
supporting
a
headless
cms
that
talks
through
an
api,
and
so
on?
Is
that
we
want.
A
You
know
whether
it's
the
web
ide,
you
could,
you
know
gitlab
the
product
will
allow
you
to
to
edit
the
source.
You
know
in
your
browser,
either
through
editor
lite.
If
you
go
directly
to
the
file
with
ide
or
static
site
editor,
or
you
still
have
the
option
of
pulling
the
code
locally
and
editing
it
like
that,
so
I
think
from
an
editing
point
of
view,
the
software
developer
is
not
a
primary
persona
that
we're
targeting
for
for
with
the
wizard
editing
mode.
A
We
where
we
do
need
to
keep
them
in
mind
is
specifically,
you
know
in
the
context
of
the
software
developer
is
the
one
that
will
potentially
create
the
project
configure
the
project.
You
know
make
sure
that
that
all
of
the
the
conflict
values
are
right,
and
so,
and
in
this
specific
case,
when
we're
dealing
around
config,
they
are
a
relevant
persona
for
us
to
consider.
B
It's
like
I
may
want
to
use
that
for
90
of
the
time,
but
if
I
just
want
to
drop
down
and
edit
the
source,
it
would
be
not
lovable
to
be
forced
to
stop
or
drop
that
mr
or
commit
it,
and
do
something
more
efficient
to
go,
want
to
use
one
of
the
other
editors
or
clone
the
thing
locally
and
go
through
a
lot
of
extra
hoops.
Just
because
you
didn't
let
me
access
the
raw
source,
but
that's
definitely
a
discussion
for
another
issue
on
another
day,
and
I
and
I
think
we.
C
I
was
going
to
throw
in
my
two
cents
and
in
the
call
yesterday
you
did
allude
to
this,
where
you
know
whether
we're
removing
the
like
we're
all
marked
down
view
or
not,
and
that
you
know
we've
been
talking
about
editor
light
and
I
think,
having
the
static
site.
Editor
is
like
one
way
to
edit,
but
we
should
provide
a
way
to
get
to
the
raw
source.
If
you
want
to
edit
that
thing,
how
we
do
that.
C
That's
a
bigger
question,
but
yeah
definitely
you
know
there
are
we
don't
want
to
get
into
the
situation
where
slack
got
into
where
they
introduced
this
like
fancy
wizzy
wig
editor,
but
then
it
pissed
off
the
rest
of
the
established
kind
of
user
base
where
they're
used
to
the
actions
and
then
now
it's
like
an
all-or-nothing
kind
of
mode
and
slack
where
you
can
only
do
like
markdown
mode
or
do
the.
What
you
see
is
what
you
get,
but
you
can't
do
both
and.
A
A
A
If
we
look
at
the
the
feedback
we've
received
from
team
members
so
far
it
has
been
the
non-engineering
ones
who
have
said.
Oh,
my
word
is
so
much
easier.
This
is
so
much
better
yeah
and
we're
gonna
get
probably
80
of
our
value
optimizing
for
for
those
people,
and
I
don't-
and
I
think
specifically
tailoring
for
the
for
the
software
engineer,
persona
in
the
wizarding
editor
and
making
you
know.
That's
where
we're
gonna
have
to
have
a
lot
of
hard
work,
potentially
for
a
very
low
reward.
A
You
know
thinking
of
things
like
markdown
shortcuts,
if
that's
something
we
have
to
custom
develop,
you
know
where
you
type
in
you
know
where
you
can
still
write
in
in
kind
of
like
markdown,
but
in
the
wizardwick
mode,
and
it
you
know
like
that,
that's
tricky!
You
know,
there's
a
lot
of
edge
cases
in
something
like
that.
A
D
I
have
something
to
add
before
moving
on
into
the
actual
topic,
that
one
of
the
reasons
that
that
I
asked
the
question
in
yesterday
meeting
about
keeping
the
front
matter
in
the
in
the
resource
was
exactly
that
point.
The
the
technical
cost
that
implies
synchronizing
the
real
markdown
mode.
With
the
we
see
with
tools
that
we
are
providing
to
edit
the
front
matter.
D
That's
not
the
main
driving
point
for
for
software
development
for
developing
this
product
right,
like
our
main
priority,
is
like
to
provide
the
best
experience,
but
I
just
wanted
to
highlight
that
there
is
a
there
is
a
cost
in
in
trying
to
provide
a
good
experience
in
both
in
both
sides.
At
the
same
time,
within
the
same
user
interface.
B
A
really
good
point:
the
technical
cost
yeah.
Okay,
thank
thanks
for
discussing
it.
I
guess
my
main
concern
is
like
we're.
Gonna
have
the
best
wysiwyg
experience
and
like
when
you
say
to
use
one
of
these
other
options,
for
example,
that
that
isn't
going
to
render
the
images
properly
that
isn't
going
to
know
where
they
are.
It's
not
really
going
to
look
like
that,
and
the
the
only
way
you're
going
to
know
for
sure
is
to
like
deploy
it
and
wait
for
a
review
app.
A
Getting
a
bit
back
on
track
here.
One
of
the
thoughts
I
have
right
now
is:
we
don't
actually
have
an
epic
related
to
configuration
for
the
static
site
editor
and
I
almost
feel
like
what
we're
talking
about
here
is:
it's
very
you
know,
high
level,
you
know
and
because
there's
going
to
be
different
kind
of
like
iterations
of
of
introducing
the
configuration
well,
I
spoke
with
chad
yesterday
and
I
mentioned
here
like
I
would
imagine.
A
The
first
iteration
is
just
have
the
file
there
and
read
the
the
values
and
pass
it
to
the
editor.
Don't
worry
about
validating
it,
checking
it
or
anything
like
that.
You
know
just
take
it
past
it
and
you
know
second,
iteration
is
okay:
let's
introduce
some
validation,
checks
and
stuff
any
thoughts
in
terms
of
kind
of
like
esc
kind
of
like
promoting
this
to
an
epic
and
then
having
kind
of
like
specific
iteration
issues
for
for
the
various
iterations.
B
B
The
main
risk
I
see
is
the
the
thought
that
goes
into
the
configuration
values,
what
they
are,
what
they're
named
and
how
those
evolve
and
what
deprecation
strategies
will
have
to
go
through
as
it
becomes
used
more,
especially
by
people
outside
of
get
lab
and
like
putting
a
lot
of
thought
into
what
what
those
are
going
to
be
up
front.
So
we
don't
have
to
deprecate
a
lot
of
stuff
and
go
through
those
hoops
and
and
cause
people.
Frustration,
I
think,
is
the
biggest
concern
around
the
config.
A
A
B
Along
the
lines
I
was
saying,
perhaps
we
should
have
an
issue
which
is
to
come
up
with
some
documented
standards
of
at
least
what
conventions
we
follow
like.
Do
we
use
dashes
or
camel
case?
Is
it
like
a
noun
verb
type
of
thing
like
to
try
to
ensure
we're
at
least
as
as
consistent
as
we
can
be,
even
though
we
can't
predict
everything,
and
part
of
that
would
probably
involve
researching
the
other
existing
config
files?
I
think
there's
at
least
two
or
three
in
gitlab
to
ensure
that
we're
consistent
with
those.
A
A
A
D
A
Well,
I
I
think
you
know
this,
for
me
is,
is
is
more
about
the
plumbing.
You
know
the
putting
the
plumbing
in
place
of
reading
and
passing.
So
I
think
this
isn't,
but
you
make
a
good
point
there,
because
not
only
do
we
need
to
discuss
the
the
configuration
we
also
need
to
properly
document
those
in
our
documentation
going
forward,
so
that
I
I
do
see
that
as
an
issue
that
we
should
have
so
define
the
configuration
that
configuration
values
or.
B
A
D
A
C
A
D
Well,
as
part
of
the
image
of
load
path,
we
actually
need
two
configuration
values.
We
need
to
know
the
base
path
of
the
of
the
website
in
the
repository,
because
we
need
a
way
of.
We
need
a
base
path
to
resolve
the
relative
urls
that
are
referencing
the
markdown
documents,
and
then
we
need
the
immersive
load
path
that
is
relative
to
that
base
path.
D
A
All
right,
okay,
so
this
gives
us
a
good
breakdown
of
what's
needed,
let's
quickly,
just
kind
of
like
scan
yeah.
If
there's
anything
further,
we
can
define
here
proposal
so
introducing
configuration
file
that
is
red
when
a
static
site
url
is
requested.
We
should
parse,
validate
and
transform
the
configurations.
Why?
So
here
we
already
know
we're
going
to
need
a
future
issue
for
valid
validation,
validate
the
configuration
file
and
we
can
later
on
define
what
that
actually
means.
A
E
B
A
I
wouldn't
be
opposed
to
introducing
that
actually
as
the
first
value,
because
we
know
already
that
our
default
is
middleman
and-
and
we
can
have
that-
and
I
I
do
think,
especially
as
I'm
gonna
file
integrating
it
with
a
with
hugo
soon
as
well.
If
there
is
any
specific
kind
of
like
assumptions
or
things
that
we
need
to
modify
based
on
the
static
site
generator
type,
it
would
be
good
to
have
that
in
there.
So
I'm
more
for
defining
this
okay.
B
That's
also
going
to
be
related
to
the
how
the
ci
build
is
generated,
so
I
don't
know
at
what
point
we
expect
like.
I
guess
that
will
be
part
of
the
template.
They
pick
for
the
project,
which
will
include
the
configuration
file
as
well
as
how
the
ci
file
is
created
to
build
hugo
versus
middleman,
for
example,.
A
Okay,
we
should
pause,
validate
and
transform
the
configuration
entries
now
the
transformation.
I
actually
see
that
figuring
out
what
we
want
to
do
and
how
we
want
to
pass
that
to
the
editor
as
part
of
this
issue.
So
I
don't
see
that
as
a
separate
issue
interest
in
the
back
end
and
positive
that
excited
component
on
the
front
end,
the
vacuum
will
only
be
concerned
with
the
parsing
validation
and
transformation
of
the
configuration
entries
further
details.
A
So
this
is
the
r
d
issue
and
I
think
it's
worth
us
just
quickly
scanning
over
that
just
refreshing
our
minds
in
terms
of
what
we
define
there.
So
let's
go
to
the
stage
proposal,
so
we
want
to
provide
more
control,
blah
blah
blah.
Introduce
this
approach.
Has
the
following
environments
similar
to
already
implemented
configuration
files?
Yes,
blah
blah
happy
path,
user
adds
it
and
uci
tasks
will
check
that
the
so
that's
validation,
the
user
visits
the
static,
backend
reads
and
validates
the
content.
A
We've
got
that
back-end
exposes
detected
settings
to
the
front
end
print
and
apply
settings
to
the
plugin
logic.
User
sees
the
diffuse
extension
of
the
configuration
file.
You
can
add
new
features
depending
on
the
feature
that
will
either
automatically
active
after
the
release
or
available
by
nukem
blah
blah
blah
david
creation
of
the
configuration
options.
We
can
just
sign
rate
in
the
future,
upgrade
yeah
possible
configuration
options,
the
destination
path.
Yes,
we've
got
that
configuration
of
the
markdown
engine
yeah,
so
that
could
be
cram
down
or
common
mark
or.
A
Configuration
default
return,
url,
okay,
so
this
just
speaks
to
potential
configuration
options
and
I
think
we'll
what
we're
shooting
the
full
trapping
is
is
going
configuration
crazy.
I
think
we
should
introduce
new
configuration
values
as
the
requirement
arises.
You
know
it's
important
that
we
get
this
infrastructure
and
plumbing
there,
but
let's,
let's
use
the
the
convention
as
soon
as
we
we
make
an
assumption
for
users
where
we,
when
we
kind
of
like
okay,
we're
going
to
assume
the
upload
path.
A
A
So
this,
I
think,
is
where
it's
also
important
for
us
to
to
document
the
default
values
that
we
now
that
we
have
in
our
in
our
in
our
logic.
So,
for
instance,
the
the
the
static
side
generator.
The
default
assumption
is
that
it's
middleman,
the
default
assumption
for
image.
Uploads
might
be
slash
images
or
whatever.
A
B
B
A
E
I
actually
have
concern
about
this
one.
I
like
this
approach
because
it's
super
visible
for
users.
They
don't
need
to
go
anywhere.
They
will
see
all
of
the
details
about
the
configuration
options
in
the
file,
but
if
we
decide
to
add
new
fields,
how
user
is
going
to
update
their
version
of
the
configuration
so.
B
A
A
My
inclination
would
be
to
provide
a
warning
and
reject
any
incorrectly
defined
values
and
and
fall
back
to
the
default
value.
But
again
you
know
we
should
make
that
really
clear
in
our
error
messages
to
the
user.
What
we,
what
what
the
impact
of
them
with
having
an
incorrectly
formatted
file
or
incorrect
value
or
a
key,
is.
B
B
A
That
that
kind
of
like
then
comes
back
to
the
should
we,
even
because,
when
you
def
when
you
that
makes
me
wonder
whether
we
should
revisit
this,
that's
the
notion
of
defining
or
adding
the
configuration
files
with
predefined
values
as
part
of
the
project
templates.
Maybe
we
add
the
configuration
file
with
commented
out
values
not
actually
defined
ones,
because
I
would
like
you
know.
B
B
E
A
B
B
B
Like
we
could
try
to
have
a
more
flat
structure,
and
so
like
different
related
values
like
image,
upload
path
and
image,
upload
image
locations
could
be
an
array
like
you
could
instead
have
like
an
images
key
and
then
under
their
values
like
there's
choices,
okay
and
just
general
philosophies
of
like
whether
we
want
to
keep
this
flat
or
try
to
make
it
hierarchical.
Those
those
are
the
sort
of
things
to
document,
so
people
don't
have
to
make
that
decision
going
forward.
A
This
would
be
a
good
one
like
it
would
be
good
to
also
potentially
reach
out
to
the
technical
writing
team
to
get
their
input
on
this
as
well.
I'm
sure
they've
been
dealing
with
these
things
for
a
lot
and
they
would
probably
know
if
there's
inconsistencies
with
the
current
configuration
files
as
well
value
conventions,
for
example,
quote
strings
or
not:
okay
supported
value
types,
so
that
would
be
kind
of
like
string
value,
boolean
numbers,
those
kind
of
things.
B
So
an
example
would
be,
if
we
had
said:
okay,
there's
only
going
to
be
one
location,
we
can
ever
expect
images
to
be
in
the
source,
and
so
we
make
that
a
scalar
string,
value
top
level
in
the
yaml
file.
And
then
we
say:
oh
actually,
lots
of
people
have
their
images
stored
in
different
directories.
That
needs
to
be
an
array
type
value.
A
I
think
related
to
this
would
be
good
to
to
link
out
to
git
labs
the
standard,
deprecation
process
and
standards
and
strategy
that
we
use,
because
I
know
I
believe
I
might
be
speaking
under
correction,
but
I
believe
we
only
remove
deprecated
things,
for
instance
with
major
releases.
So
when
we
go
from
13
to
14
or
14
to
15
or
so
so,
it'd
be
good
to
to
just
make
sure
we
align
with
whatever
is
defined
there.
B
So
what
we
were
just
talking
about,
if
we
do
auto,
generate
a
config
file
with
a
template
and
having
the
documentation
be
in
line
for
that
you
know.
What
does
that
look
like?
Is
it
sort
of
squares
of
hashes
around
it?
Multi-Line
doesn't
have
a
right
side
to
just
standards
like
that
for
okay
default
comments
in
the
file.
A
A
A
For
me,
next
steps
here
is
I'll.
Go
make
sure
all
the
labels
are
are
properly
added
on
these
chad
you'll
be
the
dri
for
fleshing
these
out
I'll
I'll,
try
and
add
some
kind
of
like
initial,
just
high
level
requirements
and
and
so
on
to
them,
but
I'm
gonna
it'll
be
on
youtube
to
flesh
these
out
I'll,
make
sure
they
all
got
all
the
proper
labels
and
all
of
those
things.
A
Yeah,
I
I
will
say
I
really
enjoyed
having
you
all
as
a
sounding
board
and
just
talking
through
this.
It
was
definitely
valuable
for
me
personally,
and
you
know
I
think,
we've
gone
and
fleshed
this
out
quite
a
bit
better
than
you
know
a
lot
better
than
wherever
it
was
one
hour
ago
or
50
minutes
ago.
So,
thank
you
all
for
your
time
and
have
a
good
day
further.