That's not a problem at all; because you can divide the work into discrete pieces after it's done (on the invoice), just like liberal professionals (eg. accountants, lawyers, administrators, etc.)
The SOW defines what is acceptable on the invoice (so in the YUVJ case, for example, it could be "code related to YUVJ implementation and bugs arising of it, as well as review of the PRs/MRs associated with it, but not tagging issue tickets, duplicated work or code formatting" — I have no idea, this is just for inspiration), as well as the timeframes by when they should submit the invoices (and if they need to submit any other proof of their work, what and when). It should also define how payment works (typically by hour or by code line, there's some leeway here though), what's the maximum budget (specially if the metric is exploitable), the value of which unit of work (defined before) which must not be above the market price. Contributors are not employees, they don't need to login at 8 and logout at 17 for a fixed wage. In fact, they might not do anything and thus no money be due to them at all. That's why we make a SOW, it makes clear what they can do, how much they can earn, what will not be paid (usually unrelated work) even if they do, and by when they should submit invoices and evidences of the work they did to receive payment. Do say if there are still questions, I'll be happy to answer and help here. Regards, Jonatas L. Nogueira (“Jesusalva”) On Sun, Jan 28, 2024, 15:59 Kieran Kunhya <kier...@obe.tv> wrote: > > Statements of Work and milestones (by definition) are for features. >> >> The SoW suggestion/need came from a lawyer that jonatas asked IIUC. >> so i can just suggest to put work like what you list above into a SOW like >> framework. Or maybe Jonatas can clarify, in case i misunderstood >> > > My point is that ongoing maintenance can't be split into discrete pieces > of work, nor arguably can a given timescale be associated with cleanup. > For example YUVJ is difficult, until you remove it and see the bugs you > don't know how long it will take. This is not suited to the bounty/SoW > methodology. > > We don't need STF to be funding features, we need maintenance, > infrastructure etc which all lends itself to salaried work. > > Kieran > _______________________________________________ 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".
