Re: [FFmpeg-devel] Sovereign Tech Fund

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

> IMO hasty actions and avoidable drama may cause damage to the project

What would be a hasty action? I've seen far too much people calling action
over stuff discussed for weeks/months as "hasty" in attempt to stall into
endless discussions, so you might want to clarify.

> The question is, what exactly would be the reprecussion for failing to
achieve projects. To us? To SPI? Not to mention the developer not
getting paid.

Given the current goal is to fund continuous maintenance tasks, it'll only
be a large problem with unpaid people if final state isn't better than
initial (eg. code gets more bloated instead of less). Otherwise, even if
some specific task cannot be completed, that's not an issue by itself, the
time already spent can be paid, as long that there's something to show for
it. (That's also an issue, but thankfully a debate for later).

Of course, if everything ends up unfinished that'll only scream you're
terrible at planning or outright don't know what you're doing.
Repercussions could make harder for you to acquire funds in the future and
likely comments that SPI should follow its projects more closely.

So mixing some easy but boring tasks is definitely a good idea.

> So you're basically saying the developers have to take the risk onto
themselves

Could you explain what exactly the risk devs are taking is? I can help if
you can make the usual risk assessment table (what risk, likelihood, and
impact/consequence).

> it's widely acknowledged that
accurate time estimates for complex projects are somewhere between
extremely hard and unfeasible.

I don't think a year is a question of accuracy, it usually indicates that
the code is becoming lasagna (if no result can be provided), ravioli (if
result can be provided but it doesn't work) or spaghetti (when it can be
provided and works... sometimes).

That sounds exactly like a good use for a maintenance grant, identifying
where the existing code base is problematic and trying to tidy it up.
That's also not something you can say "will be done by X", it's just
something you pour hours and hope end result is easier to work with than
the previous state (even if it's still pasta).

That's why the Scope of Work (which is the current task) for this is less
concerned in end results or deadlines, but in goals which can be attained
within a time frame (even if they're "making better" or can only be partly
attained, which would cause STF to believe you to be overambitious but is
not as problematic as not attaining anything at all).

> developers will try to protect themselves by playing it safe
and budgeting for the largest amount of time they think they might
possibly need. Which means in most cases they will need less time,
sometimes significantly less. Would STF be okay with us being so
wasteful?

No one is going to get paid according to their budget, the payment is over
how much time they actually spent. Budget is a limit, so the developer has
a good idea since the start of how long they can take. If they notice it'll
go over budget, they can stop, reevaluate and propose new budgets or
partial deliveries (or whatever the GA/STF decides to be acceptable). More
often than not, they'll have run in an unforeseen issue which could warrant
a fund/budget on its own.

So if you budget 15 hours and work 5, you'll be paid for 5 and the surplus
of 10 hours can be given to other projects or assigned somewhere nearing
over budgeting so it can be finished (or at least, delivered).

> my main point is that the amount of work to be done on any
interesting cleanup is unknowable beforehand. That means you have to
budget for the worst case, which means in the median case you will be
significantly overpaid.

I agree it's impossible to know, and I am sure STF is aware of that as
well. That's also why particulars usually don't fund these things, but
public funds like STF are willing to. But there will be no overpayment, as
you're paid for what you do (up to budget). If you finish with less than
budgeted, that means the surplus can be used to clean another code. (And if
there's a concern of fake hours, there are mechanisms which can be used and
can be discussed later, after the budget is made, which is after STF
returns their approval and the exact terms).

I hope this addresses some of your concerns.
Att.,

Jonatas L. Nogueira (“Jesusalva”)

On Wed, Jan 31, 2024, 09:59 Anton Khirnov <anton@khirnov.net> wrote:

> Quoting Michael Niedermayer (2024-01-30 01:15:54)
> > > Self-imposed restrictions like these at the very least need a GA vote
> > > IMO.
> >
> > I dont think its a "Self-imposed restriction"
> > The right to arbitrarily reject a invoice to a SoW never existed in the
> > first place.
> > But lets try this hypothetically.
> > If the GA decides it has the right to reject an invoice to a SoW
> > signed between SPI/STF/1 Developer.
> > Where would the GA get that right from ?
> > It can only have gained that right from the SoW/ or a contract
> >
> > This is the same in GSoC
> > if the GA decides a student should not be paid, its not going to
> > work, its the mentors decission and googles.
> > The GA never gave that right up, it never had it in the first place
>
> My understanding of your
> > There can be no late objections
> > [...]
> > objections after that cannot be considered!
> was that reviewers of the code produced by an STF-funded project would
> be restricted from rejecting the patches or demaning large-scale
> changes. If that is not what you meant then my point does not apply, but
> then this opens the developer to the risk of their code not being
> accepted.
>
>
> > >
> > > > 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.
> >
> > yes, iam trivializing, i thought people would value a grant of 200k€
> > more than arguing around.
>
> IMO hasty actions and avoidable drama may cause damage to the project
> far in excess of this sum.
>
> > And sure some arguments are quite valid i just think we can postpone
> > what needs to be postponed to get this grant and then for the next
> > round we can adjust everything as people prefer (in case there then
> > still is any wish to change something)
> >
> >
> > >
> > > These are, IMO:
> > >
> > > 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.
> >
> > Lets see
> > First STF is not about features but about maintaince. So the risk
> > of really unexpected and unavoidable sideeffects are not that high.
> > Also we dont need to do the really tough stuff in STF we can do the
> > easy but boring stuff.
>
> I do not see people queing up for such work.
>
> > But whats really the problem here ?
> > Lets imagine a example we agree to ABC
> > and it turns out the implemtation of ABC unexpectedly needs 3 letters
> > and this is unacceptable so we dont merge it.
> > Personally I would for cases where we arent sure the code is acceptable
> > for git master. Make this clear to STF before they accepting it and
> > I would not put "merge into git master" in the SoW.
> >
> > Now if we do put something in the SoW that we then do not achieve
> > thats a failure. IIRC/IIUC this is possible but will not be
> > tolerated many times. (certainly very dependant also on our
> > explanation of why that happened)
> > (thats what i remember, i cannot find the mail ATM where we where told
> that)
>
> The question is, what exactly would be the reprecussion for failing to
> achieve projects. To us? To SPI? Not to mention the developer not
> getting paid.
>
> > >
> > >    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?
> >
> > use a payment per time SoW.
> > But honestly as a buisness partner to STF we should aim for delivering
> > what we promisse at the price we request.
> > Anything else will not be good for FFmpeg independant of all other things
>
> So you're basically saying the developers have to take the risk onto
> themselves. That's ridiculous and means this cannot be used for almost
> any interesting projects.
>
> As an example, my threading work took over twice the time I initially
> expected. Are you suggesting I should have worked a year for free? And
> it's not just my personal failing - it's widely acknowledged that
> accurate time estimates for complex projects are somewhere between
> extremely hard and unfeasible.
>
> Of course the problem also works in other direction. If we go with your
> suggestion, developers will try to protect themselves by playing it safe
> and budgeting for the largest amount of time they think they might
> possibly need. Which means in most cases they will need less time,
> sometimes significantly less. Would STF be okay with us being so
> wasteful?
>
> > >
> > > 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.
> >
> > trivial ;)
> > we start with a wiki page
> > we add a some work with some monetary amount.
> > We wait.
> > If someone comes and is willing to do it for less, ok, if someone
> complains
> > its too much, not ok.
> > This seems the normal hire the "cheapest competent developer"
>
> This is not serious. "someone complains"? Like any random person? Any
> developer? In a project like ours, someone will always complain. Does
> that mean anyone has a veto over anything else?
>
> Besides, my main point is that the amount of work to be done on any
> interesting cleanup is unknowable beforehand. That means you have to
> budget for the worst case, which means in the median case you will be
> significantly overpaid.
>
> --
> Anton Khirnov
>
_______________________________________________
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".