►
From YouTube: CDEvents / SIG Events Vocabulary - Nov 29, 2022
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
B
C
B
B
B
No
problem
I
just
want
to
start
by.
D
Making
sure
that
we
understand
that
you
know,
despite
we're
going
through
a
lot
of
discussion
on
the
feedback
on
the
GitHub
repo,
it's
all
intended
in
in
a
friendly,
and
you
know
non-aggressive
manner.
B
D
Easy
to
come
across
as
very
terse
when
you're
you're
typing
into
loads
of
little
text
boxes.
But
that's
genuinely
not
not
the
intention
at
all.
A
C
Thanks
Terry
yeah
I,
it's
I
I.
It's
not
my
intention
either
to
come
across
this
across
here
at
also
I
I
hope.
That's
not
the
impression
that
giving
but
I
think
it's
healthy
discussion
on
the
topics,
but
I
appreciate
all
the
input
for
sure
yeah.
D
And
that
there's
there's
lots
of
little
points
that
we're
starting
to
kind
of
touch
on
now
that
are
are
all
fairly
big
decisions
that
you
know
it
would
be
good
to
to
get
all
these
settled
and
standardized
and
undocumented
and
I
I
think
you
know
it's
important
important
important.
D
It
can
be
yeah
a
bit
tedious
to
to
have
to
go
through
in
this
level
of
detail,
and
you
know
work
all
these
things
out,
but
once
we've
done
it
at
least
nobody
else
is
gonna
have
to
go
through
it
again
for
a
while.
B
I
I'm
not
aware
of
anyone
working
that
way,
certainly
with
the
the.
D
A
Because
I
saw
one
of
those
comments
around
that
topic
and
I
guess
we
need
to
to
decide
if
we
wanted
to
be
I
mean
readable,
at
least
in
GitHub
as
well,
and
when
it
comes
to
images
and
those
things
without
too
much
extra
if
needed
and
such
so.
Maybe
you
don't
need
to
strive
for
that,
but
if
we
don't
have
it
really,
but
in
GitHub
we
should
of
course
have
it
easily
updatable
for
any
commit
made
with
previews
and
such
things,
I
guess,
on
the
docs
site.
A
Third,
pull
requests
that
I
assume
in
some
way.
If
that's
possible.
D
Place
just
to
start
that
discussion
is
is
to
say,
coming
in
from
an
outsider
and
starting
to
to
work
with
this
as
a
an
external
committal.
Would
all
of
the
the
big
challenges
that
I'm
hitting
every
revolve
around
the
fact
that
we've
got
the
spec
in
a
different
repo
to
to
the
place
where
we're
trying
to
publish
it
and
it
all
nearly
all
the
complexity
that
we're
starting
to
inherit
in
you
know,
things
like
release,
processes
and
automation.
Stuff
like
that,
are
nearly
all
derived
from
that
structure.
D
B
D
C
A
B
C
C
And
the
reason
for
for
that
is
that
we
want
to
you
know:
I
mean
the
documentation
is
written
by
maintainers
of
the
different
projects,
and
so
it
makes
it
things
easier
from
yeah.
C
That's
definitely
more
complex
at
what
we
do
for
it
for
City
events.
A
Sorry,
I
think
that's
actually
an
interesting
idea
or
interesting
discussion
there,
because
I
mean
in
the
long
run
if
we
would
include
other
repositories
from
City
events
into
the
city
events.tem
site
as
well,
eventually
or
how
you
do
it
in
tecton.
If
there
are
different
maintainer
groups,
for
example,
for
those
different
repositories
which
I
assume
you
have
intact
on.
How
can
you
make
sure
that
the
the
combined
documentation
is
consistent
and
looks?
Looks
good,
I
mean
if
you
don't
have
any
overall
overview
review
on
the
complete
site
itself?
C
So
we
we
have
a
documentation,
working
group
and
I
guess
what
we
do
in
the
documentation
working
group,
it's
a
kind
of
provide
guidelines
and
the
design
for
what
we
want
to
do
the
documentation
to
look
like
yeah,
and
then
we
we
kind
of
promote
these
to
to
the
other
groups,
but
yeah.
So
that's
that's
a
very
good
point.
C
I
mean
so
that's
kind
of
the
flip
side
of
the
coin,
because
it
means
that
it's
not
it's
not
possible
for
the
documentation,
working
group
to
kind
of
review
and
approve
documentation,
changes
before
they're
done.
C
A
Yeah
and,
of
course,
that's
better
to
get
things
out,
probably
and
then
fix
it.
Yes,
there's
any
other
I
mean
yeah
I
think
we
cannot
review
for
weeks
before
we
publish
something
as
well,
so
at
least
not
for
the
series
at
this
stage
anyway,
of
course,
maybe
in
the
long
run.
C
E
B
C
What
I
was
saying
is
that
when
I
started
things
when
I
set
up
the
website
for
for
City
events,
and
this
we
created
the
spec
repo
I
mean
my
initial
view
was
okay.
The
City
events
website
will
be
where
we
put
like
more
general
or
high
level
information
about
the
project
and
how
to
reach
out
to
the
community
and
so
forth,
and
then
the
spec
Reaper
would
be
like
the
reference
for
you
know
implementers
and
things
where
you
get
the
actual
specification.
C
But
since
it
was
easy
enough
to
link
this
back
and
to
publish
it
to
to
the
website,
I
thought
it
was
a
nice
convenience
to
have,
but
I
never
really
imagined
it.
In
my
mind,
as
like
the
primary
place
for
like
the
the
production
for
the
spec
size,
so
I've
always
imagined,
like
someone
contributed
to
the
spec
working
on
the
spec
repo
and
not
getting
bothered
with
any
and.
C
Rendering
aspect
on
the
website,
but
that's
that
was
my
initial
mindset
for
setting
this
up,
and
maybe
it's
actually
good
that
you're,
not
not.
Maybe
it's
it's
good
that
you
bring
this
up,
because
that
was
just
my
initial
idea.
Maybe
we
need
to
revise
that
and
we
want
the
website
to
be
like
the
primary
place
for
for
this
pack
as
well
and
yeah.
C
So
maybe
then
we
should
merge
the
the
two
Reapers
I'm,
not
sure,
if
it's
something
that
we
should
do
now
or
maybe
after
the
initial
rework
is
done,
it
depends
a
bit
on
the
time
and
I
think
if
we
go
into
merging
the
two
repos
together
now
it
will
add
to
the
to
the
amount
of
work
and
timeline
that
we
have
to
do
to
get
to
the
end
of
the
rework
but
yeah.
D
D
There
are
some
technical
challenges
that
affect
how
well
we
can
make
this
look
as
a
result
of
having
it
this
way
around.
So
if
you
are,
if
you're
mastering
in
GitHub
flavored
markdown,
then
you're
fairly
constrained
in
how
that's
going
to
be
rendered
both
under
GitHub
and
under
doxy.
D
So
you
know
one
example
of
that
is
that
all
the
images
are
getting
pushed
you
know
they're
being
justified
left,
whereas,
ideally,
we
would
like
to
be
able
to
either
Center
them
or
flow
text
around
them,
so
that
the
the
page
looked
more
polished
when
people
were
reading
it.
D
There
are
bigger
problems
that
we're
just
beginning
to
touch
upon
which
are
related
to
the
the
navigation
and
structure
of
doxy
yeah,
because
doxies
intended
as
a
framework
for
documentation,
and
so
it
has
a
particular
expectation
on
how
you
structure
it
its
documents
and
that
overall
structure
is
not
compatible
with
direct
links
in
documents
to
other
files.
D
So
once
you
get
Beyond
a
a
trivial
example,
you
start
to
run
into
lots
of
places
where
your
links
don't
work
in
both
environments
and
we've
seen
some
of
that,
but
there's
also
another
related
problem,
which
is
that
doxy
really
expects
lots
of
nested
folders,
and
it
also
generates
all
of
its
navigation
based
on
that
folder
structure.
D
So,
if
we're
trying
to
put
everything
in
one
folder,
which
is
a
sub
module
from
a
different
Repository,
we
start
to
quickly
run
up
against
problems
of
how
we've
then
render
that
navigation.
With
on
the
doxy
side,
no
one
of
the
things
you
might
be
able
to
see
in
you
know
a
preview
of
this
contributions
document
is
that
it
renders
in
the
flow
of
the
specification
page
so
because
it
all
sits
under
that
docs
repo
doxy
expects
it
to
be
an
item
in
the
side
menu
of
that
category.
D
So
then
there
are
a
number
of
documents,
like
the
roadmap
document
that
also
start
to
fall
into
that
category.
So,
as
you
want
to
put
more
information
on
the
site,
you're
going
to
find
more
and
more
examples
of
these
things
that
they
Clash
they
don't
fit
in
in
the
same
navigational
model
of
the
world.
A
A
Page
for
for
the
protocol
and
have,
of
course,
you
should
read
me
MD
and
other
top
level
structure
of
some
some
documents
in
there,
which
are
only
then
on
GitHub
and
intended
forget
that
having
the
the
actual
official
published
documentation
could
still
be
in
this
picture
report
and
to
keep
it
tightly
connected
to
this
to
this
spec
itself.
So
we
have
it
versioned
in
the
right
way
and
branched
and
everything,
but
that
if
we
lose
the.
A
A
But
to
have
that
as
a
I
mean
Echo
should
go
that
way.
I
think
we
really
need
a
good
way
to
preview
every
pull
request
the
documentation
of
every
holy
question
and
also
have
a
good
way
of
working
with
your
in
your
own
client
environment.
When
you
update
these
things,
so
you
can
render
it
in
a
good
way
there.
A
Well,
we
gain
a
lot
to
think
Terry.
We
drop
the
GitHub
as
a
front-end
for
the
documentation.
D
Moving
the
narrative
documents
into
who
who
who
and
dropping
the
sub
module,
because
that
would
eliminate
nearly
all
the
complexity
that
you're
currently
having
to
work
around
and
would
make
it
really
really
easy
for
everyone
to
to
operate
on
the
documentation.
D
So
the
the
point
against
that
is,
you
know:
do
you
have
definite
requirements
for
the
the
same
situation
in
the
future
that
you're,
seeing
with
tecton,
where
you're
expecting
to
have
lots
of
contributors
each
with
their
own
repos,
pushing
loads
of
content
that
you
want
to
publish
on
on
this
external
site.
A
But
then,
apart
from
that
I
mean
if
you
would
have
like
event,
transmitters
or
events,
consumers
or
something
like
that.
Such
projects
I,
don't
think
we
need
to
have
generated
documentation,
close
included
on
the
same
website
I,
don't
think
that
will
be
necessary
really,
but
maybe
for
the
sdks.
B
D
Think
maybe
there's
a
sorry
that,
let
me
just
do
do
this
one
piece
and
then
I'll
hand
over
to
you
I
I,
think
possibly
what
we
have
here
is
a
a
need
for
a
road
map,
a
maturity
of
this
project,
because
right
now
it's
it's
mostly
you
having
to
maintain
all
of
this
documentation
and
the
harsh
problem
is
getting
anyone
else
to
join
and
contribute.
D
D
Stage
to
optimize
for
reducing
the
workload
for
you
and
also
making
it
as
attractive
as
possible
for
other
people
to
get
involved
and
contribute
without
a
steep
learning
curve
and
then
moving
forwards.
If
you
think
that
it's
likely
to
become
a
very,
very
active
project
with
a
lot
of
contributors
in
different
areas,
then
start
to
think
about
how
you
would
manage
that
to
mitigate
the
complexity
that
comes
in
in
that
direction.
D
C
C
We
we
have
like
the
API
reference,
which
is
generated
out
of
the
some
crd
definitions,
and
there
is
some
preference
for
the
CLI,
which
is
also
generated,
so
those
are
imported
in
with
some
sync
script,
but
there
could
be
usually
those
are
like
one
big
page
with
links
within
so
I
mean
there
are
ways
we
could
automate
that
just
even
having
a
single
repo,
we
could
say
like
every
time
we
make
a
release
on
the
SDK.
C
It
automatically
generates
a
pull
request
to
the
web,
repo
that
pushes
the
latest
version
of
of
that
file.
In
there
I
mean
it
would
mean
maintaining
several
copies,
but
I
think
it's.
It's
acceptable,
yeah
the
for
me
the
having
the
separate
repo
for
the
spec
I
I
like
having
the
diversioning
in
the
text
of
the
spec
specific
content
on
the
dedicated
repo
I.
Guess,
that's
the
main
motivation
I
see
the
the
website
is
a
different
thing
from
from
the
spec
and.
B
C
For
me
personally,
I
don't
see
the
the
big
obstacles
for
the
development
process,
but
yeah
I
might
not.
I
might
have
a
biased
view
there,
since
I've
been
working
with
this
for
some
time.
So
maybe
it
seems
not
a
showstopper
to
me,
but
maybe
it
is
more
complicated,
I
I'm,
not
sure
I
I
understand
your
point.
Terry
that
I
mean
for
future
contributors.
C
We
want
to
keep
the
development
process
as
lean
and
straightforward
as
possible,
but
I
think
for
you
know
no
sorry,
but
just
thinking
that
yeah,
if
we,
if
we
keep
the
spec
browsable
on
the
spec
site,
the
the
development
process
is
is
relatively
straightforward.
But
of
course,
if
like
Emil
suggested
I
mean
we,
we
then
optimize
for
a
review
on
the
web,
which
makes
sort
of
sense
as
well
yeah
I,
guess
the
development
process
and
would
become
more
complex.
Maybe
we
would
need
to
address
that
complexity.
E
B
E
D
Still
have
that
versioning
mechanism,
so
you
just
have
a
a
working
branch
and
acceptable
requests
against
that
branch
and
and
then
have
a
formal
tagged
release
against
that
Branch.
But
it's
on
the
CD
events.deb
repo.
A
Yeah
I'm
just
thinking
about
what
you
said
that
Terry
on
on
that
we
shouldn't
I
mean
since
we
are
a
very
small
project
still
and
we
cannot
afford
to
have
too
much
sugar
cumbersome
process
and
we
should
make
it
easy
for
newcomers
to
come
in
and
contribute.
A
A
Maybe
so
that
would
be
the
reason
for
keeping
the
spec
documentation
Maybe
only
in
GitHub
and
just
learning
the
website
for
the
the
new
cameras
and
I
put
a
data
general
information,
but
on
the
other
hand,
I
would
like
to
see
that
we
do
the
work
now
to
to
make
a
good
looking
website
with
the
spec
rendered
into
it,
like
the
big
projects
have
the
recognets
and
those
big
projects.
A
B
D
I,
I
I
won't
look
at
what
scripting
changes
and
automation
changes.
We
would
need
to
do
initially,
but
just
just
do
the
piece
of
work
to
say:
okay,
here's
how
we
could
handle
that
and
that
maybe
what
you
could
do
is
set
up
a
branch
on
on
that
repo.
D
Just
as
a
you
know,
a
demo
working
branch
and
rpr
against
that.
So
we're
we're
completely
separate,
but
but
then
we
could
you
know
we
could
explore
that
and
and
what
that
does.
From
the
simplification
point
of
view.
D
So
I
think
all
of
the
all
the
MD
files
that
are
in
the
spec
repo
that
we're
currently
rendering
in
in
that
documentation
section
on
the
website,
re-home
them
into
the
other
repo.
A
D
Yeah,
so
I
so
for
the
moment,
leave
the
scheme
of
biles
out
of
this.
So
it's
just
the
it's
just
the
descriptive
files
defining
the
the
vocabulary-
and
you
know
the
ancillary
stuff
like
the
contributions
documents
and
things
like
that.
A
I
mean
the
Json
files,
the
schemas
themselves.
They
are
not
very
and
very
extensive,
I
mean
they
lack
a
lot
of
commenting
and
documentation
around
it.
So
to
me
that
this
spec
files,
the
markdown
files
specifically
for
each
bucket
some
in
this
nominator,
they
are
somewhat
part
of
the
spec
themselves
as
well.
It's
not
just
the
scheme
of
us
at
all
the
spec.
To
me
at
least.
D
With
the
schema
files
you're
pulling
those
in
under
automation,
aren't
you
so
they're
they're
treated
separately
at
the
moment
from
the
rest
of
the
documentation.
C
C
I,
don't
I
wouldn't
think
so.
I
mean
what
we
discussed
in
in
in
the
past
was
a
way
to
take
some
of
the
Parts
which
are
manually
written
in
the
spec
today
in
the
markdown
files
to
be
generated
automatically
from
the
schema,
if
possible,
so
to
make
it
easier.
You
know
to
keep
thinking
sync
and
So
to
avoid
having
to
yeah,
keep
the
schema
files
and
the
tables
in
and
say
basically
so
I
think
it's
it's.
The
tables
are
the
main
thing
that
we
were
thinking
about,
but
yeah.
C
So
in
the
tables
you
have
comments,
examples
and
things
that
are
not
a
part
as
part
of
the
schema
today.
So
we
didn't
really,
you
know,
think
for
think
about
a
solution
for
that.
It's
just
something
that
we
said.
Okay,
maybe
it
would
be
good
to
do,
but
we
don't
really
have
a
technical
solution.
Okay,.
D
Well,
you
could
still.
You
could
still
do
that
on
the
other
repo,
as
long
as
everything
was
directed
to
a
working
branch
on
that
repo
you,
you
could
automate,
but
regardless
of
where
the
files
lived.
C
A
different
thought:
maybe
it's
not
that
different,
but
I
was
thinking
of
the
model
that
is
used
by
GitHub
pages,
so
where
you
have
a
branch
that
is
actually
used
for
publishing,
but
it
makes
sense
if
we
were
going
down
the
road
to
of
having
just
a
single
repo
to
keep
the
the
spec
repo
as
the
single
Reaper
having
a
branch
that
is
used
for
publishing
to
City,
events.dev
and
then
I,
don't
know
Automation
in
place
when
we
make
a
new
release
in
the
menu
tag
to
pull
those
in
into
the
CD
events.dev
Branch
there
just.
D
What
I'm
trying
to
eliminate
at
this
stage
is
the
need
to
be
able
to
view
these
two
files
into
completely
different
rendering
environments
and
the
need
to
have
a
bunch
of
complexity
to
join
those
two
things
together.
D
Now
the
the
schemers
I
they
could
easily
stay
in
GitHub
and
be
edited
on
GitHub,
because
they're
only
ever
rendered
on
GitHub.
So
it's
not
a
problem
for
that.
D
Similarly,
you,
you
could
have
automation
that
takes
changes
to
those
and
pushes
changes
into
your
your
actual
narrative
documentation,
but
if
you're
a
narrative
documentation
lives
in
a
doxy
repo
and
is
only
intended
to
be
viewed
via
doxy,
that
makes
most
of
the
complexity
go
away
and
it
makes
it
easier
for
you
to
produce
higher
quality,
looking
documentation.
D
But
it's
I
I
understand
that
what
this
is
doing
is
breaking
up
your
conceptual
model
of
what
the
spec
is
as
an
atomic
unit
and
that
might
be
uncomfortable.
So
clearly,
we
need
to
make
sure
this
is
the
right
decision.
C
C
From
from
a
branching
point
of
view,
branching
model,
if
we
could
have
what
goes
on
the
website
being
on
a
dedicated
branch.
B
C
B
C
You
talk
about
parishes
and
Terry
comes
back
to
mind
and
I.
Think
one
of
the
the
reasons
I
in
my
mind,
I
see
that
this
pack
and
the
website
repo
was
a
separate
as
because
I
think
the
content
is
is
versioned
differently
so
like.
If
we
have
a
new
version
of
a
specification
that
doesn't
mean
that
we
have
a
new
version
of
the
website
like
or
the
other
way
around
I
mean.
Let's
say
we
make
some
improvements
to
the
Community
page.
C
C
So
I
would
like
that
to
be
like
available,
regardless
of
the
version
of
the
specification
that
I'm
browsing
if
it
makes
sense,
and
so
if
we
have
like
one
single
Reaper
where
we
do
like
versions
on
that
repo
alone.
That
means
that
when
we
are
working
on
we're
doing
this
change
on
on
the
working
branch
on
the
default
Branch,
those
changes
will
not
be
reflected
in
the
historical
version
of
the
website.
D
I
think
that's
going
to
be
a
problem
regardless,
because,
what's
going
to
happen,
is
that
you're
you're
going
to
when,
when
you
do
a
new
public
release,
you're
going
to
create
a
historical
Branch
off
the
website
which
becomes
the
the
Baseline
of
the
sorry?
Let
me
with
a
different
way.
It
becomes
the
the
fixed
snapshot
of
that
history.
D
D
But
you'll
only
be
seeing
the
documentation
parts
of
it,
because
the
only
URLs
you'll
be
accessing
will
be
the
relative
ones
that
Loop
you
around
in
the
documents
section.
D
So
if
you
jump
out
of
that,
you
should
always
end
up
back
at
the
root
of
the
site
because
of
the
way
the
URLs
are
structured
but
yeah
that
that
is
a
that
is
a
problem
and
you're
you're
right
that
you
would
have
to
decide
whether
you
were
going
to
make
you
know
minor
non-version,
related
changes
to
say
the
main
branch
of
the
website
to
update
you
know,
links
and
progress,
and
things
like
that
versus
working
on
a
branch
for
spec
changes.
C
Okay,
but
maybe
then
a
solution
to
that
for
going
back
to
what
animal
was
adjusting
to
kind
of
keep
them
more
separated
than
they
are
today
and
say:
okay,
we
we
have
the
non-reference
documents
hosted
on
on
the
website,
so
we
have
the
the
main
page,
the
Community
page
I.
Guess
we
could
move
across
information.
That
is
not
version
specific,
like
broad
map,
information
like
the
primer
documentation.
C
So
all
those
documents
which
are
not
like
reference
document
for
the
specification
that
doesn't
need
to
be
versioned
and
move
them
across
to
the
website
repo
and
then
in
terms
of
specification
for
different
versions.
We
could
then
have
like
the
drop
down
list
that
all
only
points
to
to
the
GitHub.
So
for
the
reference
documentation
we
have
strictly
rendering
on
GitHub
and
for
everything
else
we
do
strictly
rendering
on
the
website.
C
Then
we
have
like
a
doxy
Reaper,
which
is
clearly
a
doxy
repo,
and
you
know
we
can
always
publish
the
the
latest
tag
that
we
want
to
publish,
but
it
you
know
and
then
the
when
we
have
new
releases
on
the
specification
side.
What
we
do
is
simply
we
we
need
to
add
a
yeah.
We
need
to
add
a
new
items
in
the
list
in
the
configuration.
D
D
C
D
Okay,
yeah
I,
think
that
would
solve
this
the
same
set
of
problems,
because
if
we,
if
we
remove
the
the
sub
module
and
the
requirement
to
be
able
to
render
in
two
different
places,
that
gets
rid
of
most
of
the
hard
hard
hard
hard
hard
hard
hard.
D
Yeah-
and
it
is
the
it's
things
like
the
primer
which
are
actually
documents
that
that
need
to
be
prettier,
so
they
would
benefit
from
from
being
on
on
the
other
side
of
the
fence,
and
as
you
say
they
don't,
they
don't
need
to
be
updated
with
the
rest
of
the
spec,
necessarily
because
once
we've
got
it,
there
there'll
be
very
little
additional
information
that
needs
to
go
into
that
document.
A
Yeah
I
think
that
that
sounds
very
an
appealing
compromise
to
me
as
well
I
mean
if
we
should
get
something
done
in
a
reasonable,
reasonable
amount
of
time
as
well,
and,
of
course,
in
the
long
run,
I
would
like
to
see
I
mean
if
the
project
grows
and
I
would
like
to
see
that
we
could
also
rendered
the
specification
documents
some
way.
So
so
it
becomes
more
professionally
looking
and
maybe
more
easier
to
to
browse
than
what
GitHub
provides
today
with
more
features.
A
B
B
D
D
On
with
the
same
proposal,
so
you
know
you
can
still,
you
can
keep
main
on
CD
events.dev
as
your
default
landing
page
and
then
you
can
start
to
create
historical
branches.
Off
of
that
to
to
allow
you
to
have
you
know
historical
supported
releases
that
are
linked
on
the
website,
so
all
of
that
will
still
will
still
function
and
you'll
still
be
able
to
point
it
to
specific
tagged
releases
of
the
spec
on
the
other
repo.
D
So
as
long
as
we
use
the
the
right
links
to
the
spec
documentation
that
that
should
be
fine.
D
We
we
can
probably
automate
some
of
the
links,
maybe
I'll
have
to
experiment.
With
with
that,
we
may
be
able
to
put
a
a
variable
in
the
system
that
says
which
version
of
this
the
spec
repo
we
should
be
pointing
at
and
then
you've
only
got
to
change
that
in
one
place
to
change
all
the
links.
When
you
update.
D
A
B
D
One
of
the
things
that
I
have
learned
from
maintaining
the
mlops
road
map
on
GitHub
is
that
they
do
have
a
habit
of
changing
the
markdown,
rendering
and
breaking
things
so
I've.
D
D
A
C
C
Yeah
and
I've
seen
GitHub
announced
some
I,
don't
remember
what
it's
called,
but
basically
the
ability
to
draw
some
JavaScript,
Within,
GitHub
rendered
and
Pages.
You
know
to
build
more
like
interactive
Pages
within
GitHub,
so
I
think
yeah.
That
might
be
something
that
we
could
use
to
to
make
those
pages
more
Dynamic,
but
yeah
or
maybe
something
else.
C
But
yeah
so
anything
else
that
we
need
to
clarify
before
we
can
move
forward.
What
is
the
timeline
for
this?
Maybe?
Does
it
still
fit
with.
D
It
shouldn't
be,
but
much
effort
to
to
do
that,
so
you
know
hopefully
I'm
going
to
do
that
overnight
or
in
the
morning
and
and
get
something
out
for
you.
Okay,
so
you
know
we
can.
D
We
can
then
look
at
it
in
preview
and
and
and
and
play
with
it,
I'm
I'm,
just
finishing
off
an
update
on
the
primer,
where
I've
I've
put
in
a
bunch
more
of
just
sort
of
basic
introductory
stuff,
because
the
the
experience
I
had
coming
in
was
that
I
wanted
to
land
a
bit
earlier
in
the
thinking
process
and
so
I've
just
put
some
stuff
in
there.
D
That
ties
all
of
this
back
to
the
Enterprise
Integration
patterns,
stuff
and
I've,
also
put
in
a
just
a
basic
section
on
you
know:
what's
the
problem
that
we're
actually
solving
with
a
couple
of
diagrams
to
show.
You
know
how
your
default
is
lots
of
isolated,
build
systems
that
can't
talk
to
each
other
and
exchange
audit
information
and
stuff
versus
the
ability
to
be
much
more
interconnected
and
integrated.
D
D
Am
there,
but
you
know,
that's
the
other
piece
they
want
to
get
delivered.
D
B
D
The
only
huge
argument
that
we
need
to
have
is
whether
we
should
have
a
fixed
line
width
on
text
documents.
E
A
D
You,
if
you,
if
you're
gonna,
have
a
fixed
line
width
you've
got
to
have
a
new
line
in
the
middle
of
a
paragraph
somewhere.
No.
A
A
A
D
B
A
D
Because
that's
what
what
that
means
is
that
we're
having
to
put
artificial
line
breaks
in
paragraphs
and
then
you
end
up
with
hidden
spaces
on
the
end
of
some
of
the
lines
and
then
you
have
to
go
through
and
find
them
all
and
remove
them.
D
C
Yeah
I
mean
I
mean
there
are
pros
and
cons
in
both
approaches.
Really
I
mean
they're,
I
I,
don't
mind
one
specifically
just
striving
for
consistency,
and
we
are
probably
not
consistent
today,
as
you
said,
but
I
I
don't
want
you
to
like
do
like
document
specific
exceptions,
but
I
think
the
moment
that
we
actually
move
things
across
to
the
other
repo.
C
D
B
D
D
And
I
think
you
know
having
fixed
line
lengths
for
for
code
and
XML
and
stuff
like
that
makes
more
sense.
It's
purely
for
the
The
Narrative
documents
where
it
it
adds
some
problems
from
a
maintenance
perspective.
E
C
Yeah
she's
probably
exclude
that
rule
then
like
in
the
Global
Link
context.
I
don't
know
so
that
is,
that
does
not
apply
to
any
other
narrative
documents.
Foreign.
A
A
A
C
B
C
I'm
fine
with
having
those
paragraphs
just
like
them
to
be
consistent
across
the
across
the
repo,
but.
E
C
And
I
definitely
don't
think
that's
stopping
issues
in
any
case
but
yeah.
So
thanks
for
the
good
discussion,
yeah
I
look
forward
to
to
the
next
revision,
then
Theory,
okay,.
B
I'll
I'll
go
and
sort
all
that
and
get
back
to
you
as
soon
as
possible.