►
Description
The Keptn documentation is maturing along with the software. Learn about the incremental improvements we have made, what we are working on, and how you can get involved if you are interested.
This is a presentation for the Keptn Community Day on October 25th. Presented by Meg McRoberts, a Keptn contributor and Developer Experience Lead at Dynatrace.
A
Captain
documentation
is
maturing
along
with
the
captain
software.
You
may
have
noticed
some
changes
in
the
documentation
and
heard
rumors
of
changes
that
are
planned.
My
name
is
Meg
McRoberts
and
I'm.
The
developer
content
lead
for
the
captain
project
in
this
video
I
will
bring
you
up
to
date
on
what
is
happening.
What
we
call
the
documentation
revamp
talk
about
ways
you
can
contribute.
A
A
One
major
area
is:
we
want
to
get
a
new
dock
engine
implemented
for
both
building
and
authoring
the
tools
we
need
an
engine
that
will
give
us
two
dock
versioning
search
box
for
Captain
documentation
and,
most
especially
powerful
multi-repo
support
Rajiv
Singh
implemented
much
of
docosaurus
as
a
gsoc
2022
project.
We
are
evaluating
whether
docosaurus
multi-repost
support
is
strong
enough
for
our
needs
and
will
make
a
decision
soon
on
the
tool
set.
A
A
You
can
see
an
example
of
this.
We
have
the
new
explore
Captain,
it's
actually
available.
The
top
item
on
the
doc
set,
and
all
you
have
to
do
is
click
here,
and
it
takes
you
in
to
killakota.
You
may
have
to
log
in
you
can
log
in
with
GitHub
or
Google
or
whatever.
As
soon
as
you
get
on,
it
begins
setting
up
your
environment.
We
have
some
material
to
read
here.
A
Special
thanks
to
absal
anzari
for
driving
the
move
to
killer
coda.
He
and
Adam
Gardner,
put
in
great
work
to
put
this
tutorial
together.
I
think
it's
a
great
addition.
One
area
where
we
need
people
we
need
people
to
develop
and
maintain
additional
interactive.
Tutorials
tutorials
are,
of
course,
very
resource
intensive
to
keep
up
to
date,
and
so
we
need
that
ownership.
A
Okay,
content
and
structure
some
of
the
issues.
It
can
be
difficult
to
find
the
information
one
needs.
Of
course,
a
search
engine
will
help
with
that,
but
still
the
structure
needs
to
be
good.
We
have
an
over
emphasis
on
docs
for
new
to
Captain
users,
and
we
don't
have
as
much
information
as
we
should
have
for
advanced
users.
Once
you
get
past
the
first
steps,
we
also
have
a
great
deal
of
redundancy
and
duplication
which
led
to
conflicting
information
all
the
standard
problems
so.
A
Incremental
changes
going
on
the
captain,
LTS
stocks
will
all
have
will
have
all
subsections
of
the
same
level
rather
than
having
some
at
the
top
level
and
some
under
release
specific
subsections
we're
consolidating
information
for
installation
working
with
projects
defining
project
functionality
trying
to
avoid
an
appropriate
redundancy
in
apparent
contradictions.
Here
we
are
also
expanding
the
set
of
reference
Pages.
We
have
with
adding
reference
Pages
for
configuration
and
miscellaneous.
A
Oh,
let's
look
at
this.
First
of
all
installation.
A
One
of
the
problems
we
discovered
was
that
a
lot
of
people
were
using
the
old
tutorials
as
an
installation
guide,
because
the
installation
material
in
the
documentation
was
spread
all
over
the
place
and
there
wasn't
any
place
where
you
could
get
a
good
view
of
what
to
do
in
what
order
so
we're
pulling
together.
All
of
that
information
into
one
section,
and
you
have
this
and
the
CSS
is
not
ideal.
A
You
don't
see
it,
but
if
you
scroll
down
past
the
cards
for
the
individual
sections,
you
get
a
list
of
tasks,
and
you
begin
you
need
your
kubernetes
cluster.
You
need
to
decide
what
your
access
is.
Then
you
install
the
CLI.
You
install
the
helm,
chart,
etc,
etc.
This
needs
more
work,
but
I
think
it's
a
very
good
start
and
it
will
solve
a
lot
of
problems.
A
The
manage
captain,
the
next
thing
you
need
to
do
is
a
project,
and
we
realize
that
there's
two
elements
of
it
so
manage
Captain
is
what
I
call
the
mechanics
of
managing
how
we
got
a
little
bit
of
soft
stuff
about
planning
your
project,
how
you
start
a
project,
create
a
service,
how
you
update
a
project,
delete
a
project
Etc.
This
is
all
here
in
this
section
ready
for
you
to
look
at.
A
Now,
the
next
more
complicated
one
is:
how
do
you
set
up
your
project
to
do
what
you
want
it
to
do?
This
is
a
more
complicated
doc
issue
and
what
we've
got
now.
This
is
the
area
that
needs
a
great
deal
of
work
so
to
get
started.
I
pulled
together.
A
What
we
had
for
that
and
we've
started
getting
a
few
other
things
in
here
again,
if
you
scroll
down
past
the
cards,
you
get
an
overview
of
what
is
here,
it's
sort
of
high
level,
but
it
gives
you
a
discussion
of
different
things,
different
things
you
can
do
and
with
links
into
the
docs
that
have
more
information.
A
So
we
need
to
do
more
work
and
develop
this
content
more
fully,
but
I
think
it
will
be
useful
when
we're
done
at
least
we've
got
a
good
structure
for
this
now
and
then
the
reference
pages
we've
always
had
the
reference
Pages
for
the
API
and
the
CLI.
What
we've
started
adding
now
is
reference
Pages
for
configurations
not
done
we
have,
but
already
we
see,
we've
got
the
distributor,
the
remediation
file,
the
ship,
of
course,
the
shipyard
file
SLI
SLO.
These
are
all
yaml
files,
values
now
values
we
ran.
A
This
is
where
we
need
our
multi
repo
support
right
now
these
are
being
author
in
the
doc
repo,
which
is
not
the
most
convenient
thing,
and
it
makes
it
hard
to
keep
things
inside
so
for
the
time
being,
rather
than
copy
values
into
the
doc
set
where
there
should
have
a
synopsis
of
the
file,
we
have
a
link
where
you
can
go
right
to
the
repo
and
find
it
we
will
also,
as
appropriate,
we'll
be
adding
differences
between
version
sections.
So
we've
got
a
history.
A
A
So
we
also
have
oh
I'm
sorry
I
forgot.
We
also
have
some
miscellaneous
Pages.
We've
only
got
a
couple
of
those.
A
Right
now,
let's
go
look,
but
we
have
one
for
the
distributor
where
we
document
all
of
the
zillions
of
environment
variables
that
can
be
used
to
control
what
the
distributor
does,
and
we
also
have
a
link
for
the
captain,
Cloud
events,
which
is
the
standard.
Of
course.
You
know
that
we
need,
and
again
we
use
the
same
convention
for
now
where,
instead
of
a
synopsis
showing
in
the
docs,
we
just
have
a
link,
so
you
can
get
to
the
docs
to
the
main
repo.
A
For
starters,
join
the
discussion
at
the
captain,
docs
slack
Channel,
you
can
ask
questions,
answer
questions
participate
in
discussions
proposed
Solutions,
whatever
we're
a
friendly
group
also
recommend
that
you
join
the
community
in
development
meetings.
We
have
there,
they
alternate.
We
have
a
community
meeting
one
week
and
the
community
developer
meeting
the
other
note
other
week.
You
can
go
to
the
main
page
for
this.
A
This
is
an
old
one,
that's
done,
but
you
can
see
what
we
discussed
and
there
may
be
some
notes
about
that
Etc
and
then,
if
you,
if
you
see
something
in
a
former
meeting
that
you're
interested
in
you,
can
go
and
watch
the
video
and
see
what
happened.
A
A
The
docs
repo
also
has
a
list
of
open
issues
of
tasks
that
need
to
be
done,
including
we
try
to
always
keep
some
good
first
issues
up
there
for
newbies.
The
first
contribution
is
always
a
little
scary,
so
it's
nice
to
have
something:
that's
kind
of
easy
for
Content,
but
not
only
writing.
We
can
always
use
people
to
review
and
test
the
docs.
If
you
have
some
time,
just
pull
out
a
chapter
and
go
through
and
try
to
do
everything
that's
in
it
and
see
if
the
material
is
correct
and
and
adequate.
A
If
there's
something
that
we
don't
explain,
you
can
submit
a
PR
or
file
an
issue
if
you
find
errors
or
omissions.
Reviewing
open
PRS
helps
and
we're
also
going
to
need
some
help.
Implementing
the
new
Doc
engine
just
for
background.
We
do
adhere
to
the
documentation
as
code
practices.
This
means
docs
are
authored
using
markdown
where
they
are
stored
in
a
GitHub
repository,
and
they
are
tracked
with
issues
and
we
update
the
docs
with
PRS
that
are
subject
to
the
same
discipline.
That's
used
for
software.
It
runs
through
a
number
of
CI
tests.
A
We
require
appropriate
reviews
before
anything
is
merged.
Now
what
we
need
to
do.
We
need
the
ability
to
import
docsource
from
multiple
repositories
so
that
we
can
get
most
of
the
at
least
technical
dot
content
located
next
to
the
software
code,
which
UPS
the
probability
that
people
are
going
to
keep
the
information
up
to
date.
A
Oh
that's
for
the
future
for
the
authoring
tools,
a
brief
overlooked.
Docs
are
authored
in
markdowns
stored
in
GitHub,
the
docs
repo
is
Captain,
slash
captain.github.io.
A
Currently
we
build
the
tools
with
huge
with
Hugo.
You
can
look
at
the
contributing
MD
file
to
learn
how
to
set
up
your
local
environment,
so
you
can
build
the
docs
locally
invaluable.
When
you're
writing
you
always
want
to
check
and
see
what
they
look
like
before.
You
push
them
and
feel
free
to
ask
questions
and
kept
in
docs
anytime.
You
need
help
so
I
think
that's
it.
Our
time
is
up
I.
Thank
you
for
listening
and
we
look
forward
to
seeing
you
in
the
captain
docs
project.