Re: [FFmpeg-devel] Sovereign Tech Fund
This is the courtesy reminder we've agreed on, to remember there's a week left to finish the Scope of Work if FFmpeg wishes to deliver it by February 12th as requested by STF. Att., Jonatas L. Nogueira (“Jesusalva”) SPI Board of Directors On Wed, Jan 31, 2024, 21:16 Stefano Sabatini wrote: > On date Thursday 2024-02-01 00:15:03 +0100, Stefano Sabatini wrote: > > José already provided and excellent summary from his side. On my side > > I meant Jonatas, sorry. > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Vote STF/SPI 2024-02
> The same of course should apply to any other future funding, it must be either the community (via GA) or a third party setting up the sponsorship. I honestly didn't understood this part. Maybe because I'm not involved with FFmpeg internal workings and policies, but could you clarify the exact differences, here? (How it would work, etc.) As for the other part of the request, I can't comment on the inclusion or not of the restriction as that's still FFmpeg internal policies, but from SPI side, we try to avoid having the liaison approving their own expenses when it could indeed pose such risk (so if it's a purchase of hardware for example, there's no need as there are already two other peers reviewing it). Although usually liaisons avoid such situations on their own and often provide additional documentation in those cases. This avoids neatly conflicts of interest, as far as someone approving their own expense goes. I'm not sure why blocking them from participating altogether would be necessary, it sounds a bit like an intent to be a punishment and I really think in such case it should be dealt with separately. As Michael said, STF expect the procedure to be fair, a restriction which might look like a witch hunt could be refused regardless of the actual reason, so in my opinion there are two better ways to make such restriction and have a better chance of STF accepting it. 1. if Michael, Thilo and me received a penalty from FFmpeg which prevents them (us?) from doing contractor work for FFmpeg instead of approving the contract work with restrictions on who can participate, that would remain fair and be better documented altogether. As another poll, it would also ensure a right for defense and a well documented motivation. STF would be more likely to accept in such form. It also maintains the discussion over sponsorship impartial. 2. Another alternative is making a permanent governance that whoever procures sponsorships are not able to participate on them. This would almost definitely be accepted by STF and address better the concerns, although it might severely hinder FFmpeg capability to procure sponsorships in future as it serves as a strong incentive to NOT seek sponsorships in future (and is the main reason why some projects or entities make similar rules). Both alternatives should be considered fair by STF unless you really mess them up, so don't let their demand for fairness to escalate into a "you must let Jonatas to participate or no money for you!" or similar nonsense. Of course, if they voluntarily renounce the right to participate that's an entirely different story. Anyone can do that, but that's entirely up to them and trying to coerce them into doing so (or not doing so) would be really frowned upon. Att., Jonatas L. Nogueira (“Jesusalva”) On Thu, Feb 1, 2024, 14:46 Vittorio Giovara wrote: > > > On Thu, Feb 1, 2024 at 5:29 AM Michael Niedermayer > wrote: > >> Hi all >> >> To do the STF/SPI thing properly, and make sure we do what the Community >> wants. >> We should do this vote: (unless lots of people reply and say we should >> skip the vote) >> (i am also CCing jonatan to make sure the option in the vote actually ask >> the GA the >> right question) >> >> The vote description will be as follows: >> The STF/SPI has suggested us to submit an Application / Scope of work >> before their february meeting. >> There are about 2 weeks left. >> The minimum grant is 150 000 € >> The next STF meeting is expected to be in may. If we submit in february >> and are not selected >> we can probably try again in may. Which would increase our chances >> If we do not submit in february we can probably submit in may. >> There is no guarantee that money will be available in may, for example >> between october 2023 >> and february 2024 no funds where available AFAIK. >> Wiki page is here: >> https://trac.ffmpeg.org/wiki/SponsoringPrograms/STF/2024 >> >> >> Option A. The Application and Scope of Work from the WIKI shall be >> submitted to STF/SPI before the february 2024 meeting, disagreements in it >> shall be decided by the TC. To achieve continuity, submission shall be done >> by the same person as previous if possible. >> >> Option B. No Application and Scope of Work shall be submitted in february >> 2024 >> > > Since all objections and requests for more time have been ignored, and > this is happening anyway, can we add a small amendment for the sake of > transparency and for avoiding any conflict of interest? Whoever was > involved with the STF/SPI talks cannot be the recipient of the sponsorship. > The same of course should apply to any other future funding, it must be > either the community (via GA) or a third party setting up the sponsorship. > > I'm aware that would exclude Micheal, Thilo, and technically Jonatas, but > at this point it's the only way I can see this move forward in any > direction. > > Jonatas any feedback on this possibility? > Thank you > -- > Vittorio >
Re: [FFmpeg-devel] Sovereign Tech Fund
I can't find anything in SPI related to NAB either. I can ask the officers if they're aware of something from NAB, but I don't think that would be the case. I can find some old booths for FOSSEM, FOSDEM and whatnot though. Can you double check? (Also: What's the relation between NAB and this sponsorship?) Regards, Jonatas L. Nogueira (“Jesusalva”) SPI Board of Directors On Wed, Jan 31, 2024, 16:07 Michael Niedermayer wrote: > On Wed, Jan 31, 2024 at 06:22:41PM +, Kieran Kunhya wrote: > > On Wed, 31 Jan 2024 at 18:03, Michael Niedermayer < > mich...@niedermayer.cc> > > wrote: > > > > > Hi Jonatas, Remi > > > > > > _THIS_ reply shows why i LOVE SPI > > > > > > I mean this is transparency, anyone try to get something similar from a > > > corporation > > > > > > Just in the last 48h i have seen a reminder from a CEO about > "shareholder > > > agreement" > > > and privacy > > > > > > > If you want transparency, where is the agreement between SPI and STF? > > > Where > > is the agreement for the NAB booth? > > I did search my inbox and spam folder fro NAB but nothing looked related > to a booth agreement. > I have someoen trying to sell me an "Attendees Database" for NAB since > 2018 though > and lots of can nab is spam. > > So either i searched for the wrong term or i was not CC-ed on such an > agreement > > thx > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > The educated differ from the uneducated as much as the living from the > dead. -- Aristotle > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Sovereign Tech Fund
There are no agreements between SPI and STF as of 31st January 2024. However, if you submit a Scope of Work, then an agreement will be made if STF approves the sponsorship (on the Feb 14th or later). I assume you don't mean National Association of Broadcasters by "NAB", so I would need to know what booth you're talking about. -- Jonatas L. Nogueira (“jesusalva”) Board of Directors Member Software in the Public Interest, Inc. On Wed, Jan 31, 2024 at 3:22 PM Kieran Kunhya wrote: > > > On Wed, 31 Jan 2024 at 18:03, Michael Niedermayer > wrote: > >> Hi Jonatas, Remi >> >> _THIS_ reply shows why i LOVE SPI >> >> I mean this is transparency, anyone try to get something similar from a >> corporation >> >> Just in the last 48h i have seen a reminder from a CEO about "shareholder >> agreement" >> and privacy >> > > If you want transparency, where is the agreement between SPI and STF? > Where is the agreement for the NAB booth? > > Kieran > > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Sovereign Tech Fund
delivering them a Scope of Work by February 12th, I'll stop posting agenda-like reminders or suggestions. Att., -- Jonatas L. Nogueira (“jesusalva”) Board of Directors Member Software in the Public Interest, Inc. On Wed, Jan 31, 2024 at 1:11 PM Rémi Denis-Courmont wrote: > Hi, > > Le keskiviikkona 31. tammikuuta 2024, 16.10.02 EET Jonatas L. Nogueira via > ffmpeg-devel a écrit : > > > 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. > > Would you care to clarify which astronomical body do you count weeks and > months in? I believe that it is customary to use Earth units when you do > not > specify. And in this case, the topic was brought to the community just > about > 0.5 week, or 0.11 month ago. > > Sarcasm aside, I take that to mean that SPI has been involved with those > discussions for months in a private and closed process. Michael asserted > that > an open inclusive process is better than the usual closed approach whence > the > funding goes through a company. > > It looks to me that those SPI discussions were just as opaque and closed, > and > all the talk of openess is just pretense. It does not help that Michael, > and > now you too, misrepresent any challenge to SPI proposed *process* as an > attempt to reject the idea of STF sponsorship, under the convenient > pretext > that there is not enough time. > > > This is further aggravated by the context that Michael brought forward the > idea of funding developers through SPI 3 months ago (in actual Earth > units). > From your statement, I have to infer that Thilo, Michael and SPI already > knew > of the STF plan and concealed that key piece of contextual information > back > then. > > In hindsight, it feels hypocritical to me that they were arguing for the > SPI > path, and against the corporate path, on the basis of openess already > then, to > be honest. > > > I can only agree with Anton that this looks like an attempt to strongarm > the > community. This is ostensibly being to ignore all the objections that were > already brought in October and are being brought again now, with the > complicity of SPI. I can't say that this looks well on SPI, but that's > just my > personal opinion. > > > With all that said, I don't think anybody will attempt to prevent this > from > happening (if they even can?). But that will take place without the > consent of > the GA, without any legitimacy on the claims of openess and inclusiveness, > and > obviously without any form of preclearance from the technical > appropriateness > of the resulting code contributions. > > > > -- > レミ・デニ-クールモン > http://www.remlab.net/ > > > > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Sovereign Tech Fund
gt; might want to have the Scope of Work rolling before starting this. (And > there are many possible solutions, so I expect quite some time to be spent > finding all of them and picking out the best one). > > If you start discussing how to properly pay for the hours spent hunting > simple typo mistakes now, you'll never be able to tell STF what actually > needs to be done in time. > > -- > Jonatas L. Nogueira (“jesusalva”) > Board of Directors Member > Software in the Public Interest, Inc. > > > On Wed, Jan 31, 2024 at 12:17 PM Kieran Kunhya wrote: > >> On Wed, 31 Jan 2024 at 14:10, Jonatas L. Nogueira via ffmpeg-devel < >> ffmpeg-devel@ffmpeg.org> wrote: >> >>> > 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 FFmpeg community was told about this three days ago. >> >> Kieran >> > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Sovereign Tech Fund
> The FFmpeg community was told about this three days ago. Fair enough if it's true (I'm an outsider, after all) > 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. What I noticed (as an external observator), was putting the cart ahead of the horse. There's no money right now, but STF is willing to grant around 200k if FFmpeg is able to submit a Scope of Work in time for their meeting (happening on Feb 14th, materials however should be submitted 48 hours before). The scope of work is, in other words, a letter of intentions of what to do with such money. They have already informed about the restrictions (e.g. should be maintenance or security related, that it is too early to ask for feature projects but it might be possible in the future, etc). A Scope of Work is a bit more than a wishlist because it assumes the work is actually going to be done, so it cannot be too overambitious. That's what needs to "act now or all the money is gone". The question currently presented is, "if FFmpeg had 200k euros to work with maintenance, what would FFmpeg do?" ─ this will become the Scope of Work (we can have people to word it into legalese later, if needed). Of course, all that will end in a Statement of Work (SOW) later, describing how the wishlist in the Scope of Work will be attained as everyone knows that money doesn't magically solve problems. And from what I've seen as an external observer, there is a lot of discussion pending for this. But that's alright, there's probably over a month for that. Of course, without a Scope of Work, there'll be no SOW, and any discussion made on this will become a waste of time. If I were the one doing it... I would first make a wishlist in a shared document with all tasks eligible (3~5 days, so completion until Feb 5th latest). There are time constraints, though, and FFmpeg takes decisions collectively, so... I would make a vote between Feb 5th and Feb 12th (yes, the deadline) to elect the tasks which will be on the Scope of Work. I would improvise a bit: ask the submitted tasks to also have a proponent (who is asking for the task to be done) and a budget (how much money the proponent thinks that will be enough to attain it). The budget here is nonsense, it is just to have a metric to decide how many options will go to the Scope of Work. The proponent is to answer questions the voters may have. With that laid out and once in motion, the remainder of discussion would be held. How much to pay the contributors, the actual budget for the approved projects, how it'll be tracked, what's more fair for deliverables, how they'll be checked, if you'll contract the developers directly or with an intermediary, etc. There's no point discussing any of that unless you're sure the scope of work can be delivered in time. Multiple Statements of Work are also possible, so there's no actual need for one-size-fits-all in those questions. If project A, B and C can be divided into commits but project D cannot, it's fine to have different rules for project D. Also why it doesn't make much sense to hold these discussions now, when you can't even answer what would be the projects. That, however, is not my call. I can provide suggestions, but actually coming with a Scope of Work in time is yours and yours alone. > 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. Coincidentally, that happens a lot. No reason to let it hinder you, though, having money gives the option to make job postings, and you might even be able to ask for help in spi-general list. > only a minority of time is spent typing code. Don't I know it... I'm also a programmer for The Mana World, pretty familiar with "I changed a couple lines and now nothing works, spend two hours trying to figure out that I forgot a curly brace". That is among the discussions I believe FFmpeg should have, although you might want to have the Scope of Work rolling before starting this. (And there are many possible solutions, so I expect quite some time to be spent finding all of them and picking out the best one). If you start discussing how to properly pay for the hours spent hunting simple typo mistakes now, you'll never be able to tell STF what actually needs to be done in time. -- Jonatas L. Nogueira (“jesusalva”) Board of Directors Member Software in the Public Interest, Inc. On Wed, Jan 31, 2024 at 12:17 PM Kieran Kunhya wrote: > On Wed, 31 Jan 2024 at 14:10, Jonatas L. Nogueira via ffmpeg-devel < > ffmpeg-devel@ffmpeg.org> wrote: > >> > IMO hasty actions and avoidable drama may cause damage to the project >
Re: [FFmpeg-devel] Sovereign Tech Fund
> 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 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 deci
Re: [FFmpeg-devel] Sovereign Tech Fund
Anton: "whether anything requires the projects to be owned by individuals"... I don't think so. At least, not from the SPI side, STF might have objections which I cannot anticipate. But from the SPI side, we probably could do a MSA/SOW with a company rather than individuals just fine, although I would still have to check with the attorney though as our MSA and SOW are optimized for individuals. As long as the final price is something that SPI, STF, IRS, and Bundestag can agree with and the job is within the scope of work, that is. In such case, STF would transfer money to SPI, SPI would sign a SOW with FFlabs, FFlabs would hire you (this has some implications, like FFlabs owning the code), then FFlabs would report completion to SPI, SPI would check if the complete work is according the SOW (peer-review + liaison approval/veto), and if everything is good, SPI would pay FFlabs. With individuals: STF would transfer money to SPI, SPI would sign a SOW with every developer, then the developer would report completion to SPI, SPI would check if the complete work is according the SOW (peer-review + liaison approval/veto), and if everything is good, SPI would pay the developer directly. Note 1: Please don't forget that the idea of the currently discussed grant, as I understand it, is maintenance and security work, not projects, so while one would need the finished Scope of Work to be sure, I don't expect #1 (pre-approval) to be an actual issue. Note 2: Doing this with a company is usually more expensive than contracting with the devs directly, so as I said, you would need to check with STF, and just like SPI won't pay for developers without the deliverables, same apply to a company (where the company could still need to pay the developers anyway). Note 3: What you need more urgently is the Scope of Work. From what you said, you might even want the GA to vote on it, and if you take a whole week for it as advised in your FAQ, then you need it done even earlier, by February 5th, giving you exactly a week to finish this. There are several potential solutions for the other issues, including practical ones like e.g. a document from the General Assembly making an incomplete MR/PR equivalent to a commit, or impractical ones like e.g. requiring all contractors to record their screens while doing the tasks and sending the low-res video to confirm they work, but none of them matter if the Scope of Work cannot be finished in time. Note 4: I am an outsider, external to FFmpeg ─ my goal here is to answer questions and support you in securing the funding. I'm not paid by SPI to do this, my time is not infinite and the time I can spare is not exclusive for FFmpeg but has to be shared among all the 42 SPI associated projects, so I would highly appreciate if you could be topical, that is, leave "dirty laundry", votes of no-confidence and such to the Community Committee and keep here only the immediately relevant part for getting the sponsorship unblocked (e.g. "The Technical Committee should send a list of contested commits and SPI should delay payment over those until the TC issues a decision"). Offtopic not only derails but wastes everyone's time. Would it help if I set up a shared Google Docs? I'm here to answer questions, but if you're in need of support of any kind just ask. I'm honestly rooting for FFmpeg to succeed, after all, even if it doesn't matter much for SPI if you decide you are better off without funding, maintaining your code or hiring help for security tasks. -- Jonatas L. Nogueira (“jesusalva”) Board of Directors Member Software in the Public Interest, Inc. On Mon, Jan 29, 2024 at 6:11 PM 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: > > 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 histor
Re: [FFmpeg-devel] Sovereign Tech Fund
Please keep in mind we're a public charity using public money from taxpayers, which means we need a criteria for payments and that said payments must be issued objectively. The GA might be able to distribute money with subjective criterias... But not this specific money which is being discussed. I mean, anyone would get mad if their elected officials did that with tax money, so obviously the same will extend here. (Remember the time when an infamous mayor used public money to fix only the roads surrounding his home? Yeah, let's not do this, alright?) If commits are a no-go because FFmpeg has internal governance issues on how those happen, we can think of something else, as long as it retains the objectiveness expected from the use of public money. But we're putting the cart ahead of the horse. Please don't get bogged down by the details, move forward with the scope of work — that's the written version of how STF funds can serve both STF as FFmpeg's purposes. A journey of a thousand miles begins with a single step, if you focus on the future steps you'll trip, fall, and lose the opportunity for the sponsorship. There are only a couple weeks longer to finish the Scope of Work, and that blocks pretty much everything. STF said itself that the other details can be discussed later. Michael: It's not very dissimilar, no. X.Org recently made something similar to Outreachy, the Endless Vacations of Code program (EVoC), if you prefer to make it more similar to that it might be possible. A few things to keep in mind in such a case: The stipend is fixed and agreed beforehand, there are less reports and payments to make, you can only hire in an educational capability (so not the staff you're looking for), it is less suitable for continuous tasks (which was the original issue), and you still need the Scope of Work before it begins. I believe you can actually do both via contracts as via education programs if you wanted, but the latter might be of limited use to you. Att., -- Jonatas L. Nogueira (“jesusalva”) Board of Directors Member Software in the Public Interest, Inc. On Mon, Jan 29, 2024 at 3:32 PM Kieran Kunhya wrote: > > > On Sun, 28 Jan 2024 at 21:47, Michael Niedermayer > wrote: > >> Hi Kieran >> >> On Sun, Jan 28, 2024 at 08:42:00PM +, Kieran Kunhya wrote: >> > On Sun, 28 Jan 2024, 20:37 Kieran Kunhya, wrote: >> > >> > > Both work fine really. For example iam not employed by FFlabs and the >> work >> > >> i did for them is just by sending invoices, while what i do qualifies >> > >> maintenance probably close to 100%. >> > >> >> > > >> > > Fflabs is a private company that can choose however it likes how to >> > > distribute its funds. STF/SPI/FFmpeg are not the same. >> > > >> > > Would you like every invoice you make to be on this mailing list and >> > > discussed in depth in public? And if that invoice was voted against >> by the >> > > GA what would you do? >> > > >> > > Kieran >> > > >> > >> > Remember the outcry about SDR that literally drove people away from the >> > project? Well imagine that for one of your invoices. >> >> Do you mean it would drive them away because of how much or how little i >> work for ? >> Or becuase of what i work for ? >> > > You refused to acknowledge the public outcry over SDR for months and > pushed patches the community clearly objected to (see andreas thread). > > That could clearly apply to invoiced work that the community disagreed > with. What would you do then? You weren't willing to compromise last time > for your hobby, what makes you willing to compromise in that situation? > > I mean it basically happened already with SDR, just without an invoice. > > "I think you should try to bring the work you want funded into the > framework > that they told us to use. Instead of complaining" > > And now you follow the same tactics with Derek. Accusing people of > disagree with you of spreading resentment. > > Kieran > > Sent from my mobile device > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Sovereign Tech Fund
Again, this sounds like a misunderstanding.
The SOW is subservient to the merge, not the other way around. In other
words, the SOW don't require you to merge, but when/if you do merge, then
the SOW will require the payment to the contractor, which SPI handles. So
the SOW makes clear that if FFmpeg refuses to merge, there'll be no payment.
This is also why there's no need to review the invoices, and no risk of a
legitimate invoice being rejected: Because the deliverable will likely be
the commit (unless the GA objects beforehand and asks SPI to use something
else), so until it (the MR/PR) is accepted, there's no invoice to start
with. And as STF is footing the bill, there's no reason to FFmpeg concern
itself if it turned out expensive or not when reviewing, and can focus in
actually improving the program (SPI and STF will place some budget limits,
so contributors/contractors know what to expect and the money won't run
out).
The goal of the SOW (and of having SPI onboard) is to allow the GA to focus
on stuff actually relevant to FFmpeg (like what's going to be merged) and
delegate the worldly concerns like payments and contracts to SPI. Who is
signing the contracts (and thus being bound and tied to it) is SPI.
This is why it sounds a lot like a misunderstanding. What is actually
required from the GA is what the GA does — managing and leading FFmpeg.
That means deciding aspects which SPI cannot and will not decide for you,
like the scope of work ("what do you want done and sponsored by STF?"), and
what SPI cannot answer for you (such as how FFmpeg does things).
Do note that if someone do a MR/PR and then the technical committee or the
GA refuse to merge, without a SOW, almost every court (in the US or in
Germany) will force FFmpeg to pay not only the invoice but also the legal
costs. That would be unacceptable for SPI, as it puts other projects in
risk as well. We must kindly request that FFmpeg's General Assembly avoid
such dangerous behavior.
Feel free to make any other questions you may have,
Att.,
Jonatas L. Nogueira (“Jesusalva”)
SPI Board of Directors
On Mon, Jan 29, 2024, 12:02 Kieran Kunhya wrote:
>
>> >> [...] the GA definitly cannot object to an invoice for a project that
>> the GA approved previously.
>> > "The General Assembly is sovereign and legitimate for all its decisions
>> regarding the FFmpeg project."
>>
>> When working with a contract (and a SOW), the General Assembly won't be
>> able to block an invoice.
>> Because the General Assembly will already have exercised its sovereignty
>> before the work started.
>> And unless the GA becomes a nation, any court of law would uphold the
>> contract.
>>
>
> In this project, acceptance of a patch is based on the technical contents
> of a patch, not a few vague paragraphs in a SoW. These decisions are made
> by the Technical Committee and the General Assembly.
>
> Tying the project contractually is unacceptable.
>
> There are plenty of "corporate" open source projects where this is fine,
> but there is a reason we are not one of those full of corporate friendly
> code like binary blobs, intrinsics, SDKs etc.
>
> Kieran
>
>>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Sovereign Tech Fund
Keep in mind I only receive messages if I'm explicitly in the To field. I'm with only half of the context, so my messages may sound weird, out of context, repetitive, etc. In any case. >> [...] the GA definitly cannot object to an invoice for a project that the GA approved previously. > "The General Assembly is sovereign and legitimate for all its decisions regarding the FFmpeg project." When working with a contract (and a SOW), the General Assembly won't be able to block an invoice. Because the General Assembly will already have exercised its sovereignty before the work started. And unless the GA becomes a nation, any court of law would uphold the contract. So the first statement which I have no context of would be correct with SPI's approach; the GA would not (realistically) be able to object to the invoice, unless it is in breach of the contract/SOW. (But if it is in breach of the contract or the SOW, then SPI will refuse to pay anyway). > You misunderstand this community. There are disagreements going on for decades. I've worked with worse. FFmpeg asked to divide the work in milestones, so focus on where you agree with. Whatever there's disagreement, you can always apply later for more funding. (At least from what I've understood). For example, everyone can agree improving code readability is a good thing, even if not how. That's a good start. Ask for funding for it. The "how" can be done later (see the PS). > Would you like every invoice you make to be on this mailing list and discussed in depth in public? And if that invoice was voted against by the GA what would you do? There's no need for that, you know? One of the reasons to have a SOW is exactly to avoid such fights. After all, the scope of work is decided before (and you need to do this anyway, to ask for STF funding). In an ideal scenario, invoices only need to be checked for legitimacy ─ if the issuer is the one who worked, if the work is on the scope, if the time spent isn't absurd, etc. So there would be no need for the whole assembly to involve itself, unless it's an appeal. But of course, if you want every invoice there, it likely can be done, as long that privacy laws are observed. > I am sure neither STF nor SPI will mind if we reject all the money. SPI is a public charity, so if you want to reject the money, that is not our problem. We're here to support you if you do decide to accept, though. SPI handles non-technical administrative tasks, after all. Do keep in mind that SPI acts as a fiscal sponsor. This means that we're taking care of all the paperwork involved, but also assuming the risks. So if e.g. some payment is improperly documented and must be returned, SPI has the duty to return it. You can do it with some other entity ─ SPI is a public charity, we honestly don't mind ─ but do keep in mind that if you don't document everything adequately, SPI will not be held responsible if it didn't pass by SPI. > lets rather work towards making a list of projects, agreeing to them and submitting an application to STF This is pretty much the Scope of Work, and that would account for half of a SOW (and also the most important part of it). One of the reasons why SPI insists on doing the SOW is because we concluded it would present better governance (so less risks for you, for STF, for SPI and for the contributors) and that it would be expedient to do (as you're already going to do the upper half when asking the funding). The bottom part (schedule, deliverables and payment) do need your input on what works best for FFmpeg, but ultimately it is mostly operational guidelines expected from contributors and SPI alike. *When do you want contributors to report their work, and how?* *How will the due amount be calculated? When should the invoice be sent? When should it be paid?* That's pretty much what's required to fill out the proposed SOW. If you cannot get a scope of work, you definitely cannot get funding (and if you get funding, then what you used is most likely an acceptable scope of work, so it likely won't need changes either). If you cannot decide the other details, then odds of being required to return the money are high. Asking for a SOW might sound like asking for a lot of work, but it is paperwork, and you can count on SPI to do paperwork for you. But SPI acts on your behalf (and never you on SPI's behalf), so you do need to instruct us on how you want it to look like. "How can SPI and the contractor know that something on the invoice is (in)adequate?" That's the sort of thing the bottom of the SOW worries about. And I already said this earlier, but the bottom part is not important right now. Securing funding and the scope of work take precedence. In the worst case, we can just ask our attorney to draft the SOW altogether. He'll make a few questions, you answer them, and we use whatever comes out of that. SPI is here so paperwork doesn't block you, and if paperwork does block you, then SPI will not be doing a v
Re: [FFmpeg-devel] Sovereign Tech Fund
While it's true a traditional SOW breaks work into milestones, we're going for a simplified one here out of need. Think on when you ask for consulting, not when you ask for a feature. You should not assume we want to write eg. "Finish removing YUVJ by date X" ─ that's not the plan and as you said it makes no sense (even less when you consider the SOW are individual agreements, and we're likely going to have multiple people working on it). The timeframes aren't "finish X by Y", they're "report what you did by date Y". In a sense, the report is the actual deliverable. The Scope of Work isn't "only touch X", but the conditions on which payment is acceptable (or not). As you said, the sponsorship is for maintenance work, so it should make clear that features aren't eligible (on that SOW at least). Otherwise, someone could make a feature nobody asked for, even less needs it, and want to be paid for it. Or find some busywork which doesn't help in the slightest and come wanting money. So if you had to refactor a whole code because you're working on X, that's fine, but if you decide to refactor the code because you think it's ugly and wanted to refactor it then it might not be what you want to pay for. Or maybe you want, refactoring can improve code readability and no one normally does that. I'm not writing the scope, you are, I at most convert it to legalese when/if required. No one is getting paid for signing a contract and merry be merry, and it's not acceptable to just give money "as we deem fit" (just think of all the possible complaints and hours you'll waste with people questioning why you paid more for A than for B). That would be poor governance, I also doubt STF would be willing to sponsor if there's not even a scope of work. I am attaching a quick example draft (actually a mockup) I made just now in hopes to make it easier to visualize what is expected from the SOW. This is not for review, it is for illustration purposes.*** *It is a quick draft/mockup with random information written under a hour just for visualization, and will not be used when the actual SOW is prepared, I just wanted to make it easier to see what I'm thinking about for the SOW. The first thing to prepare is section 2 (Scope of Work), as we need to report it to STF beforehand. It is what STF is (or is not) willing to pay for, and by consequence what FFMPEG is (or is not) willing to pay for. It is the priority, as there *is* a deadline to finish it and deliver it to STF (Feb 12th). Of course, it probably could have said "tasks with a 'maint' label on the issue tracker" or whatever, it's not like I ran this mockup by a legal counsel nor anything. Section 3 and 4 will likely later be required by STF as they have to do their own audit, but this likely can be delayed for after the grant is approved. It also seems to be somewhat controversial at the moment, so I suggest that instead of straying into heated debates over publicity of the invoices, conflicts of interest and whatnot, we focus on securing the funding first (which means the first page of the mockup). After we have a solid scope of work to present to STF, we can worry about how the funds will be distributed (the mockup is hour-based and monthly, but as I said, there are other ways to distribute them) and how the approval process will go. (And in theory, the person could provide their own hourly rate, although I see no reason why anyone would do so). Again, I'm available to answer any questions you may have. And on that note: I believe the same as Michael regarding OFAC restriction as unlike Russia or North Korea, there is no ban against China residents, but we can ask the legal counsel on the specific cases if the need arises. Regards, -- Jonatas L. Nogueira (“jesusalva”) Board of Directors Member Software in the Public Interest, Inc. Example SOW for FFMPEG.pdf Description: Adobe PDF document ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Sovereign Tech Fund
Note: I have no idea what YUVJ is (I assume you want to remove it, not to implement it?) and I forgot to mention "reverted work" (likely in the form "work not yet merged or reverted within 30 days after being merged"). The goal here was to make easier to understand what's expected. Of course, I can help with legalese if you explain to me and review it afterwards, just let me know in such case. Att. Jonatas L. Nogueira (“Jesusalva”) On Sun, Jan 28, 2024, 16:20 Jonatas L. Nogueira wrote: > That's not a problem at all; because you can divide the work into discrete > pieces after it's done (on the invoice), just like liberal professionals > (eg. accountants, lawyers, administrators, etc.) > > The SOW defines what is acceptable on the invoice (so in the YUVJ case, > for example, it could be "code related to YUVJ implementation and bugs > arising of it, as well as review of the PRs/MRs associated with it, but not > tagging issue tickets, duplicated work or code formatting" — I have no > idea, this is just for inspiration), as well as the timeframes by when they > should submit the invoices (and if they need to submit any other proof of > their work, what and when). It should also define how payment works > (typically by hour or by code line, there's some leeway here though), > what's the maximum budget (specially if the metric is exploitable), the > value of which unit of work (defined before) which must not be above the > market price. > > Contributors are not employees, they don't need to login at 8 and logout > at 17 for a fixed wage. In fact, they might not do anything and thus no > money be due to them at all. That's why we make a SOW, it makes clear what > they can do, how much they can earn, what will not be paid (usually > unrelated work) even if they do, and by when they should submit invoices > and evidences of the work they did to receive payment. > > Do say if there are still questions, I'll be happy to answer and help here. > > Regards, > > Jonatas L. Nogueira (“Jesusalva”) > > On Sun, Jan 28, 2024, 15:59 Kieran Kunhya wrote: > >> > Statements of Work and milestones (by definition) are for features. >>> >>> The SoW suggestion/need came from a lawyer that jonatas asked IIUC. >>> so i can just suggest to put work like what you list above into a SOW >>> like >>> framework. Or maybe Jonatas can clarify, in case i misunderstood >>> >> >> My point is that ongoing maintenance can't be split into discrete pieces >> of work, nor arguably can a given timescale be associated with cleanup. >> For example YUVJ is difficult, until you remove it and see the bugs you >> don't know how long it will take. This is not suited to the bounty/SoW >> methodology. >> >> We don't need STF to be funding features, we need maintenance, >> infrastructure etc which all lends itself to salaried work. >> >> Kieran >> > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Sovereign Tech Fund
That's not a problem at all; because you can divide the work into discrete pieces after it's done (on the invoice), just like liberal professionals (eg. accountants, lawyers, administrators, etc.) The SOW defines what is acceptable on the invoice (so in the YUVJ case, for example, it could be "code related to YUVJ implementation and bugs arising of it, as well as review of the PRs/MRs associated with it, but not tagging issue tickets, duplicated work or code formatting" — I have no idea, this is just for inspiration), as well as the timeframes by when they should submit the invoices (and if they need to submit any other proof of their work, what and when). It should also define how payment works (typically by hour or by code line, there's some leeway here though), what's the maximum budget (specially if the metric is exploitable), the value of which unit of work (defined before) which must not be above the market price. Contributors are not employees, they don't need to login at 8 and logout at 17 for a fixed wage. In fact, they might not do anything and thus no money be due to them at all. That's why we make a SOW, it makes clear what they can do, how much they can earn, what will not be paid (usually unrelated work) even if they do, and by when they should submit invoices and evidences of the work they did to receive payment. Do say if there are still questions, I'll be happy to answer and help here. Regards, Jonatas L. Nogueira (“Jesusalva”) On Sun, Jan 28, 2024, 15:59 Kieran Kunhya wrote: > > Statements of Work and milestones (by definition) are for features. >> >> The SoW suggestion/need came from a lawyer that jonatas asked IIUC. >> so i can just suggest to put work like what you list above into a SOW like >> framework. Or maybe Jonatas can clarify, in case i misunderstood >> > > My point is that ongoing maintenance can't be split into discrete pieces > of work, nor arguably can a given timescale be associated with cleanup. > For example YUVJ is difficult, until you remove it and see the bugs you > don't know how long it will take. This is not suited to the bounty/SoW > methodology. > > We don't need STF to be funding features, we need maintenance, > infrastructure etc which all lends itself to salaried work. > > Kieran > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
