►
Description
Recording of our discussion about the Configure CI Minutes Limits epic and use cases and the iteration plan for the epic.
A
This
is
it's
December,
1st
2022..
This
is
office
hours,
we're
discussing
CI
minutes
limits,
or
this
configuring
say
a
minute
limits
per
project
and
subgroup
day.
A
Epic
we've
had
a
couple
of
community
contributions
that
have
come
in
and
want
to
just
get
aligned
on
Direction,
where
we're
going
with
this
larger
feature
set
and
make
sure
that
those
Mrs
can
contribute
towards
that
Vision
without
working
around
license
limits,
which
is
one
of
the
things
that
we
want
to
make
sure
that
we
enforce,
especially
for
our
gitlab.com
users,
so
I
have
to
Doc
check
with
everybody.
I'll
go
ahead
and
share
my
screen
so
folks
watching
the
recording
can
follow
along
as
well.
A
And
just
talk
through
the
problem
to
solve
making
sure
that
that's
clear
for
everyone,
The
Proposal,
that's
there
and
then
last
night,
I
added
this
iteration
plan,
which
I
tried
to
call
out
very
much,
is
in
draft
making
sure
that
we
have
the
right
order
of
things
to
implement
so
that
we
can
link
back
and
get
the
Mrs
that
are
associated
with
those
issues
moved
along
foreign.
A
A
Well,
folks
are
reading
a
lot
a
little
bit
of
context
for
a
self-managed
user.
The
instance
admin
today
can
set
a
quota
I
believe
for
groups
not
for
projects,
so
that
a
group
can
have
a
quota
limit.
The
self-managed
users
are
always
using
their
own
Runners,
though
they're
not
using
the
getlock.com
shared
SAS
Runners.
B
And
I
can
give
maybe
some
additional
context
on
on
the
requester
site,
which
is
the
Drupal
project
yeah
be
great
neck,
so
I
shared
a
link
in
the
zoom
chat
for
the
self-managed
gitlab
instance
that
the
Drupal
project
has
they're
used
to
self
manage
their
git
code,
whatever
not
on
gitlab
to
sustain
the
URLs.
They
actually
had
to
create
one
group
and
all
the
projects
under
that
group.
B
So
adding
group
limits
by
the
Admin
wouldn't
work
for
them,
because
there's
only
one
group
and,
as
you
can
see,
there's
like
almost
2
000
pages
of
probably
20
projects
each
or
something.
So
that's
why
they
were
looking
into
getting
limitations
on
a
project
level.
So
hopefully
it
helps
in
terms
of
context.
A
Yeah
this
is
the
the
community
contribution
side
of
this
started
with
the
folks
in
the
Drupal
project
and
wanting
to
set
that
limit,
because
they
have
some
I
I
think
the
use
case
was
there
are
some
projects
that
are
just
tests
that
they
only
want
to
run
once
or
twice
a
month
and
not
have
them
continually
running
thousands
of
minutes.
All
the
time
like
for
every
push
and
like
it
only
really
should
be
run
once
or
twice
a
month.
I
think.
B
Correct
and
also
a
little
bit
to
prevent
abuse
on
projects
that
might
not
have
been
verified
to
be
critical.
Yeah.
A
Okay,
so
then,
moving
on
to
the
proposal,
what
we've
proposed-
and
this
is
a
pretty
wide-ranging
epic
I-
think
this
will
end
up
breaking
into
some
smaller
epics.
As
we
talk
about
self-managed
versus
gitlab.com
projects
versus
groups,
we
want
to
add
that
level
of
control
at
the
subgroup
and
project
level
and
we
might
need
to
break
those
out
Fabio
I
know
you
and
I
have
talked
a
little
bit
about.
A
Can
we
actually
do
this
for
not
just
a
group
but
a
subgroup
and
allow
that
control
of
the
quota
to
reallocate
not
really
reallocate
CI
minutes,
so
other
projects
can
get
more
than
others.
So
the
example
here,
if
you
have
three
projects
under
your
name
space
and
you
have
an
ultimate
license,
really
their
quota-
each
is
50
000,
but
that's
also
a
cumulative
quota.
So
what
we
would
like
to
do
is
limit
that
so
say,
project
a
is
that
test
project
and
it
it
only
gets
updated
once
a
month.
A
The
other
projects,
then
could
use
more
and
then
I
should
add
a
actually
I'm
going
to
edit
this,
as
we
go
I'm
going
to
add
a
use
case
here.
If.
C
Project
B,
if
the
sorry,
once
the
total
limits
are
reached.
A
All
right,
I'm
going
to
skip
ahead
to
the
constraints
and
just
talk
about
those
before
we
talk
about
iteration
plan
and
the
draft,
so
specific
limits
for
project
or
subgroup
must
not
be
higher
than
the
monthly
limit
defined
by
the
root
namespace.
Ideally,
we
can
set
that
or
we
can
enforce
that.
I
think
that
that
starts
to
get
tricky
on
gitlab.com
or
for
SAS
because
of
the
additional
Runner
minutes
that
can
be
purchased.
A
D
Correct
because
they
between
SAS
and
self-match,
there
is
no
difference
in
where
these
limits
are
set,
they're
always
set
on
the
namespace
level.
Even
if
we
say
it's
a
ultimate
customer,
it
sounds
like
it's
applied
per
plan
like
in
terms
of
implementation,
but
it's
actually
we
take
the
plan
limit
and
we
set
that
limit
for
the
specific
namespace.
So
each
namespace
has
its
own.
It
will
speak
about
top
level
in
the
space
it's
top
level.
Namespace
has
its
own
limit
that
is
set
by
an
administrator.
D
In
this
case,
either
SAS
will
be
directly
as
you
purchase
a
plan
or
you
register,
for
as
a
free
user
or
on
self-managed
will
be
set
by
an
administrator
either
as
default
instance.
D
Setting
for
the
instance
or
as
a
specific
limit
for
the
namespace,
and
we
can
do
that
and
I've
been
to
the
table
that
you
have
with
additional
details,
because
it's
like
what
we
are
touching
here
as
well.
Yeah.
A
Well,
let's
do
that
so
this
I
copy
pasted
a
comment
and
then
turned
it
into
a
table
to
try
to
kind
of
sketch
out
a
bit
of
not
necessarily
the
data
structure,
but
how
we
think
about
the
hierarchy
of
where
those
limits
apply.
So
at
the
very
top
level
there's
the
instance
limit.
This
is
the
license
for
the
SAS
Runners
I.
What
I
don't
know
is
for
self-managed.
Is
there
an
initial
limit
that
gets
set
or
are
all
projects
and
groups
set
with
a
quota
of
that
are
Unlimited.
D
So
the
instance
level
it's
more
like
a
an
application
limit
that
the
expectation
level
limit
that
you
define
for
as
a
default
limit
for
all
namespaces.
Okay,
which
means
any
new
namespace
you
create,
will
automatically
have
that
that
limit,
unless
it's
overridden
at
the
namespace
level-
and
this
is
how
it
works
on
SAS-
how
we
give
400
minutes
to
free
users.
It's
actually
not
an
explicit
limit
for
that
top
level
in
space
for
the
names.
D
If
you
look
at
the
namespace,
the
limit
is
actually
nil,
but
actually,
since
it's
not
set
there,
it
will
default
to
the
application
Level
limit,
which
is
set
as
400..
So
by
default,
every
name
space
gets
400
minutes,
okay,
but
then,
as
you
purchase
a
license
or
or
you
know,
self-managed
an
administrator
sets
a
limit
for
that
level
or
top
level
namespace.
Then
you
can
have
another
actual
quota.
It's
been
specifically
for
the
top
left
namespace,
rather
than
defaulting
to
the
400
or
whatever
it's
been
set
at
the
instance
level.
D
Okay,
which
is
basically
the
first
two
lines
in
the
table,
so
the
instance
level
will
be
on
gitlab.
Sas
would
be
the
400
minutes
set
for
all
three
users,
and
then
the
namespace
level
is
actually
something
we
override
the
namespace
level
and
that
takes
precedence
and
it
will
be
the
quarter
we
set
for
paid
users.
C
F
D
Excuse
me
so
on
self-manage,
if,
if
I
want
any
new
groups
to
automatically
take
10
000
minutes,
for
example,
I
can
set
the
default
limit
as
an
ad
pin.
But
if
I
want
a
very
specific
group
to
take,
maybe
more
minutes
or
less
minutes
and
I
can
set
a
specific
limit
for
the
top
level
namespace,
and
this
is
functionality
we
have
today.
F
A
D
A
I'm
gonna
leave
it
and
just
call
out
that
it's
already
done
and
it's
covered
by
the
line
above
it
looks
like
we
had
a.
D
G
Yeah
right,
can
you
hear
me
yep,
you're,
good
yeah,
so
I
think
there
are
two
things
that
needs
to
be
distinguished
here.
Is
limits,
meaning
no
more
like
the
the
limitation?
How
much
can
you
use
and
then
quarter,
meaning
the
pool
of
minutes
that
could
be
like
distributed
or
reused?
G
A
So
we're
going
to
specify
and
I'm
going
to
stick
that
back
up
in
The
Proposal.
D
There
we
go
so
we
I
think
yeah.
The
quota
would
be
what
is
set
by
the
Admin
at
the
top
level
namespace
or
as
default
lim
default
quota
from
the
application
limit.
It's
like,
if
you
don't
have
like
and
specifically
a
quota
set
for
the
top
level
name
space.
You
get
the
default.
These
two
values
represent
the
quarter
that
the
group
or
username
space
can
can
use,
but
what
then
also
to
get
a
little
bit
more
granular
than
that?
D
A
So
for
forgetlab.com
users.
A
So
that
would
be
your
quota.
Your
monthly
quote
is
equivalent
to
whatever
is
like
granted
by
your
license,
plus
any
additional
minutes
that
you
purchased.
That
is
your
your
quota
for
the
month.
Your
limit
within
that
might
be
different
and
that's
what
we're
working
on
is
really
setting
Ci's
minute
limits
that
respect,
then
the
top
level
namespace
corner.
B
A
I
think
that
one
point
Allison
and
I
yeah
I
think
at
one
point
Allison
and
I
defined
this
and
we
used
either
to
the
gcp
or
the
AWS
language
of
quotas
or
things
that
you
cannot
set
limits
or
things
that
you
can,
and
so
we
kind
of
matched
up
with
that
terminology.
So
this
aligns
with
that
I.
Just
hadn't
done
a
good
job
of
defining
it
here
in
the
Epic
previously.
C
A
A
Does
that
help
clarify
as
well
for
you
unhealthily.
A
All
right
or
use
some
fun
preview,
so
I
don't
have
to
click
back
and
forth.
Okay,
so
then
we
have
the
first
two
rows
set
I
feel
like
we're
doing
good
on
time,
making
good
progress.
So
now
we
get
to
top
level
group,
and
this
you
thought
that
we
could.
No
sorry
this
one's
already
good
as
well.
This
is
done
is
the
equivalent
of
the
name
space
limit.
Above
so
now
we
want
to
talk
about
subgroups
and
projects.
A
Oh
and
I.
D
A
Sorry,
I
think
at
this
point
in
the
table.
What
we
want
to
Define
is
who
we
want
that
Persona
to
be
not
exactly.
Who
can
do
it
today,
because
this
is
functionality
that
is
not
completely
implemented,
so
I'd
like
to
try
to
Define
end
State
or
the
outcome
that
we
get
to
for
the
user
kind
of
from
here
down,
and
we
can
add
a
row
to
the
table
of
from
here
down
is:
do
functionality,
foreign.
A
User
Persona,
the
group
admin
who
sets
that
would
a
smaller
iteration
or
an
MPC
for
SB.
It's
instance
AdSense
who
said
that
so
that
self-managed
can
implement
this,
or
is
that,
what's
already
implemented
for
a
self-managed
user
today,
within
the
instance
Administration
where
they
can
set
a
group
value.
B
That's
more
or
less
what
I
was
alluding
to
I'm,
not
sure
if
it
already
exists,
but
if,
if
we
can
go
smaller
in
terms
of
iteration,
I
would
go
to
the
instance
admin
also
for
the
the
user
base
that
was
requesting
this,
which
is
the
Drupal
Association.
They
don't
mind
if
it's
the
instance
admit
in
that
sense,.
D
Is
we
don't
have
that
today
because
of
course,
subgroups
we
have
only
for
top
level
groups
and
I
think
he
said
having
the
admin
as
a
user
Persona,
as
the
MVC
makes
sense
and
I
think,
ideally
on
on
SAS.
This
would
be
more.
The
group
owner
to
you
know
self-service
manage
the
the
quota
within
within
the
top
level
group.
D
How
that
can
be,
you
know
limited
among
the
the
subgroups,
but
I
think
it
also
makes
sense
for
an
admin,
maybe
maybe
from
a
point
of
view
or
and
reducing
resources
of
a
specific,
problematic
subgroup
or
project
that
is
consuming
a
lot
of
minutes.
Maybe
we
might
want
to
apply
a
limit
temporary
and
so
an
admin
can
jump
in
and
set
us
very
specific
limits,
so
at
least
that
it's
kind
of
contained
it
doesn't
affect
the
rest
of
the
shared
Runners.
A
D
In
terms
of
it's
a
question
more
slight,
more
long-term
and
eventually
I
believe
we
want
to
open
also
this
use
case
to
group
owners
to
be
able
to
set
limit
for
their
own
projects
or
their
own
subgroups
right.
Okay,
so.
A
Because
yeah
I
think
that's
the
the
iteration
I
think
we
would
start
with
it's
the
instance
admin
that's
going
to
help
solve
for
that
use
case
for
the
Drupal
community
and
other
self-hosted,
especially
open
source
projects
where
they
want
to
set
smaller
within
the
larger
top
level
group
within
a
subgroup.
Maybe
new
limits
for
those
new
projects.
Okay,.
A
C
A
Editing
is
hard,
I
think
that
we
could
split
this.
A
D
B
Correct
yeah
that
doesn't
mean
that
the
subgroup
is
not
interesting,
but
the
main
ask
is
for
per
project
yeah.
A
So
we
could
start
our
MVC
or
our
first
step.
Let's
not
call
it.
An
NPC
could
be
Implement
for
self-managed.
A
per
project
will
limit
that
is
set
by
an
instance.
Admin
foreign.
E
I
have
a
question
Jameson
Fabio
when
we
say
that
we
are
going
to
make
it
happen
for
projects.
Would
those
projects
only
be
the
ones
which
to
which
the
namespace
in
question
is
a
direct
parent
too,
like
we
would
look
at
projects
which
are
a
part
of
the
subgroups
inside
that
project
inside
those
groups
right.
D
Yeah
so
I
think
at
the
moment
would
be
more.
The
admin
can
go
into
any
project
within
gitlab
and
set
seven
minutes
and
limit
for
that
specific
project,
and
that
doesn't
matter
which
level
of
the
hierarchy
groups
subgroups
are
the
project
is:
did
you
go
directly
to
that
project
in
the
set
limit
order?
Some
admin
page
where
you
select
the
project
and
but
basically
you
you
just
set
the
limit
for
us
in
any
sort
of
projects,
got.
E
It
so
it
would
be
somewhere
in
Project
setting
and
would
only
be
accessible
to
the
admin
from
roles.
F
D
So
yeah,
okay,
there's
there's
the
use
case
that
eventually
we
want
to
extend
group
owners
to
also
do
that
to
set
limits
for
any
projects
that
they
own
within
their
group.
So
I'm
not
sure
whether
we
want
to
unify
the
ux
there
or
trip
to
this
to
different
Persona
to
different
ux,
I'm,
not
sure,
but
I
eventually
want
to
be
able
to
set
the
same
values
also
for
from
namespace
owner
persona.
E
A
All
right
so
looking
at
our
iteration
plan,
if
our
first
step
was
Implement
a
project
level
quota
for
self-managed
and
get
left
SAS
that
was
set
by
the
instance
admin
the
outcome
there.
As
we
address
the
Drupal
use
case,
we
don't
really
address
any
use
cases
for.com
today,
I
dedicated,
might
be
able
to
use
that
as
a
single
tenant,
because
it's
basically
self-managed
we're
just
the
admins,
but
we're
not
going
to
support
that
use
case
for
gitlab.com,
because
our
instance
admin
won't
set
project
level
quotas
so
that
we
would
need
later
a
implement.
C
A
So
then,
if
we
look
at
the
our
group
level
and
our
subgroup
levels,
Fabio
is
I
may
have
imagined,
but
I
thought
you
and
I
had
a
interaction
in
comments
or
in
one
of
our
one-on-ones
that
one
of
these
was
not
doable
today
and
maybe
I
misinterpreted
that
this
is
already
done
in
our
instance.
Level
limit
that
is
set
that
there
was
architecture
that
we
need
to
change
to
support.
One
of
these
use
cases
but,
like
I
said,
maybe
I
misinterpreted.
A
So
if
I'm
looking
at
like
gitlab.org
is
a
group
within
the
gitlab
instance
within
that
there
are
subgroups.
Who
is
the
right
Persona
to
set
the
limits
for
each
of
those
and
what
then
trickles
down
and
applies
to
the
the
group
in
the
project.
D
So
the
the
instance
of
the
main
can
set
the
limits
for
the
top
level
group,
for
example,
from
there
on
the
group.
Admin
should
be
able
to
set
limits
for
subgroups
or
or
specific
projects
eventually,
and
we
we
are
discussing
now
here
that
maybe
also
also
the
the
main
instance
that
the
main
should
be
able
to
have
to
to
jump
in
and
Set
limits
for
subgroups
or
projects
eventually,
but
like
at
the
minimum.
The
group
owner
should
have
access
to
setting
subgroup
level
and
project
level
limits.
Okay,.
A
A
And
so
we
could
split
that
up
to
say
we're
going
to
support
subgroups
first
for
self-managed,
because
that
code
is
already
there
for
self-managed
to
support
it
at
the
group
level,
and
it's
already
there
I
guess
for.com
as
well.
Just
thinking
about
how
these
features
match
up
and
what
code
is
and
who
the
instance
owner
is
it's
starting
to
make
a
little
more
sense.
C
A
A
All
right
so
we're
we
have
about
20
minutes
left
I
want
to
make
sure
that
we
answer
questions,
though
from
our
contributors
as
well,
make
sure
that
we
get
those
answered,
as
that
was
in
addition
to
clarifying
some
of
the
direction
and
the
use
cases
here,
which
I
hope
we've
done.
We
want
to
make
sure
that
questions
around
Mrs
that
are
open,
get
answered
of
What's
blocking
them
or
what
we
need
to
do
to
get
them
to
a
state
where
we
can
get
them
merged.
G
Yeah
right,
there
is
a
question:
if
there
is
any
mechanism
for
tracking
changes
to
those
fields,
so
right
now,
I've
just
made
Mr
that
adds
the
field
or
project
limit,
and
it's
really
really
basic,
but
when
I
need
to
add
interface
to
blog,
who
changed
the
limit
and
what
is
this
limit?
G
D
I'm,
assuming
you're
thinking
about
more
kind
of
in
terms
of
implementation
there,
so
the
at
the
moment
we
are
saying
we're
talking
about
the
MPC
that
the
instance
admin
should
be
able
to
set
the
the
limit
for
a
specific
project.
We
need
to
figure
out-
okay,
it's
probably
as
a
good
practice
to
create
a
new
table
specifically
for
CI
minutes
limits
for
projects.
So
we
have
like
a
project
ID
and,
and
especially
now,
that
gitlab
is
separated
from
separated
from
the
CI
database
is
better
from
the
main
database.
D
It
makes
sense
for
since
we're
speaking
about
CI
minutes
for
this
table
to
exist
in
the
SEI
database
and
and
then
we
can
have
an
admin
that
is,
that
has
permissions
to
write
that
table.
So
there
could
be
a
graphql
mutation
there.
So
from
the
front
end,
we
can
eventually
use
this
graphql
mutation
to
edit
accept
value
for
that
limit
for
the
project
and-
and
it
was
this
way,
we
should
have
a
way
to
set
and
and
modify
the
limit.
D
And
then
the
other
question
is
about
how
enforcing
and
the
ux
about
enforcing
limits,
and
today
we,
yes,
we
have
only
one
limit
and
you
know
we
don't
need
to
specify
what
limit
has
been
hit,
but
I'm
wondering
at
the
moment.
D
I
I
don't
know,
because
that
really
depends
on
how
the
final
enforcement
is
going
to
look
like,
but
maybe,
as
NBC
is
sufficient,
that
we
ensure
that
the
limit
that
is
set
at
the
project
level
is
at
least
equal
or
lower
to
the
top
level.
Top
level
group
limit
now
is
distinguishing
that.
So,
if
the
group
quota
is
50
000
and
my
in
my
project,
I
can
set
any
limit
up
to
50.
D
000
I
can
set
up
sixty
thousand
dollars
or
for
some
reason,
and
by
doing
that
then
we
know
that
the
lower
applies
and
the
lower
limits
is
the
one
that
actually
discussing
the
project
to
prefer.
D
But
there
are
scenarios
where
the
project
is
actually
not
hitting
the
limit.
It
might
be
another
project
in
the
same
group
that
is
consuming
all
the
ca
minutes,
so
my
pipeline
for
project
a
is
not
failing,
because
project
a
reached
the
limit
set
for
it
as
because
the
group
level
quota
is
exhausted,
and
that
is
maybe
what
yeah
we
are
saying
here
like
will
be
beneficial
to
know
which
limit
has
been
hit.
D
Part
of
the
enforcement
which,
whichever
enforce
the
limit
is
being
hit,
is
going
to
be
returned
in
in
the
error
message
or
something,
and
so
at
least
we
can
tell
the
user
pipeline.
You
know
can't
run
because
this
limit
has
been
hit
and.
G
Yeah,
my
connection
is
not
good,
but
that's
for
for
the
MVC
I
think
that's
more
than
enough
to
for
now.
D
It
will
not
be
a
complex
thing
and
what
might
be
more
complex
will
be
the
enforcement
of
the
limits,
because
we
need
to
check
two
limits
and
and
and
on
the
same
time,
all
the
time
when
you
want
to
check,
we
need
to
ensure
that
any
other
you
know
if
either
other
limit
fails.
You
need
to
report
back
which
one
is
failing
and,
and
we
have
some
logic
which
is
called
like
a
live
tracking
of
CI
minutes.
D
D
But
I
think
for
now
we
could
move
forward
with
the
setting
up
the
limits,
even
though
we
don't
initially
enforce
and
we're
looking
to
before.
We
even
you
know
enable
this
feature.
We
we
look
in
more
in
details
on
how
to
enforce
CM
minutes.
A
I
started
their
questions
to
answer
section
in
the
Epic
proposal
or
the
Epic
description,
so
Safari
app.
What
does
the
ux
when
the
limit
is
hit
for
the
projector
group
of
assignment
to
be
together
myself?
How
do
we
know
which
limit
was
hit
in
the
code
and
what
is
passed
to
the
front?
End
Caroline,
if
I
send
that
to
you?
A
Where
is
the
limit
stored,
also
assignment
Caroline,
and
what
is
the
ux
for
setting
the
limit
of
the
subgroup
project
and
I
think
we
have
design
open
for
that,
so
it's
signed
to
vetica
and
myself.
So
we'll
get
those
questions
answered
and
link
to
the
answers
as
well,
so
that
we
have
that
source
of
truth
going
through
the
Epic,
and
then
we
can
reference
back
to
it
from
the
issues
just
to
keep
track
of
these
things
as
we're
answering
them.
Okay,.
A
What
other
questions
can
we
answer
and
then,
before
we
wrap
up
I
want
to
quickly
just
talk
about
what
our
next
steps.
A
Okay,
see
no
other
questions
moving
into
the
next
steps.
For
me,
I
think
the
next
steps
are
get.
These
questions
to
answer
answered,
I
think
that
that
helps
unlock
the
Mrs
I
think
we
should
also
comment
back
in
the
Mrs
of
where
there's
where
the
business
logic
differs
from,
where
we're
going
directionalized
and
what
we
want
to
enforce
around.
A
That
idea
of
your
quota
is
still
the
top
level
limit
for
gitlab.com
or
for
the
instance
and
you're
a
limit
by
project
or
subgroup
needs
to
respect
that,
regardless
of
what
you
said
to
that,
or
if
you
have
a
bunch
of
limits
that
would
add
up
to
more
than
your
quota,
they
still
need
to
respect
the
quota
at
the
end
of
the
day,.
A
Great
well
I
think,
we've
added
a
lot
of
good
detail,
hopefully
answered
some
questions,
found
more
questions
to
answer
and
I'll
do
a
little
bit
more
cleaning
up
of
the
additional
details
table
within
the
Epic
description
and
breaking
down
some
issues
duplicating
some
issues
to
break
out
the
different
use
cases
so
that
we
have
one
per
issue:
we're
not
trying
to
mix
things
that
might
in
turn
influence
what
those
Mrs
look
like.
But
hopefully
it
doesn't
cause
too
much
strength
for
the
contributors.
A
Would
it
be
beneficial
to
do
this
again
in
a
couple
of
weeks?
Have
another
shorter
synchronous,
call
or
office
hours
call
as
we
continue
on
this
project.
D
Discussion:
okay,
when
we
tackle
the
part
of
enforcement
of
CI
minutes,
because
there
is
a
lot
of
logic
there
that
that
needs
to
be
all
right,
either
duplicate
or
or
we
find
an
efficient
way
of
dealing
with
that
at
the
moment,
I
haven't
looked
into
the
details
on
how
that
could
be
implemented,
but
it's
something
that,
as
soon
as
we
tackle
the
part
of
setting
limits,
it
will
be
the
the
second
part
of
of
this
implementation.
That
requires
more
discussion.
D
Okay,
so
then
it
depends
on
the
contributors,
whether
you
know
we,
we
find
an
unefficient
way
of
discussing
this
various
proposals
and
and
trade-offs
direct
async,
maybe
maybe
perfect.
Otherwise,
we
would
need
to
have
another
and
detailed
and
recall
where
we
might
want
to
answer
some
specific
questions.
Okay,.
A
Well,
I'll
pass
this
back
to
the
shared
channel
that
we
have
with
the
folks
at
Drupal
and
say
that
at
some
point
we
think
we
should
have
discussion
around
enforcing
the
limits
soaring
and
enforcing
limits
tracking
and
as
they
get
closer
to
that,
then
we
can
schedule
some
office
hours
just
for
wider
contributors
to
to
join
and
talk
through
any
implementation
details
as
needed
and
mentally.
Would
that
be
helpful
for
you
as
well
since
you're
kind
of
representing
our
contributors
here?
Sorry
to
put
you
on
the
spot.
G
Yeah
that
will
be
useful
because
I
see
that
big
potential
in
the
limits
in
general,
because,
for
example,
if
I
want
to
run
some
machine
learning
tasks
and
I
already
have
a
GitHub
infrastructure.
I
would
reuse
that,
because
everything
is
already
there,
so
I
just
need
a
different
interface
than
than
the
CI
pipelines,
but
I
would
use
the
same
minutes
for
that.
So
I
would
be
interested
to
see
what
an
interface
for
managing
quartus
limits
and
buy
an
additional
like
tax
could
look
like
because
it's
it's
borders
with
with
thin
Ops.
A
Great
okay
but
I'll
get
this
shared
on.
Okay,
love,
unfiltered
thanks.
Everyone
thanks
Caroline
for
helping
with
notes
and
keeping
us
on
track
and
we'll
get
this
shirt
out
and
like
back
to
the
Epic
and,
like
I,
said,
I'll.
Take
a
next
section
of
doing
some
issue:
split
and
clean
up
of
additional
details
today,.