►
From YouTube: 2022-03-03 meeting
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
A
A
A
All
right,
I
guess
you
can
start
once
again
welcome
everybody
to
the
platinum
stick
meeting
with
fabio
here.
D
Oh
yeah,
my
name
is
tyler
helmuth,
I'm
from
a
new
relic
and
I'm
looking
to
get
more
involved
with
the
open,
telemetry
python
project.
A
All
right
great,
thank
you.
Welcome
to
the
licensing
meeting,
I'm
sorry
for
the
chance,
but
we
usually
when
we
have
someone
you
like
to
like
for
that
person
to
introduce.
A
D
Thanks
yeah,
I'm
glad
to
be
here
looking
forward
to
getting
more
involved.
E
All
right,
I
can
go
nuts
hit
that
like
button
I've,
I
also
work
at
lightsaber.
I've
been
with
open,
telemetry
python
for
two
and
a
half
years
previous
maintainer.
Now
I'm
an
approver
and
yeah
contribute
where
I
can.
C
Hey,
I
can
go
my
name's
aaron.
I
work
at
google.
I've
also
been
working
in
the
python
sig
for
about
two
years.
I
think
yeah
and
I'm
an
approver
feel
free
to
reach
out.
If
you
need
help
with
anything.
F
I
can
go
next
hi.
My
name
is
sanket,
I'm
from
cisco
and
I'm
working
with
I'm
contributing
to
python
agent
since
last
three
four
months
so
yeah.
G
I
can
go
next:
hey
teller,
I'm
shikhan,
I'm
one
of
the
crop
brewers.
I've
been
working
with
open
telemetry
python
for
about
one
and
a
half
years
now
feel
free
to
reach
out
to
me
I'll
come.
Thank
you.
A
All
right
great,
so
I
guess
everyone
can
see
my
screen.
Let's
go
to
the
pr's.
What
do
we
have
here?
Oh
this
period,
all
right,
so
after
many
many
reviews
and
comments
and
everything
else,
this
pr,
I
think,
has
now
three
approvals.
Oh
aaron,
you
already
approved
great
yeah.
C
A
All
right,
perfect!
Thank
you.
Well,
okay,
so
you
have
one
comment
here.
Are
there
any
other
comments
that
are
still
open.
E
A
Yeah,
okay,
I
think
we
can
I'll
take
a
look
at
this
last
comment
just
after
this
this
meeting,
but
but
I
think
that
if
there
are
any
any
other
comments,
there
should
be
related
to
small
issues
that,
in
any
case,
I
guess
we
can
fixing
in
subsequent
vr,
so
that
you
can,
you
can
get
this
one
merged.
Oh
aaron,
thank
you
for
your
approvals.
A
E
E
I
guess
the
one
thing
I
wanted
to
mention:
if
you
can
you
scroll
down
to
the
bottom,
there's
a
there's,
an
attempted
ascii
diagram,
I'm
not
sure
if
it's
making
things
simpler
or
not
for
sure,
but
I
I
was
hoping
maybe
she'll
have
a
look
at
us
and
you
can
talk
about
the
implementation.
I
know
diego.
You
also
have
some
questions.
G
Yeah,
so
I
I
looked
at
the
br,
I
I
I'm
not,
you
know.
As
of
now.
I'm
not
really,
you
know
sure,
what's
happening,
how
how
things
are
glued
up,
but
but
I
noticed
that
there
was
some
confusing
like.
If
you
go
to
the
code
right
then,
can
you
go
to
the
code
and
open
the
pull
exporter
interface.
G
Yeah,
so
this
one
was
confusing
because,
like
this,
this
resembles
the
metric
reader
interface
like
the
set
collect
callback
and
the
color
collect
definition
on
this
interface,
so
not
sure
like
so
so.
The
difference
between
the
push
metric
exporter
and
the
pull
metric
exporter
was
that
there
is
no
like.
There
is
no
point
in
introducing
force
flash
on
like
unpullmetric
exporter.
G
I
was
hoping
that's
like
similar
interface,
but
this
one
has
like
set
collect
callback
and
then
the
color
definition.
I
was
like
trying
to
make
sense
of
it
what's
happening
here
and
also.
I
think
the
exporter
is
setting
the
call
back
here.
So
so
there's
a
lot
of
like
at
least
for
me,
there's
a
lot
of
confusion
like
who
is.
Who
is
you
know
in
working?
G
What
because
push
me
in
terms
like
in
in
periodic
matrix
exporter
and
the
push
interface,
this
different
different
things
happening
on
in
full
metric
exporter,
it
it's
pretty
different,
so
yeah
yeah,
I
still
have
to
take
a
you
know,
look
at
it
again.
E
Yeah
sure
so
I
I
mean
I
can
kind
of
explain
a
little
bit
so
the
the
reason
why
it's
so
close
to
a
metric
reader
is
that
really
this
could
have
just
been
like
the
the
poll
exporter
could
have
just
been
an
implementation
of
the
metric
reader,
but
then
I
thought
that
that
would
be
really
confusing
from
a
user's
perspective,
because
you
would
have
like
you
have
to
pass
in
a
reader
to
to
your
meter
provider
and
so
passing
in
the
prometheus
reader.
E
Rather
than
passing
in,
like
a
poll
metric
reader
with
a
prometheus
exporter,
I
thought
was
more
confusing.
So
that's
why
I
added
this
poll
metric
exporter
layer
in
between,
so
that
it
would
be
like
symmetrical
the
usage
of
a
full
versus
a
push
metric
exporter
from
a
user's
perspective.
E
So
this
is
the
same
approach
that
the
net
implementation
took.
I
I
know
the
java
implementation
decided
to
go
the
other
way
around
where
they
just
have
the.
I
think
they
call
it
the
prometheus
reader
or
prometheus
controller,
or
something
like
that,
but
I,
as
a
user.
I
just
found
that
harder
to
manage
like
to
know
that.
There's
two
different
totally
different
ways
that
you
would
be
instantiating
your
metrics
pipeline.
G
Yeah
I
that
yeah,
I
think,
like
being
consistent,
makes
it
easier
for
you
know,
user
to
understand,
but
but
there's
also
another
interface
right.
You
you,
the
scholar
yeah
so
like
this
again.
So
what's
this
interface,
so
I
was
expecting
the
like
above
set
of
definitions
to
be
in
this
reader
like
there's
a
full
exporting
metric
reader
that
we
are
introducing
today.
G
Yeah,
that's
right.
G
Okay,
I
understand
why
you
needed
to
okay.
Now
I
understand
why
you
needed
to
introduce
this
thing
yeah.
It
makes
sense.
E
A
All
right
yeah,
I'm
asking,
because
I
I
I'm
having
a
little
bit
of
a
hard
time,
finding
the
difference
between
a
bush
and
a
bull
exporter,
in
the
sense
that
what
I
think
is
happening
is
that
we
call
something
a
full
exporter
when
something
external
calls,
its
export
method,
and
we
call
a
push
exporter
when
something
in
the
application
code
or
in
the
sdk
calls.
Its
export
method.
E
Yeah,
I
think
the
spec
match
mentions
this,
as
the
plummeting
exporter
reacts
to
the
up
to
the
metric
scraper
and
reports,
the
data
passively,
but
it's
it's
essentially
what's
happening.
So
the
the
poll,
the
pull
method
is
something
external
is
pulling
the
data
out
versus
a
push
where
something
internal
is
pushing
the
data
out
somewhere.
A
Correct
so
I
think
I
mean
that
then
what
is
doing
the
pushing
and
what
is
doing
the
pulling
is
not
the
exposure,
but
something
else
I'm
trying
to
say
here
is
that
it
doesn't.
G
A
What
I'm
trying
to
say
is
that
the
property
of
pushing
or
pulling
does
not
belong
to
the
explorer.
It
belongs
to
that's
something
else.
A
A
G
Yeah
you
we,
we
don't
like
that's
like,
maybe
it's
for
we're
doing
it
for
the
consistency,
but
we
don't
have
to
have
the
export
method
on
the
pull
metric
export.
A
What
I'm
trying
to
say
is
that,
if
we
agree
that
the
poor
exporters
do
not
need
the
export
method,
maybe
that
is
the
difference
between
a
pool
and
a
push
exporter.
That
one
has
an
export
method
and
the
other
doesn't.
E
A
G
It's
not
really
just
that
so
in
in
push
exporter
right
whenever
export
is
invoked,
we
like
we,
we
send
it
to
the
you
know
external,
like
let's
say
otp
exporter
right
whenever
its
export
is
called,
we
send
that
data
to
you
know
other
otlb
collector
other
destination,
but
in
in
pull
metric
exporter
right
we
receive
it
and
we
keep
it
in
memory
and
then,
when
the
scrape
job
out
of
process
scrape
job
is
invoked
right,
then
we
translate
and
then
we
send
it
to
that.
C
G
That
that's
the
good
point,
but
but
right
now
we
are
we
we
right
now.
The
implementation
is
that
we'll
be
maintaining
a
internal
okay.
C
Yeah
yeah,
I
haven't
really
read
this
pr
yet
but
I'll
take
a
look.
I
think
I've
I've
been
listening
to
what
everybody
said
and
alex
you
mentioned
the
java
way
and
just
having
it
having
this
be
a
metric
reader.
I
think
I
would
personally
prefer
that,
because
you
like
these
two
classes
here,
you
don't
really
need
them.
C
You
know
it
would
be
a
lot
simpler
to
do
it.
That
way.
I
get
what
you're
saying
about
the
asymmetry
of
like
the
naming,
I
would
say
like
you,
like,
you
also
said
it's
not
very
well
specified,
and
I
think
this
is
something
a
lot
of
people
a
lot
of
people.
Reading
the
sdk
doc
are
pretty
confused
by
so
I
would
suggest
raising
issues
with
the
spec.
C
If
you,
if
you
feel
like,
there's
better
wording
or
we
could
make
it
easier
for
users,
but
it
seems
like
the
spike
doesn't
even
say:
hey,
you
have
to
have
a
pull
metric
exporter.
It
just
says.
The
only
thing
I
think
it
specifies
is
push
exporter,
periodic,
exporting
metric
reader
and
metric
reader
right.
E
So
the
right
so
the
poll
metric
exporter
definition
here.
I
can
just
paste
a
link
in
the
chat,
but
it
essentially
says
it's
up
to
the
implementation
to
do
what
makes
sense,
whether
it's
an
implementation
of
a
separate
like
a
poll
metric
exporter,
implementation
or
if
it's
just
a
metric
reader
implementation.
E
So
it's
kind
of
vague
as
to
how
it
should
be
done.
Yeah
I
mean
this
was
really
just
my
personal
preference
that
it
was
confusing
to
me
as
a
user
that
if
I'm
trying
to
export
data
to
prometheus,
I
just
need
to
specify
a
prometheus
reader
versus.
If
I'm
trying
to
export
to
otlp.
Now
I
have
to
have
a
reader,
and
I
have
to
set
up
an
exporter
like
the
the
difference
there.
I
I
would
find
you
confusing
that
to
user,
but
maybe
I'm
maybe
that's
just
me.
Yeah.
C
E
Right
and
and
if
you
look
at
our
like
or
push
our
periodic,
our
pretty
periodic
sorry
periodic
metric
reader,
it's
basically
doing
the
export,
so
it's
yeah
yeah.
I
guess
the
if
we,
if
we're
taking
this
and
comparing
it
to
like
the
tracing
pipeline.
C
C
Sorry,
I
was
gonna
say
you
could,
in
theory
like.
I
think
this
makes
more
sense
for
something
like
otlp,
but
if
you
wanted
to
have
multiple
endpoints
you
were
sending
otlp
to.
You
would
put
multiple
exporters
with
a
single
reader
and
that
way
they
would
they
wouldn't
have
to
duplicate
all
the
memory.
You
wouldn't
have
separate
reader
pipelines,
I
suppose,
for
prometheus
or
for
a
pull
exporter.
You
could
imagine
doing
something
similar
where,
but
but
the
problem
is
that
the
thing
is
scraping.
It
will
be
different
for
each
instance.
C
E
Although
I
guess
I
guess
now
that
you
mentioned
this,
like
you
might
say,
you're
doing
some
kind
of
filtering
on
the
different
scrapers
that
you're
configuring
via
an
exporter,
then
maybe
you
would
want
to
have
a
single
reader
right,
like
you
could
imagine
applying.
I
don't
know
different
different
filters
per
exporter
and
then
you
wouldn't
want
to
replicate
your
whole.
E
E
A
Hey
when,
when,
if
we
take
a
look
at
what
is
happening
in
the
tracing
part
of
the
project,
the
exporter
seems
to
be
something
that
is
coupled
to
a
a
format
or
a
protocol,
see
for
some
there's
an
exporter
for
consensus.
There's
an
exporter
for
sipkin
exporting
for
rotlb,
but
in
metrics
we
are
doing
something
different
right.
A
We
are
coupling
the
exporter
with
an
action
with
a
pulling
or
pushing
action,
and
maybe
that's
that's
what
causing
the
the
problem,
because
we're
trying
to
do
too
many
things
at
the
same
time,
in
the
same
insane
class.
C
I
think
I
think
what
alex
said
the
span
processor
is
roughly
analogous
to
the
metric
reader
is
accurate
and
you
can
imagine
if
there
was
like
think
think
about.
I
know:
there's
no
real
pull
pull
exporter
for
spans
for
traces,
but
you
can
imagine
if
there
was
something
that
scraped
traces.
You
might
just
implement
it
as
a
spam
processor
right,
okay,.
A
A
Yeah,
that's
fine.
My
argument
is
that
maybe
we
we
and
we
I
also
include
respect.
We
should
not
mix
up
things
in
the
exporter
and
just
leave
the
exporter
to
be
the
thing
that
is
coupled
with
the
protocol.
A
So
for
metrics
we
should
probably
follow
the
same
partner
here:
exporter
from
mateo's
exporter
or
gop
exporter,
whatever
metrics
protocol
and
yeah.
G
We're
doing
that,
we're
doing
that,
but
like
we
already
have
what
will
be
exported
right
and
in
this
pr
introducing
prometheus
exporter.
So
basically
the
difference
is
that
which
interface
are
these
exporters
implementing?
So
in
otp
exporter,
that's
implementing
push
push
exported
interest,
interface,
the
prometheus
exporter,
it's
going
to
implement
the
full
exporter
interface,
or
do
we
want
to
model
it
isometric
reader?
So
that's
the
the
question
that
we
are
having
right.
A
Okay,
yeah.
Well,
I'm
I'm
saying
that
the
at
least
for
tracing
we
seem
to
couple
the
the
exporter
to
the
protocol.
A
E
H
E
E
A
A
A
Anyways,
so
do
you
folks
think
this
is
a
an
issue
which
you
raising
spec.
C
I
think
I
think
it
is,
and
if
you
have
like
suggestions
for
the
wording,
I
think
this
is
the
most
confusing
part
of
the
specification
right
now.
A
lot
of
people
have
been
confused
with
this.
Like
the
jsig
implementing
this,
I
think,
do
do
we
all
agree.
It
could
be
done
with
the
metric
reader
right
now.
C
G
Right
now,
like
almost
everyone,
is
confused,
like
with
the
reader
exporter
like,
what's
doing
what
even
like
even
like,
even
if
it's
confusing
for
the
user
like
the
prometheus
exporter,
is
modeled
as
a
reader,
I
think,
let's
document
it
right
now
implement
it
as
a
metric
reader
and
see
what
we
can
do.
D
Are
there
any
languages
in
the
project
that
have
implemented
a
poll
exporter
for
metrics
like
net
or
go
like
have
anyone?
Has
anyone
done
this
dot
net.
E
Has
they
implemented
as
a
poll
metric
exporter
and
java
has
and
they
implement
it
as
a
metric
reader.
E
E
A
I
I
am
pretty
much
okay
with
implemented
implementing
it
in
the
best
way
that
we
can
right
now
as
long
as
we
keep
that
don't
underscore
before
the
metrics
folder
name,
and
we
ask
all
these
questions
and
when
we
have
this
clarified,
then
we
can
remove
that
underscore.
A
On
releasing
this
before
those
questions
are
answered,
but
I
think
that's
not
the
case
I
mean
it's.
E
G
So
I
I
was
going
to
say
how
do
we
like
we
keep
it
to
ourselves
that
how
it
is
model,
let's
say-
and
I
I
mean
if
users
are
going
to
use
the
prometheus
export
right.
G
So
I
I
was
going
to
say
that
that
if
it's
modeled
as
a
metric
reader,
our
implementation
of
the
push
metric
exporter,
if
there,
if
there's
a
way,
we
can,
you
know,
hide
it
from
the
users.
We
can
still
later
change
that
right.
C
I
don't
think
we
can
just
because
when
they
actually
do
the
setup
part
they're
gonna
have
to
pass
a
reader,
so
so
they'll
either
pass
the
exporter
directly
or
we'll
have
to
put
like
a
a
dummy
reader
or
something
like
that.
I
mean
I
think
we
could
do
it
in
a
backward
compatible
way,
but
so
that
their
setup
will
continue
to
work
either
way
but
yeah.
I
don't
think
it's
possible
to
completely
hide
the
implementation
right
now,
because
it
has
to
interface
with
other
classes.
E
C
C
And
then
yeah,
so
right
now,
alex
has
sort
of
implemented.
The
second
ascii
art
diagram.
If
you
scroll
down
a
little
and
then
the
java
way,
which
we're
just
a
reader,
is
the
first
one
above
okay.
A
A
H
A
C
F
C
If
the
pull
exporters
model
is
metric,
reader
implementers
may
name
the
metric
export
interfaces,
push
metric
exporter
to
prevent
naming
confusion.
So
we
would
what
what's
the
exporter
name
right
now?
Is
it
push
or
just
metric
exporter
right
now,
it's
just
prometheus
metric
exporter.
C
I
meant
for
the
for
the
push
one,
the
one
that
works
for
the
periodic.
E
C
So
I
think
we're
sort
of
consistent
with
the
recommendation
there
right
now,
if
we,
if
we
just
model,
pull
as
a
metric
reader,.
E
H
H
A
E
E
Otherwise,
we're
asking
them
to
create
a
metric
creator
with
the
exporter,
which
is
current.
The
top
one
is
currently
what
we're
doing
with
the
push
version
right
is
we
have
a
periodic
exporting
metric
reader
that
we're
instantiating
with
the
exporter
that
we
pass
in
so
like
your
tlp
export
or
whatever.
A
All
right,
but
are
we
going
to
have
also
an
otlb
metric
here.
A
C
A
This
is
I
I,
I
think
I
I'm
getting
this
feeling
that
there
is
a
smell
here,
that
if
there
is
no
consistency
between
exporters
and
why
some
exporters
are
associated
with
a
protocol
and
which
others
are
associated
with
a
metric
reader,
I
think
we
can
end
up
having.
E
The
the
thing
is
so
okay,
so
if
you
were
to
use
this
method
of
creating
like
a
prometheus
metric
exporter,
that's
only
specific
to
the
protocol,
then
nothing
would
stop
you
from
using
this
exporter.
As
a
periodic
metric
exporter,
correct.
C
How
would
you
do
that
alex?
What
would
happen
I
mean
so.
E
C
E
As
someone
who's
actually
used
it,
so
what
what
ends
up
happening
is
multiple
metrics
end
up
getting
periodically
exported,
and
so
what
you
end
up
with
is
you're
like
when
you
do
scrape
the
endpoint
that
you've
registered
with
that
prometheus
metric
exporter.
You
end
up
with
like
duplicated
metrics.
C
E
So
so
right,
so
if
you
add
some
smarts,
then
yes,
you
would
do
that,
but
the
implementation
I
had
wasn't
that
smart.
So
it
was
just
like
periodically
exporting
the
metrics,
and
so
I
always
ended
up
with
just
like.
However,
many
intervals
of
periodic
exports
between
scrapes
would
be
duplicated
metrics
on
the
scrape.
C
A
C
E
But
I
don't
know
that
you'd
want
to
use
the
same
exporter
like
you.
We
have
a
separate
exporter
for
that.
C
Yeah,
I
think
the
the
other
thing
is
for
option
one.
Instead
of
calling
it
periodic
sorry.
Instead
of
calling
prometheus
metric
reader,
you
could
call
it
prometheus
metric
exporter
and
it
can
just
implement
metric
reader
like
that
way.
It's
clear
to
people
what
it
does
and
it
just
fulfills
the
interface
still.
C
E
Yeah,
I
guess
so
it's
just
if
I'm
a
user-
and
I'm
like
say
my
I'm
using
option
one
and
I
have
like
line
eight-
is
export
or
equals
prometheus
metric
exporter
and
then
line
nine
is
set
meter
provider
with
a
parameter
called
metric,
underscore
readers
and
then
passivate
my
exporter.
I
might
find
that
confusing.
E
C
E
A
All
right,
everybody
is
there
any
other
thing
that
anyone
wants
to
say
about
this
topic.
I.
E
A
Yeah,
I
am,
I
am
pretty
much
okay
with
doing
anything
right
now,
as
long
as
we
keep
that
on
their
score.
I
I
understand
that
this
is,
of
course
confusing
and
we're
just
trying
to
do
the
best
that
we
can.
So
if
you
want
to
implement
it
like
that,
well,
I
will
have
some
problem
proving,
but
I
I
do
want
this
issue
to
be
solved
and
that's
probably
something
to
be
done.
C
B
Yeah,
what
he
means
that.
A
A
Yeah,
let's,
let's,
let's
move
this
conversation
to
fbr
so
that
we
can
make
progress
there
right
now.
Of
course,.
A
All
right,
okay,
great,
let's
see
we
have
another
topic
today,.
F
I
have
one
question
so:
do
we
have
any
approximate
date
for
ga
of
metric
api.
C
So
it's
still
the
just
the
api.
I
mean.
F
C
Yeah,
it's
marked
stable.
The
specification
is
mark
stable,
but
the
problem
is
the
there's
like
a
lot
of
pr's
coming
in
that
that
add
new
things.
C
So
so
we
I
don't
know,
does
somebody
else
want
to
take
time.
A
E
When
we
just
move
the
metrics
package
from
underscore
metrics
in
the
api
to
not
underscore
metrics
and
call
it
stable,
like
I
don't
think,
there's
a
different
version
numbers
that
need
to
be
released.
I
think
they
would
still
be
the
same
versions
as
just
the
path
would
be.
You
know,
identified
and
stable
or
whatever.
A
Yeah,
what
I'm
trying
to
say
is
that
in
theory,
we
should
be
able
to
do
that
by
to
just
release
the
api
and
not
release
the
sdk.
A
E
Yeah
I
mean,
I
think,
the
next
release
one
110
should
have
everything
marked
that's
still
like
private
packages
or
whatever,
and
I
feel
like
that's
the
release
that
we're
gonna
get
the
most
feedback
on
on
the
apis.
If
anything
doesn't
make
sense
and
then
the
following
release
might
be
the
one
where
we
actually
move
the
api.
C
G
F
Basically,
we
are
interested
in
sdk,
sorry
for
long
questionnaire,
so
when
the
sdk
will
be
ready
for
us
to
use,
I
mean.
F
Any
any
idea
about
the
approximate
one
timing
in
next
quarter
or
just
to
get
some
ideas.
C
There's
a
pull
request
open
to
do
this
sorry,
go
ahead.
I'll
find
the
request.
Somebody
else
can
try
to
answer
it.
E
You
know,
there's
a
spec
there's
a
sorry,
not
a
spec
meeting,
but
I
know
there's
a
meeting
on
fridays
at
8
30
in
the
morning
in
the
open
telemetry
calendar
around
specifically
bringing
ga
or
bringing
metrics
to
ga.
F
Sure
I
have
another
question
so
do
we
as
of
now
we
do
not
have
instrumentation
support
for
the
first
library.
So
do
we
have
anything
in
our.
A
F
Yes,
yes,
yes,
so
I'm
not!
I
don't
have
any
idea
about
how
do
we
provide
how
basically
to
provide
support
for
us
with
the
framework,
because
I'm
new
here
so
just
asking
so
there
is
a
library,
I
think
stream
processing
library
called
fast
fa.
F
One
of
our
internal
team
needs
the
instrumentation
support
for
that.
So
I
was
just
wondering
if
we
have
anything
in
plan
for
that
anything
in
the
near
future.
A
Yeah,
well
usually,
what
we
do
is
that
or
actually
usually
what
happens
is
that
people
who
know
libraries
or
frameworks
better
they
create
the
instrumentation.
They
just
open
up
the
art.
A
And
then
we'll
accept
it
after
everything
looks
okay,
if
you,
if
you
like
it,
please
feel
free
to
to
open
an
apr
that
includes.
C
A
C
A
I'm
just
okay:
well,
I
think
we
are
done
with
the
with
the
topics
this
course
here.
So
I'll.
D
Throw
one
more
out
before.
D
I
recently
got
my
dev
space
set
up
and
made
some
quick
contributions
earlier
this
week
I
have
some
troubles
with
an
m1
mac.
I'm
gonna
have
to
dig
into
those
a
little
deeper.
I
saw
discussion
and
github
around
improving
my
contribution
guides
and
and
work
set
up
and
all
that
kind
of
stuff.
D
I
think
I'm
gonna
try
to
poke
back
into
that
a
little
bit
and
focus
on
some
of
that
in
the
coming
weeks,
just
because
it
wasn't
a
great
experience
for
me
getting
things
set
up
and
like
figuring
out
some
of
the
commands
with
linting
and
all
that
stuff.
So
I
guess
just
a
heads
up
that
I'm
going
to
be
poking
at
some
of
that
going
forward
right.
C
Yeah,
that's
awesome.
Thank
you.
I
have.
I
have
one
recommendation.
There
sure
I've
done.
I
did
this
in
a
different
repository,
but
you
can
use
talks
to
actually
make
like
a
you.
Could
change
the
virtual
environment
path,
so
you
can
make
like
a
target
that
creates
the
dev
environment
with
talks.
So,
instead
of
having.
C
C
D
Wait
so
yeah.
I
noticed
that
there
was
that
each
disc
script
like
there's
a
whole
folder
of
scripts,
and
I
think
I
even
saw
an
issue.
Maybe
it
was
in
the
discussion.
Someone
said
that
this
could
be
done
with
talks.
D
Is
there
a
thought
that
talks
could
replace
that
directory
like
entirely
or
there's
just
certain
sections
of
that
directory?
We
could
replace.
D
A
All
right:
well,
if
there
are
any
other
topics,
I
guess
we
can
call
this
a
meeting
and
we
can
see
your
next
week.
Hopefully.