The only thing I’d add to @luisramos0’s breakdown is the maintenance of the committed hours each week for the global pipe devs.
What I mean is there are a set of committed hours that each dev pledges when they become a contributor (do we track this somewhere?), that must be on average honoured. With this baseline in mind:
OFFrance has funding and wants to engage someone to do that work.
They get @sauloperez to do it.
Pau agrees to work an additional day a week specifically on this thing, and on top of his committed time for the global pipe.
OFFrance has funding and wants to engage someone to do that work.
They get @sauloperez to do it.
Pau agrees to work a day a week specifically on this thing, and he includes this as part of his committed time for the global pipe.
The thing I think worth talking about next is priority of this work within the global pipe (testing and code review) against the global priorities.
With our testing capacity very low I worry about having local instance things taking up space. And the code review column is always so full, adding additional things also concerns me. Yep, the instance pays for it, but it definitely takes velocity away from global priorities. And imagine if there were multiple local initiatives coming through at once…
So maybe we have to do these things:
- Not allow for any local initiatives until we have the pipe down to 2 major global things.
- Cap the number of local initiatives being done at any given time.
The final thing to think about is funding into the global pot. Right now, we’re running low. And my concern is still that funding that would have gone directly to the global pot will instead be redirected to local priorities. And maybe this is OK? But it needs to be hashed out a little more I think.
@Rachel shall we make this a topic for the global gathering in a couple of weeks?