►
From YouTube: CDF - SIG Interoperability Meeting 2020-11-26
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
B
A
C
Okay,
so
I
missed
the
last
three
or
four
meetings:
okay,
that
explains
you're
with
dynatrace
right
yeah,
so
you
I've
just
seen
you
with
sap.
D
B
Well,
how
is
the
you
don't
have
current
in
germany
or
austria,
yeah
or.
B
B
B
And
I
put
some
of
some
questions
to
the
under
the
topic,
the
white
paper
topic
and
if
we
have
time
left,
we
can
recap
the
discussion
we
start
few
weeks
ago
on
standardized
metadata.
B
So
before
all
the
topics
as
usual,
we
look
at
the
action
items
so
that
the
first
two
action
items
are
on
me
and
the
first
action
item
was
to
ping.
We
have
be
about
to
get
jenkins,
techno,
plugin
contribution
for
white
paper,
and
I
know
viva
contributed
that
case
study,
which
we
can
come
back
to
that
one
when
we
come
to
white
paper
topic.
So
I
mark
this
as
done,
and
the
next
action
item
is
again
on
me
to
pin
cameron
on
jenkins
spinnaker
case
study.
B
I
actually
did
that
and
cameron
said
he
will
check
with
his
colleagues
to
see
if
they
have
anything
to
contribute
there
and
since
today
is
all
day
for
him.
He
is
not
with
us,
but
I
will
follow
it
up
with
them
offline,
probably
monday,
to
see
if
they
will
make
it
on
time,
because
we
agreed
to
send
the
first
draft
to
creative
to
team
next
week.
B
We
can
have
some
flexibility
if
they
intend
to
contribute,
and
the
next
action
item
is
on
new
tracey,
to
arrange
a
working
session
for
the
white
paper,
which
is
this
meeting,
perhaps
yeah
so
thick.
I
did
that
and
update
the
meeting
time
to
4
pm
utc,
which
you
did
that
as
well
yeah,
I
got
invitation.
B
I
mean
to
bring
example
from
my
manifest
from
ebay
for
metadata
topic.
I
suggest
we
keep
it
open
because
I
know
ramen
started
talking
internally
to
get
permission
for
that,
so
we
keep
it
open
and
we
ask
him
next
time
when
we
meet
the
last
last
text.
Item
is
on
trace
reagan
and
still
tailored
to
demo
hoteliers
and
same
with
them.
They
are
probably
taking
time
off
today.
B
So,
as
I
mentioned
me,
and
some
others
made
updates
to
a
few
chapters
which
is
perhaps
good
to
go
through
those
chapters
live
and
see
what
updates
were
made
there
and
everyone
can
take
time
offline
to
review
them
and
provide
comments.
B
So
the
first
chapter
that
got
updates
is
this:
what
are
we
discussing
with
content
slurry,
so
this
paragraph
was
already
there.
I
added
martin
folder's
definitions
of
definition
of
ci
there,
because
that
is
kind
of
what
we
agreed
to
take
definitions
from
some
other
document,
and
this
was
this
is
perhaps
the
most
famous
definition
of
ci.
So
that's
why
I
included
it
there.
I
don't
know.
G
So
one
comment
in
general-
and
I
just
like
to
run
this
by
the
group
and
see
what
you
think
to
be
kind
of
self
like
consistent
across,
like
in
particular
I'm
thinking
of
the
landscape,
I'm
keen
to
use
the
term
continuous
delivery
as
the
umbrella,
for
you
know,
ci
and
deployment,
and
not
particularly
in
that
paragraph.
I
don't
think
that
that
one's
a
problem.
B
G
Okay,
like
later
on,
we
refer
to
tools
and
we
sort
of
say:
okay,
these
are
all
ci
cd
tools,
but
almost
making
the
distinction
between
ci
tools
and
pipeline
orchestration
tools,
which
is
consistent
with,
I
think
how
they
get
labeled
in
the
landscape.
G
So
one
of
the
the
main
things
if
you
look
at
the
cdf
landscape,
like
we
have
a
pipeline
orchestration
category
continuous
integration,
configuration
management,
there's
no
category
there,
that's
actually
called
continuous
delivery
because
continuous
delivery
is,
you
know
that
pulling
all
those
tools
together
to
be
able
to
to
release
sort
of
safely
and
securely
and
regularly.
B
B
So,
okay
moving
on
to
the
next
chapter,
so
the
next
chapter
is
what
does
interval
mean
continuously
every
context,
and
I
read
few
other
articles
from
different
industries
and
the
healthcare,
as
I
mentioned
during
plus
meeting
they
have
this
nice
article
talking
about
integration
versus
interoperability,
which
is
what
I
kind
of
got
influenced
by
their
definition,
and
I
took
some
things
from
that
article
and
added
some
of
my
views.
There,
followed
by
some
of
the
points
raised
by
the
people
when
it
comes
to
what
they
think
when
they
hear
interpreting
cd
context.
B
G
So
for
this
part
section
like
if
I
was
to
summarize
it,
are
we
basically
saying
here's?
This
is
what
integration
is,
which
is
kind
of
being
able
to
use
tools
together,
and
that's
not
what
we're
talking
about
we're
focused
on
interoperability,
which
is
more
specific,
and
then
we
give
those
examples
and
then
we're
saying
that's
what
we
want
to
drive
for
and
especially
tying
in.
I
think
standardization
yeah.
B
Summary
yeah
yeah,
I
think
the
the
most
important
aspect
of
this
like
why
are
we
focusing
internally,
is
to
make
users
lives
easier,
because
if
you
think
integration
users
may
need
to
put
custom
fixes
to
get
tools
to
talk
each
other.
If
those
tools
are
not
built
interpretably
in
mind,
but
if
interoperability
or
some
kind
of
standards
were
in
place,
users
will
have
less
trouble
to.
You
know,
bring
different
two
systems
together.
G
Okay-
and
I
guess
the
way
I
would
think
about
that
like
jenkins-
is
a
tool
which
supports
a
lot
of
integration,
which
is
fine.
You
can
integrate
a
lot
of
things,
but
that's
different
from
saying:
let's
have
interoperability
across
lots
of
different
tools
that
have
standardized
apis
and
metadata,
so
you
can
sort
of
move
pipelines
around
or
move
workloads
around
yeah.
G
G
B
Okay,
so
this
chapter
seems
to
be
you
know
good
enough
to
you
know
for
everyone
to
review,
and
the
next
chapter
is
key
considerations,
constraints
and
concerns.
So
I
added
some
considerations,
constraints
and
concerns
there,
like
lack
of
shared
vocabulary,
is
the
first
thing
we
did
within
the
seek.
So
I
simply
took
the
paragraph
from
the
rosetta
stone
document
and
put
it
there,
followed
by
the
complex
and
cicd
pipelines,
like
organizations
start
with
simple
ci,
perhaps
later
on.
B
They
extend
that
to
cd
and
over
time,
things
become
complex
and
they
need
to
look
at
things
in
an
end-to-end
way.
So
that
is
a
concern
like
how
to
have
with
those
things,
because
different
tools
and
technologies
take
part
in
that
type
of
setup,
and
the
next
constellation
is
being
agnostic
to
to
the
technology
and
processes.
B
And
somehow
we
need
to
you
know,
tie
these
considerations,
concerns
to
interoperability.
Again,
please
go
in
and
update.
You
can
even
delete
some
of
those
things
if
you
don't
think
they
make
sense
in
the
context
of
this
white
paper,
which
takes
us
to
trends
reusable
libraries
again.
This
is
something
we
discussed
early
like
before
summer
and
I
just
added
some
tools
there
and
they
need
to
have
a
home
for
those
libraries
which
may
be
developed
by
individuals
or
group
of
people
and
cdf
taking
providing
home
detect
on
hand.
Sharp
is
an
example.
B
B
I
B
E
It's
a
problem
of
of
calling
in
so
he
asked
to
get
the
raw
pin
code
in
the
jets.
Oh.
D
Yes,
yes
yeah,
so
hi
guys!
I'm
I
guess,
is
my
first
introduction
here.
So
I
work
at
red
hat
and
basically
I'll
just
quickly
go
through
this
case
study.
So
this
is
basically
the
technon
plan
plugin
for
jenkins,
and
it's
supposed
to
kind
of
bridge
the
gap
between
jenkins
and
techtown
in
terms
of
how
jenkins
users
can
get
to
know
tecton
easily
and
start
using
tecton
without
having
to
be
without
having
being
the
aml
engineers
or
anything
so
I'll.
D
D
D
Okay,
so,
let's
so
basically
for
this,
we
we
need
to
know
what
jenkins
is
and
what
tecton
is.
So
I
take
it
that
I
take
it
that
people
already
know
this
so
we'll
just
move
forward
to
what
the
solution
is
for
into
interoperability
between
jenkins
and
tecton.
D
The
whole
idea
behind
this
was
to
just
have
jenkins
users
to
get
started
with
tecton
without
without
having
to
play
with
yamls
and
just
basically
know
what
they
know
about
like
do
what
they
do
in
jenkins,
but
instead
of
doing
it
in
jenkins,
they
are
doing
it
in
tecton.
So
basically
they
just
use
their
jenkins
philosophies
of
build
steps,
and
then
they
get
started
with
tecton.
They
create
they
create
tasks.
Task
runs
pipeline
pipeline
runs.
D
So
that's
the
idea
that
we
are
going
here
with
so
currently
now
we'll
discuss
like
what
is
the
current
scope
and
where
we
are
right
now
and
what
is
there
for
the
future.
D
So
currently
we
are
supporting
these
build
steps,
create
resource,
create
tasks,
create
task,
run
and
delete
resource
and
create
resource
and
delete
resource
here
are
raw,
which
means
that
you
will
be
able
to
give
a
url
or
yaml
and
then
create
the
resources
you
know
through
them,
and
this
is
done
through
build
steps.
So
build
steps
are
a
very
common.
D
We
is
a
very
common
way
in
which
jenkins
users
usually
do
things,
and
it
gets
things
done.
It
is
different
from
pipeline,
which
requires
users
to
know
a
little
more
about
jenkins
and
kind
of,
and
jenkins
file
is
a
part
of
that.
So
this
is
this
is
something
that
is
not
supported
so,
but
currently,
this
is.
This
is
what
the.
D
Have
so
next,
I'm
just
I'll
just
elaborate
on
what
these
are
exactly
so.
The
raw
steps
that
are
there
right
now,
which
are
tecton,
create,
draw,
create
resource
raw
and
tecton,
create
delete
resource
raw.
These
these
ones
will
allow
you
to
use
url
or
yaml
to
create
resources,
and
you
can
input
your
url
where
your
resource
lies
and
then
your
yaml,
whatever
it
is,
you
can
just
give
it
and
then
the
plugin
will
figure
out
okay.
D
So
the
main
idea
with
this
plug-in
is
that
the
user
should
be
able
to
interact
with
tecton
jenkins
users
should
be
able
to
interact
with
tecton
without
knowing
much
of
tecton,
so
it
should
be
more
of
a
fill
in
the
blanks
kind
of
scenario.
D
D
There
is
a
lot
more
to
do
even
in
the
task
and
task
runs
so
and
it
is,
it
is
on
the
roadmap,
but
basically
you
should
be
able
to
create
tasks
or
tasks
or
any
tecton
resource
in
a
very
interactive
way
without
having
to
like
figure
out
the
api
go,
you
should
just
able
to
click
button.
Okay,
I
want
to
add
this.
This
can
add
this.
Also,
oh,
that's
cool.
D
So
the
jenkins
user
is
just
kind
of
blazes
through
all
this
tecton
stuff
without
having
to
refer
to
much
of
documentation,
because
all
of
the
help
will
be
given
on
the
plugin
itself.
D
So
task
run
is
similar
and
in
the
future
there
will
be
auto
filling
of
these
task.
References
or
pipeline
references
for
pipeline
runs
and
stuff.
D
So
in
this
case
the
it
it
it
provides
like
the
jenkins
users
complete
control
of
what
they
are
doing
and
they
wouldn't
have
to
go
to
the
terminal,
select
figure
out
what
tasks
they
want
to.
What
task
is
there
and
then
copy
paste?
The
name
because
the
times
some
tasks
are
created
with
generate
name,
so
you
can't
always
know
the
name
of
certain
resources
and
stuff,
so
you
this
will
just
make
it
easier
for
the
jenkins
users
to
do
things.
D
So
what
is
what's
remaining
in
the
current
scope
in
the
current
scope,
as
you
saw,
there's
very
limited
support
that
is
there
for
creating
things
and,
what's
remaining
is
the
complete
support
for
interactive
creation
of
all
the
resources,
including
event,
listener
templates
and
everything
in
between
two
pipeline
pipeline
runs
and.
F
D
Then
what
is
what
is
most
ambitious
about
this
project
is
that
it
should
give
tecton
hub
or
catalog
support
and
yaml
hydration
into
the
into
the
build
step,
so
that
you
should
just
give
an
amul
like
a
task
camel,
and
then
it
will
just
basically
fill
out
the
entire
task,
with
whatever
is
there
in
the
yaml
and
then
you
can
go
ahead,
edit.
It
and
just
basically
get
get
down
to
the
using
the
task
directly
and
the
tech
town
catalog
support
is
basically
so.
D
Basically,
the
tecton
hub
is
a
place
where
there
are
tasks
and
task
runs
sorry
tasks
which
can
be
used
and
reused.
So,
with
the
hub
support,
you
should
be
able
to
use
tasks,
and
just
the
user
would
have
to
provide
what
parameters
they
want
for
each
task
for
their
task
runs
and
then
execute
those
trusteds.
D
So
next,
as
I
had
said,
the
next
thing
that
would
be
coming
up
is
resource
discovery
and
autofill
support.
So
if
I
have
a
reference
to
a
task
or
a
pipeline,
I
should
be
able
to
give
it
in
my
pipeline
or
not
asked
in
the
ui
itself,
so
this
will
make
it
easy
for
the
users
to
kind
of
you
know
not
have
to
search
for
the
task
or
the
pipeline
and
just
get
started
with
their
jenkins
jobs,
and
you
can
check
out
the
rest
of
the
roadmap
here.
D
It's
not
a
lot,
but
it
will
definitely
help
jenkins
users
get
get
to
know
tecton
and
the
timeline
for
this
is
by
the
end
of
q1
2021
for
delivery,
and
this
will
include
obviously
good
coverage,
support
and
testing.
D
So
this
is
the
current
scope
that
we
are
working
on
right
now.
The
next
thing,
what
sort
of
so
what's
for
the
future
is
the
cloud
event
support
which
is
not
thoroughly
discussed
yet,
but
this
was
just
an
idea
that
was
discussed
in
the
cloud
native
sig
for
jenkins.
So
we
really
don't
know
how
this
one
will
go
about,
but
considering
that
ci
cd
systems
can
be
considered
as
like
a
seas
and
the
water
that
goes
in
between
could
be
cloud.
D
Events
to
trigger
or
to
reach
reach
each
of
those
pools
of
water
and
get
stuff
moving
so
cloud
events,
as
we
know
they
are
important
in
this
landscape,
and
support
for
this
would
be
good,
but
there
is
still
stuff
that
needs
to
be
planned
in
this
case,
and
this
is
this
is
basically
it
so.
Thank
you
and
any
questions
stop
sharing
my
screen.
F
Thank
you.
That
was
a
that's
an
excellent
presentation.
It
was
interesting
to
me
that
one
of
the
things
you
highlighted
that
this
project
would
do
would
be
to
help
jenkins
users
become
more
familiar
with
taxon.
D
Yeah,
so
the
the
reason
I
even
started
this
project
was
because,
like
jenkins
users,
don't
know
tecton
and
the
way
they
would
usually
go
about
using
tecton
at
first,
they
would
write
the
tkn
tkn
task
start
get
like
they
would
use
the
tk
and
command
line
inside
the
jenkins
file,
which
is
a
very
crude
way
of
interoperability.
F
B
So
the
next
case
study
was
controlled
by
karen
james
on
jenkins,
x
and
tech
tone.
If
you
want
to
say
a
few
words
kara
or
james.
I
Nice
yeah
so
finally
got
to
it.
Sorry
for
the
delays
very
persistent.
Thank
you
very
much
for
bearing
with
me
for
bearing
with
us
yeah
it's
just
trying
to
keep
it
a
bit
high
level
you
can.
Anyone
can
have
a
read
a
bit
after
this.
I
We
just
wanted
to
try
and
not
do
too
technical
keep
a
high
level
some
of
the
advantages
of
of
tecton
and
why
jenkins
x
uses
it
and
kind
of
the
deep
interoperability
we
have
without
sharing
the
data
between
and
the
visualizations
as
well
so
yeah
feedback.
Welcome.
I
If
there's
anything
that
one
thing
wants
to
change,
we
can
do
it's
also
taking
a
bit
of
a
bit
of
a
snippet
out
of
a
blog
that
james
did
kind
of
kind
of
talks
about
the
structure
and
shows
that
we've
got
you
know
native
tecton
resources
actually
embedded
in
the
in
the
git
repos.
So
it's
just
hopefully
going
to
spark
some
interest
and
people
understand
a
little
bit
more.
They
can
relate
to
it.
I
B
B
Okay-
and
the
next
case
study
is
the
new
one.
One
of
the
new
ones-
zul
and
jeremy
from
open
infrastructure
foundation
contribute
this
and
it
is.
It
looks
similar
to
captain
case
study
because
rule
case
study
talks
about
how
zuul
is
helping
companies
to
achieve
interoperability,
especially
between
acm
systems.
I
think
github
and
garrett
were
the
two
of
them,
and
originally
we
discussed
this
contribution
as
well
cars
contribution.
But
when
I
had
a
chat
with
james,
he
sorry
jeremy,
he
mentioned
he
found
some
other
case
studies
from
zold
users.
B
B
G
So
just
a
general
comment:
how
do
I
say
this
like
to
me?
It's
not
necessarily
clear
like.
I
think
we
need
to
be
better
on
the
narrative
here,
because
it's
like
like
what
is
the
message
from
each
case
study
and
I
wonder
if
the
way
to
achieve
that
is
tying
some
of
these
case
studies
in
under
the
trends.
So
we
talk
about
a
trend
and
then
here's
the
example.
G
But
a
lot
of
the
case
studies
seem
to
be
kind
of
a
mix
of
here's,
some
technology
or
here's
some
people
using
it,
but
it
doesn't
like.
We
don't
necessarily
emphasize
what
the
point
is.
So
if
I
had
to
be
a
bit
more
critical
so
like
if
we
took
let's
say
the
captain
case
study
and
it's
in
the
section
where
we're
talking
about
cloud
events
and
we're
saying:
okay,
here's
how
cloud
events
are
making
a
difference
and
then
a
specific
example
is
kept
and
this
company
amazon.
G
G
I
I
wonder
if
there's
a
way
I
could
kind
of
agree
actually,
but
I
wonder
if
there's
a
way
to
try
and
you
the
theme
you
mentioned,
I
wonder
if
there's
a
way
to
kind
of
have
it
relate
to
some
some
kind
of
capabilities
from
the
except
from
accelerate
or
state
devops
that
we
kind
of
mentioned
before
that
we
kind
of
we
want
to
be
acknowledging
those
the
work.
I
That's
been
done
there
around
around
accelerating
the
the
efforts
that
they've
identified,
but
I
wonder
if
that's
we
could
show
some
kind
of
interoperability
that
that's
there.
That
kind
of
also,
then
helps
with
that
is
the
threat.
There's
the
trend
would
that
that
work,
or
is
that
too
much
work
or
does
that
make
sense.
G
So
I
can
see
that
for
like
when
we
talk
about
loose
coupling,
we
have
that
section
on
loose
coupling
and
I
think
that
ties
in
with
accelerate
so
then
maybe
pulling
in
some
examples
of
saying.
Okay,
these
tools
work
in
that
way
and
they're
loosely
coupled.
So
it's
it's
a
good,
a
good
way
to
approach
it
other
than
loose
couple.
I
have
to
give
it
some
more
thought.
H
B
B
Okay,
so
I
put
few
questions
to
the
agenda.
So
you
know
one
of
the
objectives
with
this
white
paper
is
to
address
different
audiences,
so
we
have
an
introduction
section
in
the
paper.
I
don't
know
if
we
should
convert
it
to
executive
summary
or
have
an
executive
summary
separately.
So,
like
decisions
makers
can
just
read
one
paragraph
or
something
and
see?
Oh,
this
is
an
important
thing.
We
should
really
get
engaged
and
contribute
and
collaborate
and
invest
in
this,
but
I'm
not
good
at
those
things.
G
Yeah,
I
think
that
could
work.
I
threw
in
a
conclusion
as
well
just
before
the
meeting
and
for
me
I
think
that
would
kind
of
tie
into
an
executive
summary
which
is
basically
saying
this.
Whole
landscape
is
ripe
for
driving
interoperability
and
then
this
is
the
group
doing
it
and
you
should
just
get
involved.
And
yes,
yes,.
B
G
B
Faster,
so
my
question
answered,
so
we
the
other
thing
I
put
here,
because
we
talk
about
lots
of
things
in
the
paper
like
the
tools
technologies.
Like
some
definitions
like
we
like,
I
personally
took
some
of
the
definitions
from
somewhere
else,
so
collecting
references
chapters,
references
yeah,
putting
a
references
chapter
for
further
reading,
for
example,
at
the
same
time,
giving
credit
to
others
who
came
up
with
those
stuff,
you
know
to
be
like
to
create
people
properly
and
also
give
people
to
blows
things
around
when
they
read
the
paper.
Oh
tacton.
B
D
I
I
had
a
question
when
we
say
audiences:
what
are
the
different
kind
of
audiences
we
are
talking
about
here
like
in
my
mind,
the
first
audience
that
comes
is
someone
who's
on
a
legacy
system
needs
to
get
on
with
the
new
system.
Then
there
is
someone
who
is
starting
off
can
do
experimental.
They
would
like
to
use
different
kind
of
ci
cds.
D
Are
there
any
numbers
around
like
how
what
like
what
other,
what.
F
B
When
I
think
about
audiences
is,
one
of
them
is
like
decision
makers
or
the
people
with
the
money.
You
know
who
can
say,
let's
go
and
work
in
this
thing,
so
that
is
one
of
the
audiences
and
the
other
audience
is
like
developers,
because
developers
take
part
in
communities
and
come
and
contribute
so
like
that
was
what
was
in
my
mind
when
I
asked
the
question
audience
like
how
to
address
different
people
because,
like
if
you
are
on
c
level
executive,
and
if
you
get
this
paper,
you
will
not
have
time
to
read
15
pages.
B
B
G
B
So
the
only
one
who
put
references
is
rule
case
study
so.
G
G
I
I
actually
I
had
some
links,
but
I
removed
them
because
I
figured
I
didn't
know
how
it
was
going
to
be
distributed.
So
if
it's
like
a
would
be.
B
Now
we
can
use
this
academic
type
of
cross
referencing,
like
numbers
like
number
one,
the
references
down
numbers
and
that
type
of
stuff,
something
like
that
and
also
tracy.
If
you
have
other
material,
you
want
to
link
like
on
the
further
reading.
It
doesn't
have
to
be
reference
like
linked
in
the
paper,
but
just.
G
E
G
Yeah,
I
don't
think
I
think,
we're
more
linking
to
further
reading
around
the
concepts
or
the
broader
story,
not
so
much
companies
thanks.
B
So
this
quest
yeah
contributors,
so
I
went
through
the
history
of
this
document
and
looked
at
comments
and
so
on,
and
I
listed
people
who
contributed
different
ways.
So
if
I
miss
your
name,
apologies,
please
add
your
name
there
directly.
It
wasn't
intentional.
B
G
I
think
like
for
future
you,
you
had
a
good
section
in
your
article
on
interoperability,
the
ericsson
one.
So
I
would
suggest
we
take
from
some
of
that.
I
think
it
talks
about
openness
and
transparency
and
people
working
together.
So
I
would,
if
you're
happy
for
us
to
use
that.
B
B
B
So
we
have
a
few
chapters
and
this
reading
further
reading
and
references
thing,
I
think
we
can
fix
those,
but
the
biggest
thing
I
see
here
what
you
tracy
mentioned,
like
tying
case
studies
to
trends
and
other
things.
All
that
is
a
bit.
You
know
larger
work
of
body
of
work.
G
Yeah,
if
you
want
to
think
on
that
I've
got
some
thoughts
of
how
to
so
well,
I
could
take
a
pass
edit
and
send
that
around
and
see
what
folks
think.
B
Yeah
or
maybe
we
can
directly
bring
the
creative
team
to
this
as
well,
so
they
and
us
do
the
work
in
parallel.
They
can
give
firstly
to
see
okay.
This
looks
great
all
this
misses
this
thing
and
at
the
same
time
we
adjust
the
structure
and
it
is
like
15
pages.
I
don't
know
if,
like
the
white
papers
generally,
are
less
than
10
pages
the
ones
I've
seen
so
this
is
like
pretty
extensive.
To
be
honest,
we
put
a
lot
of
effort
into
this,
so
my
worry
is
like.
Will
people
read
this.
I
I
G
I
G
Project
logos:
we
should
go
sprinkle,
those
in.
G
B
Okay,
so
then
we
continue
working
with
this
and
tracy
and
we
can
have
with
the
creative
folks
now
if
they
can
point
this,
you
can
point
this
to
them
or
like.
If
I
know
who's
talked
to,
I
know
who
are
those
folks.
B
Okay,
so
we
have
13
minutes
left
and
I'm
wondering
if
we
should.
You
know
talk
about
standardized
metadata
now
to
at
least
see
where
we
are,
and
we
come
in
on
the
topic
two
weeks
later,
when
we
have
fox
from
us
back,
because
we
changed
the
time
start
time
of
the
meeting
as
well.
B
Okay,
so
this
is
where
we
left,
we
discussed
to
start
a
document
and
we
had
tracy,
steve
and
james
james
volunteered
for
the
work
and,
as
you
see
it's
empty
at
moment
and
few
of
the
extinct
force
listed
here.
B
Okay,
and
also
like
I
want
to
pull
in
andrea's
materials
because
you
some
of
the
things
you
are
talking,
events
work
stream
are
related
to
metadata.
Maybe
you
could,
you
know,
share
your
thoughts
on
the
documents
as
a
you
know,
as
an
existing
effort,
because
you
have
been
talking
about
events
for
last
couple
of
months,
and
so
we
bring
your
thoughts
to
this
work
as
well.
C
J
B
And
unless
okay,
then,
I
will
pink
roman
again,
and
hopefully
we
will
have
some
examples
by
next
meeting
like
jenkins
x.
Metadata
would
be,
example
would
be
great
to
have
so
we
don't
start
from
scratch
and
also
if
we
get
some
input
from
advanced
work
stream.
That
would
be
good
things.
So
we
see
different
perspectives
for
this
topic,
and
then
we
see
where
we
are
after
that
meeting.
B
Thanks
a
lot
everyone,
especially
with
the
white
paper.
I
think
this
was
huge
amount
of
work
and
there
is
lots
of
valuable
thing
here.
I
think
this
will
be
a
good
closure
to
2020,
no
matter
how
bad
the
year
was
so
and
then
we
can
read
this
during
our
christmas
break.
While
we
think
what
will
happen
in
2021.
B
Brilliant
yeah,
okay,
thank
you
all
and
have
a
nice
day
weekend
week
evening
and
weekend
and
talk
to
you
in
two
weeks,
perhaps
the
last
meeting
for
the
year,
because
then
we
will
go
to
christmas
break,
but
we
talk
about
that
during
next
meeting
about
what
to
do
with
the
remaining
meetings.
But
again,
thank
you
and
talk
to
you
in
two
weeks.