On Sun, May 19, 2024 at 01:29:43PM +0200, Thilo Borgmann via ffmpeg-devel wrote:
[...]
* Fund administrative / maintainance work (one example is the mailman upgrade that is needed with the next OS upgrade on one of our servers (this is not as trivial as one might expect). Another example here may be some git related tools if we find something that theres a broad consensus about.
I agree that this should be paid but I would expect that STF would not be too keen on it, not that I'd know really.
We should absolutely pay for such activity and STF is very well willing to fund such things.
* Fund maintaince on the bug tracker, try to reproduce bugs, ask users to provide reproduceable cases, close bugs still unreproduceable, ... ATM we have over 2000 "new" bugs that are not even marked as open
This is a double-edged sword. If somebody gets paid to do that, then that is one more reason for others not to do it.
And again, it is completely reasonable to be paid for that, and also for code reviews and writing test cases (if we want to complete the menial task list), but I am perplexed as to STF's stance on that.
Same as above about that we should and STF would. Especially since no corporate interest usually pays anyone for these tasks (in case of reviews it might of course be considered a good thing).
The one problem to solve here AFAICT is we don't know exactly what quantity of bugs, reviewable code submissions and other maintenance work will come up in the next 12 months. So it renders impossible to define in prior the workload, milestones and compensation per contributor interested as we did this year for well-defined tasks.
What we should consider IMO is defining the tasks (patch review, bug review & fix, FATE extensions, checkasm extensions, etc. as well such things for the administrative tasks from above) and defining a budget for these tasks. Then, allow 'everyone interested' (aka git push access?) to claim a part of that budget every N-months, depending what the corresponding contributor actually did and can somehow be determined.
Another solution would be to have a variable-sized primary task, with a secondary task that can absorb leftover time. For example, if your primary task was reviewing patches, your secondary task might be improving the patch review process. So when you get to the point where you'd rather let someone else claim a bounty than say "fix your indentation" one more time, your incentive is instead to write a tutorial, or a review bot, or otherwise get to the root cause.