►
From YouTube: StackRox Community Meeting #1 - 2022-04-12
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Yeah,
just
so
everybody
knows
community
meetings,
everything
we
talk
about,
it's
gonna
go
on
youtube
for
people
to
if
they're
missing
it
if
they're
in
japan
or
india
or
stuff
like
that,
so
just
an
fyi,
it's
being
you're
gonna
be
famous
on
youtube.
C
A
C
D
Yeah,
that's
what
it
looks
like.
Oh
my
god
that
mess
this
is
so
exciting.
I
already
saw
some.
You
know
some
people
who
are
out
of
red
hat
active
on
the
community,
already
giving
advice
to
other
folks
that
is
so
exciting.
A
Yeah,
I
think,
there's
a
bunch
of
pull
requests
too
already.
I
have
a
bunch
of
issues
I
need
to
send.
I
was
just
a
little
lazy
yesterday,
but
I'm
gonna
be
the
documentation
guy
for
a.
B
While
I
mean
looking
at
the
stats
of
our
main
stackrock
stackrocks
repo,
it's
kind
of
in
kind
of
impressive-
that
we
gathered
that
much
traction,
that's
actually
more
than
I
expected
to
be
honest.
A
A
All
right,
let's
give
it
one
more
minute
and
then
we'll
we'll
kick
it
off.
It's
a
light
agenda.
First,
one
bring
all
of
your
feedback
and
we're
gonna
get
going
soon.
D
You
know
my
feedback
yeah.
That
was
a
a
hidden
slide
there
nice,
I'm
loving
it.
If
people
didn't
get
that.
A
All
right,
we
have
a
slide
presentation
today,
pretty
quick,
we're
not
gonna,
bore
you
to
death
with
any
crazy,
slides,
there's
like
eight
slides,
but
in
future
meetings.
There's
gonna
be
a
running
dock
that
we'll
use
just
to
make
sure
that
we're
keeping
track
of
things
as
we
go
along
and
documenting
it
all
so
I'll
be
on
the
public.
It'll
all
be
on
youtube
as
well.
A
B
Sure
would
you
mind
handing
me
the
permission
to
do
that.
Oh
yeah,
you
handed
away
the
power.
B
B
B
So
we
want
you
to
meet
the
team,
so
we
have
a
quick
overview
as
well
as
meeting
the
code
of
conduct
and
then
we're
doing
a
quick
round
of
release,
updates
and
basically
some
questions
that
we
that
we
have
face
it
facing
towards
the
community
and
of
course
there
will
be
some
time
for
an
open
forum
and
questions
of
course.
So
if
anyone
got
some
questions,
please
feel
free
to
yeah
to
ask
us:
that's
why
we
are
here
so
to
give
you
an
idea
of
what
stack
rocks
is
or
who
we
are
it's.
B
We
are
comprised
currently
of
eight
teams,
or
at
least
eight
teams
in
the
main
engineering
parts
of
the
organization
which
is
we
have
automation
in
infra,
which
is
the
team
that
is
related
to
yeah.
As
the
name
says,
automation
and
infrastructure.
B
We
have
team
collector,
which
collects
and
monitors
info
about
container
runtime
and
network
active
activity,
and
these
these
infos
are
then
collected
at
another
point.
In
the
platform,
then
we
have
core
workflows,
which
is,
which
is
the
team
that
takes
care
of
policy
management,
reports,
notifiers
and
integrations.
B
B
So
this
is
the
part
that
actually
scans
all
of
the
docker
images
for
known
vulnerabilities,
that
is
the
team
data
shepards
or
data
core,
and
then
we
have
three
teams
that
are
doing
also
develop
or
mostly
development,
which
is
team
draco,
which
are
with
with
which
are,
besides
other
things,
doing
taking
care
of
the
operator
and
helm.
B
We
have
team
maple,
which
are
concerned
with
the
network
graph
and
sensor
network
optimizations,
and
we
have
team
merlin
which
are
doing
all
things:
identity,
authentication
and
and
command
line
interfaces,
as
well
as
image
signing
and
then
last
but
not
least,
we
have
the
ui
team,
the
web
pack.
So
these
are
the
people
that
are
actually
building
the
nice
ui
that
everyone
is
using
on
a
day-to-day
basis.
B
So
just
to
give
you
an
idea
of
who
just
to
give
you
an
idea
of
which
parts
of
the
team
you
might
be
able
to
or
which,
which
people
you
might
encounter.
If
you,
if
you
work
with
us,
if
you
open
issues,
these
are
roughly
the
areas
of
responsibility
that
you
might
expect.
B
So
speaking
of
issues
and
interaction
with
us,
of
course,
ideally,
everything
should
be
working
flawlessly
and
there
shouldn't
be
any
problems,
but
it
might
as
well
happen
that
you
have
that
you
encounter
issues
which
is
what
the
coc
is
for
and
spoiler,
I'm
part
of
the
coc
also
so
in
general.
B
B
Both
of
the
other
members
are
on
the
call
so
maybe
to
to
not
stretch
this
any
further
and
give
you
a
little
bit
of
a
of
a
different
voice
to
hear
to
listen
to
maybe
to
start
the
introduction.
I
matthias
I've
been
with
the
project
for
since
yen
january
last
year
and
yeah.
Besides
doing
community
meetings
and
coc,
I'm
also
doing
a
little
bit
of
core
workflow
development
and
yeah
core
development
alex.
Maybe
you
want
to
introduce
yourself
as
well.
C
Yeah,
I
think,
I'm
I
joined
the
the
project
before
acquisition
before
it's
a
christmas
barrette
a
little
bit
more
than
a
year
ago,
almost
one
and
a
half
I'm
coming
from
the
apache
mesos
community
or
apache
messages,
ecosystem,
which
is
collapsing
under
the
under
the.
What
is
that?
The
pressure
of
history
and
yeah
I'm
leaving
the
merlin
team-
and
I
am,
I
feel,
responsible
for
authentication
of
the
end
authorization,
our
product
and
that's
pretty
much
it
yeah
sure
oscar.
The
mic
is
yours.
E
Okay
hi,
my
name
is
oscar.
I
am
one
of
the
members
of
the
code
of
conduct
committee.
I
work
on
the
core
workflows
team,
I'm
I
believe
the
only
member
of
the
code
of
conduct,
that's
stateside,
so
we
have
full
coverage
of
all
of
the
hours
of
the
day.
I
think
yeah
I
joined
stackrocks
pretty
soon
after
acquisition.
E
I
think
I
think
that's
all.
I
have
to
say.
B
A
Hey
I'll
I'll,
just
throw
my
my
two
cents
in
there
hey
everybody
mike
foster,
I'm
one
of
the
other
community
managers
as
well,
not
on
any
team,
I'm
just
here
to
take
what
all
the
cool
stuff
that
you
guys
do
and
show
people
how
to
deploy
it.
How
to
do
you
know
how
to
secure
their
clusters.
So
if
you
have
any
questions,
slack
channel,
hashtag,
stackrocks
and
the
ctf
slack
channel,
I'm
there
I'll
be
answering
them
until
kingdom
come.
I
guess
all
right
see
us
on
to
the
next
one.
B
Yeah
sure
so
at
this
point
we
are
more
or
less
done
with
the
broader
introduction
of
the
team.
Are
there
any
questions
so
far?
Anything
anyone
want
to
add
or
discuss
we're
open
for
a
discussion
right
now
before
we
go
into
more
of
a
forum
version
or
more
before
we
enter
the
forum.
Part
of
today's
meeting.
C
I
don't
have
a
question,
but
maybe
I
do
have
a
suggestion
since
the
first
meeting
community
meeting,
maybe
we
can
just
complete
the
full
round
of
introduction
introductions.
I
see
at
least
one
face
on
the
call
that
I'm
I
don't
know,
and
I
would
like
to
get
to
know
everyone
who
I
don't
know
what
you
all
think.
F
On
sneaking
in
yeah,
so
I'm
chris
melvis,
I'm
a
senior
architect
in
the
north
american
public
sector
side.
So
I
focus
on
on
delivery,
basically
with
with
all
of
our
products,
but
obviously
a
lot
a
lot
of
open
shifts.
You
may
have
also
possibly
seen
my
name.
I
did
run
a
what
we
call
in
the
public
sector
like
a
hackathon
with
with
acs
that
really
was
focusing
on
on
fips
mode.
F
So
I
had
a
lot
of
help
for
with
that.
From
from
from
jim
scott
and
chris
porter
as
well,
they
were
kind
of
some
of
the
the
key
players
there
that
helped
kind
of
throw
that
together
so
yeah.
I
just
really
enjoyed
working
with
the
acs
team
when
we
ran
that
hackathon
a
few
months
ago,
so
I've
just
really
been
trying
to
get
more
involved
and
everyone's
very,
very
receptive
of
what
is
the
consulting.
What
are
you
seeing
out
in
the
fields
right?
F
What
the
consultants
say
so
yeah
kind
of
here
listen
provide
some
feedback
as
well
as
we
move
forward.
So
super
happy
that
that
these
things
are
occurring
so
really
cool.
A
Yeah
we
don't,
we
won't
make
the
no
names
or
the
the
people
who
aren't
showing
themselves
introduce
yourselves
but
you're
more
than
welcome
to
come
on.
I
see
you
there
kirsten
and
gavin.
It's
good
to
see
you,
hello,
hey,
hey!
I
think
it's
a
good
time
right.
Stack
rocks
is
right
in
the
middle
of
east
coast
lunch.
So
it's
awesome.
A
F
A
All
right
mathias,
no
more
q,
a's
anyways
questions
any
time
you
can
always
throw
them
in
the
chat,
and
you
know
either
at
slackchat
or
on
github
as
well
happy
to
answer
them.
B
B
Maybe
the
fact
that
we
that
we
went
open
source
on
april
1st,
but
this
might
change
in
the
future,
so
looking
at
what
we're
doing
right
now
is:
let's,
let's
maybe
start
some
or
let's,
let's
talk
about
some
of
the
things
that
we
that
we
thought
of
I
mean
we
try
to
think
of
everything
pre-launch,
but
of
course,
as
always,
you,
you
can't
think
of
anything
or
everything.
B
Basically,
so
the
the
first
interesting
question
for
us
would
be
is:
are
there
any
community
preferences
looking
at
the
current
participants,
I
guess
most
of
us
are
familiar
with
slack.
B
We
are
currently
using
a
dedicated
slack
channel
in
the
cncf.
Oh,
that's
yeah
we're
currently
using
a
dedicated
channel
hashtag
stackrocks
in
the
cncf
slack,
but
that's
just
a
starting
point.
So
if
anyone
is
interested
in
another
tool
or
another
platform,
please
let
us
know
that's
what
we're
sticking
with
right
now,
any
active
feedback
on
that
anyone
really
doesn't
want
to
use
slack
or
doesn't
feel
yeah
doesn't
feel
like
using
slack.
C
All
right,
one
thought
that
I
have
is
that
I
don't
think
there
are
a
lot
of
acs
engineers
on
that
slack,
and
I
wonder
if
this
is
something
it
doesn't.
If,
if
it's,
because
this
cncf
select
channel
is
natural
obstacle
for
whatever
reason
and
they
would
like
to
address
or
just
it's
the
marketing
issue,
so
not
everyone
knows
about
about
that
slack.
E
I'll
say,
I
think,
I'm
personally
of
the
opinion
that
I'm
fine
with
there
being,
I
guess,
friction
between
getting
access
to
all
of
the
engineers
at
stack
rocks,
because
I
don't
think
all
of
them
will
necessarily
want
to
be
involved
in
open
source
and
it'd
be
better
if
they
were
looped
in
after,
like
a
vetting
process
of
issues
or
questions
and
treat
it
as
sort
of
like
a
a
repository
of
information
rather
than
a
first
line.
E
So
I
think
it's
fine
that
not
everyone
in
stack
rocks
is
in
the
cncf
slack
channel.
That
being
said,
I
would
also
be
happy
to
be
included
in
this
included
in
the
cncf
slack
channel,
and
I'm
not
so
maybe
we
could
have
an
internal
message
to
some
of
the
engineers
and
one
of
the
larger
slash
channels
in
the
stack
rocks
slack,
giving
instructions
on
how
to
join
that
so
that
people
can
join
if
they
so
choose.
B
Yeah,
let
me
let
me
write
that
down.
Let
me
take
that
with
me.
I'm
happy
to
provide
a
message
in
the
in
the
internal
slack,
letting
people
know
how
that
this
exists
and
how
to
join
it.
B
I
think
the
cncf
slack
is
used
quite
a
lot
also
for
for
official
how's.
It
called
for
official
conferences,
so
the
conference
slack.
I
guess
that
might
be
one
of
the
reasons,
because
I
think
the
slack
the
the
stackrock's
channel
in
the
cncf
slack
is
a
little
bit
older,
so
it
wasn't
created
in
the
time
leading
up
to
open
sourcing,
or
at
least
not
right
before
at
least
not
right
before
before
the
open
sourcing.
B
Foster
any
any
things
you
want
to
add.
A
Oh,
I
definitely
am
if
you
look
at
most
the
open
source
projects,
they're
typically
on,
if
they're
kubernetes
native
they're
going
to
be
on
kubernetes
or
in
cncf
slack
ease
of
friction.
It
also
makes
it
easy
to
enforce
community
standards
and
alex
trust
me,
and
it's
friction
for
a
specific
group
right.
A
But
that's
it
was
a
choice
too,
because
it
does
have
a
big
user
base,
it's
one
of
the
biggest
slack
channels
out
there.
So
unless
we
make
a
huge
push
towards
something
like
a
discord
type,
I
think
for
now,
while
we
grow
the
user
base,
it
works.
B
A
All
right,
speaking
of
which,
as
I'm
tracking
all
this
stuff,
are
we
the
presentation's
great
now
do
we
want
to
have
like
a
couple
slides
every
month,
but
then
have
a
google
doc
that
just
tracks
our
you
know,
who's
on
the
call,
shareable
I'll
version
control
and
save
it
just
to
make
sure
nobody
goes
and
screws
around
with
it
or
anything
like
that.
Does
that
work
for
everybody
yeah?
That
sounds
good,
perfect!
A
And
I
actually
put
this
in
here
too.
The
other
thing
is
we
had
a
couple
of
comments
about
documentation,
specifically
that
a
lot
of
our
documentation
leads
to
the
rh,
the
advanced
cloud
security
documentation.
Well,
it
is
completely
free
and
open
to
use
for
acs
and
a
lot
of
the
workflows
are
the
exact
same.
B
I
think
there
might
be
some
some
overhead,
or
or
at
least
there
might
be
some
work
involved
in
making
sure
that
we
get
the
processes
in
place,
that
if
we
have
breaking
changes,
both
pages
or
or
both
versions
are
getting
updated.
B
So
it
might
might
be
a
good
idea
to
look
into
how
we
how
we
split
these
documentations,
but
in
general
I
think
it
might
be
a
good
idea
to
have
at
least
different
branded
or
yeah.
I
mean
the
the
deployment
is
different
for
the
for
the
open
source
version
in
some
parts,
and
I
guess
at
least
these
parts
we
should
document
well.
B
We
could
even
go
as
far
as
taking
the
dev,
docs,
repo
and
trying
and
and
thinking
about
just
generating
a
static
site
out
of
that
which,
because
it's
already
holding
quite
a
lot
of
our
developer,
documentation.
A
Yeah,
I
think
you
could
do
like
an
mk
docs
deployment
structure
or
something
very
easy
on
github,
and
then
that's
pretty
much
all
you
need.
Everything
else
is
okay,
you
have
it
set
up.
You
know
here's
how
to
use
it.
Anyways
I'll,
look
into
it
I'll
see
how
much
overhead
there
is.
Leave
that
one
with
me
for
now
and
I'll
have
a
some
feedback
for
you
next
month.
B
Yeah
speaking
of
of
yeah
of
things
that
we
have
open,
we
have
actually
our
first
open.
Github
issue
which
is
having
is,
is
that
the
reporter
is
having
some
smaller
troubles
with
our
email
reporting
parts
of
the
report.
We
could
already
verify
and
are
already
actively
tracking
in
an
internal
issue.
B
The
second
part,
so
the
main
problem
seems
to
be
that
reports
are
not
in
are
not
including
vulnerabilities,
even
if
the
report
is
configured
to
do
so
and
our
current
state
in
that
is
we're
trying
to
reproduce
that
and
then
come
up
with
an
update
for
the
reporter.
B
So
this
is
the
current
state.
We
have
already
communicated
that,
or
I've
already
updated
the
ticket
before
this
meeting
to
inform
the
reporter
of
that,
and
besides
that,
we
don't
have
any
feature
requests
right
now,
but
I
guess
that
might
change
in
the
future
is
especially
when
we
look
at
how
many
people
our
interests
seem
to
be
interested
in
the
repo.
B
So
at
least
that's
that's
the
questions
that
we
had
to
any
participants
from
our
side.
Maybe,
as
an
open
forum,
is
there
any
topic
any
of
you
would
like
to
discuss
or
run
by
us.
F
So
I
was
gonna
mention
what
you
just
kind
of
talked
about
was
the
documentation,
because
I
was
on
just
stack
rocks
the
other
day
just
on
the
stackrock's
website,
trying
to
find
if
there
are
separate
docs
so
yeah
it
sounds
like
that's
being
addressed.
The
other
thing
I
noticed
too
is:
I
noticed
that
the
documentation
that
links
to
on
the
stackross
website
links
to
the
368
and
not
369.,
so
I
wasn't
sure
how
that
was
being
linked,
essentially
from
the
stackrock
site,
back
to
the
the
docs.openshift
site
for
the
official
docs.
A
Yeah,
that
is
probably
just
a
mistype
or
because
369
got
updated,
but
that's
a
quick
fix
yeah
but
yeah.
That's
a
good
point
too,
because
you're
going
to
want
it
to
be
versioned
depending
on
what
people
are
deploying
good
point
yeah.
So
I
definitely
think
that,
in
terms
of
the
website
the
docs
there
should
be
something
specific
that
calls
out
the
repo
to
say:
here's
how
you
deploy
and
then
here's
the
documentation
for
after
you
get
started
so
definitely
going
to
work
on
that
workflow.
A
F
D
So
I
have
an
adjacent
question
which,
which
I
might
have
asked,
which
I've
actually
asked
in
a
in
a
different
form,
but
I'm
not
sure
where
we
landed
with.
That
is
so.
How
are
people
expected
to
deploy
the
open
source
so
we're
pointing
them
to
docs
but
where's
the?
Where
are
the
binaries?
Is
everyone
expected
to
build
their
own,
or
will
the
project
create
binaries
on
on
some
cadence?
So
it's
easier
for
people
to
deploy.
B
We
have
a
public
qualio
organization
where
we
publish
the
open
source
builds
and
we
are
currently
working
on
updating
the
deployment
commands
and
trying
or
seeing
if
we
can
find
a
way
that
the
open
source
version
automatically
pulls
their
dock.
Their
docker
images
from
this
public
way,
io
organization.
B
A
Yeah
with
tis
that's
a
good
reminder
to
see
if
we
can
track
down
who
has
access
to
stockrocks
for
quay
right,
I
think
it
might
be
chris
porter
actually.
So
let
me
pick
him.
B
Yeah,
so
that's
also
something
that
there
there
is
obviously
some
some
workarounds
and
some
some
provisional
things
right
now,
but
these
are
things
that
we
plan
on
ironing
out.
But
thanks
for
reminding
us
about
that
and
raising
that
topic.
D
I
I
wasn't
afraid
that,
like
if
roccio
was
a
binary-
or
maybe
my
use
of
binaries
was
too
strict,
so,
yes
container
images,
helm,
charts
operator
is
available
for
openshift.
Theoretically,
operated
could
be
made
available
for
a
container
for
communities.
B
Yeah
already
so
so
let
me
take
that
with
me:
let's
see
if
we
maybe
open
an
issue
about
that
and
look
into
it,
but
that's
also
very
good
idea
to
ease
in
I
mean
our
our
goal
in
open
sourcing,
of
course,
was
to
lower
the
barrier
of
entry
and
having
operators
I
mean
operators
are
really
comfortable
to
use,
so
it
might
be.
E
B
A
That's
always
good
to
hear
it's
funny,
because
when
we,
when
we
launched
well
there's
one
or
two
repos,
because
there's
there's,
we
have
a
bunch
of
repos
right
that
needed
to
be
flipped
to
be
fully
open.
Source
technically
and
everybody
who
deploys
on
openshift
had
almost
zero
complaints
because
it
was
just
oh
operator
here,
go
install
and
it
was
the
the
starcast
xcases
that
just
had
a
little
bit
of
issue.
There
was
one
thing
is
if
you
use
the
deploy
script.
A
A
B
Yeah,
I
think,
yeah,
I
think
we're
we're
even
aware
of
at
least
partly
aware
of
that,
because
we're
also
piping
that
password
the
the
deploy
script
also
creates
a
password
file.
But
you
need
to
know
about
that,
and
I
think
we
mentioned
that
somewhere,
but,
as
usual,
documentation
can
be,
can
always
be
more
clear
and
more
concise,
right,
yeah.
A
I
was
I'll
submit
my
readme
later.
I
was
working
on
that
last
night,
so
yeah
for
sure
it's
there
and
it
you
know,
like
I
just
speed
through
the
docs.
I
don't
actually
read
it
right.
I'm
gonna
spend
more
time
than
I
need
to
so
yeah
little
things
like
that.
Also
I
mean
we
recommend
using
helm.
Anyways
helm
is
pretty
it's
pretty
straightforward
to
deploy
with
it
right.
A
B
Was
actually
surprised
by
seeing
that,
or
at
least
most
of
the
discussion
that
I
saw
of
people
having
questions
revolving
around
the
deployment
process,
most
of
them
were
either
using
rocks
cuttle
or
the
deployment
scripts,
so
there
might
be
some
room
for
improvement
up
there
and
obviously,
maybe
maybe
it's
also
showing
that
the
helm
charts
are
just
a
little
bit
more
robust.
I
guess
I
mean
they.
They
are
they're
purpose
build
for
for
for
the
use
case
that
we're
using
it
for
right.
So.
B
Yeah,
I
guess
we
we
as
developers-
I
I
guess
most
of
the
readme
in
the
in
the
github
repository
used
to
be
tailored
to
to
developers
like
us
and,
of
course,
we're
we're
not
shying
away
from
from
just
gnarly
bash
scripts
and
and
and
just
opening
a
shell
script
and
reading
what's
documented
in
there.
B
But
I
guess
if
we
look
at
the
extended
user
base,
that
we
have
right
now,
basically,
people
stopping
users
stopping
by
in
the
git
repository
and
looking
for
ways
to
to
deploy
this
in
in
a
semi-production
or
or
even
production,
environment
or
evaluation
environment.
Of
course,
they
might
shy
away
from
this.
They
might
not
want
to
do
that
for
a
production
deployment.
So
it's
it's.
It's
still,
I'm
I'm
super
eager
to
see
what
people
are
doing
and
how
people
are
using
the
product
and
what
they
are
trying
and
especially
how
they
deploy
it.
E
Yeah,
I
think
our
only
bit
of
insight
at
this
point
is
the
the
issue
that
was
filed
against
the
repository,
where
somebody
mentioned
that
they
were
using
the
deployment
script
and
tweaked
a
number
to
have
it
deploy
on
the
k3s
instead
of
gates
yeah.
So
it
seems
like
I
guess
I
don't
know
if
that
was
their
specific
use
case,
but
maybe
looking
at
the
repository
and
looking
at
the
documentation
as
as
it
exists
right
now,
users
are
being
pushed
more
towards
the
idea
of
using
the
deployment
scripts
rather
than
something
like
a
helm
operator.
B
I
mean
I'm,
I'm
again,
I'm
super
interested
to
see
how
the
majority
of
users
deploy
that's
something
that
I
might,
I
guess,
might
also
be
kind
of
hard
to
track
or
or
get
get
a
feeling
for,
but
at
least
from
we
we
could
at
least
see
that
through
the
kind
of
reports
that
we
get
or
questions
that
we
get,
but
also,
I
guess
that
might
be
a
skewed
statistic
because
maybe
one
user
group
is
is
just
having
more
issues
than
others
or
one
user
group
is
trying
more
complex
things
than
others
are,
but
I
mean
time
will
tell
let's
see
where,
where
this
gets
us.
B
All
right
any
more
questions
or
comments
that
anyone
has.
B
Then,
if
that's
not
the
case,
I
would
hand
over
to
to
foster
again
to
wrap
up.
I
guess.
A
Yeah,
just
you
know,
thanks
to
everybody
in-house
out
of
house
who
have
been
helping
out,
you
know
github
issues,
it
all
helps
so
much,
and
I
think
the
big
takeaway
of
this
meeting
is
work
on
enablement
right,
so
documentation
making
sure
that
people
can
get
using
the
project
as
quick
as
possible,
and
then
you
know
working
on
issues
and
prs
and
setting
it
up
so
that
we
have
the
structure
moving
forward.
I
think
that's
the
biggest
thing.
That's
some
easy
things
that
I
think
we
can
all
take.
A
I
mean
I'll
just
submit
some
issues.
You
know
when
I'm
bored
one
night
so
look
forward
to
that
and
yeah
thanks
for
all
the
feedback.
It
all
helps
a
lot.
F
A
Diasporas
I'd
say:
that's
something
that
we
kind
of
are
working
on,
because
we
were
so
focused
on
getting
this
thing
out
to
the
community
and
working
on
documentation
that
now
it's
like
okay.
Well,
what
is
something
that
the
community
wants
to
do?
Do
you
want
to
work
on
a
kids
operator
right?
So
I
think
you
know
we'll
start
with
maybe
pushing
some
small
issues
out
things
that
or
some
things
that
you
think
are
wrong
with
the
product
maybe
or
should
be
slightly
changed.
A
I
think
the
general
workflow
was
that
we
have
this
meeting.
You
come
with
all
of
your
gripes
and
concerns,
and
then
we
kind
of
structure
them
for
the
next
meeting
review
it.
If
it
sounds
good,
then
we
we
work
on
that
from
there,
because
it
doesn't
really
make
sense
for
you
to
take
on
like
a
coding
project
with
no
real
feedback
from
us
too
right
so
yeah.
I
think
it's
partially
on
us
to
get
some
work
for
the
community
and
then
also,
if
there's
something
specific,
you
want
to
work
on
happy
to
hear
it.
B
So,
generally,
of
course,
especially
as
we
talked
about
documentation,
we
have
the
dev
docs
repo,
which
is
at
least
containing
quite
a
lot
of
markdowns
to
help
people
getting
started.
If
you
find
something
there
that
is
not
up
to
date
or
that
isn't
working
out
for
you
of
course
feel
free
to
improve
documentation.
B
And
generally,
I
would
say,
if
there
are
any
third
party
integrations
to
other
platforms
or
services
that
you
might
be
interested
in.
It's
always
a
good
idea
to
start
with
a
feature
request
or
an
issue
to
open
up
discussion
with
us.
We
can
run
this
by
engineering
and
see
if
that
is
something
that
we
might
be
interested
to
take
up
on
ourselves
or,
if
that's
something
that
we
would
be
interested
in
working
together
with
the
community
that
the
community
creates
it
so
yeah.
I
guess
the
best.
B
The
best
point
of
of
starting
this
process
is
always
hand
file
an
issue.
Let's,
let's
have
a
discussion
over
there
and
see
where
this
gets
us
and,
of
course,
we're
doing
the
monthly
community
meetings,
like
the
one
we're
doing
right
now.
Exactly
for
this
reason
to
basically
have
file
an
issue,
we
have
a
look
at
it,
we're
thinking
about
it,
and
then
we
can
talk
about
it
in
these
meetings.
If
you're,
if
people
are
interested,
I
was.
A
Also
going
to
say
that
we
are
looking
for
another
community
manager,
we
have
two
we're
looking
for
a
third
and
then,
as
we
grow,
you
know
kind
of
have
that
sort
of
structure,
and
last
thing
I
will
say,
is
we're
keeping
rockstars
alive.
A
So
stackrocks
used
to
have
rock
stars
like
every
month
we
have
like
a
little
swag
gift
bag,
so
people
who
contribute
who
come
on
the
calls
who
are
doing
that
stuff
will
kind
of
all
get
together
and
say:
hey,
you
know
you're
the
rock
star
of
the
month
and
maybe
you'll
get
like
a
little
well.
Actually,
the
swag's
pretty
good,
not
gonna
lie
but
yeah.
A
So
you
know,
honestly
anything
is
awesome,
even
if
you're
just
you
know,
if
you
see
something
wrong
and
you're
saying
it's
like
hey,
I'm
having
issues
applying
on
google
like
that's
great
because
yeah,
sometimes
those
things
fall
through.
D
Yeah,
I
think
those
points
for
the
community
for
some
of
the
people
who
are
going
to
listen
to
this
recording.
I
know
for
sure
at
least
one
other
group
or
project
as
actually
interested
in
looking
deeply
at
stackdrivers,
and
they
were
really
eager
waiting
for
stackx
to
go
open.
So
as
they
watch
this
they
might
have
feedback.
I
don't
know,
what's
the
best
way
for
people
to
then
leave
that
feedback
is
in
slack.
A
A
Yeah
I'll
put
a
description
with
the
notes
of
the
meeting
and
what's
it
called
I'm
blanking
on
the
word
for
it,
the
captions
and
everything
like
that.
So.
C
I'm
also
going
to
add
a
couple
of
cents
to
this,
which
is
similar
to
what
boss
has
just
said.
I
personally
am
looking
into
feedback
from
real
users
who
are
tinkering
who
are
using
or
playing,
or
maybe
thinking
about
alternatives
or
other
ways,
better
ways
to
do
things.
I'm
looking
at
this
feedback,
I
don't
care
that
much,
how
I
get
it,
whether
it's
a
issue
on
github
or
it's
a
message
in
the
slack
channel.
So
I
think
that's
something
that
I
would
be
curious
in
in
receiving.
C
So
that's
that
I
would
welcome
a
lot.
A
A
Yeah,
whenever
I
submit
a
documentation
pr
here,
it's
going
to
come
your
way.
Sure.
A
A
Cool
so
second,
tuesday
of
every
month
same
time,
hey
how's,
it
going.
I
know
one
of
the
key
contributors
to
while
I
were
open
source
in
the
first
place
spent
what
a
year
with
us
yeah.
I'm
sure
I
can't
believe
you're,
not
sick
of
us
now.
Yet
it's.