Re: [FFmpeg-devel] Sovereign Tech Fund

["Jonatas L. Nogueira via ffmpeg-devel" <ffmpeg-devel@ffmpeg.org>]

Keep in mind I only receive messages if I'm explicitly in the To field. I'm
with only half of the context, so my
messages may sound weird, out of context, repetitive, etc. In any case.


>> [...] the GA definitly cannot object to an invoice for a project that
the GA approved previously.
> "The General Assembly is sovereign and legitimate for all its decisions
regarding the FFmpeg project."

When working with a contract (and a SOW), the General Assembly won't be
able to block an invoice.
Because the General Assembly will already have exercised its sovereignty
before the work started.
And unless the GA becomes a nation, any court of law would uphold the
contract.

So the first statement which I have no context of would be correct with
SPI's approach;
the GA would not (realistically) be able to object to the invoice, unless
it is in breach of the contract/SOW.

(But if it is in breach of the contract or the SOW, then SPI will refuse to
pay anyway).


> You misunderstand this community. There are disagreements going on for
decades.

I've worked with worse.
FFmpeg asked to divide the work in milestones, so focus on where you agree
with.
Whatever there's disagreement, you can always apply later for more funding.
(At least from what I've understood).

For example, everyone can agree improving code readability is a good thing,
even if not how.
That's a good start. Ask for funding for it. The "how" can be done later
(see the PS).


> Would you like every invoice you make to be on this mailing list and
discussed in depth in public? And if that invoice was voted against by the
GA what would you do?

There's no need for that, you know?
One of the reasons to have a SOW is exactly to avoid such fights.
After all, the scope of work is decided before (and you need to do this
anyway, to ask for STF funding).
In an ideal scenario, invoices only need to be checked for legitimacy ─ if
the issuer is the one who worked, if the work is on the scope, if the time
spent isn't absurd, etc.
So there would be no need for the whole assembly to involve itself, unless
it's an appeal.
But of course, if you want every invoice there, it likely can be done, as
long that privacy laws are observed.


> I am sure neither STF nor SPI will mind if we reject all the money.

SPI is a public charity, so if you want to reject the money, that is not
our problem.
We're here to support you if you do decide to accept, though.
SPI handles non-technical administrative tasks, after all.

Do keep in mind that SPI acts as a fiscal sponsor.
This means that we're taking care of all the paperwork involved, but also
assuming the risks.
So if e.g. some payment is improperly documented and must be returned, SPI
has the duty to return it.

You can do it with some other entity ─ SPI is a public charity, we honestly
don't mind ─ but do keep in mind
that if you don't document everything adequately, SPI will not be held
responsible if it didn't pass by SPI.


> lets rather work towards making a list of projects, agreeing to them and
submitting an application to STF

This is pretty much the Scope of Work, and that would account for half of a
SOW (and also the most
important part of it). One of the reasons why SPI insists on doing the SOW
is because we concluded it
would present better governance (so less risks for you, for STF, for SPI
and for the contributors) and
that it would be expedient to do (as you're already going to do the upper
half when asking the funding).

The bottom part (schedule, deliverables and payment) do need your input on
what works best for FFmpeg,
but ultimately it is mostly operational guidelines expected from
contributors and SPI alike.

*When do you want contributors to report their work, and how?*
*How will the due amount be calculated? When should the invoice be sent?
When should it be paid?*

That's pretty much what's required to fill out the proposed SOW.

If you cannot get a scope of work, you definitely cannot get funding (and
if you get funding, then
what you used is most likely an acceptable scope of work, so it likely
won't need changes either).
If you cannot decide the other details, then odds of being required to
return the money are high.

Asking for a SOW might sound like asking for a lot of work, but it is
paperwork, and you can count
on SPI to do paperwork for you. But SPI acts on your behalf (and never you
on SPI's behalf), so
you do need to instruct us on how you want it to look like. "How can SPI
and the contractor know that
something on the invoice is (in)adequate?" That's the sort of thing the
bottom of the SOW worries about.

And I already said this earlier, but the bottom part is not important right
now.
Securing funding and the scope of work take precedence.
In the worst case, we can just ask our attorney to draft the SOW
altogether. He'll make a few questions,
you answer them, and we use whatever comes out of that.

SPI is here so paperwork doesn't block you, and if paperwork does block
you, then SPI will not be doing
a very good job, right?


PS. in the code refactoring example, usually whatever procedure you use to
transform a PR/MR into a commit is ideal.
I like using commits as deliverables because most projects have all their
internal governance set before it is merged.
So when it becomes a commit (on master branch), it means the project as a
whole already agreed with it.
I'm not sure how FFmpeg does this, though, that's a problem for you to
figure out and not for an outsider to intervene.


Also, sorry if I'm seen to be overstepping my bounds here.
I, as well as the whole SPI Board, wish you to succeed.
However, I admit my enthusiasm might have gotten the best of me in some
earlier messages.
That aside, I do hope the SOW is slightly more clear and easier to
understand now.

--
Jonatas L. Nogueira (“jesusalva”)
Board of Directors Member
Software in the Public Interest, Inc.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".