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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
