►
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
Okay,
we're
returning
who
this
is
ace.
Existing
breakout
today
is
3/4,
and
here
it's
talking
about
get
up,
I
shot
a
link
to
a
document
in
which
I
will
try
to
take
some
notes
into
the
chat,
and
could
somebody
quickly
show
if
they
have
it
open.
A
Cool
I
think
it's
probably
reasonable,
just
to
try
to
start
at
the
top
of
calls
out
and
just
quickly
run
through
these
topics
and
comment
on
the
first
thing
that
he
put
in
here
that
ended
up
sending
us
a
bunch
of
weird
events
and
causing
some
interesting
behavior
on
our
end
was
a
quarantine,
PR
I
think
from
a
account
that
got
suspended
force
yeah
ended
up,
sending
an
incredible
amount
of
these
github
st.
close
events
and
so
I.
Think
in
general,
there's
a
little
bit
of
leakage
of
these
undocumented
things
that
happen.
Sometimes.
B
Yeah
we
called
we
call
those
because
of
spammy
users,
so
when
you
request
information
about
them
via
the
API
you'll
get
404
x'
and
it
will
look
like
them
and
the
resources
that
they've,
created
and
stuff
like
that
won't
exist.
That
does
leak
right
now
in
web
hooks
and
a
couple
other
places
I
think
they
can
still
trigger
them
to
be
sent.
So
that's
definitely
an
open
bug.
I
can
confirm
that
more
or
less
and
something
that
we
can
probably
fix
next
few
months.
I
would
guess.
B
A
This
one
specifically
tied
as
a
controller.
The
way
that
works
is
periodically
it'll
issue
a
graph
QL
query
to
grab
the
state
of
the
world,
then
it
processes
it
doesn't
match
of
other
actions
afterwards,
on
startup
tied
is
doing
a
little
bit
more
of
those
queries
than
usual
and
we're
actually
timeboxing
the
queries.
A
A
We
hit
this
at
least
abuse
detection
mechanism
every
single
time,
and
so
we'd
like
to
know
if
there's
something
that
we
could
do,
that
would
not
happen
because
we
I
think
this
doesn't
actually
end
up
impacting
us
too
badly,
because
we
only
end
up
missing
some
events.
That
happened
during
the
redeployment,
but
it
would
be
great
if
we
could
and
we're
not
yeah.
A
B
Got
a
few
abuse
like
we've
got
I
think
it's
like
about
half
a
dozen.
What
would
be
really
useful
for
me,
is
you
wouldn't
happen
to
know
like
how
does
the
type?
How
does
the
user
query
the
API?
Is
it
an
OAuth?
App
does
use
a
personal
access
token?
Is
it
a
github?
App
I
can
probably
come
back
and
tell
you
the
exact
which
one
of
the
abuse
rate
limiters.
It's
hitting.
B
So
one
thing
that
you
might
be
too
spaced
out
and
thumbs
up
the
time
window
a
little
bit
or,
if
there's
multiple
theories
being
involved,
just
space
them
out
a
little
bit
more
about
starting
up,
but
I
can
definitely
take
a
look
and,
at
the
the
specific,
like
the
actual
specific
requests
and
errors.
I
just
need
to
see
the
like
I,
you
know
like
the
OAuth
ID
or
the
bat
ID
or,
however,
it
actually
requests
a
github
API,
so
I
mean
this
is
actually
maybe.
A
Something
we
can
talk
about
right
afterwards,
so
we're
only
using
personal
access
tokens
I
think
only
because
of
history.
I
think
that
was
the
only
thing
available
to
us
at
the
time
that
we
started
the
project.
So
a
better
understanding
of
what
you
guys
expect
from
API
users
would
be
would
be
super
cool
for
that,
but
yeah
so
we're
using
personal
assistance
for
all
these,
and
it
makes
sense
that
this
because
of
the
query,
because
it
asks
for
every
change
since
the
date
at
the
time
would
take
a
lot
of
time.
B
Personal
access,
token
is
definitely
interesting.
If
you
want
to
I
guess,
that's
gonna
follow
up
acing
to
I,
be
curious,
but
user
the
Pat
is
under
that's
you
know,
I'll
bill,
what's
recorded
in
our
logs
in
the
database.
I
would
definitely
recommend
and
going
for
a
github
app
here
if
possible
can
have
apps.
Are
nice
they're
first-class
actors
against
the
kind
of
the
github
system,
so
you
install
them
on
an
on
a
list
of
repositories
or
on
a
user,
and
then
they
kind
of
exist
without
needing
an
actual
user
to
off
against.
B
So
it's
like
a
user
leaves
or
whatever
the
github
back
stays
installed
and
is
attached
to
that
repository.
So
it
kind
of
allows
you
to
not.
Like
you
know,
one
users,
Pat
is
a
much
box.
You
know
the
real
Italy
will
be
collated
and
stuff
like
that.
It's
a
much
cleaner
authentication
method
and
also
makes
it
a
lot
easier
to
debug
stuff
like
this
and
added
bonus,
is
that
every
installation
of
you
can
have
application.
B
D
Given
that
prow
sort
of
deployed
by
potentially
a
bunch
of
different
people,
how
would
you
think
that
how
do
you
have
a
recommended
way
for
us
to
integrate
with
that?
There's
not
just
like
one
proud
deployment
like
you
know,
the
CNCs
prow
is
one
instance,
but
like
Steve
has
a
different
one.
The
Red
Hat
and
you
know,
there's
probably
10
or
20
of
these
throughout
the
various
locations.
Oh
interesting.
B
So
we
do
have
often
take
up
the
documentation
because
an
app
the
actual
app
app
there's
there's
a
few
options
right.
It
depends
on
I
think
the
level
of
trust
you
could
have
every
proud
deployment
create
its
own
github
app.
Those
are
like
heavy
records.
Those
belong
to
a
user
similar
to
an
OAuth
application.
We
have
a
support
promoter
called
app,
manifest
I
believe
which
are
basically
a
template.
You
can
use
to
a
machine
create
again
have
apps
like
that.
A
deployment
process
can
be
very
easy
for
creating
additional
github
apps.
B
If
that's
what
we
need.
Alternatively,
it
have
apps
support.
The
primary
method
of
authentication
is
public,
private
key,
so
and
github
app
supports
multiple
keys.
The
problem
is
that,
like
every
Sherri's
has
access
to
all
of
the
installations.
So
if
you
don't
want
the
you
know,
proud
version,
or
instance
a
over
here
to
be
able
to
get
the
repository
information
for
the
install,
for
instance,
see
what
you're
probably
looking
at
is
creating
one
github
app
per
like
trust,
namespace,
more
or
less,
and
that
can
be
automated
fairly
easily
it's
nice.
B
Also
because
again
it's
one
user
owns
the
app,
but
the
app
install
itself
is:
is
user
independent
and
exists?
Is
a
first-class
actor
and
stuff
like
that?
So
the
you
know,
the
the
app
comments
leaves
a
comment.
For
example,
it
shows
as
the
app
commenting
and
not
the
user
that
it's
commenting
through
so
it's
kind
of
a
replacement
for
machine
accounts,
and
it's
got
some
some
nice
properties
inside
I.
Don't
that
signs
to
it?
It's
definitely
you
know
like
the
the
getting
started
story
is
definitely
a
little
bit
more
complex.
B
There
was
a
time
when
I
guess
you
know
there.
There
are
still
some
limitations
as
far
as
what
data
you
can.
Access
like
off
the
top
of
my
head
I
think
some
search
data
is
a
little
bit
limited
and
it's
like
the
mental
model
is
more
complex.
So
what
you
probably
want
to
do
is
double
check
like
everything.
You're
querying
is
supported
by
the
app
and
go
through
the
flow
once
because
it's
not
as
easy
as
just
wrapping
a
call
with
a
personal
access
token
you
have
to
have
a
you,
create
a
DWT
token.
B
A
B
The
not
every
route,
I
guess
I
should
take
a
step
back,
and
this
is
documented
I'm,
pretty
sure
it's
almost
all
wrapped
up.
Now
there
was
a
time
when
not
every
API
route,
though,
is
available
for
access,
as
the
personal
access
token
is
available,
free,
github
app.
An
example
of
that
is
a
github.
App
can't
react
to
a
comments
if
we
don't
want
to
give
ass
first
class
support
for
thumbs
up
being
and
founding
an
issue.
B
Same
thing
was
like
reading
notifications,
thinking
about
can't
read
notifications,
and
so
there
are
some
weird
limitations
where,
like
the
actor
model,
doesn't
fit
in
the
some
of
the
APRs
and
some
of
the
data
model,
it's
less
of
a
concern
than
it
was
a
year
ago,
and
that
was
pretty
heavier
restriction.
But
before
you
go
all-in,
you
know
you'll
want
to
check
the
documentation.
B
Another
big
advantage
is
that
the
permission
system
is
significantly
more
fine-grained
than
it
is
with
with
personal
access
tokens
it's
much
more
fine-grained
than
allah
scopes.
So
you,
depending
on
the
security
model
again,
you
can
be
sure
that
the
app
won't
be
able
to
access
certain
things
and
connects
at
certain
things,
but
that
really
depends
on
what
all
the
app
is
designed
to
do.
B
D
B
Works
with
Enterprise
yeah
yeah
yeah,
the
give
app
support
was
shipped
in
a
few
versions
of
enterprise
that
you'll
have
the
normal
problems
or,
like
some
things
lag.
But
at
this
point
there
should
be
quite
a
bit
of
parity
between
ghe
and
you'll,
definitely
have
to
work
with
the
app
manifest
stuff.
If
you
want
to
work
in
ghe
like
the
github
app
the
first-class
database
record
that
exists
in
github
comm,
doesn't
you
know
percolate
to
an
enterprise
instance?
A
B
In
terms
of
just
like
the
different
opinions
you
can
have
been
using
and
personal
access
token
like
are
there
other
reasons
to
switch
Oh
if
personal
access
tokens
are
working
for
you,
personal
access
tokens
were
we'll
work
like
they
have
the
most
basic
permission
bottle,
which
allows
them
to
be
the
most
powerful
kind
of
without
the
least
amount
of
configuration.
We
find
that
organizationally
they're
the
most
inflexible
because
they
require
that
user
account
and
they
don't.
They
don't
live
in
a
place
like
with
a
github
app.
B
You
can
have
a
group
of
owners
and
it
like
the
the
permission
model,
is
much
better
for
groups.
I
would
say,
though,
that,
like
the
specific
problems
that
you're
experiencing
here
will
necessarily
be
self
with
again
about
I
would
call
it
classified
as
more
of
an
optimization
if
the
workflow
works
for
you.
But
if
you
wanted
to
change
the
model,
if
you
wanted
to
have
like
a
single
github
app
that
was
run
by
a
central
and
a
central
source
that
worked,
you
know
like
across
multiple
organizations.
B
Instead
of
having
an
instance
like
federated
for
every
every
person,
they
could
have
that
model
and
work
perfectly
for
you
and
that
would
probably
reduce
the
overhead
of
everyone
running
their
own
instance
and
stuff,
like
that.
That's
really,
where
I
think
the
advantages,
not
necessarily
in
a
small
step
to
still
till
federating
it
out,
but
you
thinking
about
yeah.
A
B
A
B
I
know
I
know
very
little
honestly,
I
know
very
little
about
search.
Our
kind
of
dealings
with
the
search
are
basically
a
Sydney
Opera
over
the
tools
that
search
provides.
So
that
is
definitely
a
good
follow-up.
To
get
specific
information,
I
will
say
that
using
the
API
outside
of
search
like
the
REST
API,
the
graphical
API
outside
of
search,
will
almost
always
get
you
the
proper
non
search
results.
B
We're
scoping
that
out
literally
tomorrow
and
we'll
have
we'll
have:
are
there
any
specific
so
just
to
30
seconds
yeah,
the
kind
of
core
requirements
that
we're
thinking
about
are
the
ability
to
see
failed
web
hooks
and
github
app
or
an
organizational
info,
or
the
repository
or
left
hook?
Probably
look
at
the
original,
payload
and
or
maybe
retry
them
and
potentially
then
being
able
to
filter
an
organizational
web
hook
down
by
repository
so
that
when
you
have
an
org
web
book
that
Scott,
you
know
install
of
an
org
with
a
thousand
repos.
B
A
C
A
A
A
C
A
Hook,
recipient
goes
down
right
and
I.
Think
it's
simple
idea:
we've
all
we've
been
talking
about
this
for
a
while.
We
might
build
just
like
the
cash
price
in
cash
to
just
yeah
and
I.
Think
an
automated
retry,
if
there's
an
outage
for
30
minutes,
might
just
give
up
on
a
whole
bunch
of
things.
So
I
think
automatically
tries
with
solvent
vast
majority
of
cases,
but
we
might
still
end
up
wanting
the
API
or
building
sort
of
proxy
cash
anyway,
cool.
B
Yeah,
that's
that's
kind
of
been
that's
been
what
I'm
thinking
as
well.
You
know
my
like
what
I've
been
asking
customers
is.
Basically,
if
we
had
retry
is
that
I
mean
we
wouldn't
try
for
very
long
right,
it
would
be.
It
would
be
difficult
to
retry
for
five
minutes,
even
because
that's
a
lot
of
web
hooks,
would
you
still
dedicate
the
engineering
resources
towards
using
a
failure
API
if
we
had
a
small
amount
of
retries,
usually
the
answer.
I've
gotten
is
yes.
B
C
A
B
B
A
B
A
That's
a
good
point,
I
think.
Originally
we
wanted
every
I
think
originally
the
thought
was
we
could
only
use
search
and
then
the
search
response
would
give
us
the
exact
list
of
PRS
that
leave
its
feet,
worried
about.
Since
then,
we've
we've
changed
how
the
that
works
and
so
we're
doing
a
search
and
then
the
filtering
afterwards
anyway.
So
we
could
just
stop
using
search,
I.
Think
I,
love.
B
Our
search
team
deeply,
but
for
things
like
this
I
think
that
maybe
our
exceedingly
shall
we
say,
availability
and
consistency
of
our
search
system.
It
might
make
sense
to
try
and
use
some
basic
heuristics
like
label,
because
Wieck
basic
search
like
if
you
look
for
label
and
some
things
sometimes
it
gets
sent
to
elastic
search.
Sometimes
it
doesn't
I
can
offer
some
advice,
but
especially
using
the
graph
QL
API.
B
B
B
B
A
B
Can
definitely
pass
like
I
said:
I
mean
I
I'm,
so
unfamiliar
with
search.
We,
we
literally
passed
the
search
string
and
it's
awful
because
you
can
type
a
search
straight
in
the
graph.
Go
curry
and
then
you're
typing
a
query
language
in
a
language.
Wonderful
computers
are
great,
but
all
we
really
do
is
forward
it
and
then
marshal
the
responses
on
the
way
back,
but
I'm
happy
to
go
to
the
search
team.
If
there's
anything
that
I
can
pass
along
or
ask
any
questions
and
stuff
like
that,
let
us
look
into
using.
A
A
B
A
Every
once
in
a
while,
I
just
put
this
in
here,
cuz
I'm,
watching
it
happen
at
the
moment
mm-hm
every
once
in
a
while.
We
do
see
like
these
waves
of
get
failures
against
and
I.
Don't
know
if
there's
something
we
should
be
doing
there.
That's
interesting
and
we'll
see
like
hundreds
of
these
fail,
just
in
like
I
sure,
like
five
minute
window.
B
That's
very
interesting,
I
would
I,
would
bet,
I
mean
I'm,
assuming
you're
doing
quite
a
few
yes
operations
per
timeframe,
but
that's
interesting
I
also
I
can
also
take
this
back.
Is
it
mostly
for
us
anyone
repo,
or
do
you
see
it
across
all
repositories?
No,
when
it
happens,
we
see
it
across
that'd.
Be
really
interesting.
A
B
B
A
A
B
A
So
I
think
both
flight
number
two
is
fairly
terrifying
for
us.
So
if
it's
now
a
document
that
I
like
authenticated
request
should
be
made
serially
and
then,
if
we're
making
a
lot
of
requests,
we
should
wait
at
least
a
second
between
each
request.
I
think
that
was
not
clear
to
us
when
we
started
I'm
writing
this
and
I.
Don't
know
if
this
was
published
at
the
time,
but
we're
really
egregious
ly
briefing
both
of
those
bullet
points
and
so
I
think
a
lot
of
at
least
personally
I
would
love
to
know.
B
Good
question
I
I
would
say
that
those
these
are
more
so
you've
been
hit
by
a
rate
limiter.
What
what
North
Star?
Should
you
start
to
orient
to,
especially
that
one
unless
a
we
will
rate
limit
you?
Unless
this
happens
more
specifically,
I,
don't
see
us
starting
I
think
it's
it's
not
customer
friendly
to
not
allow
for
some
a
level
of
concurrency.
We
recommend
people
to
limit
their
concurrency
if
ever
possible,
but
we're
talking
something
like
10
to
15
concurrent
requests
and
not
1
to
2.
We
do
have
specific.
B
You
know
there.
There
is
a
specific
abuse
rate
limiter
that
does
sweep
for
people
making
too
many
concurrent
requests.
I,
don't
remember
the
number
off
the
top
of
my
head
and
we
try
not
to
talk
about
them,
but
it's
in
the
double
digits.
And
so,
if
anything
you'll
know
and
you
you
know,
you'll
know
when
you
fit
it,
which
you
know
you
are
in
that
one
bot
and
it's
possible
that
that's
what
it
is,
but
it's
Esprit
lenient,
I'm
being
honest.
Okay.
So
if
we
so.
A
A
B
D
A
B
A
B
I
mean
I
would
say,
I
would
say:
25
would
be
a
good
number
lower,
concurrent
requests.
The
way
that
it
works
is
it's
like
a
sliding
60-second
window.
Every
time
a
request
comes
in
and
counter
is
incremented
and
comes
out.
It's
decremented.
So
if
you
kind
of
hit
the
sliding
window
the
wrong
way,
you'll
end
up
with
funky
numbers,
so
I
wouldn't
push
it
right
up
to
limit,
but
I
think
I.
Think
25,
concurrent
requests
is
probably
safe.
The
there
are
other
limiters
that
you'll
probably
hit
before
that
the
CPU
time
and
stuff
like
that.
B
B
The
502
s
are
almost
certainly
now
that
I
know
you're
using
search
are
almost
certainly
search,
related,
I
would
bet,
search
and
CB
related,
so
I
would
definitely
recommend
trying
to
optimize
some
of
that
out
of
the
start
up
critical
path,
either
by
spreading
it
out
into
smaller
queries
over
a
few
minutes.
If
you
can
afford
that
or
doing
in
the
background
or
something
like
that,
the.
A
The
github
apps
one
of
the
next
questions
here
rate
limit
an
exemption
for
our
BOTS
question.
Mark
yeah,
probably
not
gonna
happen.
Does
the
genome
app
mechanism
scale
with
the
number
of
users
that
are
using
in
with
a
number
of
members
in
the
arc?
I
remember
there
was
one
mechanism
of
the
scale.
Yes.
B
A
B
So,
if
you
have
a
big
organ,
you
install
the
app
on
there.
You
can
scale
your
rate
limit
up
your
numeric
rating
without
fairly
significantly
the
abuse
limits
for
being
the
same.
I
wouldn't
be
running
into
just
like
too
many
requests
in
an
hour
which
it
seems
like
you're,
not
know,
especially
when
they
catch
me,
where,
if.
A
B
Happens
all
the
time
we
do
that
to
other
people
like
we
do
and
then
to
us
so
but
yeah.
That's
that's
how
that
scales,
we're
always
trying
to
kind
of
tweak
that,
in
the
abuse
rate
limits
or
the
focus
of
some
of
our
recent
ire
around,
like
them
scaling
in
a
way,
that's
not
conducive
to
the
way
that
people's
application
scale,
but
yeah
numeric
array
elements
was
your
problem
and
github
app
is
definitely
a
good
answer.
Okay,
cool.
A
I
do
know
that,
like,
if
I
submit
a
github
support
like
a
request
thing
and
I've
done
this
a
couple
of
times
and
I've
tried
to
be
like
I
I,
think
that
you
see
like
sometimes
think
that
channel
has
a
couple
of
hops
skips
and
jumps
before
it
actually
gets
to
somebody
who's
able
to
respond
to
it
and
I'm
wondering
why
it's
the
way
that
we're
looking
forward
but
I
guess
now,
if
you
guys
are,
you
know
like
somewhat
available
on
slack
I'm,
not
super.
Certainly
we
need.
B
Yeah
I
mean
I,
can't
I
can't
commit
to
a
personal
SLA
but
you're
in
my
slack,
and
we
use
slack
at
github.
So
during
rough
working
hours,
I
will
say
that
our
support,
if
you
just
email,
support
support
they
that
is
staffed
with
technical
people
on
in
my
kind
of
department,
in
most
European
and
most
European
to
Pacific
evening
and
they're
generally
pretty
good,
especially
at
helping
with
like
diagnosing
and
understanding
the
way.
B
Our
infrastructure
works
a
little
bit
and
it
will
level
up
to
me
like
when
you
wrote
to
support
about
the
above
hook,
issue
that
we
were
experiencing.
It
got
to
my
inbox
two
or
three
hours
afterward.
So
if
it's
urgent,
urgent
I
would
support
ticket
and
then
follow
up
on
slack
and
one
of
three
things
will
usually
be
happening,
will
have
no
idea,
hopefully
not
that
one.
It
will
be
limited
to
you
or
it
will
be
a
real
thing
and
we'll
say
we're
about
to
status.
B
But
I
think
that's
probably
the
best
thing
for
now
I
wish
there
was
a
page
support,
you're
kind
of
saying
that
we
could
offer.
We
do
offer
that
for
our
enterprise
customers
that
it's
probably
it's
not
a
very
good
mismatch
and,
in
the
end,
what
you're
trying
to
do
is
most
likely
escalate
to
me
or
my
team
anyway.
So
I
think
having
a
direct
line
is
probably
easier
and
if
it
becomes
a
burden
or.
A
B
B
A
B
Yeah
yeah,
no,
that's.
If
you
get
a
404
accessing
that
the
problem
is
you
can
get
anyway?
Yes,
that
will
definitely
happen.
We
have
we
have
there's.
There
is
some
strategies
that
people
use,
the
API
will
use
if
you
fetch
the
underlying
user
and
they
404.
That
means
that
they're
spammy,
and
that
means
you
can
ignore
it,
but
that's
another
API
call.
We.
A
For
your
deployments
internally,
I
think
one
of
the
focuses
for
us
this
year
is
seeing
how
broadly
at
the
wiltrout
can
be
just
forwards
in
general
and
so
I
think.
In
the
last
couple
of
years,
we've
seen
a
lot
of
adoption
of
proud,
mostly
clustering,
around
kubernetes,
but
like
there's
a
bunch
outside.
So
if
you're
interested,
you
can
send
your
web
hooks
to
yourself,
I
think
what.
B
A
C
A
B
About
I
can
say
confidently
that
we
are
aware
of
these
problems.
I,
don't
know
how
we're
trying
to
address
them.
I
know
and
I
was
hopeful
that
we
could
get
you
some
face
time
with
Devin
who's.
We've
got
a
PM
dedicated
to
like
the
open
source
and
just
like
how
large,
specifically
a
lot
of
the
time,
how
large
projects
kind
of
thrive
or
don't
thrive
on
github.
This
has
come
up
a
lot.
B
I,
don't
know
specifics
of
what
we're
doing,
but
I
see
like
directory
based
code
ownership
and
more
granular
restrictions
on
things
like
labels
and
stuff.
Like
that,
absolutely
the
kind
of
thing
that
we
just
don't
do
very
well
we're
very,
very
much
github
permission
system
is
very,
very,
very
much
set
up
to
the
repo,
both
in
terms
of
not
being
granular
enough
and
both
in
terms
of
being
too
granular
with
things
like
labels
and
stuff.
C
B
Great
yeah,
she's,
she's,
fantastic
and
she's
super
passionate
about
this
and
I
know
we
really.
We
really
do
care
about
about
this.
Like
there's
been
some
really
good
blog
posts
about,
like
the
kernel
github,
just
mono
repos
in
general
I've
worked
at
companies
that
have
had
mono
repos
on
top
of
github.
It
doesn't
work
that
well
so
I'm
hopeful
that
we
can
make
some
strides
there
and.
B
All
be
reflected
in
the
API
and
stuff
like
that,
but
I
don't
have
any
specific
knowledge.
I
know.
There's
like
there
are
specific
for
things
like
cross
repo
administration.
Even
we
use
like
Probot
scripts
to
do
like
issue
sync
label,
sync
and
stuff
like
that.
So
even
we
feel
that
pain
on
on
our
end,
a
lot
of
the
time.
A
B
B
A
C
C
A
Know
the
feeling
I
think
in
the
last
thing
that
on
the
architectural
notes,
so
from
like
a
administrative
perspective,
trying
to
administer
things
between
repos
and
across
orgs
is
a
little
bit
cumbersome.
So
we
have
created
schools
that,
for
instance,
like
help
us
sure
that
a
basic
set
of
labels
is
available
across
or
that
we
control
like
team
membership
and
totally
so,
if
there's
anything
coming
on
that
front,
yeah.
B
Not
that
I
know
this
is
the
kind
of
thing
that
a
genome
app
could
be
useful.
You
could
say
something
like
anywhere
that
the
app
is
installed
with
the
right
permissions.
It
sets
up
a
base
set
of
labels.
It
copies
team
membership
over
and
stuff
like
that,
but
yeah.
Another
thing
that
I
think
Devon
is
the
the
right
area,
cooler
to
be
back
in
and
will
be
very,
very
honest
about
the
fact
that
that
needs
to
get
better.
B
That's
there
for
that
reason,
so
they
actually
are
lighter,
because
what
we
don't
have
to
do
is
build
the
whole
request
body
up
which
our
API
s
are
pretty
fat
a
lot
of
the
time
and
take
a
lot
of
labelings
resources
and
stuff
like
that,
so
they
are
easier
and
it's
just
like
it's
something
that
we
we
kind
of
have
to
do.
Like
imagine
imagine
if
we
change
this
behavior,
you
spend
a
lot
of
your
time.
Optimizing
your
API
usage
and
that's
not
a
good
use
of
your
time.
So
not
going
away.
B
That's
documented
and
I
don't
see
that
changing
and
yes,
it's
easier
and
and
that's
the
kind
of
thing
I
think
where
we
would
instead
of
removing
it,
we
would
look
to
optimize
it
further.
Instead
of
do
away
with
it
and
kind
of
make
make
you
have
to
go
back
on
that
and
not
be
able
to
use
the
caching
so
you're
doing
that
right
if
you
wanted
to
know
how
how
to
kind
of
make
use
of
our
system
the
best.
B
D
B
B
D
D
A
B
That's
awesome,
yeah,
no
I
would
that
sounds
perfect,
and
if
you
can
just
apply
like
a
high-level
concurrency
control
there
and
it
doesn't
even
I
mean
it
almost
almost
doesn't
even
have
to
be
like
super
strict,
but
just
to
track
it
and
to
kind
of
see
where
you're
trending
would
be
good
and
then,
if
it
ends
up
being,
you
know
like.
Oh,
we
burst
a
500
concurrent
request
or
whatever
that's
when
adding
some
back
off
and
stuff
like
that,
would
be
good
I,
don't
know
how
timeouts
working
stuff
like
that,
but
yeah
that
would
be.
B
A
Cool
has
a
list
of
things
that
we
love
in
his
dog
I.
Think
web
apps
in
general
I
mean
the
system
they
had
before
was
just
like
it,
a
poll
that
would
just
grab
an
enormous
volume
of
data
and
try
to
cash
it
and
lunge
it
having
being
reactionary,
is
awesome
getting
as
much
data
in
every
web
hook
as
we
do
is
awesome
like
the
workflow
makes
a
lot
of
sense.
A
B
A
B
Okay
yeah:
this
is
not
that
nothing
about.
This
is
actually
something
that,
like
a
lot
of
people
do
and
in
the
past
we've
explored,
but
never
quite
done,
like
a
first
class
like
call
it
a
key
value
store
on
almost
a
lot
of
the
big
objects
like
a
repo
key
value
store
or
an
issue.
Key
value
store,
PR
a
key
value
store
because,
like
we
don't
really
mind,
it
keeps
you
on
github
that
keeps
you
time
to
get
up,
which
is
nice,
and
it's
also
just
like
people.
B
B
Cool,
so
just
to
recap:
on
Miami's
I've
about
two
or
three
takeaways
gonna:
take
a
look
at
the
spammy
or
blocked
user,
sending
still
sending
web
hooks.
So
if
we
can
pry
our
does
that
or
need
to
take
a
look
at
how
much
effort
that
is.
I
also
want
to
look
at
the
specific
personal
access
to
the
users
and
see
what
the
abuse
rate-limiting
problems
are
to
see.
Make
sure
I
gave
good
advice.
I'm
just
gonna.
Follow
up.
I've
also
got
a
pull
request.
B
Web
hooks
and
labels
that
click
5-minute
things
and
then
I
will
wait
for
your
advice
on
kind
of
how
you
use
the
Search,
API
I
think
they're
connects
you
with
that
team,
or
we
can
kind
of
figure
out
what
the
next
steps
are
or
wind
up
not
having
to
use
the
Search
API
but
chat
through
how
some
of
that
might
work
in
the
graphical
on
the
REST.
Api
have
I
missed
anything
I.
A
B
The
problem
with
what
this
is:
that's
the
one
thing:
that's
such
a
great
pattern
when
we,
you
know
when
they
first
came
out,
I,
don't
think
we
had
some
of
the
primitives.
My
dream
world
would
be
something
a
little
bit
more
durable
because
they
just
get
they
get
lost
so
easily,
even
with
retries.
You
get
ordering
issues,
and
my
goodness,
but
yeah
I'll,
take
a
look
and
with
two
failures
as
well.
I
was
seeing
a
specific
error
with
that
one
repo
that
might
be
like
we
often
see
it
when
code.
B
A
And
actually
not
that
I'm
thinking
about
it.
What
you
there
was
a
retry,
the
I
on
those
hooks.
It
would
be
interesting
to
know
what
sort
of
guarantees
that
would
give
for
ordering
none
our
yeah
so,
which
is
a
topic
we
probably
had,
or
if
you
guys
are
doing
reach
rice
by
yourselves
and
we're
not
asking
for
them
through
an
API
that
would
honor
any
ordering
yeah.
B
Ordering
is
ordering
it
stuff.
We
can
talk
more
about
that
for
sure,
but
that's
one
of
the
reasons
that
I
would
rather
present
our
our
version
of
ordering
to
you
and
let
you
kind
of
disseminate
that
how
you
wish,
instead
of
I,
think
trying
to
guess
at
what
the
customer
wants,
because
they're
probably
very
different,
depending
on
the
customer
yeah
that
makes
sense
cool
anything
else.
Anything
else
I
mean
I
want
to
keep
this
line
of
communication.
Open
I
mean
I'm
in
slack
and
stuff
like
that.
So
just
you
know
ping
me.