►
Description
Meeting notes: https://docs.google.com/document/d/1ttqkcYPmYZyqvtkaHs92bx2UeVUiXDhuzP-0WbP11Fw/edit#heading=h.7o2ubzl5z39r
A
A
C
C
E
C
C
A
E
B
A
A
A
E
A
A
Shall
we
jump
in
and
just
talk
about,
we've
got
two
agenda
points
really
to
talk
about.
One
of
them
is
the
some
work
that
I
did
and
then
another
one
is
some
work
that
you
did
Christine
I,
think
yeah
right
and
shall
we
talk
about?
Let's,
let
me
just
jump
in
and
I
can
talk
about
what
I
did
earlier,
which
is
basically
just
rearranging
content
that
gnome
provided.
So
this
is
all
just
it's.
A
It's
just
rearranging
things
in
in
in
a
way,
but
also
came
to
led
me
to
some
interesting
questions
when
I
was
doing
it.
So
this
is
the
prepaid
document
and
basically,
what
I
did
is
I
took
the
organizational
structure
that
gnome
put
together
in
the
spreadsheet
and
I
applied
that
to
the
to
the
markdown
to
create
a
an
org
structure.
A
Organizational
management
repository
configuration,
continue,
yeah
cicd
but
spelled
out
and
then
server
config,
which
I
guess
only
applies
to
gitlab
and
then
miscellaneous
I
changed
to
high
hygiene
factors
and
I
I
moved
a
couple
of
things
around
so,
for
instance,
I
moved
scorecards
out
of
I
forget
where
it
was
before.
I
think
it
was
in
repository
configuration
into
hygiene
factors
because
I
felt,
like
that's
a
that's
a
specific.
That's
that's
the
kind
of
thing
that
I
think
of
as
a
open
source
hygiene
factor.
A
A
A
So
if
we
look
at
member
access
members,
access
control
and
permissions,
you
scroll
down
to
numbers,
access,
control
and
permissions,
then
we
get
the
you
know
the
best
practice
statement
the
severity
and
then
I
added
an
applicability
thing
here,
saying
it's
applicable
to
get
GitHub
and
gitlab.
We
have
the
description.
We
have
a
threat
sample
and
then
the
remediation-
and
this
is
where
I
think
we
actually
need
a
separate.
We
need
like
remediation
for
git
lab.
We
need
remediation,
for
you
know
like
like
what
are
the
steps
for
git
lab?
A
E
A
17
under
organizational
management
depend
about,
monitoring,
should
be
enabled
and
like
from
a
perspective
of
making
it
a
vendor,
neutral,
I
change
up
the
dependency
monitoring,
and
then
you
know
when
we
actually
go
to
the
I,
didn't
make
the
change
in
the
actual
text
itself
right,
but
but
I
was
thinking.
We
could
change
that
text.
To
kind
of
make
it
a
little
bit
more
vendor
neutral
and
say
depend
about
is
a
is
one
example.
A
You
know
there
are
other
examples
as
well,
and
then
there
are
certain
things
where
I
thought
thought
like
like,
for
instance,
here
under
organizational
management,
we're
talking
about
two-factor
authentication
should
be
enforced
for
the
organization
and
I.
You
know,
I
have
a
question.
Should
that
be
it?
A
But
you
know
everything
here
is
in
the
sections
that
it
was
in
because
that's
how
it
was
listed
in
the
spreadsheet.
Basically
so,
but
I
I
had
a
few
questions
about
where
moving
things
around
and
but
I
really
kind
of
wanted
just
to
bounce
that
off
of
the
group
before
making
any
further
work
on
it
and
as
well
I
guess
the
question
I
have
for
Gnome
is:
could
we
could
he
set
up
the
markdown
generation
to
kind
of
spit
things
out
in
this
format
or
in
this
organization?
A
D
D
A
I
mean
it
should
be
as
it
should
be.
It
should
be
that
way
it
should
be
oriented
towards
towards
the
towards
the
user
towards
the
the
reader
of
the
document
right
and
making
it
easy
as
easy
for
them
as
possible.
Absolutely
I
guess
the
other
thing
I
was
thinking
was
adding
some
or
adding
a
placeholder
for
some
of
these.
A
Introductory
paragraphs,
so
that
you
know
underneath
organizational
management
a
bit
of
a
blurb
about
this
is
what
organizational
management
is
all
about,
why
it's
important
or
or
something
like
that,
but
I
again
yeah
optional.
But
how
about
the
thing
about
where,
where
you
have
a
best
practice,
which
has
is
applicable
in
both
GitHub
and
git
lab,
do
you
feel
like
that's
the
right
approach
to
have
it
kind
of
called
out
in
the
table
of
contents
and
also
have
like
this
is
the
best
practice?
A
C
E
D
B
Or
maybe
three
right,
one,
which
is
the
central
document
where
you
go,
but
it's
a
bit
and
two
one
for
GitHub
and
one
for
git
club
and
then,
but
it's
a
bit
annoying.
If
I
go
to
to
the
use
case
that
you
just
describe
Norm
if
I'm,
a
GitHub
user
and
I
just
want
to
go
over
the
policies,
then
I
have
to
skip
back
and
forth
between
the
central
document
and
the
one.
That's
lists
the
actual
steps
to
remediate.
D
A
B
C
B
E
D
B
Yeah,
but
even
in
a
single
document
there
is
a
and
there
is
a
great
variance
between
the
first
proposition
and
what
Dan
just
proposed
right
in
how
like
in
the
original
document,
it
was
all
the
GitHub
policies
and
then
all
the
gitlab
policies
and
personally
I
feel
it's
more
easily
consumable.
This
way,
where
I
see
all
the
policies
and
then
can
diverge
according
to
the
specific
use
case,
I'm
looking
for.
A
Yeah
I
was
going
to
say
just
have
the
table
of
contents
or
just
have
a
couple
of
different
tables
of
contents.
That
link
through
that
have
internal
links
within
the
document
through
to
the
same
content,
so
that
you
can
view
it
as
I
want
to
see
all
the
stuff
relevant
to
GitHub.
Or
you
can
view
it
as
I
want
to
see
all
the.
A
C
A
E
D
C
E
D
C
There
might
be
some
assumptions
here
that
may
or
may
not
apply
to
other
books
and
I
stripped
around
a
lot
of
things
are
related
to
F5.
So
because
there's
a
confusion
between
GitHub
organizations
and
how
do
you
call
the
person
who
might
be
running
this
I'm,
calling
it
company
and
not
not
like
and
then
I
also
have,
because
it's
fi
specific
there
are
these
sort
of
different
audiences
that
would
be
consuming
this
document.
One
is
like
operations
because,
within
the
way
we're
structured,
the
Ops
teams
might
be
the
ones
who
have
to
like.
C
If
you
add
a
new
member,
could
you
create
a
repo?
Could
you
things
like
that
can
happen?
They
typically
handle
that
then
I'm
part
of
the
open
source
program,
office
or
hospital,
and
so
we
are
the
ones
who
are
sort
of
like
the
ones
who
know
what
should
and
should
not.
If
somebody
wants
to
turn
on
a
repo,
what
kind
of
like
The
Gatekeepers
in
some
way.
So
we
play
a
role.
So
that's
what
different
audience
and
then
a
third
audiences
project
maintainers.
So
so
the
doctor.
C
So
this
document
is
kind
of
like
it
might
be
like
a
mix
and
a
match
of
like
addressing
those
three
audiences.
So
it
might
might
seem
a
little
jumbled
up
at
the
beginning,
but
it
might
help
and
then
then
I
just
talk.
The
rest
of
the
section
is
organizing
the
guidelines
into
three
into
organizations
into
our
repos
and
then,
after
that,
there's
a
section
around
operations.
So
the
operations
is
meant
to
like
address
those
folks
who
are
going
to
do
like
the
Ops
types
work
so
under
organizations.
C
A
lot
of
these
will
be
familiar
but
to
your
point,
Dan
there's
usually
a
blurb
in
the
beginning
which
talks
about
like
what
we
want
to
do
for
organizations
the
usual
thing
about.
We
want
to
make
sure
things
are
secure
and
then
in
here
then
I
talk
about
what
are
generally
organizing
like
what
are
requirements
for
things.
C
All
organizations
should
be
under
like
one
Central
GitHub
Enterprise
account,
only
employees
of
the
company
can
be
members,
two-factor
authentication
must
be
enabled
and
then
I
kind
of
go
into
some
like
managing
roles
and
access,
and
here
we
say
who
should
be
the
ones
who's
even
gonna,
get
to
decide
who
are
the
org
owners,
because
they're
typically
important
on
and
then
we
talk
about
only
things
like
only
company
employees
can
be
organization.
Members
I,
don't
know.
C
If
that's
something,
that's
in
the
guide
that
I
don't
think
it
doesn't
necessarily
have
to
be
in
the
guide
that
game
that
gnome
did.
But
it's
important,
if
you
like,
a
company
or
whatever
the
entity
managing
all
these
GitHub
orgs
and
then
all
things
like
non-employees
who
need
access
should
have
elevated
permission.
So
there's
things
around
like
just
employees
that
are
not
really
part
of
the
original
doc.
A
C
Yeah
I
got
it
okay,
it's
a
similar
thing:
yeah
external
collaborators
would
be
books
or
not
I,
don't
know,
however,
you
want
to
tell
them.
Yes
that
would
help
then
just
talk
about
like
the
access
control
and
things
like
only
organization
owners
can
create
public
repos,
because,
usually
you
want
things
under
some
process
and
that's
another
assumption
that
there
is
a
process
in
how
things
actually
become
public,
and
so
that's
why
there
might
be
more
of
a
lean
towards
that,
and
some
people
may
not
actually
do
things
this
way.
A
C
And
they
may
or
may
not
be
a
process,
but
this
is
assuming
there
is
so
there's
some
assumptions
that
are
in
this
that
this
document
flows
through
that
I
haven't
stated
explicitly.
But
if
there
is
a
process,
then
you
probably
want
to
limit
who
can
actually
make
repos
public
and
then
also
things
like
certain
folks
could
only
be
allowed
to
create
private
and
internal
repos,
especially
if
you
want
control
over
repo
creation,
for
whatever
reason
you
may
or
may
not,
and
then
we
also
said
things
like
organization
members.
C
Access
to
new
reposition
be
restricted
by
default.
Again,
it
may
not
be
something
that
you're
you're,
organizing
or
your
company
wants
to
do,
but
that's
kind
of
like
how
we
wanted
to
play
it
out
mentioned
two
Factor
here
as
well
under
managing
rules
and
access
make
sure
that
this
is
there.
And
then
we
talk
about
things
like
use:
Access,
Control,
to
manage
members
for
inactive
members
or
ex-employees,
so
best
practices
removing
members
from
GitHub
box
who
are
no
longer
employees.
C
They
can
be
converted
to
external
outside
collaborators
down,
grow,
downgrade
Global
admin
owner
privilege
for
people
who
have
no
activities
in
the
past
six
months,
which
maps
to
stuff
from
like
legitify.
Then
we
talk
about
GitHub
actions
and
just
like
things
like
the
most
restrictive
permissions
by
default
and
restricted
of
actions
to
known
repos
and
the
GitHub
orgs
and
restrictive
repost
only
use
GitHub
actions
from
GitHub
and
Marketplace
verified
creators.
Very
much
I
think
in
line
from
what's
in
the
policy
that
a
gnome
contributed.
So
that's
organizations,
I'll
pause
just
in
cases.
D
C
C
So
that's
why
we
start
talking
about
like
even
before
talking
about
like
how
and
the
security
and
how
we
talk
about
like.
Where
should
projects
be
grouped
under
orgs?
They
may
again
not
be
relevant
to
the
folks
who
are
reading,
like
the
other
document
that
we
may
put
up.
So
it's
not
really
sem
related.
C
This
is
more
like
I,
don't
watch
it
on
call
it
just
it's
very
much
specific
to
how
you
want
to
set
up
things,
but
basically,
if
you're,
organizing
a
whole
bunch
of
repos,
you
just
want
to
make
sure
that
your
orgs
make
sense
and
the
repos
that
are
going
into
those
orgs
make
sense,
because
at
some
point
you
may
want
to
signal
to
the
external
community
that
these
are
only
like
sample
projects
and
you're,
not
really
maintaining
these.
So
these
are
like,
like
the
really
good
projects,
and
therefore
there
is
some
expectation
of
Maintenance.
C
So
that's
where
that's
where
some
of
this
this
section
is
talking
about
so
I
kind
of
like
skip
over
that,
because
it
might
not
be
relevant
to
the
to
the
guide
that
we
want
to
put
together.
That's
sem
related,
so
that's
why
we
talk
about
things
like
private
repos
lasting
longer
than
six
months
should
be
evaluated
and
deleted.
It's
not
really
related
to
SEO,
so
I'll
skip
to
the
other
ones,
which
is
more
in
line
with
what
we
may
be
interested
in
so
under
repos.
C
They
just
have
like
requirements,
the
ones
we
know
protected
branches
use
branches
to
make
pull
requests,
enable
secret
scanning
alerts.
Access
roles
must
be
managed
with
accordance
with
the
policies
and
I
kind
of
have
them
requirements,
and
then
I
say
best
best
practices
like
user
security
scanning
tool,
enable
security
alerts
for
GitHub,
repos
and
then
I
have
actually
down
at
the
end,
got
like
an
appendix
which
has
like
a
detail
like
step
by
step
for
how
to
actually
Implement
some
of
the
things
that
we
are
talking
about,
then,
under
managing
roles
and
access.
C
We
just
say
that
we
want
to
organize
things
in
terms
of
in
teams,
so
if
somebody
actually
creates
a
new
repo,
we've
created,
different
kinds
of
teams
like
one
is
almost
like
a
maintain
a
team.
With
this
maintain
role.
Permissions
one
would
be
like
a
right
which
is
only
like
useful
in
certain
scenarios,
but
a
right
role,
permission
and
then
one
maybe
they're
helping
out
with
triaging.
You
could
have
a
triage
and
then
one
would
read
only
if
it's
a
private
repo.
C
So
this
is
a
way
to
kind
of
organize
things
in
relevant
teams,
and
then
we
also
state
that
non-employees
can
only
be
added
as
outside
collaborators
to
a
repo,
and
that's
like
things
like
if
somebody
needs
elevated
access
to
say,
do
something
like
triaging
and
again.
This
is
related
to
maybe
more
like
operations
and
how
you
set
up
a
new
project.
You
talk
about
things
like
if
there
is
a
process
for
getting
a
project
lab
ready
for
launch.
This
is
what
you
should
do
said.
D
C
Yeah
because
the
way
we
used
to
do
it
back
at
when
I
was
at
Facebook
is
when
we
had
teams
like
that
set
up,
then
eventually,
we
actually
built
tooling
through
the
GitHub
API.
On
top
of
that
that
which
then
allowed
the
the
project
owner
to
add
and
remove
people
to
the
relevant
teams
that
way
they
could
self-service
and
it
made
it
a
lot
easier
and
so
and
then
we
could
get
out
of
the
way,
but
organizing
a
teams.
C
All
right,
then,
jumping
into
the
kind
of
like
the
last
remaining
session.
It
just
talks
about
operations
and-
and
it's
really
for
the
folks
who
are
going
to
be
operating
things-
we
just
tell
them
things
like
you-
should
turn
on.
Github
insights
should
be
used.
We
talk
about
the
GitHub
audit
log
should
be
tracking
member
activities
and
procedures.
Any
security
procedure
should
be
reviewed
and
updated
annually.
Clear
communication
instance
reports.
A
response
plan
should
must
be
established
in
regular
security.
Audits
and
vulnerability
assessments
should
be
conducted.
C
Then
here
I
just
this
is
what
I
was
mentioning
to
where
if
we
have
like
internal
tools-
and
this
is
internal
to
the
company-
if
they
were
able
to
use
internal
tools
and
go
through,
say
GitHub
API,
that
might
have
like
some
Advanced
token
permissions-
that
you
could
automate
streamline
some
of
tasks
that
you
may
not
want
to
Grant
to
the
offs
team
and
then
avoid
giving
owner
access.
But
that's
just
something
that
is
a
it's.
C
A
nice
to
do,
but
it
might
not
be
not
ever
to
be
able
to
do
that
and
as
I
mentioned
before,
I
talked
about
self-service
tools.
If
Community
Management
needs
to
be
happen,
you
could
actually
make
that
available
through
a
different
UI
for
maintainers
and
then
allow
that
avoids
giving
maintainers,
elevated,
GitHub
permissions
and
then
automatic
automated
alerts
and
tools.
C
C
Add
any
folks
who
need
to
be
as
owners
and
then
I
say,
configure
the
required
settings
which
is
in
the
appendix
and
configure
the
recommended
settings
in
the
appendix
and
then
then
also
setting
up
a
GitHub
repo.
Very
short,
it's
just
like
again.
If
the
project
needs
to
make
public,
if
there's
approval
been
given
and
then
just
basically
configure
the
right
settings
and
have
the
whoever's
requesting
access
to
be
like
the
maintainer
role
axis
and
and
then
the
last
bit,
we
haven't
kind
of
like
gone
through
and
figured
out.
C
How
do
you
archive
a
repo
because
there's
thoughts
around
that,
but
the
then
there's
a
section
about
what
kind
of
like
what
the
resources
used?
It's
like,
obviously
GitHub
documentation,
scorecard
legitify
the
concise
guide
for
more
developing
wall,
secure
software
and
we
put
status.
The
rest
of
this
section
is
very
much
like.
How
do
you
do
this?
How
do
you
do
that?
If
you
want
to
turn
into
ethics?
This
is
straight
out
of
legit.
If
I'm
mostly
go
to
this.
C
C
A
C
A
It's
got
me
thinking
about
another
organizational,
because
Noah
mentioned
having
three
documents.
The
other
thing
we
talked
about
is
maybe
having
like
the
document
B2
part
like
like
your
document
here
and
I
start
so
now,
I'm
kind
of
thinking
like
maybe
we
should
do
it
being
like
well,
just
basically
adopt
your
organizational
structure,
but
then
at
the
bottom
of
the
document,
have
GitHub
stuff,
git
lab
stuff,
that's
two
separate
kind
of
subsections
or
sections
of
the
document
and
then
from
the
top
matter.
We
link
to
the
specific
things
like
like
it'll,
be
talking
about.
C
S
for
2fa
as
an
example
right.
Yes,
if
you
just
know
that
you
need
2fa,
then
I
guess
but
you're
talking
about
like
because
I
think
what
could
be
useful.
Like
I
said,
like
I
said,
most
of
the
links
were
mainly
around
like
okay.
If
you
want
to
do
more,
go
to
get
our
bulk
settings
so
yeah.
If
you
want
to
set
up
a
new
git
lab
organ
I,
don't
know
if
they
call
it
organizations
and
get
along.
They
probably
don't.
C
D
F
F
E
E
F
Other
little
bit
of
feedback
is
that,
when
you're
posting,
this
I
saw
this
in
the
the
vulnerability
exposures
working
group.
If
you
post
this
link
in
a
the
email
thread
for
this
working,
this
working
group
include
a
pdf
version,
because
there
are
certain
banks
that
can't
access,
Google,
Docs,
so
just
yeah
whenever,
whenever
you
share
it
into
the
email
thread,
include
a
PDF,
a
pdf
version
of
it,
including
yeah.
F
C
F
F
A
F
Think
for
live
edits
before
it
turns
into
markdown
it's
better
to
do
the
live,
edits
and
Live
reviews
in
Google
Docs.
Unless
well,
there's
a
discussion
about
that.
But
but
currently
the
best
practice
is
to
is
to
do
the
review
with
everybody
in
Google
Docs,
because
then
you
can
live
update
and
then
turn
it
into
a
markdown
and
then
future
things.
Future
reviews
and
changes
come
in
Via,
pull
request
right.
C
A
Accessible,
sorry,
no
no
I
mean
I,
mean
I,
mean
sorry.
I
was
talking
more
about
the
question
of,
should
it
be
one
once
we
publish
it,
should
it
be,
you
know,
should
we
be
organizing
things
more
like
the
way
that
Christine's
document
is
organized
where
there's
like
General
front
matter,
and
then
we
go
into.
G
I
thought
we
had
originally
talked
about
structuring
the
document
around
kind
of
the
secure
principles,
so
you
should
use
multi-factor
authentication
and
then
you
would
provide
those
specifics
on
here's
how
to
do
it
in
GitHub.
Here's
how
to
do
it
in
gitlab
and
kind
of
talk
about
the
nuances,
how
it
might
be
named
differently
right.
G
G
A
Here's
how
you
do
it
in
git
lab,
but
the
I
think
one
thing
that
we
need
to
resolve
is:
should
we
be
doing
that
in
line,
or
should
we
be
linking
off
to
a
to
to
subsections
of
the
document
which
in
themselves
are
here,
are
all
the
principles
for
GitHub?
Here
are
all
the
principles
for
git
lab
and
then
it's
really
you're
you're.
G
F
You're
using
GitHub
right,
if
you're,
going
to
do
GitHub,
git
lab
setup
you're
using
gitlab
like
those
should
be
distinct
documents
with
the
best
practices
for
each
I
I
think
like
maybe
they
have
a
union
point
that
is
coalesced
into
a
central
document,
but
like
all
of
the
Google
or
all
of
the
GitHub
stuff
should
be
in
one
document
that
may
link
to
the
equivalence.
There
might
be
like
some
parent
document
links
to
the
Sub
sub
sections
of
that.
Maybe
so.
G
G
With
the
C
and
C
plus
plus
compiler,
work
has
very
similar
challenges
where
we
have
GCC
and
C
Lang
and
the
Intel
compiler
and
the
Microsoft
compiler,
so
how
they
are
solving
that
problem
is
we
have
a
general
eye.
We
have
like
an
overview
of
here's
the
best
practices,
and
then
we
have
tldr
tables.
So
if
you
are
a
GCC
user,
here's
a
list
of
those
particular
options,
we're
endorsing
and
if
you're,
a
sea
Lang
or
an
Intel
or
a
Microsoft
compiler
they'll
have
their
dedicated
artifacts
so
that
that
could
be
a
separate
markdown
file.
G
It
could
be
a
separate
section
in
one
document.
We
want
to
think
about
the
maintainability,
because
we
don't
want
this
to
become
somebody's
full-time
job
having
to
administer
the
doc.
So
it's
I
would
advise
whatever
is
the
simplest
path
for
maintainability,
whether
it's
one
or
multiple
dive,
it's
simpler
to
have
a
dedicated
dock
for
git
lab
and
a
dedicated
dock
for
GitHub,
and
you
know
cite
those
out
of
a
you
know.
Master
principles
list
great.
E
E
G
C
A
A
G
A
But
the
the
benefit
of
doing
it
in
the
way
where
well
I,
don't
know
whether
it's
separate
documents
or
or
separate
sections
within
one
single
document,
but
one
benefit
of
doing
it.
That
way
is
that
we
could
have
the
editorial
stuff,
which
is
kind
of
more
hand
curated
up
at
the
top
and
then
all
of
the
actual
best
practice
listings
the
general
auto-generated
from
the
legitify
data.
A
E
C
A
Thinking,
yeah
turning
it
into
that,
basically
adapting
that
to
to
the
front
matter
that
we're
talking
about
and
then
showing
how
you
know,
because
you,
because
you
have
the
link
to
the
GitHub
best
practice
showing
how
it
could
look
if
we
have
linked
to
GitHub.
This
part
best
practice
link
to
git
lab
best
practice.
A
C
E
C
E
A
A
Layout-
let's,
let's
put
make,
let's
make
the
focus
the
the
Google
Doc
for
now
for
for
kind
of
organizing
it,
and
then
we
we
can
keep
in
mind
that
the
intention
is
for
the
best
practices
themselves.
The
the
you
know,
the
the
individual
bullet
points
for
GitHub
and
gitlab
that
will
be
generated
out
of
the
legitified
data.
E
A
F
A
D
A
D
A
C
A
A
Yeah
it
was
like
it
was
more
like.
If
you
start
typing
markdown,
then
it
will
automatically
format
it
for
you
as
a
format
rather
than
yeah.
I
want
to
be
able
to
paste
markdown
in
I
want
to
be
able
to
export.
This
I
want
to
be
able
to
just
export
this
as
markdown.
That
was
more
of
the
functionality
that
I
was
looking
for,
and
it
didn't
seem
to
be
built
in.
There
is
a
markdown
plug-in
for
Google
Docs,
but
I.
It
was
not
working
very
well
for.
C
A
Okay,
so
I
think
we've
got
a
an
action
point
to
kind
of
okay:
let's
take
it
to
the
slack
and
then
see
if
we
can
iterate
on
this
document,
and
maybe
we
can
figure
out
a
way
to
easily
export
it
to
markdown
and
start
iterating.
It
iterating
on
it
that
way,
but
let's,
but
but
at
this
point,
let's
just
start
working
on
it
in
the
in
the
GitHub
doc
that
Christine
shared
and
then
we
can
see
where
we
get
to
basically
bye.
Okay,
all
right.
A
A
A
D
A
Hoping
we
yeah
I
feel
like
this
is
a
good
direction
we
had
to
kind
of
like
there
might
we
we
still
need
to
do
I
think
a
little
bit
of
research
and
development
between
between
us
to
to
come
up
with
some
answers
to
these
questions,
but
but
we're
getting
there.
We
will.
We
will
get
a
document
out
there,
we're
not
going
to
just
keep
rearranging
that
the
chairs.