►
From YouTube: OpenActive W3C Community Call / 2020-10-07
Description
Schedules
- Possible ways;
* Directly on the event
* Partial schedule
* Event schedule
A
Okay,
welcome
to
the
call.
I
think
this
is
going
to
be
a
fairly
fine
drain
call.
It
might
also
be
an
inconclusive
call.
The
subject
of
this
is
simply
things
to
do
with
scheduling,
simply
because
there
seem
to
be
an
awful
lot
of
options
regarding
scheduling
and
I'm
not
sure
it
seems
like
a
very
loose
area
for
validation
right
now.
C
A
A
A
Right,
you
can
also
have,
if
you're
using
event
schedule.
You
can
then
have
start
date
and
date
start
time,
end
time
and
duration
and
then
there's
some
variation
in
the
data
types
that
can
be
associated
with
each
of
these
so
start
date
and
end
date
can
both
be
dates
or
date
times.
Presumably,
if
the
former,
you
would
then
have
to
also
supply
start
time
and
end
time.
A
B
B
B
B
Later
discussion-
oh
yeah
yeah,
of
course
I
guess
one.
What
I
meant
was
that
the
taking
that
issue
aside
and
the
event
issue
aside,
which
is
all
related
to
the
event
properties,
the
schedule
properties
themselves
are
defined
as
in
the
spec
as
start
date
and
date
is
dates
and
start
time.
And
time
is
time,
so
it's
it's
fairly
strictly
defined.
I
realize
I
should
have
responded
to
this
issue
saying
exactly
that.
B
A
B
A
B
B
B
Yes,
so
I
believe
that
the
session
series
start
and
end
date-
let's
see
if
we
can.
I
really
hope
this
is
something
that's
clearly
written
somewhere,
because
otherwise,
my
understanding
of
those
properties
is
that
that
is
a
day
related
to
the
session
series
itself.
So
the
session
series
could
start
and
end
in
a
given
date
right.
But
yes
exactly,
but
that's
the
series,
so
the
series,
for
example,
might
go
on
for
two
months,
but
that's
not
they're
not
going
to
be
the
same.
The
scheduled
session
doesn't
inherit
those
properties.
A
B
For
the
text
where
that
is
written,
I'm
hoping
it's
written
here
session
series
it
must
have.
Yes,
it
is
okay.
So
three
paragraphs,
sorry,
it's
not
it's
not
in
the
same
bullet
points.
Three
paragraphs
above
the
bullet
points
as
a
session
series
is
intended
to
be
a
prepare,
an
event.
It
must
have
either
an
event,
schedule
or
expertise
associated
sub
events.
B
B
B
And
kind
of
has
some
specific
examples
there
to
clarify
what
schedule
generation
is
about,
but
I
mean
basically,
the
the
main
thing
people
seem
to
get
confused
about
is
the
schedule
rather
than
the
partial
schedule,
because
the
partial
schedules
just
kind
of
metadata.
This
is
every
tuesday
which
people
intuitively
kind
of
get,
but
but
the
schedule
is
like
a
generated
thing
which
has
kind
of
there's.
There's
a
whole
scheduling
generation
mechanism
around
that,
which
is
what
this
the
documentation
on
the
developer
site,
goes
into.
B
To
automatically
generate
the
scheduled
sessions,
well,
in
fact,
the
scheduled
session
can
be
supplied,
but
only
to
override
well,
but
but
there's
a
there's,
a
explicit
overriding
of
the
session
series
so
using
an
example
from
book
when
I
think
book
when
team
up
and
open
sessions
will
implement
this
at
the
moment.
So
in
book,
when
you
have
a
schedule
that
might
go
on
for
months
or
years,
there's
no
constraints
around
it
and
and
then
you
might
have
some
bookings
made,
maybe
in
the
next,
maybe
in
the
next
week.
B
Maybe
next
two
three
weeks,
so
those
bookings
are
a
number
of
spaces
remaining.
You
know
remaining
attendee
capacity,
those
things
they're
in
the
materialized.
If
you
like,
scheduled
sessions
which
are
in
the
scheduled
sessions
feed,
but
the
session
series
is
is
going
to
go
way
beyond
what's
in
the
search
scheduled
session
feed,
so
you
might
generate
three
months
of
events
from
the
session
series,
but
only
override
two
of
those
from
the
scheduled
sessions
that
are
provided.
If
that
makes
sense.
B
A
B
A
B
Yeah,
so
this
is
what
the
documentation
clarifies
and
I
and
I
think,
the
issue
that
was
originally
discussed
where,
where
the
semantics
of
schedules
was
discussed,
had
more
detail
in
it,
but
I'm
not
sure
it
all
made
it
into
the
specification
around
generation,
which
is
what
that
documentation
kind
of
then
additionally
covers
so
that
is
that
is
that
the
it's
basically
a
two-step
process,
if
you're
consuming
the
data,
you
first
generate
all
this.
The
schedules.
A
B
A
B
But
those
identifiers
are
the
same
identifiers
that
are
used
for
the
opportunity,
update
notifications.
So
if
someone
moves
a
scheduled
session
from,
you
know,
7
to
8
p.m,
and
it's
a
generated
one.
The
problem
we
have
is
that
the
id
that's
being
used
to
generate
those
actually
encodes
the
time
in
it.
So
if
you
move
the
event,
you
actually
create
a
new
event
because
you've
changed
the
id.
B
B
B
But
as
soon
as
you
get
into
any
of
the
edge
cases
that
follow
that
you're
in
a
world
of
complexity,
that
makes
it
actually
easier,
often
not
to
use
schedules
and
just
to
materialize
the
scheduled
sessions,
because,
if
you're
materializing
scheduled
sessions
based
on
an
id,
that
is
your
internal
identifier
for
your
database,
then
everything's
easy,
because
it
doesn't
matter
what
date
they're
on
doesn't
matter.
When
you
reschedule
them.
B
A
B
Yeah
this
is
a
yeah
completely,
so
the
there
is
an
id
template
in
the
spec
which
is
defined
for
this
purpose,
and
it
says
the
properties
required
if
data
providers
are
supporting
third
party
booking
via
open
booking
api,
so
the
modeling
spec
already
references
the
yet
to
be
finished,
open
booking
api
with
this
intention.
It's
just
I,
I
guess
the
challenge
with
finalizing
the
spec.
What
is
it
two
years
before
the
yeah
booking
api?
B
They
don't
materialize
anything
until
it's
booked,
and
so
it
is
a
natural
fit
in
some
ways.
But
the
problem
is,
of
course,
that
when
you
book
a
team
up
thing
or
you
book
a
open
sessions
thing
in
the
background
there's
an
id
generated
that
is
then
used
throughout
the
whole
process
and
the
way
that
we
have
the
open
booking
stuff
will
works
is
that
those
ids
are
already
published
openly
in
advance
of
the
booking
beginning.
B
So
you
can't
like
switch
up
the
id
at
c1.
For
example,
like
hey
you've,
given
me
this
id
from
the
open
feeds,
but
actually
now
I've
made
a
booking,
I'm
going
to
materialize
it.
So
now
you
need
that
id.
You
know
to
use
this
id
going
forward,
which
I
mean
I
guess
we
could
do
that
type
of
thing
in
the
booking
spec
to
solve
this
problem
and
actually
allow
you
to
materialize
the
ids
as
you
go,
then
you
have
a
well.
B
C
A
Yeah
yeah.
Well,
I
guess
I
guess
it's
just
about
isolating
them
in
a
way,
because
I
would
like,
in
a
sense
to
have
the
same
guidance
for
identifiers
simply
in
the
opportunity.
Spec
and
the
booking
specification
be
nice
to
be
able
to
have
the
same
guidance,
but
it
sounds
like
actually
that
could
be
inflicting
pain.
B
Yeah,
well,
I
suppose
the
thing
is
we're
trying
to
make
these
these
identifiers
last,
because
that's
jason,
ld
kind
of
way,
and
so
that
supposes
where
the
challenge
of
generating
generating
ids,
I
suppose
itself
is,
I
suppose,
implicitly,
a
bit
of
a
challenging
idea,
but
yeah
because
I
mean
the
other
way
you
yeah
the
other
way
you
I
suppose
you
could
do
it
is
you
is
those
ideas,
don't
ever
exist
right
like
anywhere
and
so
yeah?
I
guess
I
guess
this
is
where
you
get
into
like.
B
Mean
I
guess
I
guess,
having
c1
reflect
back
the
ids,
that
it's
a
it's
actually
using.
Isn't
the
craziest
idea
to
be
fair,
because
we've
already
got
positions
in
there
in
the
order
items.
So
I
guess,
as
long
as
you're
able
to
as
a
data
consumer,
remember
the
thing
that
you
said
you
were
going
to
book
or
set
out
to
book
before
it
materialized
it.
B
I
suppose,
then
what
would
need
to
happen
is
the
id
for
the
yeah.
This
is
the
really
hairy
thing,
so
you
would
then
have
the
same
rpd
id
for
an
item
but
you've
just
changed
its
json
ld
id
because
you've
just
materialized
it
or
that
type
of
idea
or
yeah.
Well,
I
guess
you've
just
introduced
a
new
yeah
you've
introduced
a
new
item
in
the
scheduled
sessions,
feed
and
then
you've
probably
got
a
you've,
probably
got
to
have
an
exclusion
that
also
gets
created
at
the
same
time.
B
Agrees
so
what
we've
done
we've
done.
We've
got
the
moment,
there's
an
issue
in
booking
which
has
this
problem
in
it.
No
one's
yet
tried
to
solve
this.
I
think
no
one's
tried
to
make
anything
work
using
this
using
booking,
obviously,
all
the
tests
etc
built
expecting
the
feeds
to
include
sorry.
It's
not
obvious.
The
tests
currently
assume
materialization
the
tests
don't
allow
for
booking
of
anything,
that's
scheduled.
B
So
I
guess
that's
the
thing
at
some
point.
We're
going
to
have
to
you
know
have
to
come
across
that
bridge,
and
I
guess
when
that
happens,
we
maybe
build
a
couple
extra
tests
and
bits
of
the
reference
implementation
and
then
do
schedules
and
then
figure
out
how
we
actually
implement
that
as
we
go
along
so
have.
A
B
B
And
it
references
one
three,
nine
and
and
the
test
suite
issue.
One
two
three
test
fit
issue
is
a
an
issue
to
suggest
that
tesla
does
this
generation
because
it
doesn't
currently
do
that
one
three
nine
is
nathan
is
actually
commenting
139
already.
This
is
back
in
august
about
dereferencing
and
feed
retention,
and
and
these
are
related
to
schedule,
generation
stuff.
B
I
guess
what
I
was
really
hoping
for
is
that
one
of
the
pilots
would
start
to
solve
this
problem,
so
we
could
really
get
into
the
detail
of
it,
but
I
wonder
whether
the
thing
to
do
to
solve
this
is
probably
get
book
when
team
up
open
sessions
on
a
call,
because
they've
all
got
the
same
problem
and
discuss
which
of
the
two
solutions
we've
outlined,
which
are
basically
versioning.
Your
set
version
in
your
schedule
or
having
these
ids
that
are
fake
and
become
real,
would
be
the
most
useful.
C
B
I
think
I
I
definitely.
I
think
this
is
probably
something
we
need
to
handle
before
we
finish
finalize
the
booking
spec,
to
be
honest,
because
without
it
I
mean
play
finder,
it's
going
to
be
hypothetical
because
they
only
deal
with
facilities
that
don't
include
schedules,
but
at
least
I
know
nathan
will
probably
have
a
view
on
how
they
might
have
thought
about
it,
and
obviously
I'm
in
can
be
another
one.
B
It's
going
to
be
difficult
to
fully
flesh
out
the
implications
of
so
the
versioning
is
probably
intuitively
an
easier
solution
in
terms
of
the
spec
but
for
implementation
perspective,
but
then
also
to
be
honest
for
an
implementation
perspective.
It
might
not
be
that
difficult,
because
versioning
is
something
that
team
up
already
do.
I
don't
have
book
when
do,
but
you've
already
got
a
schedule,
object
usually
in
your
database,
so
we're
just
talking
about
adding
versions
to
that.
A
B
A
C
A
B
Probably
versions
but
then,
as
you
say,
there's
there's
so
many
edge
cases.
To
that
I
mean
you
know,
there's
a
whole
extra
section
of
the
test
suite
or
whatever
needs
to
probably
cover
various
different
situations
where
you
might
reschedule
something,
and
so
therefore
something
else
needs
to
be
yeah.
What
exclusions
apply,
making
sure
that
all
of
that
works.
A
Okay:
let's
look
at
the
next
call,
then,
because
I
feel
like
yeah,
it's
possible
to
imagine
alternatives,
sort
of
indefinitely
and
but
also
impossible
to
foresee
all
the
difficulties.
I
think
yeah
meant
to
enough
eyes
all
bugs
are
maybe
not
shallow,
but
at
least
can
be
seen
we're
not
there
at
the
moment.
A
C
A
A
B
B
Basically,
the
problem
that
partial
schedule
solves
and
and
is-
and
it's
quite
widely
used,
actually
partial
schedule.
Okay,
is
that
very
often
you
have
a
situation
where
there
is
very
useful
information
available
for
an
event,
but
the
information
isn't
complete
from
a
kind
of
temporal
technical
sense.
B
However,
it's
not
every
tuesday
in
a
semantic
sense
of
the
those
words,
so
it
might
not
happen
at
christmas.
It
might
not
happen,
and
you
know
easter,
it
might
not
happen
at
whatever,
like
it
doesn't
mean
every
tuesday
can
rain
or
shine.
We
will
absolutely
be
running
on
that
track
because
you
know
so
many
things
happen.
B
I
mean
that,
doesn't
that's
not
the
case,
including
you
know,
cover
19
or
whatever
it's
come
up,
so
those
things
we'll
still
see
every
tuesday,
even
though,
maybe
that
every
tuesday
session
has
been
cancelled
for
for
some
time,
and
so
that's
useful,
but
it's
not
enough.
It's
not
enough
to
generate
sessions
from,
and
so
the
subtle
semantic
difference
between
these
two
things
is
that
partial
schedule
is
something
that
says
every
tuesday.
You
can
render
it
like
that
in
the
br
in
the
front
end,
you
should
render
it
as
every
tuesday.
B
What
you
should
not
do
is
extrapolate
it
to
next
tuesday
and
put
a
date
on
it
right
because,
because
that's
misleading
the
user.
However,
with
a
schedule,
you
can
absolutely
do
that
because
that's
the
point
of
the
schedule
and
it's
and
its
exceptions,
so
with
the
schedule
with
x,
update
with
with
except
dates,
you
can
say
yeah.
B
It
will
definitely
happen
this
next
tuesday
because
the
schedule
has
said
it
will
and
therefore
it
will-
and
it's
probably
bookable
at
that
time
so
and
that's
and
so
obviously,
ideally
all
our
open
data
would
be
of
the
more
solid
schedule
type
and
so
what
what
we
really
have
in
in.
If
you
look
at
kind
of
the
data,
that's
been
made
open
so
far,
is
you
have
three
different
types
of
data?
You
have
data
where
every
single
session
is
materialized
and
that's
the
only
type
of
information
you
have.
B
So
all
I
can
say
is
it's
next
tuesday
and
the
tuesday
after
I
can't
say
every
tuesday.
I
just
know
the
next
two
tuesdays
are
definitely
happening.
That's
the
first
time,
the
second
type,
the
most
common
type
is
you
have
some
materialized
stuff
combined
with
a
partial
schedule,
and
so
that's
saying
next
tuesday
and
the
following
tuesday
are
definitely
happening
and
it's
every
tuesday.
Most
of
the
time.
A
B
B
You
can
allocate
this
event
into
one
of
those
columns
with
accuracy,
because
the
partial
schedule
says
it
happens
on
a
tuesday,
okay
and
you
can
also,
if
you've
got
an
depending
on
your
calendar
view.
You
can
also
say
this
happens
after
another
thing,
because
it's
it's
eight
o'clock
on
a
tuesday,
so
those
things
make
it
more
useful
than
just
text.
There
was
the
schedule.
B
Note
was
added
after
to
count
to
cover
things
like
people
wanting
to
write
that,
so
it
doesn't
happen
at
new
year
and
christmas,
but
most
of
the
time
it
does.
But
basically
I
guess
the
reason
I
was
enumerating
those
different
types
of
of
data
sources,
because
we've
been
kind
of
saying
that
there's
a
gold
standard
here,
which
is
that
we
want
to
have
real,
actionable
data
if
that's
with
a
schedule
or
without
doesn't
matter
as
long
as
you
can
guarantee
that
next
tuesday's
event
is
happening.
B
So
if
you
don't
have
the
actual
data,
then
the
consumer
doesn't
know
whether
they
can
turn
up
or
not
without
making
a
phone
call
and
that's
what
we're
trying
to
get
away
from
with
all
of
this
active
stuff.
So
that's
the
gold
standard
and
all
data
currently
published,
except
for
two
data
sources,
has
that
so
all
data
currently
published
has
either
it
will
happen
at
this
time
or
this
day
or
it
it
does
it
and
there's
a
schedule
which
says
exactly
when
it
will
happen.
B
B
Emd
has
two
data
sources
that
do
that,
and
those
two
data
sources
are
in
the
process
of
being
phased
out
in
favor
of
that
gold
standard
I
mean
jade
could
explain
a
lot
if
she
was
on
the
call
around
this
whole
thing,
but
this
gold
standard
for
them
is
about
making
sure
that
book
when
all
the
sessions
of
book
of
all
sessions
actually
happen.
So
on
class
finder,
when
they
show
you
a
session,
that's
definitely
a
session.
B
You
can
just
turn
up
to
and
attend,
which
means
that
we're
kind
of
moving
away
from
partial
schedules
on
their
own.
However,
partial
schedules
on
their
own
are
used.
Sorry,
partial
schedules,
in
conjunction
with
materialized
or
actionable
events,
are
used
for
all
the
kind
of
leisure
operators.
For
example,
gladstone
implemented
legend
implements.
It
others
implement
that,
because
it's
very
common
to
have
a
tuesday
eight
o'clock
class
for
a
leisure
center,
and
you
want
that
information
in
combination
with
the
actionable
events.
A
Okay,
no
that's
useful.
I
was
hoping
there
would
be
a
way
we
wouldn't
have
to
support
one
or
the
other,
but
that's
clearly
not
the
case.
Okay,
that's
useful
status
quo,
fine,
so,
okay,
so
just
with
a
few
minutes
left-
and
I
really
only
raised
this
as
a
kind
of
attempt
to
kick
something
back
into
play.
A
So
this
is
the
issue
that
you
alluded
to
earlier,
which
is
about
variable
durations,
basically
estimated
durations
situations
in
which
the
length
of
time
of
something
is
not
known,
which
also
somewhat
ties
into
situations
where
the
date
or
the
time
of
something
is
not
known.
More
generally,
like
in
the
case
of
british
triathlon,
where
things
like
start
dates
and
end
dates
are
difficult
to
specify.
A
A
So
I
just
raised
two
ideas
there:
more
as
a
way
of
kind
of
getting
the
discussion
going
and
kicking
the
tires,
and
hopefully
through
critique
refining
the
issue.
A
little
bit
because
it
does
seem
difficult
that
there
are
a
lot
of
activities
like
park,
run
like
triathlon,
where,
actually
you
can't
you
know
the
duration
is
or
marathons.
A
So
I
just
made
two
very
simple
suggestions
at
the
end
of
the
thread,
one
of
which
was
we've
got
indicative
duration
in
the
root
specification
which
works
like
duration,
except
that
it's
a
complex
object
and
it's
got
an
activity
associated
with
it.
So,
yes,
it
takes
indicatively.
It
takes
two
hours
to
run
it
four
hours
to
walk
it.
You
know
50
minutes
to
horse
ride.
A
A
B
I
can't
remember
from
that
last
call
what
the
main
pushback
to
just
implementing
this
beta
property,
as
is,
was
because,
as
if
you
just
if
you
exclude
end
date
and
just
have
start
date
and
estimated
duration,
I
mean
start
date
plus
estimated
duration,
because
I
think
end
date's
already
optional.
Isn't
it?
I
think.
B
A
I
mean
the
only
pushback
I
could
imagine
I
mean
so.
The
the
one
is
simply
that
it
complicates.
Writing
queries
a
little
bit
that
the
logic
becomes
more
or
more
convoluted
right.
That
might
just
be
an
inescapable
feature
of
the
domain.
The
other
is
that
actually
parker,
apparently
just
doesn't
like
specifying.
A
B
B
Yeah
yeah,
well,
I
mean
pete
raised
it
because
it
was
in
the
lta
data
or
and
oh
sorry,
the
running
data,
the
athletics
data.
So
I
I
mean,
I
think
yeah
I
mean
I
think
the
semantics
we've
got
are
are
fine.
If
we've
already
got
a
situation
where
the
start
date
is
the
only
required
field
and
end
date
is,
is
in
fact
optional.
B
Then
all
we're
doing
really
is
adding
additional
metadata
where
it
wasn't
there
before
saying,
there's
an
estimated
duration.
We're
not
really
I
mean,
if
there's
a
challenge
here
about
about
end
date,
not
being
present,
which
is
what
that
12th
of
february
comment
seems
to
be
saying.
Then
that's
that's
kind
of
already
a
problem
right
as
in
we
don't
have
an
end
date
in
every
case
currently
and
so
from
park
runs
perspective.
That's
that's!
That's
correct,
like
that's!
B
That's
what
that's
what
they
would
that's,
what
they'd
expect?
They
don't
publish
an
end
date
themselves
because
it
varies
as
by
the
participants,
so
so
that
yeah.
So
I
don't
see
what
the
complexity
here
then
is
I
mean
if
we
want
to
mandate
an
end
date,
that's
a
different
conversation
and
it
sounds
like
there's
a
fairly
strong
case
to
not
do
that,
based
on
some
of
the
data
publishers
and
and
their
own
customer
behavior,
which
they're
aware
of.
B
The
only
organization
I
can
think
of
that
was
interested
in
doing
this
was
part
of
the
open,
active
accelerator
cohort.
I
don't
think
they're
actually
using
open
data
at
the
minute.
They
might
be,
though,
because
the
athletics
data
they
might
be
using-
let's
see,
I
can't
remember
they
called
run
something.
B
B
C
B
B
Yes,
there
must
be
scraping
that
so
yeah
so
I
mean
park
run.
I
know
they're
on
the
list
somewhere
to
do
the
open
data
stuff
and
they
are
the
reason
for
part
of
this,
but
yeah
I
mean
they.
Don't
they
don't
use
it
at
present
this
estimated
thing,
but
then
it's
not
in
park
run
data.
So
maybe
that's
a
look
at
another
one.
B
I
guess
I
guess
the
the
the
the
thing
is
that
this
data
is
really
more
about
running
and
cycling
than
it
is
about
other
things
yeah.
So
I
think
probably
the
question
is:
do
these
current
the
places
where
you
look
at
this
information
currently
include
that
they
also
include
distances,
though
as
well.
A
B
Okay,
well
so
find
a
race
doesn't
allow
you
to
search
by
duration
of
time,
only
allows
you
to
search
by
distance,
and
the
same
is
true
of
run
together,
so
I
mean
yeah
and
run
together
actually
doesn't
include
on
their
own
website.
Presently,
an
estimated
time
just
puts
the
it
just
puts
the
distance.
B
Than
most
openly
well
I
mean
potentially
I
don't
know
well,
I
wonder
what
this
I
mean
unless
anyone's
crying
out
for
it,
whether
it
makes
sense
to
leave
it
as
a
beta
property
until
we've
got
more
people
using
it,
which
I
guess
is
why
I
was
there
to
see.
If
you
know
people
the
data
gets
published,
see
if
people
pick
it
up
yeah,
so
I
don't
know
if
it
does
it,
I
don't
know.
If
there's
any
doesn't
it
doesn't
appear
that
there's
any
particular
urgency
to
promote
it
at
this
stage.
C
B
Yeah
completely,
I
mean
it's,
it's
interesting.
I
think
I
think
what
we
what
we've
got
here
is
a
situation
where,
when
you're
publishing
data,
you
obviously
want
to
publish
as
much
as
possible.
So
we
we
add
beta
properties
where
we
can,
if
there's
data
that
exists,
to
make
it
to
make
it
available,
and
then,
when
that
data
gets
consumed,
those
business
questions
happen.
You
know
what
do
we
want
to
display?
B
A
A
B
B
Presently,
I
know
one
of
the
live
debates,
just
looking
at
the
slack
and
github
over
the
last
few
days
has
been
around
the
or
weeks
has
been
around
the
lease,
the
number
of
spaces
that
you
have
in
a
in
the
feed
versus
the
number
of
spaces
that
you
have
in
the
calls
and
how
that
works,
for
leasing
and
for
booking.
So
there's
some
of
that.
That's
those
discussions
already
happening
on
github,
and
I
know
that
I
seem
to
be
converging
in
terms
of
various
feedback
on
some
stuff
there,
but
yeah.