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 8DE8C48F01 for ; Mon, 29 Jan 2024 23:53:38 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 8AF7D68D297; Tue, 30 Jan 2024 01:53:35 +0200 (EET) Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 6D39A68D287 for ; Tue, 30 Jan 2024 01:53:29 +0200 (EET) Received: by mail-lf1-f48.google.com with SMTP id 2adb3069b0e04-5102b43035eso4297954e87.1 for ; Mon, 29 Jan 2024 15:53:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706572408; x=1707177208; darn=ffmpeg.org; h=user-agent:in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:to:from:date:from:to:cc:subject :date:message-id:reply-to; bh=ya74ORVOeNKxwggjIXreMe0BhwZqhvRY59HjPxv7DVs=; b=JJxDFObu1bomOIcgQQphNAVojtxhod9diXL4FMqFAHnMCmUC2i9tN5zU0GA61PZUn9 UcaVJuJyO5hgQREE2QUOFaaqFDd6SrEyyJniFt4gPpMmJeTR0sW0DyJCLkMOtHslsa/1 z6abhXH8ViHwfb46B2YtYuvo8Y/fKNa6oIfS9ezYpru6csVrF4i/7323fDApSEXvbY3N BueBNCjY1iGjCWzTzF+fv/xrcIsWNvprLCl1oQMxTODF/8MNQ+XoyvKVPG00EZ5wmSN4 NF2gGjbtg9Ehq5qf5sLXw0PH0m3oyTnxrIUWxbPSn7tavsp47kSoqodXGtb33YyJPHkq v5KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706572408; x=1707177208; h=user-agent:in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=ya74ORVOeNKxwggjIXreMe0BhwZqhvRY59HjPxv7DVs=; b=nD8ADixWMIBHOcn2tl9Gv/JJ5W593tAYef3JvNPg+jE9uGNo9l21fYmpKUfqBTl0co vBXBFCV3+rmMgXC+HBXi4WMz6HyMf2yuRyaY2kt/i0Ob7k/msAtWXDIlzKGz6DeOkEOr k/Hk08fost42tb53O0cXJZHDQ2DyCe8jn77iAQlkil00hVkS8R0wUrsmHfjJ0Xy94EXJ I0/Qm7I8hZ9SF+9sZcCuyXG8JvhvMAaOC/zuAMiUj3Naq6FMr018QKGr4CPp1cn2TZ13 SF5CyEZBpF2by9VXtaUpRo/vWBV8Q3aOyi+725j3uHgj9HzXx/oMBrbvr1RqecKLIkyR VT4A== X-Gm-Message-State: AOJu0YxpN3ir7j5urKcJ8YM0yPpTdy+hficTuWTbv1Rr/RLrSxg9r+1K rB/Ti/ilGcly2B5XCREIkzvvvmW5cekX9KaIV4Nl5Yemr5r/clvkF/XvKG5m X-Google-Smtp-Source: AGHT+IEWF/3JY+sh5TrAXtpmurdjIASZiWJcmk4A+tj7i9F3XY42fF+kOPqc/F1uXuFDw2BNAPk93A== X-Received: by 2002:ac2:457a:0:b0:510:cae:bbaf with SMTP id k26-20020ac2457a000000b005100caebbafmr4065283lfm.68.1706572407347; Mon, 29 Jan 2024 15:53:27 -0800 (PST) Received: from mariano (dynamic-adsl-84-220-189-10.clienti.tiscali.it. [84.220.189.10]) by smtp.gmail.com with ESMTPSA id vk5-20020a170907cbc500b00a3527fd8937sm3626880ejc.139.2024.01.29.15.53.26 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Jan 2024 15:53:27 -0800 (PST) Received: by mariano (Postfix, from userid 1000) id A1824BFB9D; Tue, 30 Jan 2024 00:53:25 +0100 (CET) Date: Tue, 30 Jan 2024 00:53:25 +0100 From: Stefano Sabatini To: FFmpeg development discussions and patches Message-ID: Mail-Followup-To: FFmpeg development discussions and patches References: <20240128032549.GN6420@pb2> <170656270992.8914.17597847459142276038@lain.khirnov.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <170656270992.8914.17597847459142276038@lain.khirnov.net> User-Agent: Mutt/2.1.4 (2021-12-11) 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: 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".