[FFmpeg-devel] Sovereign Tech Fund

[Anton Khirnov]

Quoting Jonatas L. Nogueira via ffmpeg-devel (2024-01-31 15:10:02)
> > 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.

There are arguments in this very thread how we cannot discuss things in
detail and must instead ACT NOW OR ALL THE MONEY IS GONE. Naturally this
makes the mood more tense, especially given the other circumstances.


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

The risk for the developers is spending a lot of time and not getting
paid accordingly. I see the danger of that happening when the project
depends on the delivery of some specific milestone, which
* is never reached because of disagreements during review
* turns out to require significantly more effort than it was budgeted
  for

The only proposed way of avoiding these is for every project to be
either:
* Decomposable into very small discrete tasks, which is doable only in
  some cases.
* Of the form 'work towards X', but then evaluation becomes more tricky.

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

So far it does not seem we have an abundance of volunteers, so it seems
more likely we'll struggle to spend all the money.

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

It's not so much fake hours as the problem of counting what time was
actually spent on this work - only a minority of time is spent typing
code.

> I hope this addresses some of your concerns.

Some of them, thank you.

-- 
Anton Khirnov