►
From YouTube: 2022/03/24 Weekly Dev Meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hello,
it's
march
24th
2022,
and
this
is
the
backdrop
weekly
developer
meeting.
We
get
together
every
week
to
talk
about
the
latest
in
core
developments.
We
cover
any
issues
that
have
been
raised
by
the
community
in
the
past
week
and
we
talk
about
prioritized
issues
before
we
get
started.
We'll
do
introductions
of
everybody
who's
here
in
the
meeting
my
name
is
nate
lampton
from
oakland
california.
I
go
by
quick
sketch
on
the
internet
and
let's
go
to
robert
and
then
jen.
C
I'm
jen
lampton
joining
from
oakland
california,
that's
it
for
me.
D
Tim
erickson,
I'm
st
paul
pim
and
deerwood
minnesota
and
turkey
just
came
back
to
visit.
I
haven't
seen
the
wild
turkey
in
my
week,
big
news.
A
All
right,
wilbur
and
then
finally
peter
if
you're
available.
A
C
I
don't
know
what
ca
files
are.
Oh
certificate
files,
interesting
and
tweet
feed
and
tweet
feed
was
imported
by
the
drupal
maintainer.
So
that's
pretty
exciting.
A
All
right,
excellent,
all
right!
So
every
week
we
have
a
forum
post
shared
from
forum.backdrop
that
solicits
topics
for
discussion
this
week.
I
I
should
have
managed
to
check
that.
I'm
not
totally
sure.
D
A
Okay,
that's
why
okay,
but
we
did
have
some
other
topics
that
have
been
brought
up
at
the
start
of
the
meeting.
I'm
gonna
share
my
screen
because
this
first
one
is
hard
to
comprehend.
A
A
So
the
the
general
problem
that
we
have
here
actually
jen-
maybe
you
could
summarize
it-
I
think
you're,
better
prepared.
C
Sure
so
this
issue
actually
came
in
through
an
email
on
the
contact
form
from
up
cms
from
one
of
our
users,
who
has
been
helping
us
with
accessibility
reports
on
a
bunch
of
stuff
in
backdrop
for
a
long
time.
C
So
because
he's
a
pretty
good
contributor
and
submitted
this
request,
I
immediately
went
to
look
at
it
and
was
able
to
reproduce
the
problem
where
we
have
this
scenario
right
now,
where
the
latest
version
of
rules
got
an
update
where
it
changed
the
version
of
the
entity
tokens
module
that
it
depended
on
and
entity
tokens
module
at
the
time
of
the
issue
had
two
supported
releases,
a
1.1.0
and
a
2.0.0
release,
or
something
so
two
major
versions
that
were
supported.
2.01.
C
Now,
I
guess,
and
at
the
time
they
were
both
supported
and
so
backdrops
installer
would
be
like
well,
there's
two
versions
for
you
to
choose
from,
but
they're
both
supported
and
so
we're
not
automatically
gonna
update
you
from
the
one
version
to
the
two
version,
because
maybe
you're
not
ready
to
make
that
change,
but
because
the
rules
module
depended
on
the
two
version
now
and
backdrop
wouldn't
update
from
one
to
two
on
the
dependent
c
module
rules
wouldn't
update,
so
the
person
was
trying
to
use
the
installer
module
to
update
rules
and
it
got
stuck
in
this
situation.
C
So
initially
I
was
like.
Oh,
this
must
be
a
problem
with
backdrop
core,
because
it
can't
handle
the
updates
properly
and
then
everyone
did
a
bunch
of
research
and
realized.
Oh
no.
No!
This
is
a
supported
scenario
right.
We
allow
you
to
have
a
two
versions
of
a
module
supported
at
any
given
time
and
we
don't
want
to
automatically
update
someone
from
version
one
to
one
version:
two,
if
they're
not
ready.
C
So
what
we
need
to
do
is
fix
this
situation
and
contribute,
or
if
we
mark
the
one
version,
one
branch
of
enemy
utopian
is
unsupported.
Then
backdrop
will
update
you
to
the
supported
version
and
everything's
fine,
so
they
found
a
solution
right
now.
So
the
issue
is
no
longer
urgent,
but
it
occurred
to
me
that
this
is
still
going
to
be
a
problem.
C
If,
for
example,
the
rules
module
were
to
have
a
security
update
come
out
next
month
and
the
nad
token,
module
did
still
want
to
have
a
new
version
and
an
old
version,
new
version
and
testing
an
old
version.
Not
we
would
now
have
a
situation
where
people
who
are
relying
on
the
installer
module
to
handle
their
updates
or
in
the
future,
the
automatic
update
system
or
whatever,
wouldn't
be
able
to
get
that
security
update,
because
the
project
it's
dependent
on
wouldn't
update,
which
means
that
project
itself
wouldn't
update.
C
So
it
seems
to
me,
like
there's,
still
an
issue
here,
even
though
we
did
find
an
immediate
solution,
and
I
don't
know
what
the
right
solution
is
for
this
in
core,
like
a
checkbox
somewhere.
That
says,
like.
I
understand
the
risks
update
me
to
the
dev
version
of
2.x
or
whatever
it
is,
but
I
do
think
that
we're
sort
of
boxing
without
without
a
solution
in
the
user
interface
we're
boxing
in
these
people
who
don't
have
access
to
their
code,
to
not
be
able
to
get
security
updates
in
the
future.
So.
A
Yeah
thanks
for
the
summary,
I
think
that
the
current
behavior
of
staying
within
the
major
version
seems
desirable,
like
I
think
that
that's
that's
what
we
would
normally
want,
but
moving
up
to
a
major
version
is
also
like.
That's
a
a
tricky
thing,
and,
and
once
we
move
into
like
automatic
updating,
you
know
we
won't
really
get
the
opportunity
to
like
prompt
the
user.
A
For
the
question
of
like
do
you
want
to
do
this
major
update?
I
don't
know
it's
kind
of
it's
kind
of
sounding
to
me
like
this.
This
should
possibly
be
a
question.
You
know
like
in
installer
update
module
about
preferred
versions
like
you
know,
stay
within
minor
versions
or
stay
within
major
versions
or
upgrade
to
the
latest
major
versions,
and
if
you
chose
to
stay
within
a
major
version,
your
site
would
just
get
locked.
A
I
mean
it
would
get
stuck
if,
if
another
module
had
a
dependency
and
could
no
longer
update,
because
it
couldn't
update
a
major
version
of
something
else,.
B
We
have
two
qualitative
characteristics
of
releases,
whether
they
are
supported
and
whether
they're
recommended
so
it's
I
mean.
I
think
whatever
decision
process
would
probably
need
to
be
based
on
those
two
statuses,
as
opposed
to
whether
it's
a
major
version
upgrade
or
not
so
right,
because
because
the
major
version
upgrade
could
be
recommended
or
or
might
not
be
recommended,
because
it's
in
alpha.
A
C
And
we're
also
dealing
with
a
situation
where
we've
got
more
than
one
trainer
involved
right,
so
it
could
be
that,
like
the
maintainer
of
entity,
tokens
is
like
not
recommended,
and
the
retainer
of
rules
is
like.
I
love
this
new
entity
tokens
we're
going
to
depend
on
it
and
now
the
problem
is
upstream
from
the
solution,
or
vice
versa,
or
something.
A
Yeah
well,
I'm
curious
jen
in
your
testing,
so
we
don't
have
any
like
update
module.
A
C
A
A
That
could
then
ask
you,
you
know
additional
details
about
which
version
you
wanted
to
update
to.
That
would
be
different
than
the
bulk
updater,
which
just
updates
everything
and
that
that
could
overcome
a
lot
of
the
like.
You
know
I
have
this
problem
with
this
one:
individual
module
that
there
could
be
a
manual
process
for
for
specifically
choosing
a
version.
C
D
C
Because
rules
depends
on
any
token
version
two
and
then
there
could
be
a
link.
That's
like
investigate
individual
module
and
you
go
to
that
page
and
then
on
that
page,
that
could
have
like
entity
version
now
available
entity
version.
Two:
do
you
want
to
update
yes
and
so
there's
sort
of
a
manual
process
where
you'd
have
to
say,
like
update
to
version
two?
You
can
update
to
version
two
first
and
then
you
can
return
to
your
like
update
everything
page
and
then
it
would
continue.
C
So
I
don't
know
what
that
feels
like
like.
I
don't
know
what
that
process
would
feel
like,
but
at
least
we
would
give
people
some
interface
that
would
allow
them
to
like
get
the
update
they
needed
from
within
the
installer.
A
Yeah
interface,
this
could
be
entirely
in
instead
of
the
option
to
choose,
like
you
know,
stay
within
majors
or
not
our
policy.
We
could
switch
that
to
like
majors
need
to
be
done
manually
and
automatic
really
only
means
within
the
major
version.
All
the
time.
E
B
B
C
E
Why
can't
entity
tokens
go
to
1.2
instead
of
wait.
C
A
Yeah,
I
kind
of
like
this
mentality.
If
we
can
make
clear
what
the
consequences
are
of
major
versions,
including
things
like
automatic
updates,
would
incentivize
people
to
stay
within
a
major
version
for
longer.
If
a
major
version
required
manual
intervention
on
their
users
part,
then
that
might
encourage
more
maintainers
to
have
longer
release
cycles,
just
like
core
does,
which
would
have
a
side
benefit
for
our
end
users,
if
they
could
hold
on
to
that.
A
But
that's
I
yeah
wilbur,
I
don't
really
know
what
why
there
was
2.x.
You
know
what
what
caused
that
change,
but
it
probably
was
some
some
api
that
no
longer
functions
the
same
as
before.
A
A
Feature
dash
requests,
I
think
it
is.
I
think
I
actually
added
a
redirect
from
survey
as
well
to
that,
to
that
url
automatic
updates
is
now
number
two
under
add
an
icon
font
to
core,
which
is
really
surprising.
A
So
there's
a
documentation
issue.
Next,
I'm
not
sure
who
wrote
this
one
in
here
that.
C
That
was
that
was
me,
so
this
is
a
follow-up
where,
a
long
time
ago,
when
we
first
stood
up,
you
started
using
issue
milestones
things
that
made
the
next
bug
fix.
Release
were
like
things
that
were
almost
ready
and
things
that
we
thought
were
really
important
and
when
we
documented
the
milestone
process
that,
like
critical
bug,
fix
issue
wasn't
included
in
there.
So
I
added
that
back.
That's
the
last
paragraph
that
says:
there's
one
exception
to
the
above
for
bug
fix
releases.
C
If
a
bug
is
deemed
sufficiently
critical
that
it
needs
to
be
fixed
by
the
next
bug
fix
release,
then
the
milestone
can
be
added
before
the
issue
has
a
pull
request
in
your
ready
state,
and
that
was
something
that
we
had
been
doing
for
a
long
time.
It
wasn't
documented
so
I
wrote
it
in
here,
but
it
occurs
to
me
that
we
should
also
determine
and
document
how
we
deem
an
issue
sufficiently
critical.
C
Who
needs
to
do
that?
Does
that
come
from
a
core
committer
write
that
down
security
team?
I
don't
know
and
then
once
we
figure
out
that
process
or
that
the
decision-making
criteria.
I
would
like
to
apply
that
to
the
issue
we
just
discovered.
C
This
is
no
longer
quite
as
urgent
as
it
was
yesterday,
because
we
were
figured
out
for
the
people
who
are
currently
running
rules
and
entity
token
today,
but
just
as
an
exercise,
it
could
be
good
to
be
like
hey.
Is
this
a
critical
issue,
and
then
that
way
we
can
use
that
in
the
future.
C
If
we
have
something
that
I
can
think
of
recently,
we
had
like
a
user
interface
break
in
a
major
version
of
backdrop,
and
we
wanted
to
make
sure
that
that
got
fixed
before
the
next
bug
fix
release,
so
that
would
have
gotten
added
to
the
milestone
before
we
had
a
pull
request.
So
just
some
process
there
like
when,
when
do
we
make
that
determination?
How
do
we
make
it
and
how
does
that
milestone?.
A
This
is
actually
this
issue
that
we
were
just
looking
at
it's
kind
of
interesting,
because
you
added
milestone
candidate
bug
right
away.
C
C
A
C
A
D
C
Okay,
I
will
add
a
sub
section
there
for
the
one
exception
and
I
have
it
I'll,
maybe
post
it
in
zulip,
for
review
to
make
sure
that
looks
reasonable.
F
D
F
Needs
to
have
like
the
pull
request,
so
we'd
need
something
else
there,
because
they
both
already
have
two
people
needing
to
do
it.
D
Peter
it
does,
we
do
have
a
requirement
for
bug
fixed
release
that
it
has
a
a
recent
pull
request
in
the
near
ready
state
yeah.
So
it's
not.
I
don't
know
if
I
knew
this,
I
thought
any
it
takes
more
than
two
people,
even
if
you
have
two
people
agreeing
to
it,
if
there's
no
pull
request,
it
shouldn't
be.
C
D
A
This
exception
here
that
it
can
be
moved
into
rtbc
or
moved
into
the
milestone
if
there
is
a
pull
request,
that's
rt.
C
A
Yeah,
I
think
that
that
sounds
better
because
it
it
then
both
things
would
need
to
be
seconded
and
there
would
be
an
exception
for
both
unless
there
was
a
pull
request.
That
was
already
nearly
ready,
and
the
only
difference
is
that
minor
versions
require
an
advocate
and
bug
fix.
Once
any
two
people
agreeing
can
put
stuff
into
the
bug
fix
milestone.
B
A
And
that
don't
let
me
steamroll
that
I
just
yeah,
you
tell
me
if
that
sounds
good.
D
D
It's
a
related
question:
if,
if
we
have
a
rtbc
label
on
a
minor
or
on
a
bug
fix
it,
can
it
automatically
go
to
the
original
people.
C
A
That's
right,
that's
correct,
and
I
think
I
don't
want
it
to
be
automatic
because
they
often
don't
get
put
in
at
the
first
pass
of
being
rtbc.
They
get
marked
needs
work,
and
I
don't
think
that
we
would
then
want
to
automatically
remove
things
from
the
milestone
after
they
got
bumped
back
down.
A
C
F
B
C
A
Let's
see
yeah
are,
we
are
we
done
with
that
topic?
Yep.
A
Okay,
let's
see
bw
panda
wanted
to
raise
this
issue
about
the
admin
bar
item,
sometimes
going
off
the
screen.
Here's
a
little
gif
of
it
happening
live
where
some
of
the
menu
items
fly
off
the
right
side
of
the
screen,
but
it
looks
like
there's
already
a
pull
request.
That's
been
filed.
A
That
makes
it
so
that
when
you
get
close
to
the
edge
of
the
screen
like
this,
it
just
pops
the
menu
out
the
opposite
direction,
which
I
do
believe
that
this
was
the
case
at
one
point
in
backdrop
core
and
it
may
have.
We
may
have
suffered
from
a
regression
and
not
noticed
it,
because
I'm
pretty
sure
this
was
already
supposed
to
be.
A
The
behavior
I'd
be
curious
to
see
how
this
works
when
it
goes
off
to
the
right
for
the
first
time,
and
then
it
hits
the
edge
of
the
screen
and
then
the
next
time
it
needs
to
go
backwards
because
after
you
get
to
so
many
levels,
you
know
you
might
end
up
with
like
a
zigzagging
type
effect
where
it
hits
the.
F
So
it's
not
that
I
mean
my
javascript
and
stuff
isn't
the
best,
but
I
think
it's
better
than
the
current
situation,
which
is
where
it's
just
not
usable
in
that
situation
because
there's
another
issue
which
is
where
we're
adding
a
new
thing
to
the
more
tasks
section
and
it
has
a
drop
down
and
it's
basically
unusable
because
it's
it's
always
on
the
right
hand,
side
and
you
can't
see
the
sub
menus
so
at
least
fixes
that
issue,
and
it
fixes
this
one
on
smaller
screens
but
yeah
for
multi-nested
menus.
F
Then
there
is
a
an
issue
where
it
just
goes
back
on
itself,
I'm
still
kind
of
usable,
but
I
don't
know
how
to
fix
it,
ideally
other
than
the
whole
reworking.
But.
A
Yeah
yeah,
we
have
a
bigger
issue
to
switch
out
the
entire
admin
bar
to
using
smart
menus,
which
is
the
same
thing
we
use
on
the
front
end,
but
quite
honestly,
drop
down
menus
are
really
they're,
always
difficult,
and
so
there
hasn't
been
a
whole
lot
of
enthusiasm
for
doing
the
work
there,
because
it's
a
lot
of
work
and
the
current
admin
bar
is
fine.
It's
fine,
yeah.
C
D
A
Yeah
great
all
right
next
up
is,
is
one
that
I
added
that
has
some
interesting
technical
challenges.
A
A
So
if
you
do
a
config
override
in
your
settings.php
file
like
this,
so
this
changes
the
config
or
this
changes
the
mail
system
to
a
different
class
like
if
you're
going
to
send
via
smtp
or
something
like
that.
So
if
you
have
a
config
override
and
then
you
do
and
then
you
pull
the
config
in
a
couple
of
different
ways
like
this
config
get
system
mail
and
then
you
say
default
mail
system.
A
A
So
the
kind
of
complaint
here
is
seems
pretty
valid
that
it's
like,
regardless
of
which
one
you
use.
The
override
should
always
be
returned.
A
So
there's
also
a
little
bit
of
an
efficiency
problem,
potentially
that
checking
an
entire
file
for
overrides
could
be
a
little
trickier
than
checking
an
individual
key.
A
The
good
news
is:
is
that
we're
not
actually
doing
this
in
very
many
places.
There's
only
seven
places
in
all
of
core
that
we
call
config
get
on
an
entire
file
instead
of
asking
for
an
a
particular
key.
A
Usually
it's
when
loading
a
complex,
complex
object
like
a
layout,
a
custom
block,
a
text
format,
and
these
are
things
that
are
less
likely
to
be
overridden
via
config
overrides
in
settings.php
anyway,
but
loading
the
mail
system
settings
is
just
a
weird
situation
where
we're
doing
this
for
a
setting
for
some
reason,
and
so
the
immediate
fix
that
herb-
and
I
have
discussed
it's
like
well.
D
A
Don't
we
just
fix
the
immediate
problem
of
making
the
mail
system
config
read
the
settings
correctly
correctly,
the
the
predictable
way
and
that
will
solve
the
immediate
problem
of
the
mail
system,
not
being
overwritten
overwriteable.
A
A
Sorry,
I
haven't
looked
at
this
since
apparently
a
couple
of
hours
ago,
where
her
apparently
now
has
made
a
pull
request.
So
maybe
maybe
this
whole
thing
will
be
a
moot
point
because
it's
been
fixed.
I
don't
know
I'll
have
to
take
a
look.
A
C
A
Right
well,
this
is
the
immediate
fix
that
I'm
talking
about
that
in
in
core,
where
we're
currently
calling
config
get
the
one
that
doesn't
do
a
config
override.
We
just
switch
it
to
calling
config
instead
and
then
instead.
A
I
think,
in
the
case
of
and
these
there's
no
good
reason
for
why
we
did
it
here
for
mail.
A
There's
not
really
any
any
good
explanation,
but
it
does
make
a
lot
of
sense
for
loading,
layouts
or
custom
blocks
or
text
formats
also
check
out
views
are
loaded
because
I
suspect
they
would
be
kind
of
similar
that
you
need
to
load
the
entire
file
for
view
yeah.
D
A
That
it
happens
most
frequently
when
the
entire
config
file
needs
to
be
pulled
in,
and
then
the
entire
config
gets
like
passed
into
a
constructor
for
like
a
more
complex
object
like
a
layout
or
view
because
in
in
those
cases
the
entire
file
is
generally
needed
in
order
to
construct
the
the
complex
thing,
but
for
settings
yeah,
it's
set
settings
it's.
A
It
doesn't
really
make
any
difference,
one
way
or
the
other
it
it
from
most
people's
perspective.
Probably
is
the
difference
about
whether
or
not
you
want
an
object
to
work
with
or
whether
you
want
an
array
to
work
with,
and
it
syntactically
you
you
could
choose
which
one
you
wanted,
but
now
this
actually
is
making
a
a
difference
between
the
object
and
the
arrays
I
mean.
A
We
also
could
deprecate
loading
an
entire
file
via
config
get
that's.
C
A
Yeah
yeah
yeah,
since
we
only
have
these
seven
instances
and
this
these
are
they're
some
of
them.
They
do
it
in
multiple
places.
That's
how
you
end
up
with
seven,
but
there's
only
four
places,
actually
four
modules
that
do
this
outside
of
tests
that
load
a
config
file
directly
like
this,
and
so
it
wouldn't
be
very
hard
to
update
core
to
change
that
mechanism.
A
A
B
B
A
Okay,
well,
the
immediate
problems,
we're
kind
of
working
through
them,
just
solving
them
in
in
focused
issues
or
focused
pull
requests,
but
yeah.
This
is
an
overall
concept
could
be
interesting
to
debate.
A
little
bit
about
a
side
effect
would
be
if
we
started
doing
this
insert
in
certain
places
or
when
we
load
an
entire
file.
We
might
need
to
document
things
like
a
layout.
A
You
can't
alter
via
a
settings.php
override,
but
you
could
alter
it
via
a
hook.
Layout
load,
you
know,
and
so
maybe
we
need
to
start
like
clarifying
that
some
of
the
more
complex
objects
don't
override
like
they
do
for
settings.
You
know
which
I
don't
know
doesn't
seem
like
it's
that
much
of
a
a
loss
in
my
opinion,
but
I
think
in
in
the
world
of
drupal.
I
think
you
can
config
overwrite
even
like
deeply
nested
settings
within
a
view,
even
though
I
don't
think
that's
a
very
good
idea.
A
Okay,
sorry
somebody
I
made
everybody
enter
snoozefest
there
with
the
config
override
discussion,
all
right
that
does
it
for
the
topics
that
we
had
raised
before
the
beginning
of
the
meeting.
D
Apparently
I
don't
have
the
issue
number
peter's
been
working
on
an
issue
to
customize
date
formats
based
on
whether
or
not
the
users
in
europe
or
the
us
and
indigozella
proposed
it
even
further
peter.
Do
you
want
to
talk
about
it?
Do
you
have
the
issue
number
hand?
F
I
don't
know
the
issue
but
yeah,
so
the
thing
is
that
backdrop:
ships
with
us
formatted
dates
like
month
day
year
by
default
and
based
on
the
wikipedia
research.
We've
done.
That's
in
the
minority
of
the
everyone
around
the
world
that
uses
dates
most
people
use
day
month
year
or
year
month
day.
So
we
thought
to
ship
backdrop
with
either
more
formats
to
allow
people
to
to
choose
the
ones
they
want.
But
then
I
had
the
idea
to
change
the
formats
that
are
created
by
default.
F
F
Request
that
makes
it
so
that
by
default
in
the
config
file,
the
date
formats
are
demonstra.
And
then,
if
you
install
backdrop
with
a
time
zone,
that's
in
a
us
place,
then
it
changes
it
to
month
day
year.
Instead,
I
think
I
then
also
added
a
thing
in
there
to
change
it
for
people
in
europe,
because
they
prefer
like
dots
instead
of
slushes
or
something
like
that.
F
Anyway,
that's
my
pull,
requests
and
there's
an
issue
somewhere
for
that
and
then
indigozella
in
zulup
has
been
tossing
up
the
idea
of
going
one
step
further
and
adding
in
a
I
don't
know
if
it's
a
third-party
library
or
just
some
third-party
code
that
uses
some
php
library
or
extension
to
do
it
automatically
as
a
really
specific
way
of
if
you're
from
this
country
do
this
format.
F
If
you're
from
this
country
do
this
format
and
it
sort
of,
I
guess,
automates
it
a
bit-
I'm
not
sure
so,
it's
a
sort
of
another
another
step
which
was
getting
an
idea
if
it's
worth
it
for
making
a
poor
request
for
that
or
not
it's
unclear
whether
she
got
that
feedback
she
wanted
or
not.
But
there's
that
suggestion
too.
D
I
think
there
are
two
questions
that
come
to
mind,
one
of
which
is
just
in
general,
this
approach
of
customizing
data
keeping
the
same
date
formats,
but
having
them
configured
differently,
based
on
where
you
are.
Is
that
a
good
idea?
First
and
then?
If
so,
then
the
question
is
how
fine-grained
to
make
that
and
whether
this
thing
that
indicates
proposed,
which
would
be
much
more
fine-tuned,
is
possible
or
worth
it
peter.
F
People's
servers
in
their
installation
of
php
they're,
like
service
setup,
would
have
to
have
php
installed,
with
this
extension
enabled,
as
far
as
I
understand
it,
which
I'm
not
sure
if
that's
by
default
or
not,
I
don't
know
if
that's
a
default
thing,
that's
added
to
php
or
whether
you
have
to
do
it
manually.
D
A
Yeah,
I
think
that
yeah,
that
per
user
different
information,
definitely
should
be
a
different
issue.
I'm
I'm
in
favor.
Conceptually
of
this,
like
you
know,
based
on
the
time
zone,
you
select
also
change
the
date
formats.
A
It's
not
always
the
case
that
the
person
doing
the
installation
or
the
one
selecting
the
time
zone
is
necessarily
the
same
as
where
the
site
is
going
to
be
used,
but
it
generally
is
especially
because
the
the
question
at
install
time
is
like
what
is
the
time
zone
the
default
time
zone
for
the
entire
site.
A
So
I
think
that
that's
a
pretty
good
question
or
value
to
hinge
all
of
the
date
formats
upon,
and
I'm
also
totally
in
favor
of
doing
this
idea
that
we
have
universal
formats
universal
global
formats
by
default
and
then
use
the
us
as
a
like
a
specific
like
if
they're
in
the
us
then
do
these
particular
things.
I
think
that
every
time
we
have
these
kind
of
situations
about
there's
something
that
is
u.s
centric
within
our
software,
we
should
work
towards
a
solution.
A
That's
more
global,
and
I
really
like
that
this
doesn't
inconvenience
the
u.s
users
at
the
same
time
like
u.s
users,
it'll
be
the
same
as
before,
and
that's
the
the
best
of
both
worlds.
D
D
I
think
that's
what
indigoza
was
trying
to
solve
and-
and
the
question
would
be
that
you
know
peter
suggested
a
confirmed
module,
but
I
think
pointed
out
that
this
happens
that
it
stalls,
so
it
can't
be
a
contribution,
and
if
we
did
it
in
core
it
would
be
adding.
It
would
be
a
little
more
code
changed
than
what
his
proposal
is
and
also
I
don't
know
about
this
int
requirement.
D
A
Yeah
sometimes
we
we've
done
that
in
the
past,
where,
if
there's
an
easy
way
of
doing
it,
that's
provided
by
something
that
may
or
may
not
be
there.
We
we
try
to
use
the
easy
solution
first
and
then
we
have
like
a
simplified
manual
fallback,
that's
like
oh.
If
the
plugin
isn't
available,
then
you
know
we
support
the
american
override
potentially
and
then,
but
nothing
else.
That
sort
of
thing.
A
D
A
All
right,
okay!
Well,
that's
all
I've
got
for
today
and
looks
like
we're
nearly
at
the
top
of
the
hour.
So
it's
time
to
wrap
up.
Does
anyone
have
any
closing
thoughts
or
anything
they'd
like
to
mention.
D
Let's
mention
the
open
force
thing
we're
in
the
final
week,
so
just
so
everybody
knows
open
force
is
wrapping
up.
I
forget
the
exact
date,
but
it
was
at
the
end
of
the
month.
So
I'm
pretty
sure
our
next
meeting
will
be
in
april
on
it
or
not.
We
have
one
more
anyways.
D
D
And
we've
got
one
competitor
right
breakish,
I
don't
know
if
I
was
saying
his
name
right,
but
a
shout
out
to
the
rakish
again
apologize.
If
I
got
your
name
wrong,
but
he's
done
a
whole
number
of
issues.
He
also
wrote
a
blog
post
that
he
mentioned
us
in
you
know,
at
least
for
the
time
being
been
pretty
enthused
about
backgrounds.
That's
been
fun
to
see.
A
Excellent,
I
thought
yeah
I'm
very
excited
about
this.
Oh
one,
more
call
out
then
also
related
to
open
force
and
some
of
our
contributors
from
southeastern
asia.
I
saw
that
there
was
now
office
hours
that
are
happening
kind
of
opposite
global
time
zone.
Wise
wilbur.
Are
you
still?
Do
you
have
a
hand
in
the
new
additional
office
hours?
I
don't
that's.
That's
tim.
I'm.
E
Still
running
the
the
otc
utc
19
hours
and
tim's
running
the
utc
six
hours
now
actually
they're
utc
fine.
I
had
to
make
a
job.
D
All
right,
we,
I
have
some
colleagues
in
bangladesh
and
for
the
last
two
weeks
we
have
been
having
office
hours
and
just
working
on.
They
basically
kind
of
codes
working
for,
but
we're
inviting
and
encouraging
other
people
to
join
us.
A
Yeah,
wonderful
news:
I
love,
I
love
to
hear
that
and
I'm
sure
that
that's
helping
with
open
force
a
lot
as
well,
because
you
do
have
a
lot
of
indian
and
pakistani
contributors.
I
believe.
A
Yeah,
wonderful,
okay!
Well,
let's
wrap
up
for
today!
Thank
everybody
for
being
here
in
these
discussions
and
thank
you
out
there
for
for
watching
and
listening
and
as
always,
keep
up
the
great
work
so
talk
to
you
all
next
week.