HDL_workflow/rfp_submission_guide.mdwn

   1 # RfP Submission Guide
   2
   3 * HDL workflow guide page: [[HDL_workflow]]
   4 * LibreSOC bug process page: [[HDL_workflow/libresoc_bug_process]]
   5 * New bug for further LibreSOC documentation: [bug #1233](https://bugs.libre-soc.org/show_bug.cgi?id=1233)
   6 * email thread detailing RfP submission process:
   7 <https://lists.libre-soc.org/pipermail/libre-soc-dev/2023-December/005829.html>
   8 * Meeting used to introduce team to this process:
   9 [[meetings/sync_up/sync_up_2023-12-19]]
  10
  11 ## Verbatim copy of email thread
  12
  13 ## email 1
  14
  15     Hi Luke,
  16
  17     Based on our conversation on bug #701, Luke suggested to start a mailing
  18     list thread which we can use as part of documenting RfP submission in
  19     general. This will then be added to:
  20     https://libre-soc.org/HDL_workflow/libresoc_bug_process/
  21
  22     Thanks,
  23
  24     Andrey
  25
  26 ## email 2
  27
  28     On Tuesday, December 5, 2023, Andrey Miroshnikov via Libre-soc-dev <
  29     libre-soc-dev at lists.libre-soc.org> wrote:
  30     > Hi Luke,
  31     >
  32     > Based on our conversation on bug #701, Luke suggested to start a mailing
  33     list thread which we can use as part of documenting RfP submission in
  34     general. This will then be added to:
  35     > https://libre-soc.org/HDL_workflow/libresoc_bug_process/
  36
  37     ah. yes. ok
  38
  39     so first thing: the secret URLs are to be respected and treated
  40     as plaintext passwords. you DO NOT put them on the internet
  41     or send them to people on publicly logged Libre-SOC resources.
  42
  43       https://bugs.libre-soc.org/show_bug.cgi?id=1126#c48
  44
  45     second: you click the "New Request" button then fill in your
  46     bank details and name from the dropdown. then you put
  47     in the amounts, under each milestone.
  48
  49     third: you go to the bugtracker and fill in the TOML field
  50     with "name={amount=NNNN, submitted=YYYY-MM-DD}" in that
  51     EXACT format, because it is machine-readable.
  52
  53     ***EXERCISE EXTREME CAUTION HERE BECAUSE YOU ARE EDITING
  54       FINANCIAL BOOKKEEPING RECORDS***
  55
  56     if you are uncertain STOP DO NOT PROCEED ASK FOR ADVICE
  57     IMMEDIATELY. it is best that you WAIT until someone on
  58     IRC can walk you through the process, or set up a conference
  59     call with screen-sharing to REVIEW YOUR CHANGES ***BEFORE***
  60     YOU HIT THE BUGZILLA SUBMIT BUTTON.
  61
  62     fourth: you run the budget-sync program LOCALLY on your
  63     personal machine, and if it produces errors and you know
  64     how to correct them then do so, but if not STOP, do NOT
  65     attempt further changes, instead IMMEDIATELY ask for help
  66     on both IRC and the mailing list. this is a REQUIRED
  67     (mandatory) action. do NOT if you make a mistake "just leave it"
  68     as your actions will have consequences for everyone who then
  69     also tries to run budget-sync.
  70
  71     fifth: find your own task_db/yourname.mdwn file,
  72     return to the NLnet RFP and cut/paste the relevant
  73     autogenerated sections into the "results" form.
  74
  75     you *do not* repeat DO NOT have to write a long-winded
  76     report: you can write one *if it is useful to the project* but
  77     should in no way feel "obligated to write one just for NLnet".
  78     if you do write one it should be placed PUBLICLY onto
  79     Libre-SOC resources, and the *URL* given in the associated
  80     bugreport under comment #0 (which you can of course edit
  81     to include it).
  82
  83     basically NLnet are flexible and trusting but MUST have
  84     ACTUAL EVIDENCE of completion of the milestone, whatever that
  85     may be, such that an EU Auditor is satisfied that no fraud
  86     has taken place (yes, this *has* actually been attempted in
  87     the past, by scammers).
  88
  89     sixth: hit the submit button, review the page and then
  90     submit the RFP.
  91
  92     seventh: the MoU Signatory will have been notified by email,
  93     and should review the submission.  DO NOT just "click yes",
  94     you must ACTUALLY do Due Diligence as you are RESPONSIBLE
  95     FOR ENSURING COMPLIANCE with the Memorandum of Understanding
  96     and for knowing the FULL consequences of getting things right
  97     or wrong here.
  98
  99     that's basically it, other than we have been asked by NLnet
 100     to set up some CI which shows actual unit test results
 101     passing (or, ha, failing). this will need some work as there
 102     is NO WAY we can submit multi-megabyte unit test results
 103     with THOUSANDS of unit tests... oh look, somwehere buried
 104     in that there is ONE that is actully relevant.
 105
 106     no.
 107
 108     we need to keep NLnet's workload RIGHT down by giving
 109     them as BRIEF and compact a "review" task as is humanly
 110     possible whilst also giving them enough heads-up to
 111     PRE-EMPT any EU Auditor questions.
 112
 113     PLEASE NOTE: for the >50k Grants an Audit is a *HUNDRED PERCENT*
 114     guaranteed, as part of the *EU* Funding conditions. it is NOT
 115     hypothetical or a "lottery" (like the one that came up a few
 116     months ago where NLnet had its first *full* Audit of its
 117     entire project suite, by an EU Auditor).
 118
 119     even for the <=50k Grants we there have to assume that an
 120     Audit could take place at any time, and therefore also act
 121     pre-emptively to provide NLnet with satisfactory answers
 122     to questions that the EU Auditor will be asking to determine
 123     if Fraud is or is not taking place.
 124
 125     i trust that that hammers home that this is in fact really
 126     quite serious and a hell of a responsibility, because we are
 127     representing NLnet's trust in us to keep these Financial
 128     Records meticulously accurate, in order to not have ourselves
 129     be accused of Fraud or money-laundering by the EU and thus
 130     bring both ourselves *and NLnet* into serious disrepute.
 131
 132     as a reminder this was why i had to call an Emergency Freeze
 133     and full audit of the OPF ISA WG Grant Financial Records a few
 134     months ago. i *really* do not want ever to have to do that ever
 135     again, so i expect everyone to LISTEN and take the above on
 136     board and treat it with the seriousness it requires.
 137
 138     once again if there is anything you are hesitant about or
 139     feel you must "assume" stop immediately and ask for help.
 140
 141     l.
 142
 143
 144     --
 145     ---
 146     crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
 147
 148 ### email 3
 149
 150
 151     >
 152     > seventh: the MoU Signatory will have been notified by email,
 153     > and should review the submission.  DO NOT just "click yes",
 154     > you must ACTUALLY do Due Diligence
 155
 156     which includes checking that the "submitted" date is
 157     correctly entered for each milestone under its TOML field,
 158     and contacting the submitter to ask that they update it
 159     *before* clicking the "approve" button.
 160
 161     do not do this for them (except under mitigating circumstances),
 162     walk them through the process.  over IRC is the better medium
 163     as it is both interactive *and logged* so if there are mistakes
 164     or constructive feedback required there is a full audit log
 165     to analyse to see what went awry, and why.
 166
 167
 168     --
 169     ---
 170     crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
 171
 172 ### email 4
 173
 174     On Wednesday, December 6, 2023, Luke Kenneth Casson Leighton <lkcl at lkcl.net>
 175     wrote:
 176
 177     > walk them through the process.  over IRC is the better medium
 178     > as it is both interactive *and logged* so if there are mistakes
 179     > or constructive feedback required there is a full audit log
 180     > to analyse to see what went awry, and why.
 181
 182     ninth: the person will receive their payment, and as part of
 183     the secret URL there is a table stating "paid date" against
 184     each RFP. the person is *required* to go back through the
 185     milestones against which they first added "submitted=YYYY-MM-DD"
 186     and to now add "paid=YYYY-MM-DD" on every single one.
 187
 188     (there is a mode of budget-sync that can perform this action
 189     automatically, documented in the README, but it should ONLY
 190     be used if properly understood as it can perform "mass change"
 191     risking destruction of the Financial Records if abused.
 192     ONLY use this program under STRICT supervision, on the
 193     logged IRC Channel, with an experienced Authorized MOU
 194     Agent/Signatry guiding and monitoring its use).
 195
 196     as with "submitted" run budget-sync to ensure that you
 197     have not caused "damage" to the Financial Records.
 198
 199     tenth: notify the MoU Signatory Agent (Project Lead) that
 200     the payment records have been updated. the Project Lead
 201     *should* be receiving bugzilla change notifications but that
 202     does not guarantee they have been seen: it is your
 203     responsibility to keep notifying them and escalating until
 204     you have received an *acknowledgement*.
 205
 206     eleventh: the Project Lead (MoU Signatory) then needs to
 207     double-check the Financial Records, by re-running budget-sync,
 208     then going to the mdwn/{payee}.mdwn file and check that
 209     all tasks on the corresponding NLnet RFP have moved to a
 210     "paid by NLnet" section. they should all have the same "paid"
 211     date because RFPs are never split. there should also neither be
 212     tasks listed as "paid" that are not listed on the RFP, or
 213     tasks on the RFP but that are not listed on the payee mdwn file.
 214     if there are this needs to be raised on Audit-tracked Libre-SOC
 215     resources, NOT discussed privately with the payee, requesting
 216     that they review and if necessary correct any discrepancies.
 217
 218
 219
 220     yes this really is this astoundingly meticulous, specific
 221     and detailed, and requires extreme thorough rigour, patience
 222     and diligence.
 223
 224     that diligence and meticulous attention is why we have been
 225     trusted with the order of HALF A MILLON Euros of EU Grant
 226     money over the past five years. it all comes down to being
 227     able to demonstrate, if asked, in effect, putting it plainly:
 228     "are you committing fraud here?"
 229     we can categorically answer NO.
 230
 231     l.
 232
 233
 234
 235     --
 236     ---
 237     crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
 238
 239 # TODO: Refactor or remove the content below, probably duplicate...
 240 ## Checks beforehand
 241
 242 - Is the task under a grant sub-task?
 243 - Has the grant been accepted by NLnet **and** MoU signed?
 244 (Work on tasks can begin after grant accepted, but RfP submission **only**
 245 after MoU signing.)
 246 - Has NLnet set the RfP system for the grant (and provided *the secret URL*
 247 for the team members to make RfPs)?
 248 - Has the task been declared complete? The comment section of the bug needs
 249 to have a clear history of completed work (sub-tasks, git commits,
 250 development thoughts).
 251
 252 ## NLnet RfP system
 253
 254 This site can only be accessed by a secret URL. This URL will be
 255 distributed to MoU signees by Andrey or Luke after NLnet confirms the RfP
 256 system is in place.
 257
 258
 259 ## Making a submission
 260
 261 1. Go to the NLnet RfP system via the secret URL.
 262 2.
 263
 264