From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 364EB49020 for ; Wed, 31 Jan 2024 15:17:33 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id B105D68D060; Wed, 31 Jan 2024 17:17:30 +0200 (EET) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 88F1368C25D for ; Wed, 31 Jan 2024 17:17:23 +0200 (EET) Authentication-Results: mail0.khirnov.net; dkim=pass (2048-bit key; unprotected) header.d=khirnov.net header.i=@khirnov.net header.a=rsa-sha256 header.s=mail header.b=cMs+d32l; dkim-atps=neutral Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id 34E332405F2; Wed, 31 Jan 2024 16:17:23 +0100 (CET) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavis, port 10024) with ESMTP id 6kzYK8z80mgu; Wed, 31 Jan 2024 16:17:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=khirnov.net; s=mail; t=1706714242; bh=Fg5F8Trwy/MDesE0WsT+34+G3XBfxB/yMbJRTX5SXks=; h=Subject:From:To:In-Reply-To:References:Date:From; b=cMs+d32lpHF+6Ax14eAt5+75YlCmHLR4BOv10fVKmwVGUkJv1cCedf5zZMKcxlmOx cRK5fg6jSA676FREbawzXQ+7riT9tze3LoMmENiEoS0RyBufhoK91klwg80sAbnvTR i975X8mRDHqiZX8g7qy5M1O/V+dhg7pTXNX/o0VDJ1DjOZfVTSPm519usb6ZhSaxCw sLyXxV+/rgGCA5Gxe+TJzInpKldTWWDOnIz7OFFH4JYnUuV8MuO142R4s/yj7lh66q MDb9LFs1OfRmsjZi4ZyTVo2w7AKP92FlhGhCdCgZst43Q1tShB/tFVJe1hPUwnzFb9 NLyP/gwbOyrXQ== Received: from lain.khirnov.net (lain.khirnov.net [IPv6:2001:67c:1138:4306::3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "lain.khirnov.net", Issuer "smtp.khirnov.net SMTP CA" (verified OK)) by mail0.khirnov.net (Postfix) with ESMTPS id 7706C2404E5; Wed, 31 Jan 2024 16:17:22 +0100 (CET) Received: by lain.khirnov.net (Postfix, from userid 1000) id 4EC951601B9; Wed, 31 Jan 2024 16:17:22 +0100 (CET) From: Anton Khirnov To: FFmpeg development discussions and patches , "Jonatas L. Nogueira" In-Reply-To: References: <20240128032549.GN6420@pb2> <170656270992.8914.17597847459142276038@lain.khirnov.net> <20240130001554.GH6420@pb2> <170670599775.8914.331021234730065376@lain.khirnov.net> Mail-Followup-To: FFmpeg development discussions and patches , "Jonatas L. Nogueira" Date: Wed, 31 Jan 2024 16:17:22 +0100 Message-ID: <170671424229.8914.16945908276654184539@lain.khirnov.net> User-Agent: alot/0.8.1 MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] Sovereign Tech Fund X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: 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 _______________________________________________ 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".