rfp_submission_guide: Add email copies
authorAndrey Miroshnikov <andrey@technepisteme.xyz>
Thu, 14 Dec 2023 18:58:27 +0000 (18:58 +0000)
committerAndrey Miroshnikov <andrey@technepisteme.xyz>
Thu, 14 Dec 2023 18:58:27 +0000 (18:58 +0000)
HDL_workflow/rfp_submission_guide.mdwn

index 70add1043c29c7d9f6f3149e3a95a56d1c3ac6ae..4ec6d449741c1f98b0a52c5d43ea957599a12c43 100644 (file)
@@ -4,7 +4,306 @@
 WTH ZERO CONTEXT**
 
 * 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:
+<https://lists.libre-soc.org/pipermail/libre-soc-dev/2023-December/005829.html>
 
+## 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 "submit" 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.
+
+    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
+
+    On Tuesday, December 5, 2023, Luke Kenneth Casson Leighton <lkcl at lkcl.net>
+    wrote:
+    >
+    >
+    > 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 "submit" 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.
+    >
+    > 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?
@@ -28,3 +327,5 @@ system is in place.
 
 1. Go to the NLnet RfP system via the secret URL.
 2.
+
+