►
From YouTube: Building a Community: How Cortex Went from a Vendor Project to a Community - Goutham Veeramachaneni
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Building a Community: How Cortex Went from a Vendor Project to a Community - Goutham Veeramachaneni, Grafana Labs
In 2018, Cortex was largely vendor-driven, and almost no one other than maintainers could run it. Its docs were lacking; you had to read the code instead. While that might be acceptable for a new project, it's not for wide adoption. Over the last few years, since joining the CNCF, we have put a focus on building a vibrant community. It was a long and arduous journey, but we're very happy with the healthy community we have today, with maintainers from 5 different companies and a 5x increase in activity on the Cortex Slack and GitHub! While our _public_ adopters document lists more than 15 companies, with several providing Cortex as a service, we have a lot more companies running it, from international banks and Fortune 50 enterprises to small startups. In this talk, we will walk through the key changes we made and how our philosophy on community-building helped us thrive and led to fruitful collaboration with sibling projects Thanos and Prometheus.
A
Hello,
everyone
thank
you
for
coming
to
my
talk,
how
cortex
became
a
community.
This
is
a
talk
that
I'm
really
passionate
about
yeah,
let's
just
dive
in
so
I'm
gautam,
I'm
a
senior
software
engineer
at
grafana
labs
and
I've
been
involved
in
the
prometheus
community.
For
about
five
years
now
I
started
off
using
prometheus.
A
I
was
also
one
of
the
initial
co-authors
of
grafana
loki,
a
log
aggregation
system
inspired
by
prometheus
and
cortex,
and
I've
seen
loki
go
from
launch
to
a
huge
community,
a
huge
user
base
and
yeah.
That's
that's
pretty
interesting
cool
before
we
dive
into
it.
I
just
want
to
cover
a
little
bit
about
cortex
and
the
history
of
cortex.
A
A
We
was,
we
was
creating
weave
cloud
and
they
wanted
to
give
all
their
users
a
hosted,
prometheus
solution,
so
it
started
out
by
at
weaveworks
it
had
a
few
early
adopters
in
ea
maya
cloud
and
a
couple
of
others
and
then
later
grafana
labs
started,
contributing
to
prometheus
started,
offering
a
hosted
prometheus
solution,
and
today
it
is
being
run
by
tens
of
companies.
I
think
I
know
of
25
companies
that
are
running
running
cortex
and
it
is
powering
their
mission,
critical
monitoring
systems
cool.
A
With
that
context,
I
want
to
go
into
a
little
numbers,
so
contract
started
off
somewhere
in
2016,
I'm
not
even
going
to
cover
that
graph.
Let's
start
somewhere
in
end
of
2017,
and
you
can
see
it's
pretty
flat,
but
in
the
recent
years
there's
been
a
huge
spike
and
the
community
has
been
growing
over
time.
A
This
becomes
a
lot
more
apparent
if
you
look
at
the
number
of
contributors
that
are
contributing
every
month,
so
it
was
roughly
around
10
contributors
and
then
in
2019,
once
we
joined
the
cncf,
it
started
going
up
and
there's
been
a
huge
spike
and
in
jan
2021
we
had
75
unique
contributors
in
that
month,
which
is
kind
of
crazy.
To
be
honest,
and
I
really
absolutely
love
this
growth,
we
also
have
a
huge
growth
in
the
adoption.
You
can
see
this.
A
So
why
this
stock?
If
you
see
the
numbers,
the
numbers
are
actually
not
that
big,
but
we're
actually
pro
quite
proud,
proud
of
the
numbers
we
have
and
the
adoption
that
we
saw
and
over
time,
we've
experimented
with
a
lot
of
things,
and
we've
noticed
that
some
things
contributed
a
lot
to
the
growth,
while
some
other
things
did
not,
and
we've
tried
to
do
the
same
thing
with
loki
and
we
saw
incredible
adoption
in
loki
and
over
over
time.
I
think
I
had
this
playbook
in
my
mind
as
to
okay.
A
What
should
open
source
projects
do
if
they
want
to
have
more
users,
have
more
maintenance,
have
more
adoption,
and
I
was
talking
to
a
couple
of
friends
of
mine
who
were
involved
with
the
newer
stage,
open
source
projects
that
were
kind
of
struggling
to
build
adoption,
and
while
I
was
giving
them
tips,
I
realized
that
I
could
give
a
full
talk.
That
would
be
useful
for
more
open
source
projects
and
by
no
means
we're
not
experts
at
this.
A
We're
still
learning
a
lot
about
how
to
build
communities,
and
this
is
just
a
subset
of
the
items
that
I
think
are
important.
If
you
know
of
other
items
that
you
think
are
important,
please
share
them
with
me.
After
this
talk,
I
would
I
would
love
to
write
a
blog
post
or
a
live
doc
as
to
what
open
source
projects
can
do
cool
with
that
context.
Let's
dive
in
so
this
is
going
to
be
obvious.
Documentation
will
break
or
make
your
project.
A
You
can
build
the
best
open
source
system
in
the
world,
but
if
you
don't
have
good
documentation,
nobody
will
use
it.
This
is
obvious
right,
but
turns
out.
We
actually
didn't
do
a
good
job
of
it
until
quite
recently,
so
we
had
docs,
they
were
all
in
github.
You
had
to
click
through
md
files
to
kind
of
figure
out
where
they
are,
they
didn't
have
a
proper
structure
and
we
did
not
have
a
website
until
december
2019
and
in
december
2019,
one
of
the
loki
maintainers
cyril,
who
was
also
contributing
to
cortex.
A
We
we
kind
of
redid
our
we
docs
a
lot
more
structure
and
once
we've
launched
a
website
with
proper
docs
docs,
we've
got
a
lot
of
feedback
that
it's
like.
The
change
like
the
usability
and
adoption
story
is
like
night
and
day
people
who
were
struggling
to
use
cortex
before
found
it
much
more
easier
to
adopt
and
they
were
loving
the
new
website.
So
if
your
project
doesn't
have
a
website,
add
a
website
make
sure
the
website
has
a
search
bar,
because
people
will
use
it
and
yeah.
A
One
of
the
first
things
you
need
is
a
getting
started
guide,
make
sure
you
have
a
very
simple,
very
easy
to
use.
Getting
started
guide
that
lets.
People
install
the
system
on
their
laptop
play
around
click
around
and
also
make
sure
to
include
a
production
and
troubleshooting
guide.
The
production
guide
will
tell
them
okay.
This
is
how
much
you
need
to
provision
this
is.
This
is
like
for
this
scale.
These
are
the
tweaks
that
you
need
to
do
and
things
like
that,
while
a
troubleshooting
guide
will
be
like.
A
Oh,
if,
if
you're
not
seeing
any
of
your
metrics
look
at
these
numbers
or
look
at
these
logs-
and
maybe
this
is
the
issue
so
simple
faq,
based
based
on
the
common
request
that
you
get
or
common
errors
that
you
get,
that
would
be
quite
nice
if
possible.
If
you
can
have
a
proper
page
with
the
config
file,
that
is,
that
describes
the
config
file.
What
are
the
different
options
that
you
can
browse
and
search
through?
That
would
be
super
helpful
for
users.
We,
we
did
some
good
job
automating.
A
The
generation
of
this
page
from
the
config
object
that
we
have,
and
that
page
has
been
the
go
to
page
for
a
lot
of
people.
So
if
you
can
do
that,
that
would
also
be
nice
so
basically
put
the
man
page
in
the
browser,
yeah
cool,
so
documentation
is
important
again
make
sure
you
have
all
these
guides
and
make
sure
you
have
a
website.
A
So
before
may
2019,
if
you
open
the
cortex
website,
it
would
show
you
this
architecture
diagram.
So
now
this
is
a
lot
of
moving
parts
and
a
lot
of
dependencies
like
you
have
to
depend
on
a
nosql
store
like
cassandra
or
bigtable,
a
console,
a
memcached
and
possibly
even
an
object,
stores
and
there's
like
a
lot
of
these
moving
parts.
A
And
if
you
are
looking
for
a
long-term
storage
solution
for
prometheus-
and
you
look
at
this
diagram,
you
would
be
immediately
discouraged,
but
that
was
the
reality
of
cortex
and
there's
a
good
reason
why
the
cortex,
the
cortex
architecture
is
this
way.
It's
so
disaggregated.
Cortex
runs
at
massive
scale.
We
handle
20
million
samples,
a
second
we
ingest
and
compress
them,
and
we
need
to
make
sure
that
every
single
component
that
we
are
running
is
highly
available
and
horizontally.
A
Scalable,
there's
a
reason
why
every
one
of
these
components
exists
and
we've
added
one
more
component
recently,
because
the
query
front
end
need
needed
some
additional
features
and
needed
to
be
scalable
cool.
So
with
that
in
mind,
let's
go
back
a
little
bit
to
understand
how
loki
was
built.
A
lot
of
loki's
coding
was
was
done
on
transatlantic
flights,
so
essentially
one
of
the
one
of
the
reasons
that
cortex
didn't
work
or
like
the
cortex
was
a
little
hard
to
adopt,
is
or
a
little
hard
to
contribute
to
was
the
development
process.
A
Was
you
you
make
your
changes?
You
write
tests
for
it,
you
make
sure
all
the
tests
pass
and
then
you
have
to
deploy
it
to
a
remote,
dev
environment.
In
the
cloud
this
means
the
dev
cycle
was
slow
and
if
you
did
not
have
a
dev
environment
setup,
it
was
kind
of
hard
to
contribute,
but
for
loki's
case
we
made
sure
all
of
loki
runs
as
a
single
binary.
You
do
dot,
slash
loki
and
it
just
simply
works,
there's
no
dependencies.
A
It
works
off
of
your
file
system
and
you
can
test
and
play
around
with
loki
on
your
laptop
this
airplane
mode
or
simplicity
of
loki,
and
it's
the
same
for
prometheus
was
a
huge
part
of
why
loki
was
super
like
was
adopted
widely,
and
we
we've
learned
from
that,
and
we
focused
on
two
things:
one
making
cortex
much
simpler
to
run
and
reducing
the
dependencies
that
cortex
has
today.
If
you
look
at
the
cortex
architecture,
it
looks
something
similar
to
this,
so
you
do
dot,
slash
cortex,
you
don't
need
to
run
10
different
microservices.
A
All
the
microservices
sit
in
a
single
binary.
You
can
run
multiple
replicas
of
it.
We
use
gossip
to
communicate
between
these
replicas,
so
you
don't
need
a
console
or
an
cd
and
we
don't
even
need
a
nosql
store
anymore.
So
we
just
write
directly
to
an
object,
store
object,
stores
are
really
cool
because
one
they're
inexpensive
and
two
there's
virtually
zero
configuration
that
you
need
to
do
so
when
we
made
these
changes.
A
So
if
you
are
an
open
source
project,
make
it
really
simple
to
run
just
do
just
create
a
single
binary
or
a
single
single
point
of
entry,
where
people
can
just
run
that
thing
and
everything
is
just
working
and
try
to
reduce
the
number
of
external
dependencies
that
your
project
has
so
one
of
our
adopters
of
trace.
They
wrote
a
blog
post
on
why
they
adopted
cortex
and
they
were
like.
A
Yes,
we
were
looking
at
possible
solutions
and
we
realized
that
cortex
needed
to
use
a
database
like
dynamodb
or
cassandra,
but
then
one
of
our
community
members
he
came
in
and
contributed
a
new
storage
engine
based
off
our
sister
project.
Thanos
that
uses
simply
object,
storage
and
we
spent
a
year
optimizing
the
engine,
contributing
to
thanos,
contributing
to
promet,
prometheus
and
cortex.
To
make
sure
that
now
cortex
only
depends
on
an
object
store.
This
has
increased
our
adoption
massively,
so
yeah
simplify
running
your
system,
there's
a
good
reason.
A
Cortex
has
all
those
micro
services
at
the
scale
that
we
run.
We
still
need
a
lot
of
those
micro
services,
but
for
a
lot
of
lot
of
people,
they
don't
have
that
scale
and
they
can
run
a
much
simpler
version
of
cortex.
So
if
you
can
simplify
your
project
that
way
try
to
do
so,
it
will
improve
adoption
and
also
it
will
make
things
easier
to
develop.
It
will
also
improve
contributions
yeah,
so
one
more
thing
I
do
want
to
cover
is
be
accessible.
A
So
what
does
this
mean?
So
I
have
a
huge
issue
with
slack
for
community
support.
The
problem
with
slack
is
people.
Ask
you
a
question,
you
answer
it
and
then
20
days
later,
when
someone
else
has
the
same
question,
they
would
ask
it
again.
You
would-
and
you
would
answer
it
again,
so
there's
no
searchability
here,
a
google
group's
mailing
list
is
really
good,
which
is
what
we
use
in
prometheus.
Basically,
when
somebody
asks
a
question,
you
answer
it:
it's
persisted
on
google,
so
next
time
somebody
googles
the
same
error
or
same
issue.
A
They
will
find
your
answer.
So
while
that
is
really
cool,
when
your
project
is
just
starting
out,
it's
really
important
that
you
have
a
sync
chat
system
like
something
like
slack,
and
this
is
even
true
for
prometheus
when
I
was
using
prometheus
five
years
ago,
when
it
was
point
eight
or
something.
I
initially
asked
my
question
on
the
mailing
list.
I
got
an
answer.
A
The
answer
was
not
very
clear,
so
I
immediately
jumped
on
to
irc,
which
is
what
prometheus
uses
to
use
this
for
community
support,
and
I
started
asking
people
the
maintenance
there
questions
about
it
and
they
could
immediately
answer
without
the
latency
of
using
a
meaningless
and
that
basically
helped
me
fix
my
prometheus
issues
and
that
also
helped
them
understand
some
of
the
common
problems
people
were
facing.
So
if
you
can
have
a
sync
chat
system
combined
with
a
mailing
list,
do
that?
A
Maybe
10
to
15
percent
of
your
time
will
going
will
go
into
answering
these
questions.
It's
important
and
you
will
be
doing
it
for
a
few
months,
but
you
will
be
giving
the
community
such
a
good
experience
that
once
they
have
your
system
up
and
running
they're
going
to
stick
around
and
answer
questions
because
that's
they
want
to
contribute
back
and
that's
the
easiest
way.
They
could
contribute
back
so
yeah
in
in
the
initial
months
when
you
launch
or
if
you're
a
newer
project
spend
some
like
spend
a
decent
amount
of
time.
A
The
other
thing
I
want
to
mention
is
have
regular
office
hours
or
a
community
call
where
the
maintainers
just
jump
on
for
30
minutes
for
an
hour,
whichever
works
for
you
and
they
they
give
the
highlights
like
what,
what's
in
the
new
release,
what
are
the
new
bugs
that
we
fixed
then
open
up
for
questions
from
the
community,
so
this
is
really
important
for
the
community
to
have
to
have
a
space
where
they
can
directly
talk
to
the
maintainers
with
their
weekly,
the
video
on
and
yeah.
I
would
like.
A
I
would
highly
suggest
that
every
project
that
doesn't
have
a
community
call
make
a
community
call
that
is
30
minutes
at
least
a
month
at
least
once
a
month.
So
that's
that's
really
useful.
In
cortex
we
have
one
one
every
three
weeks
and
we
have
new
users
jumping
on
all
the
time
telling
us
about
their
use
cases,
and
we
also
have
all
the
maintainers
from
different
companies
and
time
zones
who
are
talking
about
different
issues
that
they're
seeing
and
potential
fixes.
A
A
So
the
reason
for
this
is
people
who
are
using
your
project.
They
will
keep
seeing
these
updates
and
they
will
probably
join
a
few
more
few
times
later.
If
you
cancel
the
calls,
because
there's
no
agenda,
people
like
people
won't
realize
that
there's
even
a
call-
and
this
30
minutes
just
hang
out
with
your
maintenance
and
talk
about
random
stuff.
If
nobody
shows
up
but
yeah
try
to
have
a
regular
office
hours
community
call
so
yeah.
The
other
thing
I
want
to
mention
is:
we
are
doing
one
for
tempo
and
the
initial
thing
times.
A
So
this
is
another
big
thing
dedicate
time
for
outreach,
so
by
outreach
I
mean
make
some
noise
about
like
do
some
marketing
for
your
project,
like
don't,
do
vendor
marketing
but
like
market,
your
project
right,
regular
blog
posts
like
write
a
blog
post
every
month,
if
possible
and
share
them
on
social
media.
Twitter
is
a
good
medium
for
this.
Now
you
might
wonder:
hey
like
what
blog
post
should.
A
I
write
like
write
about
the
new
features
that
came
up
in
the
last
month
or
like
if
there
was
a
release
right
about
what's
new
in
the
release,
why
that
release
is
important
or
if
you
found
some
nice
performance,
optimization
write
about
the
performance
optimization,
just
like
so
many
things
that
you
can
write,
write
about
different
use
cases.
People
can
use
your
project
with
but
make
sure
you
continuously
ship,
like
ship
blog
posts
out
about
your
project.
A
This
is
because,
in
the
future,
people
are
going
to
google
about
their
problems
and
if
you
say
so,
people
are
going
to
google
about
multi-tenancy
in
prometheus
and
I'm
pretty
sure,
there's
like
five
or
six
blog
posts
that
that
we
wrote
about
cortex
that
are
going
to
show
up
so
they're
going
to
read
about
cortex
and
then
they're
going
to
try
things
out.
So
yeah
always
try
to
publish
a
lot
of
blog
posts.
A
This
way,
it's
not
just
you,
but
your
community
is
also
empowered
to
talk
about
the
project
that
they
really
like
about,
and
one
of
the
things
that
we've
done
at
grafana
labs.
That,
I
think,
is
super
cool
and
worked
really
well.
Is
we
have
an
okr
to
publish
a
blog
post
or
a
talk
per
quarter,
so
this
essentially
means.
If
you
have
a
team
of
three
people,
you
already
have
a
a
blog
post
or
a
talk
per
month,
which
is
really
cool.
A
So
if
you
can
have
okrs
that
that
that
have
to
do
with
outreach,
try
to
like
yeah
try
to
try
to
add
the
okrs
and
try
to
see
how
that
would
work,
yeah,
so
yeah.
So
the
good
thing
about
cortex
is
it's
just
not
one
company
who
is
using
it
so
like
a
lot
of
companies
are
using
it,
and
each
of
them
is
a
writing
cortex,
blog
post,
which
are
really
nice.
Here.
A
We
have
an
example
of
a
blog
post
from
v
works,
one
from
aws
and
one
from
grafana
labs,
and
you
can
kind
of
see
all
the
different
ways
or
all
the
different
kinds
of
blog
posts.
This
is
a
the
first
one
is
about
a
performance
optimization.
This
is
about
the
aws's
journey
of
adopting
cortex
and
where
the
third
one
is
like,
what
did
we
do
in
cortex
in
2020.
A
So
one
of
the
things
that
I
really
like
to
do
is
work
closely
with
a
few
users.
So
this
gives
you
a
lot
of
insight
and
it
helps
you
kind
of
improve
the
project
a
lot.
So
what
do
I
mean
by
work
closely
if
possible,
have
a
weekly
call
with
the
user?
So
this
can
be
right
after
you
launch
and
you're
struggling
to
find
adoption,
and
you
find
a
user
who
is
like
super
seriously
wanting
something
like
your
project
or
wanting
to
try
that
project.
A
If
they're
super
keen
on
it
set
up
weekly
calls
with
them
see
what
they're
struggling
with
and
prioritize
their
their
requirements
over
yours,
if
possible,
even
create
a
shared
slack
channel
because
they
might
be
trying
it
at
different
times
and
if
they
can
have
like
access
to
you
over
dms
or
a
slack
channel
or
like
a
sync
communication
channel.
That
would
be
super
useful
and
this
will
actually
help
you
build
the
right
product.
A
I've
done
this
a
couple
of
times
for
a
couple
of
projects,
and
this
need
not
be
even
right
after
you
launch
your
project.
Let's
say:
you're
working
on
a
large
feature,
a
huge
change
or
or
a
huge
performance
optimization,
and
the
kind
of
problems
that
you
have
are
different
from
the
problems
that
users
have.
So
whenever
we're
doing
something
big,
we
try
to
find
a
beta
user
who
would
want
who
would
be
okay,
testing
it
out
in
their
environment
and
giving
us
regular
feedback.
A
One
caveat
is
make
sure
the
end
user
that
you're
working
with
is
as
invested
as
you
are.
You
might
be
wanting
to
help
them
but
like
they
might
not
have
the
bandwidth
to
do
this.
So
it's
it's
kind
of
really
hard
to
find
this.
This
is
why
I
like
meetups
and
conference
talks
where
especially
meetups
you
give
this
talk,
and
then
you
you
likely
find
one
person
who's.
Like
super
keen
into
trying
this
testing
this
because
they
have
the
same
problem
as
you,
it
also
happens
in
conferences.
A
For
example,
I've
done
this
with
gojek
gojek
is
an
indonesian
company,
but
it
has
offices,
engineering
offices
in
india,
and
I
gave
a
conference
talk
talking
about
cortex
and
they're,
like
oh
we're
having
this
issue
with
scaling
influx
db,
and
we
really
want
to
try
cortex.
So
it's
like
hey.
This
is
amazing.
I
really
want
to
help
you.
Can
I
come
to
your
office
to
give
you
like
a
tailored
presentation
and
to
kind
of
look
at
your
problems,
so
they
said.
Yes,
I
visited
their
office
a
couple
of
times.
A
They
had
a
direct
connection
to
me
and
as
they
were,
adopting
cortex
we
had
to
improve
our
documentation,
publish
some
of
our
configs
to
kind
of
fix
issues
at
scale,
and
things
like
that,
and
I
had
a
lot
of
fun
working
closely
with
the
team
and
improving
the
documentation
and
the
adoption
story
over
a
couple
of
months
and
one
of
the
really
cool
things
is.
This
is
ankit,
you
see
in
the
picture.
A
He's
part
he
was
part
of
the
gojek
team,
and
now
he
shifted
from
gojek
to
a
company
in
berlin
and
he
moved
to
berlin,
and
now
we
are
really
good
friends
and
we
hang
out
all
the
time
like
open
source.
Helped
me
made
a
lot
make
a
lot
of
friends
and
unkit
is
just
one
like
one
of
those
amazing
friends
I
made
through
open
source,
which
is
super
cool
yeah.
A
So
that
brings
me
to
my
final
final
piece
of
advice
is
do
case
studies
so
basically
case.
Studies
are
documents
where
end
users
outline
the
problems
that
they
faced.
What
were
the
requirements
they
had
for
the
solutions?
They
were
going
to
pick
why
they
picked
your
project
or
why
they
picked
cortex
and
how
they
can
like
what
were
the
challenges
they
they
faced
and
how
they
overcame
them
and
what
is
like
what
benefits
did
cortex
or
your
project
gave
them
so
we've
we
have
a
few
case
studies.
A
We
have
actually
three
more
in
the
pipeline
that
I'm
going
to
publish-
and
these
are
super
useful
because
turns
out.
Other
people
read
the
case
studies,
so
the
first
one
we
did
was
go
check
and
we
have
a
couple
of
users
who
read
the
gojek
case
study
who
were
struggling
with
influx
as
well,
so
they
so
they
read
the
thing
and
they're
like
oh,
this
is
great.
A
A
Having
said
that,
make
it
really
easy
for
them.
So
essentially,
if
you
ask
an
end
user
to
write
a
case
study,
it
most
likely
won't
ever
happen.
So
what
we
do
is
we
jump
jump
on
a
call
with
them.
We
have
a
technical
writer
interview
them
based
on
a
template
that
we
create,
we
record
it,
and
then
we
actually
do
the
write
up
ourselves
and
then
share
it
with
that
company
once
the
end
user
has
sign
off
from
legal.
We
publish
it.
A
A
That
would
be
much
easier
for
the
end
users,
and
your
first
case
study
like
having
one
case
study,
is
actually
much
much
better
than
having
no
case
studies
and
if
you
already
have
companies
that
you're
working
closely
with
try
to
use
them
for
the
first
case,
study
one
caveat
is
make
sure
that
the
case
study
is
approved
by
the
company's
legal
and
legal
team.
Before
before
you
do
the
case
study,
because
sometimes
the
person
who's
who's
running
your
software
might
be
really
interested
to
do
a
case
study.
But
it
might
not
have
the
right
approvals.
A
Cool
yeah
and
continuously
encourage
your
end
users
to
submit
conference
talks
and
to
write
blog
posts.
End
user
talks
are
much
more
appreciated,
have
more
a
lot
more
nuance
than
vendor
or
maintenance
stocks.
So
again,
I
want
to
reiterate,
if
you
have
a
cortex
one
on
one
deck
ready,
that
would
also
be
super
useful
for
end
users.
It
will
just
reduce
the
amount
of
time
they
put
in
cool.
A
Have
a
sync
communication:
channel:
have
a
community
call
have
office
hours
and
yeah
spend
a
significant
amount
of
time,
20
percent
at
even
to
work
on
community
and
outreach
right
blog
post?
This
is
how
you're
going
to
get
an
option
work
closely
with
a
few
users
to
refine
your
product
and
your
features-
and
this
is
like
these
users
will
become
champions
for
your
product
in
the
future
and
that
will
drive
more
adoption
and
yeah
leverage,
leverage
the
end
users
to
generate
more
content
and
make
sure
to
have
some
case
studies.