►
Description
Meeting notes: https://docs.google.com/document/d/1ttqkcYPmYZyqvtkaHs92bx2UeVUiXDhuzP-0WbP11Fw/edit#heading=h.7o2ubzl5z39r
A
C
A
A
A
My
first
item
of
business
is
I,
am
going
to
be
a
semi-regular
attendee
on
this
call,
so
I
need
to
have
one
of
the
folks,
that's
a
contributor
or
collaborator
of
the
larger
working
group.
If
they
could
assist
in
kind
of
co-leading,
this
group
helping
herd
the
cats
on
the
call
so
to
speak,
being
mini
probe.
So
do
we
have
anyone
interested
in
potentially
taking
on
that
role
to
help
us
with
our
forward
momentum?.
A
A
Oh
and
you
have
someone-
that's
been
a
long
time
contributor
for
the
group
now
you'll
definitely
be
actively
engaged
and
you
can
provide
as
much
energy
as
you
want,
but
I
need
to
have
kind
of
someone
just
a
keep
an
eye
on
things.
If
I'm
not
around
someone,
that's
familiar
with
the
foundation
in
the
group,
Dan.
E
E
A
A
E
A
E
F
G
H
E
A
H
H
A
E
A
But
to
give
everybody
context
generally,
when
we've
worked
on
groups,
I've
been
involved
with
have
worked
on
guides
is
we
have
typically
put
things
into
a
Google
Document,
though
that
appears
to
be
a
little
easier
for
like
when
there's
heavy
changes
potentially
and
then
ultimately,
things
get
put
into
GitHub,
and
then
things
are
managed
with
PRS
and
issues
whatever
style.
The
group
is
comfortable
with
if
we
just
want
to
manage,
because
it
already
is
in
GitHub
through
PRS
and
issues
that
is
perfectly
acceptable,
but
I
agree
Dan.
C
C
C
E
E
I
B
Actually,
it's
we've
got
the
contribution
yesterday
to
just
modifies
a
little
bit
the
rewarding
to
be
exchange
it
from
being
like
a.
What
is
the
problem
to
be?
What
is
the
advice
so,
instead
of
saying,
for
example,
instead
of
saying
a
collaborator
found
a
stale
collaborator,
the
policy
now
is
a
collaborator
should
have
a
activity
in
the
last
three
months
and
I.
Think
it's
a
good
idea
to
to
decide
what
kind
in
this
group
what
kind
of
wording
we
want.
H
E
Yeah
I
mean
I
kind
of
I,
agree
with
that
and
I
I
also
well,
whether
or
not
it's
Google
doc
or
in
markdown
I
kind
of
feel
like
it
would
be
easier
to
edit
as
a
document
if
it
was
in
one
document,
rather
than
a
bunch
of
different
markdown
documents,
which
I
would
be
happy
to
take
a
crack
at
kind
of
assembling
it
into
one
document.
But
then
that
kind
of
breaks
the
tool
chain
of
regenerating
it
from
the
yaml.
H
Yaml
is
grouped
into
GitHub
a
GitHub
and
gitlab,
and
then
under
that
there's
all
these
different
groups
related
to
types
of
policies
and
all,
and
then
it
just
talks
about
like
the
description
and
all.
But
is
there
like
agreement
on
sort
of
like
even
just
step,
taking
a
step
back
and
thinking
about
how
the
groupings
are
done
and
all
of
those
different
pieces?
And
is
it
easier
to
do
that
outside
of
the
yamo
file,
that's
kind
of
like
where
I'm
getting
at
or
sometimes
it's
hard
to
see
things?
H
Maybe
inside
of
me
just
to
kind
of
give
you
an
example:
I
took
a
legitify
as
inspiration
and
created
a
different
document
internally
for
how
we
wanted
to
manage
our
GitHub
documents
and
those
like
some
best
practices
related
to
other
pieces
of
it.
But
then,
at
the
end,
I
took
some
of
the
pieces
that
came
out
of
legitify
in
terms
of
like
the
step-by-step
directions
but
put
that
on
in
the
appendix.
But
there
was
like
a
lot
of
Preamble
that
basically
talked
about
more
like
the.
Why?
Behind
some
of
those
things
in
Greater
detail.
E
He
that's
exactly
what
I
think
we
need
here:
I
mean
that
you
know
from
from
a
perspective,
from
a
perspective
of
a
document
that
people
can
go
in
and
start
reading
right
and
the
other
thing
that
I
think
we
talked
about
early
on
which
I
is
the
idea
that
we
would
have
as
opposed
to
splitting
it
up
into
GitHub
and
gitlab.
We
would
split
it
up
into
topics
and
say
like,
for
instance,
two-factor
authentication
is
important
because
XYZ
right
and
then
here's
how
you
do
it
in
GitHub.
E
A
As
a
reader
of
the
document,
I
would
prefer
to
have
the
topics
listed
as
an
implementer.
If
I'm
going
to
apply
this
to
my
repo
I,
like
how
it's
organized
now
but
I
think
for
the
purpose.
Our
first
purpose
I
would
suggest
we
combine
it
by
topic
and
then
say:
here's
how
to
execute
in
Hub
and
lab
and
whatever
other
forges,
just
by
suggestion.
I
E
So
Christine
and
I,
don't
suppose
that
document
that
you
wrote
internally
based
on
the
legitify
stuff
would
be
something
that
you
could
turn
into
something
that
could
be.
That
could
could
because
I,
because
I
could
go
and
do
this
work.
But
if
you've
already
done
it,
then
it
feels
like
duplication,
but.
H
B
H
Topic
is
like
managing
managing
roles
and
access
that
you
kind
of
have
it
internally,
deep
down
under,
say,
GitHub
and
gitlab.
Another
topic
could
be
just
around
something
related
to
the
two-factor
authentication
and
securing
access.
Another
topic
could
be
teams,
house
and
kind
of
organizing.
The
repository
in
the
themes
could
be
a
topic.
A
A
Several
points
that
address
that,
like
you,
should
Implement
multi-factor
authentication
for
your
admins
and
this
and
this
and
this
and
then
you
know,
as
you
have
those
things
we
can
tie
those
into
the
specific
actions
that
would
be
taken
in
the
repository,
but
just
try
to
up
level
a
little
bit
to
talk
about.
It
brought
more
broadly
at
a
topic
level.
D
H
Yeah
yeah,
that's
something
that
was
also
useful
in
terms
of
like
they
showed
me
how
that
there
were
some
topics
around
when
you
were
doing
a
certain
thing
like,
for
example,
when
you
are
setting
up
the
organization
the
very
first
time.
That
could
also
be
like
a
topic
in
terms
of
like
what
you
do
for
best
practices,
and
there
was
also
a
topic
around
when
you're
setting
up
a
repository
the
very
first
time.
H
These
are
the
things
that
we
recommend
you
do,
and
then
there
was
some
like
ongoing
things
and
then
the
other
thing
that
I
also
found
that
could
have
been
a
topic
that
was
sort
of
outside.
Of
this,
when
I
was
when
we
were
trying
to
implement
one
of
the
best
practices
around
how
turning
on
Branch
protection
and
all
these
things,
we
kind
of
hit
this
wall
with
a
small
team,
but
they
were
too
small
to
kind
of
like
have
all
these
rules.
H
So
there
was
like
all
of
these
like
gotchas,
that
we
kind
of
learned
along
the
way
that
was
it
was.
It
would
have
been
nice
to
kind
of
know.
Okay,
these
are
these.
Are
things
you
need
to
be
mindful
of
when
you
turn
on
these
settings,
but
anyway,
those
are
the
topics
around
like
the
show
me,
how
like
show
me
how
to
do
this,
if
I'm
doing
it
for
the
very
first
time
or
show
me
how
to
do
this,
if
we're
gonna
run
into
all
these
different
issues,
troubleshooting
things
like
that.
B
G
E
C
I
E
B
H
And
another
thing
that
is
interesting
in
terms
of
audience
is
depending
on
who
is
actually
implementing
it.
For
example,
in
our
case,
we
are
open
source
program
office,
so
we
we
may
not
want
to
give
all
of
the
the
developers
on
all
access
to
everything,
so
the
audience
might
dictate
some
of
the
things
you
may
turn
on
and
off.
For
example,
in
our
case
we
said,
okay,
folks,
within
this,
certain
group
are
able
to
have
these
extra
level
permissions.
H
H
D
E
A
G
D
B
B
And
they
want
to
talk
about
the
point
I
raised
before
about
the
wording
of
the
policies
amen.
So
we
just
got
a
contribution
that
changed
the
the
phrasing
from
being
the
violation.
For
example,
a
stale
admin
found
to
the
the
recommendation
like
admin,
should
be
a
active
in
the
last
three
months
and
which
is
easier
to
to
act
to
act
with
this
kind
of
policies,
because
you
know
what
is
the
problem
exactly
and
you
don't
need
to
go
to
the
documentation
and
see?
A
D
A
H
H
Another
thing
that
I
don't
know:
if
you
want
to
do
it
or
not,
that
was
actually
pretty
helpful
for
some
of
the
for
some
of
the
like
recommendations
or
whatever
it
was.
It
was
interesting.
Sometimes,
when
I
was
trying
to
figure
out
how
important
it
was
because
you
had
like
medium
high
and
when
I
was
at
a
stalemate.
I
actually
went
out
to
the
internet
and
looked
for
like
some
examples
of
if
I
were
to
turn
on
or
off
those
things.
H
What
would
happen,
and
it
was
good
to
kind
of
see
examples
of
what
could
go
wrong
to
help
me
make
a
decision
on
whether
or
not
I
wanted
to
turn
something
on
or
off.
So
all
this
to
say,
potentially
some
examples
of
what
not
doing
something
can
lead
to
wasn't
interesting
this.
It
would
be
interesting
to
kind
of
like
add
on
to
either
the
topics
or
add
on
to
the
the
individual
pieces.
B
A
D
A
I
think,
once
we
start
to
think
about
the
document
and
the
implementation
I
think
we
can
definitely
make
it
a
task
to
go
around
and
see
what
threats
or
risks
could
be
realized
here.
What's
the
attack
service,
for
example,
to
try
to
provide
that
additional
information
outside
of
for
people
that
are
using
the
guide
to
understand?
Do
I
want
to
turn
this
on
or
not
what
what's,
the
worst
that
could
happen.
I
H
I
know
like
there
were
some
things
that
are
also
a
matter
of
opinion.
For
example,
one
of
the
settings
was
related
to
require
linear
history
and
when
you
went
out
and
searched
out
there,
some
people
who
are
against
it
had
a
bunch
of
reasons
why
it's
good
and
then
some
people
were
had
a
bunch
of
reasons
why
it
was
bad.
But
at
the
end
of
the
day
it
was
a
contest
of
the
coin.
But
it
wasn't
really
clear
at
that
time,
which
one
should
I
choose.
A
A
So
I
have
that
Noam
is
going
to
combine
the
FI,
combine
all
the
data
into
one
MD
file
for
us,
so
that
we
can
start
to
think
about
how
we're
going
to
organize
and
tag
it.
Dan
will
assist
once
that's
done,
we'll
be
moving
the
meeting
time
next
time
and
then
Noam
said
he'll
build
a
table,
the
policies
for
us,
so
we
can
kind
of
start
to
talk
more
specifically
about
organization,
any
any
other
items.
I
missed.