►
From YouTube: OpenActive W3C Community Group Meeting / 2017-12-13
Description
A public hangout for members of the OpenActive W3C Community Group.
Agenda: https://lists.w3.org/Archives/Public/public-openactive/2017Dec/0001.html
For more information visit: https://www.openactive.io/w3c-community-group.html
A
Okay,
so
in
this
hangout
we
were
going
to
chat
about
booking.
So
that's
what
we'll
focus
on
for
the
main
body
of
the
discussion,
but
I
also
just
wanted
as
usual.
Give
you
a
kind
of
general
update
on
some
of
the
work
we've
been
doing
at
the
ODI.
That's
relevant!
That's
what
we're
discussing
here
and
then
might
add
some
time
for
any
other
business
at
the
end
to
raise
any
particular
issues.
A
So,
just
to
begin
with,
on
general
update,
we've
been
continuing
to
do
some
development
work
around
the
API
dashboard
and
which,
hopefully,
some
of
you
have
had
a
chance
to
look
at.
If
you
haven't
already
it's
a
status,
dot
open,
active
dire.
If
you
go
there
now,
you
can
see
all
of
the
twenty
publishers
who
have
started
to
provide
open
data
as
part
of
the
program
and
and
some
metadata
there
to
indicate
whether
they
are
currently
conforming
to
either
the
paging
or
the
opportunity.
A
A
So
we've,
because
we've
heard
from
a
few
people
that
the
availability
of
that
kind
of
information
was
a
key
key
criteria
about
deciding
which
feeds
to
harvest.
We've
included
that
in
the
table,
though,
so
you
can
quickly
find
those
that
are
publishing
that
information
and
we're
working
out
how
to
provide
people
with
recommendations
about
how
to
add
this
type
of
data
to
their
feed
in
ways
that
are
compatible
with
the
open
licensing,
so
we'll
be
sharing
something
with
the
community
to
try
and
get
more
ticks
into
that
column
over
the
coming
months.
A
The
other
thing
that
we've
been
doing
to
start
to
do
some
summarization
of
some
of
the
data.
That's
in
each
of
the
feeds,
a
few
of
the
few
public
few
developers
have
told
us
that
they
really
want
to
get
a
sense
of
the
coverage
of
individual
feeds
in
terms
of
both
geography
and
also
the
types
of
activity
that
they're,
including
so
now,
for
those
feeds
that
conform
to
the
opportunity
data
model.
You
can
click
a
link
and
get
a
high-level
summary
of
the
contents
of
the
feed
at
the
moment.
A
What
we're
showing
is
an
indication
of
the
types
of
activities
that
we've
identified
in
the
feed,
based
on
how
people
tagging
tagging
their
opportunities
and
also
the
geographic
spread.
So
I'll
I'll
highlight
the
caveats
that
we've
got
on
the
page
there
and
you
can
see
in
the
application,
which
is
that
we're
not
in
we're
not
currently
indexing.
All
of
the
data
from
all
of
the
feeds.
A
What
we're
doing
is
every
day
we're
sampling
data
from
that
by
harvesting
a
few
thousand
opportunities
from
each
provider
so
that
over
time
we
can
build
up
a
picture
of
what's
in
there.
It
may
be
that
in
future
we
switch
to
indexing
all
of
them,
but
as
a
kind
of
first
pass,
we
just
thought
we
would
do
some
sampling,
which
we
think
you
know
could
give
you
a
useful
kind
of
indicative
idea
about.
A
Open
active,
do
a
dress,
because
we
want
to
make
sure
that
this
is
meeting
people's
needs,
but
we're
already
find
it
useful
to
help
encourage
publishers
to
start
to
conform
to
the
standards
and
improve
what
they
do.
So
that's
kind
of
general
updates
any
questions
or
comments
on
that
before
I
move
on.
B
A
So
there's
there's
Audia
a
few
issues
on
the
backlog
that
people
have
reported.
One
of
them
is
indication
of
whether
it's
events
or
facilities
and
the
other
one
is
whether
the
opportunities
are
booked,
able,
there's
two
kind
of
high
level
indicators.
So
that's
they're
on
the
backlog,
but
until
we've
worked
out
how
to
best
publish
represent
that
data
kind
of
be
part
of
a
movement.
C
A
You
mean
the
summaries
that
you
can
so
the
the
data
that
you
can
see
on
the
page
on
the
screenshot
is
available
to
download,
so
that
everything
that
we're
showing
on
the
dashboard
you
can
download
it
in
a
machine,
readable
format.
It's
there
under
an
open
license.
So
if
people
wanted
to
do
some
further
work.
A
You
say
well
we're
only
producing
the
summaries
for
those
publishers
that
are
supporting
both
if
their
standards
yeah
it,
partly
because
it
simplifies
the
development,
because
it's
we've
got
a
single
structure
to
conform
to,
but
also
is
a
bit
of
an
incentive,
bring
that
extra
bit
of
insight
for
for
doing
that
work,
but
yeah
over
time.
I
think
it
will
be
a
bit
useful
insight,
and
just
you
know,
I
just
reiterate
the
caveat.
They
add
that
it's
not
a
complete
representation
of
everything
that
would
have
been
discovered
from
that
feed.
Just
a
sample
yeah.
C
But
I
guess
that
the
data's
there,
so
if
someone
wanted
to
go
in
and
I
was
just
thinking
from
an
insight,
perspectives,
they'd
say
the
feed
had
five
hundred
thousand
and
opportunities
on
it.
I
think
like
knowing
the
breakdown
of
those
opportunities
and
what
what
the
top
activities
were
and
what
the
geographical
breakdown
and
that
sort
of
information
is.
It's
really
really
useful.
C
A
You
agree
we
we
had
Nick
I
mean
it
might
know
this
better,
but
I
think
we
had
at
least
one
potential
data
user
who's
interested
in
that
kind
of
insight
and
analysis,
but
we
haven't
worked
out
the
best
way
to
kind
of
expose
that,
in
a
way
that
you
could
do
analytics
around
it
at
the
moment,
somebody
would
need
to
do
the
kind
of
harvesting
and
in
similar
way,
that
we
are
and
generate
some
output.
Well,
there
might
be
ways
to
improve
that
in
the
future.
Okay,.
C
A
B
A
B
We've
been
there's
been
a
request
to
see
if
we
can
export
the
data
we've
got.
Csv
I
think
that's,
probably
someone
the
backlog
of
things
that
are
good
to
do
just
kind
of
a
translator
to
get
from
harvesting
to
CSV
was
was
the
request,
so
you
can
do
spreadsheet
analytics,
but
that
was
the
other
I.
Don't
if
anyone
wants
that's
happened.
So
you
know
that
I
mean
that's
something
that
could
be
prioritized
by
someone
that
wants
to
be
there.
We
go
that's
very
ambiguous,
isn't
it
yeah.
A
Just
present
a
summary
of
of
that
and
what
we
think
the
next
steps
are.
What
I'll
be
going
through
here
on
the
slides
is
a
there's,
a
document
that
Sally
who's
been
on.
Previous
call
has
written,
and
she
she
couldn't
be
here
today,
so
I'm
gonna
kind
of
do
my
best
to
present
for
so
many
of
her
work,
but
the
will
be
links,
there's
links
and
slides,
which
I'll
circulate
afterwards,
which
take
you
through
to
her
short
short
reports.
A
So
you
can
explore
it
in
more
detail,
so
a
where
we're
at
at
the
moment
and
we've
been
having
a
lot
of
conversations
across
the
team
both
here
in
these
calls,
but
also
individually
with
some
people
engaging
with
ran
program
around
the
importance
of
booking.
So
it's
very
clear
to
us
that
progress
around
booking
is
really
important
for
some
aspects
of
the
the
community
and
the
data
ecosystem
were
building
were
an
open
active.
A
So
to
begin
with,
what
we've
been
doing
is
looking
at
those
api's
already
exist
within
physical
activity
sector,
so
implemented
by
existing
platforms
like
legend
in
Gladstone,
but
we've
also
been
looking
more
broadly
at
other
platforms
and
api's
that
offer
more
generic
booking
services
or
kind
of
tailored
around.
You
know
kind
of
like
the
event
rights
that
are
specialized
around
booking
particular
types
of
event.
A
It's
quite
a
scope
in
terms
of
functionality
and
in
terms
of
some
of
the
quality
of
service
offerings
across
the
api's.
You
know
whether
they
are
free
or
paid
for
services,
level
of
rate
limiting
and
really
the
level
of
developers.
Support
that
is
provided
to
get
third
parties
on
on-boarded
I
think
it
wouldn't
be
entirely
unfair
for
me
to
say
that
some
of
the
existing
platforms
have
pretty
poor
documentation
and
developer
experience.
At
the
moment.
A
Not
everyone
is
offering
sandboxes,
for
example,
to
make
it
easier
to
test
services
and
the
documentation
is
quite
varied
as
well.
There's
often
quite
a
lot
of
internal
knowledge
required
amount
and
some
of
the
some
of
the
platforms
in
order
to
actually
do
anything
successfully
with
the
api's.
So
there's
quite
it's
quite
a
lot.
We
could
be
doing
around
just
kind
of
recommending
better
approaches
to
exposing
these
type
of
api's
within
the
sector.
A
We
happy
to
look
at
other
examples,
so
I
wanted
to
kind
of
just
put
that
request
out
there
that
if
you
are
offering
or
using
api's
that
support
booking
at
the
moment,
then
we
would
really
like
to
be
able
to
see
what
public
documentation
you're
you're
happy
to
share,
so
that
we
can
do
more
of
this
kind
of
comparison
between
services.
A
key
thing
around
building
any
kind
of
technical
standard
like
this
is
being
able
to
build
on
people's
existing
work,
so
the
more
we
can
get
shared
from
the
community.
A
D
A
A
On
the
publisher
side,
things
are
very
mixed
and
I
think
this
reflects
the
fact
that
you
know
there's
a
kind
of
very
mixed
approach
to
offering
booking
api's
in
in
sector.
At
the
moment,
some
publishers
are
holding
opportunity,
data
which
isn't
bookable
just
by
its
nature,
so
walking
reads
outside
Jim's
walking
trails,
all
that
kind
of
stuff.
A
You
know
we
kind
of
need
to
know
and
be
aware
of
that,
and
just
be
clear
that
with
data
users,
that
not
everything
will
always
be
booked
abour,
but
we
need
to
nevertheless
be
encouraging
that
users
to
be
using
that
opportunity,
data
and
making
it
visible
to
potential
participants
to
make
picture.
People
are
seeing
the
breadth
of
opportunities
that
are
available
to
them.
A
I
think
quite
mixed
outlook
in
terms
of
platforms
in
terms
of
how
much
they
kind
of
brought
into
offering
complete
third
party
booking
experience,
so
whether
they
want
to
retain
some
ownership
of
the
that
kind
of
experience
and
that
kind
of
interaction
with
the
with
the
users
or
whether
they're
happy
for
it
to
be
really
done
on
somebody
else's
application
or
poor
platform.
I
think
that
kind
of
is
reflected
in
the
level
of
investment
that
some
publishers
made
around
api's.
A
We're
hearing
that
some
publishers
are
very
happy
to
provides
booking
api's,
but
before
they
do
anything,
they
want
some
guidance
from
us
as
a
program
in
order
to
get
a
better
sense
of
what
the
community
needs.
So
there
is
a
kind
of
definite
need
there
to
help
services,
but
also
that
this,
this
kind
of
work
from
a
platform
point
of
view
needs
to
be
slotted
into
existing
roadmaps.
A
There's
a
whole
variety
of
customer
needs
that
they're
meeting,
and
so
we
need
to
be
very
clear
with
them
about
when,
where
they
can
engage
with
both
helping
us
move
forward,
the
standardization
of
any
booking
api's,
but
also
when
it
will
be
ready
for
them
to
implement.
So
it's
quite
a
mixed
economy.
I
think
at
the
moment
and
in
terms
of
kind
of
general
feature
requirements
that
have
come
up
so
clearly
needs
for
booking
both
events
facilities.
So
people
are
interested
in
classes,
courses,
sports,
all
pitches,
table
tennis
tables
and
need
for
ticketing.
A
In
order
to
support
a
proper
third
party
booking
experience,
you
need
to
be
able
to
create,
update
and
cancel
bookings
somewhere.
Some
of
the
Plex
complexity
comes
in
is
around
with
how
you're
handling
how
people
handle
booking
of
individual
opportunities
or
multiple
sessions,
so,
whether
there's
some
time
in
signing
up
for
a
kind
of
full
schedule
of
events
where
their
bookings
are
for
individual
people
and
potentially
quite
a
lot
of
complexity
around
the
kind
of
business
models
in
terms
of
revenue
share
and
how
booking
is
made.
Sustainable
I
don't
feel
like.
A
That
is
something
that
we
should
be
kind
of
making
a
recommendation
on
within
this
group,
and
it's
not
something
that
we
would
necessarily
standardize.
But
it's
just
something
that
we
need
to
be
mindful
of
when
it
comes
to
any
technical
recommendations
that
they
may
need
still
need
to
be
some
negotiation
between
platforms
and
developers
in
terms
of
using
with
using
and
how
they
use
the
booking
api's,
or
what
kind
of
extra
information
that
may
need
to
be
passed
between
them
in
order
to
support
a
variety
of
different
business
models.
A
So
Sally's
sketched
out
of
a
few
areas
of
complexity
that
are
likely
to
kind
of
impact.
The
design
so
I'll,
just
kind
of
briefly
run
through
so
weather
api's
are
supporting
bookings
from
new
casual
users
or
from
members
the
different
types
of
booking,
so,
whether
it
booking
a
facility
or
an
event
group
based
bookings,
there's
complexity
that
we've
discussed
on
some
of
our
previous
calls
around
time.
A
So
an
event
may
be
scheduled
in
advance,
but
you
may
only
be
able
to
book
it
24
or
48
hours
before
it
begins.
So
this
there
in
terms
of
how,
when
data
users
can
kind
of
trigger
booking
processes
which
might
also
impact
the
way
that
we
are
surfacing
some
of
the
opportunity
to
obviously
could
be
a
lot
collects
D
around
how
payments
are
processed.
A
Cancellations,
security
testing,
I've
mentioned
sand
boxes.
So
you
know
really
anyone
who's
offering
an
API
needs
to
have
those
sandbox
that
allow
someone
to
test
it
in
their
application
before
moving
into
a
production
setting.
So
that's
got
some
implications
in
terms
of
how
people
surface
some
of
their
infrastructure
for
their
purchase
to
use
and
also
flex
tea
around
the
kind
of
user
handoff
between
the
different
services.
So
who
is
it?
The
user
is
directly
engaging
with
if
they've
received
follow-up
emails
with
tickets
or
stuff
in
the
post,
then
who
is
he
coming
from?
You
know?
A
So
quite
a
lot
to
dig
into
there's
some
in
Sally's
documents,
she's
put
some
initial,
quite
high-level
recommendations
around
what
we
think
platforms
need
to
think
about.
We've
also
been
working
on
a
document
that
spells
out
for
platforms
what
it
means
to
support
open,
active
in
terms
of
adding
features.
So
what
what
the
technical
implications?
That's
something
that
has
been
shared
with
a
couple
of
the
larger
platforms
already
but
I'm
hoping
to
get
that
kind
of
published
more
broadly,
so
people
have
got
a
better
idea
about
what
it
means
to
be
involved
from.
A
So
well,
we've
surfaced
quite
a
lot
of
complexity.
Here
we
need
to
start
to
find
some
way
to
prioritize
work
in
various
areas,
so
I've
put
together
a
survey,
there's
a
bitly
link
that,
hopefully
you
can
see
on
the
screen.
There
I'll
send
link
right
afterwards,
which
will
help
us
start
to
collect
some
use
cases.
So
within
the
survey
it
asks
asking
developers
to
provide
a
bit
of
information
about
their
application.
A
So
what
is
it
that
they're
building
give
an
example,
use
a
story
that
reflects
a
typical
booking
workflow
in
the
application
to
help
us
start
to
share
those
those
different
approaches
across
the
community
and
also
some
structured
questions
to
help
us
work
out.
Some
of
the
prioritization
around
booking
different
types
of
events
and
facilities.
A
Members
non-members
the
types
of
integration
that
people
want
to
do
with
platforms
where
they're
looking
to
integrate
with
specific
platforms
or
anyone
that
is
publishing
open,
active
data
so
yeah
and
encourage
anyone
who's
building,
applications
that
that
would
benefit
from
booking
api's.
To
fill
this
in
we'll
be
circulating
it
not
just
the
main
list,
but
through
our
usual
channels
as
well,
so
that
we
can
get
an
a
good
sense
of
requirements
across
the
community.
A
So,
in
terms
of
next
steps,
there
are
a
few
ways
that
people
can
start
to
feed
in
to
plans.
So
I've
already
mentioned
that
if
you
have
API
documentation
that
would
be
useful
for
us
to
look
at
then
then
please
share
it.
You
can
provide
comments
on
the
document
on
the
document.
Sally
has
put
together
to
give
us
feedback
on
some
of
our
findings
and
recommendations.
You
can
fill
in
the
survey
to
help
us
collect
a
bit
more
information
but
structured
information
and
we're
also
hoping
to
run
a.
A
D
Just
my
side
I
wonder
in
creating
this
this
framework.
What
bian
have
we
got
from
any
of
the
other
operators?
I
know,
for
example,
less
on
the
school
from
betting.
Berg
they've
got
very
good
API
documentation
at
the
moment
from
some
of
the
ones
that
have
not
got
such
good
documentation
have
you
spoke
from
them
about
them,
aligning
their
api's
to
the
specification
we're
trying
to
write
here.
B
B
But
the
this
all
kind
of
starts
from
the
customers
of
those
platforms,
and
what
we
understand
is
those
interest
from
those
customers,
certainly
seen
it
literally
in
class
day
and
accent
to
an
extent.
So
the
customers
asking
for
this
to
be
prioritized
as
a
requirement
is
something
that
the
big
systems
have
said.
If
the
customers
ask
for
it,
then
we'll
do
so
working
with
those
customers
to
just
see
if
they're
interested
in
doing
and
so
yes
they're
pushing
for
it.
B
So
as
much
as
we
can
facilitate
those
conversations
and
helping
people
understand
the
benefits
and
see
if
they
want
to
see
happen.
So
so
the
answers
yeah
it'll,
be
great.
If
they
were
all
in
this
Raymond
is
very
much
engaged
he's
alive,
and
so
they
are
certainly,
although
they're
the
fourth,
the
other
three
I
just
mentioned.
B
I
think
they
certainly
will
be
adopting
all
of
the
recommendations
as
soon
as
we
can
get
them
to
do
that,
and
then
obviously
there's
that
the
rest
of
the
systems,
including
looking
above
book
when
many
others
who
just
as
important
and
hopefully,
although
we
haven't
spent
as
much
time
with
those
there's
a
there's,
a
benefit
in
in
joining
in
with
this
as
this
progresses.
So
any
thoughts
on
how
we
make
this
more
accessible
or
encourage
people
to
do
that.
A
A
We
need
them
to
be
clear
about
what
their
individual
roadmap
and
we're
adding
support
for
elements
of
open
active
will
fit
into
that,
and
in
order
for
them
to
do
that,
they
needed
a
clearer
statement
from
us
as
a
program
about
what
we
were
going
to
be
asking
them
to
do
so.
That
was
the
kind
of
document,
though
I
mentioned
just
now,
where
we've
we've
laid
out
in
quite
clear
way
and
what
the
high-level
requirements
are.
A
But
in
order
to
get
more
detail
around
working,
we
need
to
kind
of
surface
more
of
the
requirements
for
the
community
around
what
we
know.
What's
the
most
important
thing
that
they
can
do
immediately,
that
will
address
as
many
people's
needs
as
possible.
So
that's
why
I've
kind
of
focused
on
this
survey
for
data
users,
because
we
can
turn
that
into
that
set
of
requirements
that
the
platforms
can
start
to
work
on,
and
he
may
be
that
there
are
some
short-term
improvements
that
they
could
be
doing
to
existing
API
services.
That
will
just
help.
A
A
A
If
we
go
into
that
in
more
detail
and
I,
think
that
they'll
give
me
a
bit
of
time
to
look
at
some
of
the
samples
that
you
sent
and
others
have
sent
and
and
kind
of
understand
what
they'll
come
if
defeat
is
between
what
we've
got
in
the
current
model
and
what
we
might
need
to
add
so
kind
of
stretched
way
to
move
forward.
Also
if
people
are
really
working,
facilities
is
more
important
than
booking
events,
and
obviously
we
need
to
note
that
first
and.
B
On
that
actually
on
facilities,
we've
got
school,
hire
booking
Berg
sports
and
one
other
booking
system
of
that
via
fusion
or
potentially
interested
in
publishing
or
facilitating
that
work.
My
understanding
last
few
weeks
of
conversation,
so
that's
for
potential
publishers
and
facility
data.
If
anyone
has
any
more
that
I
haven't
just
talked
about
that,
I
would
be
good
to
ask
that
list
and
bring
into
the
conversation.
B
D
E
So
I
think,
from
our
perspective,
the
the
interest
in
open,
active
is
really
I.
Guess
broaden
our
opportunity
for
booking
providers.
In
terms
of
you
know,
we
have
customers
the
want
open,
active
integration
and
therefore
you
know
release
conference
those
those
the
relevant
api's
in
terms
of
providing
that
term
integration.
D
A
Okay,
yes
interesting
I
mean
I
I
had
assumed
that
the
kind
of
payment
process,
so
so
I
think
the
category
that
will
pay
would
be
in
would
be
kind
of
hidden
behind
whatever
API
their
platforms,
providing
rather
than
you
having
to
integrate
booth,
will
pay,
as
well
as
when
yeah
my
misunderstanding.
What
that
the
issue
I.
D
So
if
you
want
to
disintegrate
with
the
well
payers
API
instead
of
just
publishing
their
widget,
they
can
make
that
very
difficult.
It's
not
completely
impossible,
but
it
takes
an
awful
lot
of
waiting
and
you
got
to
get
through
to
the
right
person.
It's
a
big
kind
of
payment
gateways,
though,
on
a
kind
of
Vedic
level.
It
might
be
worth
just
getting
them
into
the
conversations
to
explain
what
we're
trying
to
do
as
a
group
and
see
what
they
can
do
in
terms
of
making
API
as
payment
API
is
more
accessible.
B
There's
two
ways
of
doing
payment:
there's
treating
the
booking
system
as
an
isolated
system
that
you
just
say
I've
booked.
It
trust
me
there's
five
pounds
being
paid
and
then
a
separate
system
for
payment
a
chain
was
saying
where
you
then
do
the
payment,
and
so
the
way
you
do
that
is
you
lease
the
lease
the
slot
and
then
you
go
and
take
the
payment
of
five
pounds.
Then
you
say
that's
confirmed
and
you
make
separate
API
calls
to
those
two
different
systems:
alternately
and
totally
independently.
There's
no
links
between
the
two
systems.
B
It's
just
one
way
of
taking
payment
and
one
is
doing
booking
and
then
there's
another
approach
which
is
used
in
some
systems,
which
is
one
where
you
have
to
bounce
to
an
iframe
or
something
and
the
payment
process
it
does
it
and
then
it
gives
you
the
link
back,
I.
Think,
generally
speaking
from
the
data
user
conversations
we've
had,
the
latter
is
not
preferred
because
it
limits
the
use
cases.
So
Apple
watch
Apple
pay,
saving
credit
card
details
for
users
under
their
account,
so
you
can
easily
pay
seamlessly
and
against
each
provider.
B
All
those
things
stop
being
possible
if
you
have
to
bounce
people
to
different
iframes
depending
on
what
provider
they
happen
to
interact
with,
and
so
the
preference
seems
to
be
to
have.
This
kind
of
you
know
operate
talk
to
them.
People
talk
to
the
booking
system
and
I.
Think
our
all
the
discussions
here
have
been
very
much
focused
on
the
booking
system.
Api
is
and
what
they
provide
and
I
totally
understand.
Jamie's
point
on
the
payment
is
a
mess
strike.
Do
it
very
well,
a
lot
of
others?
B
A
F
It's
and
Easter
active
Devon,
the
the
only
area
and
I'm
only
flagging
this
up
as
I
think
it's
fun
to
bear
in
mind
for
the
future,
rather
than
any
of
the
general
thrust
of
the
conversation.
That's
happened
so
far
because
that's
clearly
the
you
know,
the
priority
areas
is
the
link
between
what
we're
talking
about
doing
here
and
opportunities
in
the
future
around
issues
like
social
prescribing,
where
there
are
two
aspects
that
I've
sort
of
spotted
now
respond
through
the
use
cases
and
others
for
this.
F
But
one
is
around
when
a
booking
is
made
there,
there
may
some
be
some
sort
of
authorization
or
acknowledgement
of
the
book
and
being
accepted
being
required
in
terms
of
the
eligibility
of
that
that
opportunity
for
the
the
person.
If
it's
you
know,
sort
of
clinical
setting
or
context,
the
other
thing
is
is
on
the
payment
side
in
terms
of
actually,
if
it's,
if
there
is
any
sort
of
revenue
attached
to
the
social
prescribing.
F
B
A
Scheduled
the
next
three
months
next
12x12
calls
I,
send
the
invite
round
to
the
mailing
list
earlier
I
thought
that
might
be
an
easy
way
for
people
to
get
the
calls
into
their
diaries.
But
there
is
still
the
shared
calendar
as
well,
which
I'll
continue
to
update,
and
so
the
first
call
in
the
new
year
will
be
on
17th
January
and
will
focus
on
facilities
just
discussing
then
the
end
of
January
we'll
do
another
round
around
booking.
A
So
I
want
to
make
sure
that
we're
keeping
this
as
open
as
possible,
so
that
people
who
can't
actually
make
it
on
the
day
will
still
have
an
opportunity
to
get
their
requirements
and
views
added
into
plans
and
then
sort
of
tends
to
be
suggested
that
we
should
return
to
the
activity
list
as
a
focus
for
the
call
in
February.
But
again,
there's
going
to
be
some
work
happening
before
that,
particularly
around
doing
some
more
to
validate
tool
evaluation
to
help
us
move
forward,
some
of
their
kind
of
data
management
aspects
of
that
so
yep.