While it's true a traditional SOW breaks work into milestones, we're going
for a simplified one here out of need. Think on when you ask for
consulting, not when you ask for a feature. You should not assume we want
to write eg. "Finish removing YUVJ by date X" ─ that's not the plan and as
you said it makes no sense (even less when you consider the SOW are
individual agreements, and we're likely going to have multiple people
working on it).

The timeframes aren't "finish X by Y", they're "report what you did by date
Y". In a sense, the report is the actual deliverable.

The Scope of Work isn't "only touch X", but the conditions on which payment
is acceptable (or not). As you said, the sponsorship is for maintenance
work, so it should make clear that features aren't eligible (on that SOW at
least). Otherwise, someone could make a feature nobody asked for, even less
needs it, and want to be paid for it. Or find some busywork which doesn't
help in the slightest and come wanting money. So if you had to refactor a
whole code because you're working on X, that's fine, but if you decide to
refactor the code because you think it's ugly and wanted to refactor it
then it might not be what you want to pay for. Or maybe you want,
refactoring can improve code readability and no one normally does that. I'm
not writing the scope, you are, I at most convert it to legalese when/if
required.

No one is getting paid for signing a contract and merry be merry, and it's
not acceptable to just give money "as we deem fit" (just think of all the
possible complaints and hours you'll waste with people questioning why you
paid more for A than for B). That would be poor governance, I also doubt
STF would be willing to sponsor if there's not even a scope of work.

I am attaching a quick example draft (actually a mockup) I made just now in
hopes to make it easier to visualize what is expected from the SOW. ****This
is not for review, it is for illustration purposes.*** *It is a quick
draft/mockup with random information written under a hour just for
visualization, and will not be used when the actual SOW is prepared, I just
wanted to make it easier to see what I'm thinking about for the SOW.

The first thing to prepare is section 2 (Scope of Work), as we need to
report it to STF beforehand. It is what STF is (or is not) willing to pay
for, and by consequence what FFMPEG is (or is not) willing to pay for. It
is the priority, as there *is* a deadline to finish it and deliver it to
STF (Feb 12th). Of course, it probably could have said "tasks with a
'maint' label on the issue tracker" or whatever, it's not like I ran this
mockup by a legal counsel nor anything.

Section 3 and 4 will likely later be required by STF as they have to do
their own audit, but this likely can be delayed for after the grant is
approved. It also seems to be somewhat controversial at the moment, so I
suggest that instead of straying into heated debates over publicity of the
invoices, conflicts of interest and whatnot, we focus on securing the
funding first (which means the first page of the mockup). After we have a
solid scope of work to present to STF, we can worry about how the funds
will be distributed (the mockup is hour-based and monthly, but as I said,
there are other ways to distribute them) and how the approval process will
go. (And in theory, the person could provide their own hourly rate,
although I see no reason why anyone would do so).

Again, I'm available to answer any questions you may have.
And on that note: I believe the same as Michael regarding OFAC restriction
as unlike Russia or North Korea, there is no ban against China residents,
but we can ask the legal counsel on the specific cases if the need arises.

Regards,

--
Jonatas L. Nogueira (“jesusalva”)
Board of Directors Member
Software in the Public Interest, Inc.