►
From YouTube: DefCore Lighthouse Meeting 1
Description
https://etherpad.openstack.org/p/DefCoreLighthouse.1
This meeting was mainly planning for the Lighthouse cycle; however, some decisions were made
1) We decided that we have enough support to push for score cards for all three releases
2) We need to engage actively with the technical community to help score capabilities and identify designated sections
3) We want to complete the Havana capabilities score by 7/4 for community review
4) We need to design an easy to read view of the capabilities (this was already in process by Refstack team)
5) We're starting with a "plain English" version of the by-laws change. Review at the Face-to-Face.
A
C
A
A
Todd
and
I
were
talking
when
we
kicked
off
that
we've
got
a
lot
to
do
a
lot
of
work
to
do.
We
need
to
make
sure
it's
prioritized
and
we
need
to
some
of
these.
Things
are
going
to
just
be
long
fuses,
and
so
we
need
to
make
sure
we
light
the
fuses
so
that
they
wind
down
by
the
end
of
the
cycle
and
with
that
I,
would
reviewed
any
any
questions
and
I.
Don't
necessarily
want
to
walk
through
the
agenda
point
by
point,
but
is
there
anything
people
want
to
add
to
it?.
C
C
D
I'll
say
something
I
think
the
reaction
was
all
over
the
all
over
the
place.
I
got
a
lot
of
positive
reaction
from
analyst
actually
and
I
felt
that
was
hard.
They
they
thought
that
the
effort
was
exactly
what
we
needed
and
and
so
I
thought
that
went
well.
I
think
there's
other
folks
who
were
skeptical
as
to
whether
it
can
frankly
be
done
and
done
well
and
I
got
that
type
of
reaction,
as
well
to
in
general,
would
seem
to
be
a
positive
tone.
D
C
E
E
So
my
I
was
expecting
some.
What
of
the
response
that
Todd
just
talked
about
you
know
so
much
skeptical
and
such
but
I
didn't
really
get
any
of
that,
and
I
got
a
lot
of
positive
feedback
where
people
were
really
happy
that
we
were
working
on
this
and
really
agreed.
Maybe
it
was
due
to
Troy's
evangelism
up
on
stage
I
mean
I,
know
I
almost
came
to
tears,
but
it
for
whatever
combination
of
great
reasons.
E
D
A
D
A
C
D
E
E
Well,
if
we
can
that's,
that
seems
to
be
something
that
we've
been
consistently
concerned
about
of
of
how
we
properly
communicate.
This
is
not
a
beauty
contest,
but
interoperability,
so
I
guess
that,
just
probably
as
things
we
could
go
further
along,
we
just
need
to
make
sure
that
we
we
take
that
mind.
A
Right
I
felt
the
best
the
interop
message
was
well,
it
was
understood
the
people
in
discussing
it.
We're
like
okay,
I,
see
where
how
this
gets
to
enter,
not
interop,
it
didn't
I
was
worried.
They
feel
like
this
was
far
away
from
interop
and
it
didn't
seem
like
we,
oh
I
had
that
trouble
explaining
it
yeah.
F
F
D
That
it
really
would
be,
but
you
know,
but
people
are
looking
at
it
from
their
perspective
of.
Is
it
something
that
supports
you
know
a
vendor,
unique
saying
and
it
suddenly
left
out
of
the
distribution
it
might
make
it
look
like
that
attribute.
You
know
whatever
it
was
that
was
in.
There
is
certainly
less
desirable
and
therefore
they
shouldn't
pay
attention
to.
It
hurts
their
marketing
more
than
anything.
A
E
That
actually
brings
up
a
point
that
I
assumed
I
understood
that
maybe
I
didn't
understand
it
as
well
as
I
thought.
I
did
that
we're
not
by
us
calling
something
a
core
kippur
up
a
capability
or
designated
code
section
doesn't
determine
I
mean.
Let
me
just
go
back
to
capabilities
if
something
is
considered
to
be
a
capability
and
thus
can
carry
the
mark
of
it.
It
supports
these,
can
support
these
tasks
or
pass
these
tests.
That
doesn't
mean
that
that's
the
base
amount
of
code
that's
going
to
be
distributed.
E
A
E
So
yeah,
so
we
need
to
make
sure-
and
that
brings
up
a
point
that
I
think
may
be
confusing
some
people.
In
fact,
I
just
stumbled
trying
to
speak
my
mind
that
the
difference
between
passing
being
able
to
pass
the
tests
for
capabilities
thus
being
able
to
carry
the
mark
and
the
project
release
cycle
and
the
code
that
gets
released
as
part
of
that
cycle
are
you
know,
they're
they're
similar,
but
they're
not
the
same
so.
C
E
A
E
A
A
E
B
G
G
C
C
B
In
in
the
Swift
world,
where
he
you
know
his
opinion
of
what
Swift
is
and
why
it
should
be
part
of
every
other
SEC
mark
product
doesn't
have
much
to
do
with
the
way
the
rest
of
the
OpenStack
community
consumes
or
interacts
with
Swift
and
I.
Think
this
sort
of
general
question
of
what
are
the
users
think
they're
getting
versus
the
one
of
the
devastate
their
building.
We
have
called
this
programs
versus
projects,
and
we
talked
about
it
is
like
the
simple
case
is
just
what's.
B
H
A
G
A
B
B
C
D
A
A
C
D
A
A
A
To
just
make
sure
I
could
we
close
the
community
summit
with
a
resolution
that
we
have
enough
feedback,
there's
no
reason
to
slow
down
and
I.
Just
I
think
that
should
be
a
committee,
a
committee
resolution
effectively
out
of
this
meeting.
Yes,
we
think
we
think
we're
on
the
right
track,
keep
keep
moving
forward,
but
generally
acclaimed
any
concerns
about
that
statement.
I.
A
C
B
You
know
we're
not
quite
sure
yet
what
to
do
about
Swift
visa
be
designated
sections.
We
believe
this
is
the
last
hard
part
of
this
first
release,
and
then
we
know
that
we
have
questions
around
the
rollout
timeline
and
deprecation
and
the
future
of
other
marks.
So
we
know
we
they
have
these
sort
of
two
or
three
issues.
Is
there
anything
else,
and
I
got
really
clear
feedback
that
people
thought
we
had
things
relatively
covered,
that
they
didn't
have
other
issues
mind.
A
A
A
A
C
A
B
B
G
A
A
E
B
I,
just
I
just
put
that
we
got
a
bunch
of
feedback
from
from
John
Dickinson,
specifically
saying
that
he
thought
the
capabilities
groupings
for
swift
were
confusing
the
challenges.
All
of
the
capabilities
he
suggested
don't
have
tempest
test
if
they
have
a
whole
separate
test
suite
in
Swift
itself,
and
so
his
request
was
either.
Can
we
use
this
other
chest
sweet
as
well
or
do
we
need
them
to
port
all
of
those
tests
to
tempest?
And
if
so,
what's
the
timeline
for
that?
B
B
A
B
E
B
I
see
I
think
it
is
I.
Think
the
Swift
team
gets
to
talk
to
the
refs
tag
team
about
it
and
say:
hey
you
know.
Is
it
easier
for
us
to
help
you
make
refs
tackle
on
this
other
test
suite
as
well,
and
is
that
an
unnecessary
burden
on
the
users
or
do
we
need
to
put
the
tests
and
if
so,
we'll
go
and
work
with
it?
B
C
B
A
B
A
A
A
For
Havana,
yes,
thank
you
yeah,
and
this
is
in
the
Havana
section,
but
it's
useful
for
doing
that,
but
I
think
Juno
is
coming
down
so
fast
that
it's
there's
really
not
much
leeway
right,
but
I
think
I'm
fine
to
do
it
for
Havana
talk
about
it
and
we'll
get
the
implications.
Are
people
cool
with
taking
this
stance?
C
A
It's
it's.
My
goal
is
to
act
as
a
driver
to
say
figure
out
the
designated
sections
or
will
will
rely
on
the
tests
alone,
because
what
I,
what
I'm
worried
about
doing
is-
and
this
is
a
trick
right-
the
tc's
definition
actually
says,
but
things
are
designated
by
default-
I'm
worried
in
the
case
with
Swift
or
Keystone,
or
something
like
that
that
it
we
cause
tricky
problems.
If
we
make
the
code
one
hundred
percent
designated,
maybe
that's
okay,.
F
F
G
E
A
D
B
B
A
G
B
Mean
what
I
feel
robbed
I
just
feel
like
it
needs
an
executive
summary.
That's
all
it
just
needs
like
two
or
three
paragraphs
of
prose.
That
says.
Look
roughly.
What
happened
is
these
ones
look
like
they're
in
and
these
ones
are
on
the
bubble
in
these
ones
are
out
and
here's
the
histogram
story,
and
it's
what
we
end
up
saying
every
time
we
talk
about
it
and
explain
it.
My
concern
is
just
if
I
write
that
down
or
you
write
it
down,
I
mean
well,
you
could
probably
do
it.
A
C
C
B
B
D
G
A
G
D
C
A
G
B
Of
different
at
as
a
separate
conversation,
swagger
is
probably
exactly
the
tool
we
should
be
using
because
it's
just
you
you,
you
start
from
json,
and
then
it
generates
no
nicely
interactive
HTML
pages.
Everything
else
so
I
mean
something
like
that.
I
agree.
We
need
the
formatting
and
the
sort
of
user-friendly
display,
but
I
think
we
can
have
a
technical
conversation
on
like
two
or
three
choices.
Right.
G
G
A
A
C
A
A
C
C
B
B
A
B
A
D
C
B
And
then
can
we
assume,
let's
maybe
break,
to
working
group
sessions
for
scoring
them
I
mean
in
each
bucket,
one
of
which
is
the
easy
one.
So
a
quick
scan
of
things
that
were
already
in
core
to
make
sure
that
they
haven't
fallen
out,
but
we
shouldn't
have
to
dramatically
you
score
them
and
then
probably
the
most
focus
on
the
things
that
we're
on
the
bubble
and
then
the
last
pass
on
the
stuff
that
was
clearly
not
in
core
the
first
time
to
see.
If
things
have
dramatically
changed.
Does
that
make
sense.
A
B
B
E
A
I
think
we
can
divide
and
conquer
I'd.
I
would
rather,
since
they
have
a
specific
process,
they
want
to
do
and
they
might
want
to
do
it
as
reviews
and
garrett,
whatever
you
know,
and
that
would
whatever
I'd
like
to
get
their
feedback
on
how
they
want
to
take
it
on,
and
then
we
can
debate
back
and
forth
if
it
makes
sense,
I
think
we
did
the
hard
ones
at
the
heart.
The
heart
iteration
this
time,
I
think
the
future
iterations
might
be
a
lot
easier.
A
A
So
I
think
if
we
say
look,
here's
the
deal
we're
going
to
assume
that
if
it
was
Savannah
this
disk
or
it
moves
straight
into
ice
house
with
the
same
score
and
then
then
we
could
actually
throw
it
through
a
garret
review
or
something
like
that
new
be
pretty
straightforward
to
go
through
and
have
people
comment
on
individual
shoot.
We
didn't
capture
this
level
of
detail
in
the
in
the
in
the
JSON
file,
so
I
think
what
we
might
need
to
do
is
add
the
scoring.
A
C
A
A
A
B
E
E
E
A
E
Can
while
I
was
I
was
in
on
the
conversation
talking
about
storyboard
with
the
refs
TAC
team
rocky,
but
maybe
rocky
could
chime
in,
but
I
think
for
an
actual
project
like
rough
stack,
I
think
it's
dangerous
because
it's
it
doesn't
have
the
capability
of
right
now
of
handling
bugs,
but
it
does
have
the
capability
of
describing
I
mean
it's
come
a
long
way
last
couple
months.
It
has
the
capability
of
describing
user
stories
and
and
features
that
would
tie
into
those
user
stories
and
be
able
to
have
some
kind
of
conversation
about
them.
G
That's
an
interesting
question:
guerlain
well
is
moving
ahead
and
getting
us
into
storyboard
and
listening
to
the
folks
on
infra
or
reading
the
folks
on
intro
infra.
They
seem
to
believe
that
a
single
task
could
be
is
equal
to
an
issue
is
equal
to
a
bug
and
so
by
adding
a
new
task
into
the
story
for
the
epic
you're,
adding
you're
putting
this
mug
in
place.
E
G
A
I
agree:
I,
don't
want
to
invent
something
news
either,
so
we're
bad
at
actually
I
want
to
I
want
to
set
want
to
be
clear
that
I
the
reason
I'm
suggesting
it
is
because
that's
how
the
TC
seem
to
be
operating
on
evaluating
group
decisions,
I,
don't
necessarily
think
that's.
That's
the
only
thing
to
consider
I'm
just
proxying
for
the
TC.
G
Possibility,
I
don't
know
if
it's
a
big
possibility
or
not,
but
google
docs
now
have
traceability
of
for
versioning
and
it
might
be
worth
looking
into
that
and
just
limiting
a
management
of
that.
So
you
comment
on
the
google
doc
and
when
people
are
in
greement
it
gets
tossed
into
google
doc
and
then
you've
got
your
spreadsheet.
A
G
A
All
right,
I
was
looking
back
at
the
agenda.
One
of
the
things
that
we
were
looking
at
is
a
trigger
for
when
we
would
start
this,
it's
possible
that
we
need
to
talk
about
how
we
want
to
do
it
with
dcs,
but
we
don't
we're
not
ready
to
do
the
scoring
until
after
the
bosque
on
after
the
board
blesses
the
havana.
Do.
We
want
to
step
that
as
a
trigger.
B
H
A
Yeah,
what
what
I
was
expecting
is
that
we
would
present
the
Havana
capabilities
score
cork,
the
core
capabilities
to
the
Board,
for
approval,
to
sort
of
exercise
that
process
at
the
at
OSCON
and
have
it
have
them
say?
Yes,
these
are
the
advisory
core
capabilities
and
then
that
score
would
then
translate
forward
for
ice
house
and
then
for
Juno
and
there's
a
whole
bunch
of
work
to
get
ready
for
that.
So
I
think
we're.
A
We
don't
want
to
jump
start
actually
having
the
discussion
about
the
ice
house
capabilities
until
we've
done
some
of
this
other
work.
Actually,
don't
they
I
think
we'd
be
we'll
be
lucky
to
start
it
after
you
know
the
day
after
ask
on.
If
we
actually
can
start
that
process
I
think
we'll
be.
We
should
be
excited
about
that.
The
timing,
because
it
looks
like
there's
a
fair
bit
of
work
to
do
even
just
to
get
ready
for
that
event.
A
G
H
B
H
C
B
A
G
A
A
Version
of
the
change,
so
what
do
it?
We've
talked
about
for
the
bylaws
changes
with
that
we're
going
to
do
a
plain
English.
This
is
what
we
want
to
Sela
bylaws
look
like
and
have
the
Deaf
core
committee
review,
the
plain
English
and
I
actually
think
that
is
a
major
work
item
for
the
face
to
face.
Actually,
why
don't?
We
do
that?
A
A
A
So,
let's
do
this
before
the
face-to-face
we're
going
to
write
the
plain
English
version
of
the
changes,
but
very
very
briefly.
What
we
decided
was
to
stop
writing
the
bylaw
right,
rewriting
the
bylaws
with
before
we
knew
what
we
wanted
and
write
down
what
we
wanted
and
then
write
to
make
the
bylaws
changes
for
that
right.