RfP Submission Guide

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 <lkcl at lkcl.net>
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.