# RfP Submission Guide * HDL workflow guide page: [[HDL_workflow]] * LibreSOC bug process page: [[HDL_workflow/libresoc_bug_process]] * New bug for further LibreSOC documentation: [bug #1233](https://bugs.libre-soc.org/show_bug.cgi?id=1233) * email thread detailing RfP submission process: * Meeting used to introduce team to this process: * *RfP submission walkthrough on IRC*: [IRC log](https://libre-soc.org/irclog/%23libre-soc.2023-12-21.log.html#t2023-12-21T14:24:42) ## Verbatim copy of email thread ## email 1 Hi Luke, Based on our conversation on bug #701, Luke suggested to start a mailing list thread which we can use as part of documenting RfP submission in general. This will then be added to: https://libre-soc.org/HDL_workflow/libresoc_bug_process/ Thanks, Andrey ## email 2 On Tuesday, December 5, 2023, Andrey Miroshnikov via Libre-soc-dev < libre-soc-dev at lists.libre-soc.org> wrote: > Hi Luke, > > Based on our conversation on bug #701, Luke suggested to start a mailing list thread which we can use as part of documenting RfP submission in general. This will then be added to: > https://libre-soc.org/HDL_workflow/libresoc_bug_process/ ah. yes. ok so first thing: the secret URLs are to be respected and treated as plaintext passwords. you DO NOT put them on the internet or send them to people on publicly logged Libre-SOC resources. https://bugs.libre-soc.org/show_bug.cgi?id=1126#c48 second: you click the "New Request" button then fill in your bank details and name from the dropdown. then you put in the amounts, under each milestone. third: you go to the bugtracker and fill in the TOML field with "name={amount=NNNN, submitted=YYYY-MM-DD}" in that EXACT format, because it is machine-readable. ***EXERCISE EXTREME CAUTION HERE BECAUSE YOU ARE EDITING FINANCIAL BOOKKEEPING RECORDS*** if you are uncertain STOP DO NOT PROCEED ASK FOR ADVICE IMMEDIATELY. it is best that you WAIT until someone on IRC can walk you through the process, or set up a conference call with screen-sharing to REVIEW YOUR CHANGES ***BEFORE*** YOU HIT THE BUGZILLA SUBMIT BUTTON. fourth: you run the budget-sync program LOCALLY on your personal machine, and if it produces errors and you know how to correct them then do so, but if not STOP, do NOT attempt further changes, instead IMMEDIATELY ask for help on both IRC and the mailing list. this is a REQUIRED (mandatory) action. do NOT if you make a mistake "just leave it" as your actions will have consequences for everyone who then also tries to run budget-sync. fifth: find your own task_db/yourname.mdwn file, return to the NLnet RFP and cut/paste the relevant autogenerated sections into the "results" form. you *do not* repeat DO NOT have to write a long-winded report: you can write one *if it is useful to the project* but should in no way feel "obligated to write one just for NLnet". if you do write one it should be placed PUBLICLY onto Libre-SOC resources, and the *URL* given in the associated bugreport under comment #0 (which you can of course edit to include it). basically NLnet are flexible and trusting but MUST have ACTUAL EVIDENCE of completion of the milestone, whatever that may be, such that an EU Auditor is satisfied that no fraud has taken place (yes, this *has* actually been attempted in the past, by scammers). sixth: hit the submit button, review the page and then submit the RFP. (NOTE: it is strongly recommended you take a screenshot or do a "print page" to make sure that you have the bank records correct! NLnet's database may get corrupted or you might have one digit wrong) seventh: the MoU Signatory will have been notified by email, and should review the submission. DO NOT just "click yes", you must ACTUALLY do Due Diligence as you are RESPONSIBLE FOR ENSURING COMPLIANCE with the Memorandum of Understanding and for knowing the FULL consequences of getting things right or wrong here. that's basically it, other than we have been asked by NLnet to set up some CI which shows actual unit test results passing (or, ha, failing). this will need some work as there is NO WAY we can submit multi-megabyte unit test results with THOUSANDS of unit tests... oh look, somwehere buried in that there is ONE that is actully relevant. no. we need to keep NLnet's workload RIGHT down by giving them as BRIEF and compact a "review" task as is humanly possible whilst also giving them enough heads-up to PRE-EMPT any EU Auditor questions. PLEASE NOTE: for the >50k Grants an Audit is a *HUNDRED PERCENT* guaranteed, as part of the *EU* Funding conditions. it is NOT hypothetical or a "lottery" (like the one that came up a few months ago where NLnet had its first *full* Audit of its entire project suite, by an EU Auditor). even for the <=50k Grants we there have to assume that an Audit could take place at any time, and therefore also act pre-emptively to provide NLnet with satisfactory answers to questions that the EU Auditor will be asking to determine if Fraud is or is not taking place. i trust that that hammers home that this is in fact really quite serious and a hell of a responsibility, because we are representing NLnet's trust in us to keep these Financial Records meticulously accurate, in order to not have ourselves be accused of Fraud or money-laundering by the EU and thus bring both ourselves *and NLnet* into serious disrepute. as a reminder this was why i had to call an Emergency Freeze and full audit of the OPF ISA WG Grant Financial Records a few months ago. i *really* do not want ever to have to do that ever again, so i expect everyone to LISTEN and take the above on board and treat it with the seriousness it requires. once again if there is anything you are hesitant about or feel you must "assume" stop immediately and ask for help. l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 ### email 3 > > seventh: the MoU Signatory will have been notified by email, > and should review the submission. DO NOT just "click yes", > you must ACTUALLY do Due Diligence which includes checking that the "submitted" date is correctly entered for each milestone under its TOML field, and contacting the submitter to ask that they update it *before* clicking the "approve" button. do not do this for them (except under mitigating circumstances), walk them through the process. over IRC is the better medium as it is both interactive *and logged* so if there are mistakes or constructive feedback required there is a full audit log to analyse to see what went awry, and why. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 ### email 4 On Wednesday, December 6, 2023, Luke Kenneth Casson Leighton wrote: > walk them through the process. over IRC is the better medium > as it is both interactive *and logged* so if there are mistakes > or constructive feedback required there is a full audit log > to analyse to see what went awry, and why. ninth: the person will receive their payment, and as part of the secret URL there is a table stating "paid date" against each RFP. the person is *required* to go back through the milestones against which they first added "submitted=YYYY-MM-DD" and to now add "paid=YYYY-MM-DD" on every single one. (there is a mode of budget-sync that can perform this action automatically, documented in the README, but it should ONLY be used if properly understood as it can perform "mass change" risking destruction of the Financial Records if abused. ONLY use this program under STRICT supervision, on the logged IRC Channel, with an experienced Authorized MOU Agent/Signatry guiding and monitoring its use). as with "submitted" run budget-sync to ensure that you have not caused "damage" to the Financial Records. tenth: notify the MoU Signatory Agent (Project Lead) that the payment records have been updated. the Project Lead *should* be receiving bugzilla change notifications but that does not guarantee they have been seen: it is your responsibility to keep notifying them and escalating until you have received an *acknowledgement*. eleventh: the Project Lead (MoU Signatory) then needs to double-check the Financial Records, by re-running budget-sync, then going to the mdwn/{payee}.mdwn file and check that all tasks on the corresponding NLnet RFP have moved to a "paid by NLnet" section. they should all have the same "paid" date because RFPs are never split. there should also neither be tasks listed as "paid" that are not listed on the RFP, or tasks on the RFP but that are not listed on the payee mdwn file. if there are this needs to be raised on Audit-tracked Libre-SOC resources, NOT discussed privately with the payee, requesting that they review and if necessary correct any discrepancies. yes this really is this astoundingly meticulous, specific and detailed, and requires extreme thorough rigour, patience and diligence. that diligence and meticulous attention is why we have been trusted with the order of HALF A MILLON Euros of EU Grant money over the past five years. it all comes down to being able to demonstrate, if asked, in effect, putting it plainly: "are you committing fraud here?" we can categorically answer NO. l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 # TODO: Refactor or remove the content below, probably duplicate... ## Checks beforehand - Is the task under a grant sub-task? - Has the grant been accepted by NLnet **and** MoU signed? (Work on tasks can begin after grant accepted, but RfP submission **only** after MoU signing.) - Has NLnet set the RfP system for the grant (and provided *the secret URL* for the team members to make RfPs)? - Has the task been declared complete? The comment section of the bug needs to have a clear history of completed work (sub-tasks, git commits, development thoughts). ## NLnet RfP system This site can only be accessed by a secret URL. This URL will be distributed to MoU signees by Andrey or Luke after NLnet confirms the RfP system is in place. ## Making a submission 1. Go to the NLnet RfP system via the secret URL. 2.