[FFmpeg-devel] Sovereign Tech Fund

[Stefano Sabatini]

On date Wednesday 2024-01-31 13:30:50 +0100, Anton Khirnov wrote:
> Quoting Stefano Sabatini (2024-01-30 00:53:25)
> > On date Monday 2024-01-29 22:11:49 +0100, Anton Khirnov wrote:
[...]
> > > 1) How does the project protect itself from pre-approving some code that
> > >    does not exist yet? This is not just some theoretical danger, it's
> > >    easily possible that some project sounds good in theory, but actually
> > >    implementing it comes with so many gotchas and caveats that it ends
> > >    up being not worth it. Or there are fundamental technical
> > >    disagreements about the specific way it's been implemented. Both
> > >    cases exist in our history.
> > 
> > The design and investigative work should be covered as part of the
> > SOW. In other words, the SOW should also cover the preliminary design
> > and experimentation. In case it leads to no committable work (which is
> > unlikely but not impossible), the output should be a document/report
> > documenting the result of the initial investigation, and the project
> > might be aborted at that point.
> > 
> > This should protect both the developer and the project. In each case
> > it should be assumed that the final result of the investigation would
> > not lead to committable deliverables, but to design documents which
> > might lay the foundation of further work (possibly in a different
> > direction).
> 

> That might be a viable direction, but it does not really solve the
> problem. Initial investigation only gets you so far and some issues
> simply do not become apparent until quite far in the development
> process.
> 
> E.g. my recent threading work (that keeps getting mentioned in this
> thread as an example of what a cleanup project could look like) was
> largely composed of many "sub-projects", each disentangling a specific
> feature or area. And there was no reliable way to predict in advance
> whether a given sub-project would take two hours or two weeks.

So let's tweak the format. It might be formulated as something as:
--------------8<----------------------------------------------------
This project covers doing this and that. It will be split in several
stages lasting a given amount of time (e.g. two months per each
stage). At the end of each stage the developer will provide a report
giving an overview of the findings and of delivered code, which will
be the subject of the invoice.
--------------8<----------------------------------------------------

In this way we drop the requirement on achieving a specific goal in
terms of committed code, and require instead a report to document the
changes/finding (which will be subject to validation).

Maybe José can provide some guidance about the viability of this
specific format.

Assuming this format is acceptable on the STF/SPI side, the next
problem is to understand who is going to provide the validation based
on the report. The SPI liaison might be involved but only to sign-off,
not to provide the actual validation, which must be agreed upon by the
project according to some agreed internal procedures.

Other issues might arise in case the work is delayed due to various
circumstances (e.g. the developer getting sick or having other
external impediments or having more urgent tasks to attend). In this
case I can foresee a few possible outcomes: the developer will delay
sending the invoice, or the invoiced sum is reduced accordingly.

It seems to me we need to design these validation processes in advance
or we risk to turn each invoice delivery into a potential flamefest.