Re: [FFmpeg-devel] Sovereign Tech Fund

[Stefano Sabatini <stefasab@gmail.com>]

On date Monday 2024-01-29 22:11:49 +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2024-01-28 04:25:49)
> > There can be no late objections here to any project suggestions.
> > Objections must be before a project suggestion is submitted to STF,
> > objections after that cannot be considered!
> 
> Self-imposed restrictions like these at the very least need a GA vote
> IMO.
> 
> > Also once the person doing the work reaches the agreed milestone.
> > She will submit an invoice with stefano and my help to SPI/STF.
> > (in the unlikely case of a dispute on reaching a milestone
> >  it would be decided by the technical committee if the milestone
> >  has been reached from FFmpegs point of view)
> 
> Unlikely? I believe you are overlooking and/or trivializing the most
> serious problems that need to be addressed before we can submit any
> applications and not have it end in disaster.
> 
> These are, IMO:

The following are good points, I propose some possible solutions.  I
think these should be based on the assumptions that failure can
occurr, and the system should be designed to be robust to failures.

> 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).

> 2) How do developers protect themselves from spending vast amounts of
>    time on work they may not get paid for? As per 1), we may easily run
>    into fundamental technical disagreements which result in the work
>    having to be scrapped or redone entirely.
> 
>    It's also very hard to accurately estimate the amount of work
>    required to do something. What do we do when someone spends a month
>    working before realizing the project needs 5x more time than it's
>    budgeted for?

Assuming a SOW can be split in several parts, the first one being the
initial investigation, and assuming that the developer can split her
work in parts, and that only the first one (the one about the initial
investigation) can be invoiced in case there is no consensus about the
actual implementation. Again, I don't think this is very likely to
happen, but we should have a mechanism to handle this (and protect
both the project and the developer committing the work), in order to
minimize the risk.

> 3) Who exactly will be judging what amount of money is appropriate for
>    what amount of work performed? How will we avoid conflicts of
>    interest, or endless bikesheds over who is getting too much money for
>    too little work? We just bikeshud a thread to death over rather
>    little money, now imagine what would happen with ten times the
>    amount.

The amount of money might be defined based on economic parameters
related to the living country of the developer and according an
estimated amount of time. This is not perfect but it's probably the
best we can come around.

As per the final decision (e.g. in case there is no community
consensus after the investigatory stage) probably the Technical
Committee should be involved. This assumes that once the TC committee
reaches a decision, this cannot be reverted. At the end this is one of
the reasons why the TC exists in the first place, use delegation to
reach consensus in case the overall community cannot find it.

> Contrary to the overall mood of this thread so far, I hope these issues
> can be overcome and some useful work sponsored successfully. But they
> need to be taken seriously first.
> 
> I'd also like to ask Jonatas whether anything requires the projects to
> be owned by individuals. Were I to propose a project, I'd much rather it
> went through FFlabs than myself individually.

Also it would probably help to define the areas for the candidate
projects, I can think several things related to documentation for
example like completing/reviewing the documentation for the missing
parts which belong to low-risk area (note: I would not be able to
apply for any SOW given my employment status).

Probably it would help, if rather than discussing these things in
general, we would have some concrete project and candidate to get a
measure of what it could be like. I hope that if even we don't end up
with enough proposals, this should help to gain more experience to
understand what can and cannot work.
_______________________________________________
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".