HDL_workflow/rfp_submission_guide.mdwn

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