►
Description
Special meeting focused on Keptn Documentation: Google Summer of Code and Season of Docs, restructuring Keptn documentation, new documentation engine, and using Katacoda for tutorials.
Meeting notes: https://docs.google.com/document/d/1y7a6uaN8fwFJ7IRnvtxSfgz-OGFq6u7bKN6F7NDxKPg/edit
Learn more: https://keptn.sh
Get started with tutorials: https://tutorials.keptn.sh
Join us in Slack: https://slack.keptn.sh
Star us on Github: https://github.com/keptn/keptn
Follow us on Twitter: https://twitter.com/keptnProject
Sign up to our newsletter: https://bit.ly/KeptnNews
A
A
So
what
do
we
have
in
the
agenda?
For
today?
That
groups
is
not
called
google
system
docs
recommendation
destruction
is
mac,
then
formalizing
the
viewers
team,
because
we
get
more
and
more
pull
requests
and
probably
need
to
have
more
reviewers
than
new
documentation
engine,
as
we
agreed
before,
and
also
for
the
playground.
A
A
Okay
and
I'll
just
start
so,
first
of
all,
google
somewhere,
of
course
these.
So
as
you
already
know,
we
are
accepted,
we
have
project
ideas,
we
have
potential
contributors
joining
and
we
have
seven
projects
and
there
is
still
demand
for
more
potential
mentors.
So
if
everyone,
if
anyone
is
interested,
please
join
and
you
can
see
that
the
list
is
already
quite
extensive
and
if
you
see
any
potential
improvements
and
project
ids
et
cetera,
just
don't
hesitate
to
create
a
pull
request.
A
A
So
they
changed
the
the
layout
a
bit.
So
when
you
go
to
the
old
one,
so
what
happens
here
so
we
are
currently
accepted
so
until
april
third,
potential
contributors
just
reach
out
to
the
communities
try
out.
Captain
now
keys
project
ideas,
have
discussions
and
then,
until
april
9
19
there
will
be
application
phase.
So
basically,
when
these
proposals
are
refined
and
then
submitted
to
google
and
then
we'll
have
selection
phase
so
next
month,
we'll
have
discussions,
including
community
meetings,
and
we
can
use
these
meetings
for
any
kind
of
donate
coordination
feedback.
A
A
A
B
So
that
that
sounds
like
a
really
cool
thing,
but
I'm
wondering
like
we
do
have
a
lot
of
efforts
going
on
with
the
documentation
and
tutorials
and
so
on.
I'm
wondering
if
that's
kind
of
conflicting
now
or
if
we
can
try
to
join
those
efforts
together
or
I
don't
know
because
I
I
think
it's
a
wonderful
project.
At
least
it
sounds
like
one
so
and
we
definitely
need
more
documentation.
A
Yeah,
so
my
question,
for
that
is
that
we
definitely
wouldn't
start
a
new
documentation
effort.
Instead
of
that
they
could
join
one
of
existing
threads.
So,
for
example,
everyone
on
the
documentation
side
of
the
documentation
structure
and
the
advantage
of
google
season
of
talks
that,
since
it's
more
professional,
targeted
program,
you
do
not
need
to
have
isolated
projects.
A
B
A
No
so
applications
already
open,
they
will
be
open
until
25th
of
march.
So
basically
until
the
next
week
we
agree
should
agree
whether
we
apply
and
we
need
to
accept
project
ideas.
So
I
would
definitely
put
just
documentation
inside
the
engine
content
side
because
we
will
need
to
drag
a
lot
of
content
align
it
face,
lift
all
the
documentation.
A
B
Let's
have
it:
let's
have
a
discussion
on
the
captain
slack,
because
I
think
we
will
need
more
mentors
than
just
mac.
I
think
we
should
have
at
least
two
dedicated
mentors
for
that.
I'm
not
sure
if
I
can
help
with
mentoring.
My
my
capacity
is
already
on
limit,
but
let's
have
the
discussion
on
slack
see
if
we
can
find
the
second
mentor,
because
that
would
be,
I
think,
for
going
forward
that
would
be
required.
C
B
A
Yeah,
so
I
could
be
potentially
a
second
mentor,
I
mean
providing
technical
advice,
etc,
because
I
would
be
around
in
this
project
anyway,
but
yeah
haven't
actually
more
mentors
who
are
ready
to
step
up
who
have
more
bandwidth.
It
would
be
awesome
because,
in
my
case,
yeah
I'm
already
spread
too
much
across
the
different
efforts.
C
C
A
C
C
And
I
had
it
here,
so
I
could
get
to
it
instantly
and
of
course
I
just
lost
it
in
this
mass,
so
working
on
various
issues,
as
I
mentioned
one
of
the
first
ones
that
I
see
as
a
a
real
problem,
we
do
not
really
have
a
complete
set
of
reference
pages
on.
We
have.
We
have
a
section
called
reference
pages.
We
have
something
for
the
cli.
C
We
have
something
for
the
api
that
are
a
little
bit
and
then
over
say
under
the
quality
gate
section
we
have
a
bit
of
reference
about
the
slo
and
the
sli
file.
You
know
this
sort
of
thing.
We
don't
have
one
place
where
we
go,
where
you
can
get
complete
reference
information
for
everything.
That's
on
there.
I
think
this
is
indispensable.
C
It
is
a
place
we
can't
do
tutorials
for
every
corner
case.
You
know
this
is
where
we
record
everything
that
the
product
can
do,
what
each
of
these,
like
a
field
in
a
file
what
it
can
be
set
to
and
how
you
can
use
it
and
how
it
gets
populated
how
it
gets
used.
All
those
sort
of
things
the
the
classic
model
is
the
old
universe.
D
D
A
C
B
A
A
E
Great
so
yeah
I
did
introduce
myself
previously
on
the
last
call,
but
yeah,
okay,
so
hey
everyone.
I
am
a
junior
from
india
and
I
just
looked
at
that.
Captain
got
selected
for
gsoc
2020
congrats
for
that
and
I
saw
that
revamping
of
the
documentation
side
and
I'm
pretty
much
interested
into
it.
I
did
work
with
andrea
before
not
much,
but
I'm
also
working
with
github
actions.
So
if
automation
is
needed,
I
can
jump
it
so
yeah,
that's
something!
I'm
looking
for
and
yeah
it's
a
great
community.
B
E
A
E
E
C
C
C
C
The
one
thing
we
have
to
do
is
we
have
four
files
currently
in
the
reference
page
that
are
not
referenced
at
all,
that
are
the
documentation
for
bridge
and
that
needs
to
be
pulled
out.
I
think
that's
already
happening
into
a
separate
section.
I
think
at
the
same
level
as
the
quality
gate
section
to
get
that
done
so
and
then
at
least
we'll
have
a
place
where
you
can
go
for
each
file
and
then
we'll
start.
C
There
are
a
lot
of
in
the
source.
There
are
readme
files
and
there's
all
sorts
of
stuff
that
will
get
us
a
good
start
on
the
reference
pages
and
then,
if
you
can
scroll
down
to
the
very
bottom,
I
think
there's
sort
of
a
what
we've
talked.
I've
got
some
of
those
listed
where
we
can
grab
stuff
the
structure.
The
file
reference
pages
are
the
biggies.
C
The
apis
and
cli
have
something
and
some
other
who
have
to
look
at
those
but
a
standard
thing.
We
start
with
a
brief
description
and
then
we
have
the
synopsis
of
the
file
and
go
through
and
tell
them
everything
we
know
about
every
field.
That's
there
and
then
there's
a
usage
section
which
is
kind
of
free
form.
You
can
do
whatever
you
want
to
there
with
what
you
need
to
tell
people
about
this
file
and
how
it's
used
configuration
examples.
C
Examples
are
you
got
it
and
then
an
important
one
is
differences
between
versions
which
is
a
instead
of
having
these
rolling.
You
know
have
a
different
version
to
reference
in
each
release.
This
becomes
one
set,
that's
good
for
the
product
and
it
will
preserve
a
little
bit
of
history
for
us,
it's
very
useful
for
the
customers
too,
to
if
they
look
at
it
and
they've
I've
been
working
with
this
file
for
a
while-
and
I
don't
remember
that
field.
C
Oh
well,
it's
new
in
this
release
or
was
added
last
release
or
whatever
file
location
which
will
have
to
be.
You
know
it
isn't
always
going
to
be
a
straight
path
name,
but
where,
where
files
should
go
and
a
question
for
everybody,
because
it's
an
open
source
project,
I'm
also
thinking
that
it
might
make
sense
to
show
the
github
location
for
the
source
and
then,
of
course,
the
sea
also
and
those
would
be
arranged
alphabetically
there.
C
So
the
the
reference
section
would
have
subsections
right
now
for
cli
api
files
and
then
a
miscellaneous
one
equivalent
to
the
old
man5,
the
one
that
I
saw
immediately
for
that
is
distributor
which,
right
now
they
have
a
readme
file
that
it
just
lists.
All
apparently
just
is
controlled
by
a
whole
bunch
of
variables,
and
but
this
would
be
a
place
where
we
can
describe
all
of
those
and
what
they
are
for
and
how
that
works.
C
So
I
may
not
understand
the
situation
there,
but
that
it
would
be
good
to
have
a
list
of
all
the
event
matrix
metrics
that
are
defined
in
the
product
by
including
all
of
the
different
services
that
you
could
ever
and
have
this
something
that
is
generated
automatically
similar
to
what
in
jenkins
they're
doing
with
the
steps
reference.
So
it's
not
the
most
marvelous
writing
job,
but
it's
comprehensive
and
then
for
the
steps
reference,
and
I
think
this
would
be
nice
here-
have
the
ability
on
your
local
installation.
C
You
can
run
this
and
you
get
a
local
copy.
That
tells
you
just
the
events
that
are
defined
for
the
services
that
are
installed
in
your
environment.
So
that's,
that's
not
the
first
pass
of
it,
but
this
is
what
I
see
that
I
have
thinking
of
so
I
would
love.
I
would
especially
love
to
hear
reasons
why
people
think
this
is
a
bad
idea.
B
So
if
I
may
add
some
comments
here,
the
way
that
the
website
or
the
docs
are
structured
right
now
with
the
versions
is
coming
from
the
fact
that
there
have
been
a
lot
of
breaking
changes
over
the
time.
Obviously,
there
is
still
heavy
development
going
on
so
the
equality
gate
feature
the
slo
sli
files.
B
So
you
can
see
it
immediately
when
you
access
the
page
and
you
don't
have
to
like
go
back
in
time
or
whatever,
but
something
like
that
just
to
have
a
batch
or
some
some
informal
string
that
tells
you
hey.
This
is
this
is
until
captain
c
or
12
and
the
other
one
is
is
now
the
new
one
for
cap
0.13
or
something
like
that
and
the
another
thing
about
the
distributor
itself.
The
distributor
is
a
very,
very
technical
instrument
that
you
usually
shouldn't
need
to
interact
with.
B
C
Right
and
there-
and
you
know
a
first
take
on
that-
is
that
some
of
that
is
it's
still
true.
I
mean
we
did
just
have
a
question,
come
up
and
help
on
it,
and
it
was
somebody
who
wanted
to
limit
the
stages
that
the
distributor
was
working
on
and
the
documentation.
That's
there.
I
forget,
I
think
it
was
the
distributor
didn't
say
but
or
the
val
or
the
file
didn't
tell
them
that
they
could.
You
know,
specify
a
comma
separated
list.
B
B
B
C
B
A
Maybe
it
also
brings
up
a
question
about
the
top
level
entities,
because
what
we
created
in
jenkins
over
time
is
introduced
several
separate
developer,
guide,
separate
user
and
administrative
guide.
Okay,
so
basically
for
three
key
roles,
and
also
contributor
guide
is
actually
so.
Maybe
it's
also
something
we
could
shoot
for
in
captain,
because
christian
is
totally
right.
A
lot
of
content
is
solo,
very
quiet
for
those
who
develop
things,
and
maybe
it
should
be
put
separately
right
away.
C
A
C
Right
now,
I
would
advocate
that
the
reference
pages
would
not
be
separated
that
in
the
content
they
can
say
you
don't
touch.
The
only
reason
you
need
this
is
for
such
as
for
development
or
something
but
yeah.
Definitely
the.
Then
we
need
what
I
call
guide
material
where
you
explain
how
to
use
this,
and
you
know
the
the
common
things
you
do.
Yeah
not
need
to
distinguish
what
is
developer
and
user
and
admin,
of
course,
an
admin
management.
F
C
I
I
don't
think
the
I
mean
there's
some
amazing
information
there,
but
whether
the
quality,
you
know,
whether
that's
what
we
want
for
the
documentation,
I'm
not
sure,
I'm
I'm
inclined
to
think
no,
but
this
is
so.
You
know,
I
think
we're
going
to
have
to
look
at
this
as
we
go
forward
and
somebody
adam
asked
if
we
could
pull
dynamically
the
environment
variables.
C
C
That's
sometimes
not
enough,
but
there
are
ways
you
know
that
that
can
be
embedded
in
the
code
and
then
get
pulled
out
for
the
system.
So
we
would
say
that
in
general,
anything
that
can
be
generated
automatically
is
a
good
thing,
because
we
can
constantly
and
make
sure
it
is
always
in
sync,
with
the
source
code.
And
then
we
have
to
trade
that
off
as
to
whether
we
get
the
right
level
of
information
and
the
quality
of
information
with
it.
A
And
for
go
long,
it's
actually
the
same.
So
for
golonka.
There
are
other
annotation
projects
that
generate,
for
example,
jfpc,
specs
or
long
goals
whatever,
and
we
can
try
introducing
some
annotations
right
inside
the
code
as
one
of
the
ways
another
one
is
to
just
have
spec
a
standardized
spec
file
in
the
repositories
which
can
be
used
for
both
code
for
generation,
so
basically
generation
import
from
the
spec
file
generating
documentation.
C
And
I
will
completely
defer
to
you
on
those
sorts
of
issues
you'll
have
to
decide
and
that,
yes,
the
the
I'm
trying
to
watch
these
comments
and
pay
attention
to
the
conversation.
It's
interesting.
Captain
cli
is
auto-generated.
Now
the
captain
api
reference
page
right
now,
I'm
just
filing
an
issue
for
that.
That's
that's
a
little
bit
of
a
problem,
because
that
tells
you
how
you
get
this
material
and
it
gives
you
instructions
for
pulling
it
up
and
it
gives
a
link
that's
to
your
local
system.
C
So
if
you're,
not
on
your
that
link
in
the
documentation
does
not
work
and
I'm
not
sure.
I
would
like
to
see
the
api
out
where
I
could
see
it
when
I
was
not
on
a
system
that
had
it
installed
or
before
I
installed
it,
but
I'm
gonna
have
to
look
at
that,
but,
yes,
anything
that
can
be
auto
generated
or,
and
you
know
or
code
in
the
or
documentation
in
the
code-
that's
good
and
and
adam
in
general.
C
C
C
A
I
do
not
object,
especially
if
you
touch
on
the
version
0.14,
because
0.14
hasn't
been
released,
yet
one
problem
with
that
significantly
restructuring
the
tutorials
may
cause
difficulties
for
developer
teams
because
they
need
to
propagate
the
documentation,
changes
between
versions,
but
I
would
actually
argue
that
previous
versions
do
not
matter
too
much
right
and
now
us
yeah
just
preserve
and
clean.
This
is
generally
a
good
idea
because
we
don't
have
test
automation
which
discovers
broken
links,
as
all
of
us
don't
have
hard
way.
So
it
means.
A
The
documentation
somebody
will
eventually
just
update
the
version
somewhere
in
the
code
and
everything
breaks.
So
maybe
it's
something
we
should
really
think
about
prioritizing
doing
some
github
actions
for
checking
links
super
trivial
for
markdown
in
the
current
organization,
but
otherwise
I
think
that
we
should
proceed.
B
The
new
ones
can
be
wherever
you
want
them
on,
whichever
level
you
want
them,
and
I
actually
see
the
development
team
in
being
responsible
here
for
updating
the
links
in
the
in
the
code.
They
need
to
be
aware
of
that.
Obviously,
so
let's
get
them
onboarded
with
the
idea
and
give
them
a
warning:
hey
we're
changing
the
docs,
but
I
don't
think
it's
a
big
deal.
I
actually
think
they
will
be
happy
to
hear
that
the
version
string
gets
removed
from
that
link,
because
that
is
causing
a
lot
of
problem.
B
A
B
I
mean
there
shouldn't
be
too
many.
Some
of
them
are
in
the
cli
as
far
as
I'm
aware,
some
of
them
might
be
in
captain
bridge,
but
really
we
just
need
to
create
issues
in
in
the
captain
core
repository
telling
him
hey.
This
is
the
new
link
to
the
documentation.
Please
verify
in
cli
and
in
bridge
that
you
change.
C
B
I
think
they
will
be
happy
to
see
that
change,
because
if
you
remove
the
version
string
from
that,
it's
a
huge
pain
to
generate
a
link.
You
know
and
maintain
that
link
with
a
version
string.
If
you
can
just
remove
that,
it's
it's
better.
Also
to
what
suraj
said
in
the
in
the
chat
yeah.
If
you
search
on
google
for
a
certain
topic
of
captain,
you
are
not
necessarily
ending
up
on
the
latest
version
of
that
topic.
C
B
We
should
we
should
do
too
much
with
redirects,
like
it
just
generates
more
maintenance
effort.
When
you
release
a
new
version,
you
need
to
create
new
redirects
like
let's
do
a
breaking
change.
I'm
I'm
fully
in
favor
of
doing
it
just
make
sure
we
inform
let's
say
in
this
case
captain
core
wire,
github
issues
or
directly
wireless
like,
and
it
should
be
fine.
A
B
A
Latest
for
basically,
which
we
would
default
to
or
content
move
outside
the
documentation,
it's
trivial
to
do
now,
the
problem
that
we
would
need
to
generate
robots
txt,
because,
while
the
current
search
is
basically
crap
that
google
et
cetera,
they
have
no
idea
how
to
index
the
docs
which
we
can
generate
the
robots
txt,
so
that
we
could
ignore
previous
versions
of
documentation
by
default,
and
we
can
point
to
a
test.
But
we
need
to
see
whether
this
whether
it
will
work
with
redirects
because
definitely
a
network.
C
A
We
can
do
probably
developers
will
hate
me
after
that,
but
we
can
create
a
global
github
action
which
verifies
actual
absolute
links
and
related
links
without
within
the
repositories
for
markdown
files
and
create
issues.
If
so,
if
a
link
is
broken,
this
part
is
trivial
to
implement
the
other
existing
pipelines.
For
that.
A
A
A
Probably
drop
all
the
recommendation
up
to
12,
at
least
because
in
12.1
we
had
a
security
release
with
zero,
now
11.
and
theoretically
versions
before
we
don't
really
encourage
people.
But
in
this
case
we
would
also
need
to
talk
to
kira
tech
team,
because
kratos
uses
captain
and
they
rely
on
these
recommendations
and
for
data
trace
and
cloud
automation.
C
A
A
So
this
table
is
definitely
generated
and
yeah
so
mean.
One
thing
we
could
do
is
just
putting
yaml
files
whatever
in
the
repositories
and
aggregating
them.
It's
a
small
matter
of
coding,
and
it's
not
that
big
right
now.
We
had
a
lot
of
challenges
with
jenkins
system
properties,
which
were
manually
managed
at
some
point
and
actually
me
and
daniel
beck
spent
a
lot
of
time
reworking
them
because
in
jenkins
we
have
something
like
solvent
system
properties
and
currently
so
this
page
is
fully
auto
generated.
A
So
you
can
see
a
properties
in
the
jenkins
core
and
then,
if
you
scroll
down
plugins
somewhere,
so
the
user
experience
is
still
a
crap.
But
at
least
now
it's
auto-generated
before
that
it
was
a
huge
table.
Then
it
was
a
huge
yaml
file
and
now
it's
generation,
probably
something
we
could
do
so
again.
It's
just
a
github
action,
generating
content.
B
F
B
To
0.13
you
know
and
scroll
down,
there
is
a
link.
The
full
list
is
yeah
exactly
there.
We
go
not
there
yeah
okay,
so
the
list
is
still
kind
of
there.
You
need
to
dig
through
it
a
little
bit,
but
I
guess
the
intention
was
to
have
the
list
in
the
captain
source
code
repository.
But,
as
you
can
see
this,
this
is
the
problem
right
now
you
have
a
link
in
here
the
link
works
but
you're
not
finding
the
expected
content
so
yeah.
So
in
this
case,
if
you
see
something
like
that.
A
This
debug
and
we
will
put
some
templates
to
make
it
more
easier
and
what
we
already
discussed
with
mac
and
with
others
having
buttons
that
actually
help,
for
example,
again
in
jenkins
yeah,
you
could
keep
it
using
this
example
because
we
did
a
lot
of
such
investments.
So
here's
a
report,
a
problem
and
when
you
click
it,
it
automatically
uses
issue
templating
that
generates
at
least
sample
pointing
to
this
page
etc.
C
F
A
So
yeah
we
don't
have
a
official
project
idea
for
all
these
kinds
of
automation,
but
for
me
it's
kind
of
implied
to
gsoc
as
well.
So
for
me,
it's
also
part
of
the
documentation
engine.
If
you
are
interested
in
such
auto
documentation
or
degeneration,
I
think
it
could
be
also
a
fully
viable
project
idea
that
would
probably
not
align
with
what
we
have,
but
it
will
follow
the
same
goal
so
and
actually
it
can
be
one
of
the
options
for
google
summer.
A
A
So
it's
one
of
the
topics
we
could
keep
discussing
and
that's
why
it's
nice
to
have
a
discussion
in
public,
because
we
can
touch
all
these
points
and
see
who
is
interested
in
what
and
maybe
some
even
coordinated
proposals
to
some
extent,
because
if
there
are
multiple
good
contributors
interested
in
the
same
project
idea
having
some
alignment
to
let
everyone
work
on.
That
is
actually
a
good
opportunity
for
us.
A
Okay,
so
should
we
move
on
to
the
project
idea?
We
have
something
like
10
minutes.
Left.
Okay,
so
definitely
be
slightly
slow
on
this
topic,
but
we
have
a
documentation,
engine
and
also
catacota
so
for
documentation
engine.
Do
we
have
specific
topics
we
would
like
to
discuss
today
because
so
rajiv
cannot
participate.
I
will
also
on
thursdays
based
demo
too
late,
so
that
we
discuss
them
together.
Maybe
next
week
you
know
how
to
for
the
meeting
and
so
for
this
project
idea.
A
A
So
again,
as
you
could
have
seen
from
today's
meeting
and
discussion,
there
is
a
lot
of
areas
and
one
thing
I
would
like
to
highlight:
that
is
project
idea
and
you
can
come
up
with
your
own
project
proposals
based
on
these
discussions,
etc,
which
are
completely
and
not
aligned
with
this
project
idea.
So,
for
example,
rajiv
makes
a
point
that,
because
is
better
than
entera
and
it's
totally
violated
for
discussion
and
we'll
see
how
it
goes.
A
I'm
super
interested
to
have
this
conversation
and
if
you
see
other
topics,
you're
more
interested
in
just
creating
a
lot
of
github
actions,
automating
documentation,
generation,
etc.
All
of
that
could
be
valid.
You
just
need
to
be
sure
that
the
most
of
the
project
remains
about
a
code,
because
it's
still,
google
somewhere,
of
course,.
A
And
yeah,
so
if
there
is
no
questions
for
this
particular
project
idea,
we
can
talk
more
about
cretacoda,
because
catacode
is
basically
the
same
part.
It's
also
part
of
the
condition
for
me,
but
rather
for
tutorials
and
automating
these
tutorials,
so
that
you
can
make
it
easier
for
users
to
get
the
environments
and
to
delete
caption.
C
A
Also,
we
can
discuss
maybe
some
sponsors
from
captain
vendors
etc.
Who
would
like
to
have
these
tutorials
as
a
part
of
their
course?
So,
for
example,
banana
trees
does
a
lot
of
workshops
for
captain
and
for
cloud
automation,
which
could
be
also
reused.
So
again,
we
could
find
an
option
to
get
it
hosted,
and
this
is
how
it
happens
for
other
tutorials
etc.
Sometimes
there
are
sponsors.
D
C
A
B
Also,
I
don't
think
that
catacota
is
in
that
sense,
going
to
be
used
to
deploy
workloads.
You
will
have
a
tutorial
where
you
might
install
captain,
but
only
the
control
plane,
so
you
would
not
do
a
helm
delivery
or
whatever
che
meter
test.
That's
the
wrong,
let's
say
a
platform
for
that,
but
the
control
plane
getting
access
via
api,
getting
the
bridge
getting
to
test
some
features.
B
A
D
G
A
C
A
Adam
created
docker,
sorry
demo
in
k3d,
which
prints
hello,
world
and
yeah.
It
is
them.
There
isn't
changes.
Slot
works
like
a
charm
thanks,
a
lot
adam,
but
still
it
takes
something
like
several
minutes
to
get.
This
demo
started
and
most
of
that
captain
awaits
in
different
timeouts,
etc
in
the
console
so
yeah.
A
A
A
B
Also
very
important:
if
we
do
that
as
an
entry
point
for
users,
we
need
to
constantly
verify
like
if
every
new
release,
even
if
it's
a
patch
release,
we
need
to
try
out
if
this
environment
is
still
working
or
if
something
is
broken.
So
whatever
the
the
new
demo,
the
new
quick
start
whatever
it
is.
We
also
need
to
consider
some
sort
of
automation
and
end-to-end
testing,
because
it's
the
same
as
we
have
right
now
like
we
have
no
end-to-end
tests.
Some
users
try
it
out.
They
run
into
a
problem.
B
C
A
Agree
so
for
me,
credit
code
is
definitely
not
a
full
replacement
for
existing
tutorials,
but
it
would
be
nice
as
additional
playground,
and
maybe
it
would
be
good,
especially
for
tutorials.
So
quick
start
we
could
keep
them
as
well,
but
for
some
tutorials
et
cetera,
we
could
use
category
to
bootstrap
the
environment
needed
for
this
tutorial.
So,
for
example,
if
you
have
a
tutorial
for
how
to
use
auto
remediation
with
captain
etc,
you
don't
need
15
steps
how
to
set
up
captain
like
it's
written
in
the
current
tutorial.
A
C
F
A
A
A
A
G
A
A
A
Sharing
and
also
presenting
your
site,
it's
really
interesting,
and
I
think
that
we
should
keep
doing
that.
Maybe
it
makes
sense
to
have
a
meeting
next
week
same
time
so
that
we
can
continue
with
the
topic,
maybe
having
demos,
because
definitely
there
is
a
lot
of
brainstorming
to
be
done.
So
it's
probably
not
too
early
to
start.
Regular
meetings
dedicated
especially
to
dogs
like
recommendation
working
group,
but
having
another
discussion
would
be
useful.
What
do
you
think.
C
B
E
C
If
we
get
the
basic
structure
in
place,
that's
what
I'm
saying
to
take
the
existing
pages
that
aren't
structured
right.
We
get
theirs
and
then,
when
something
when
somebody
thinks
of
something
or
runs
into
something,
we've
got
a
good.
You
know
quick
pr
and
add
the
information
we
can
rewrite
and
restructure
later,
but
we
could
start
growing
the
wealth
here
so.