(no commit message)

diff --git a/nlnet_2022_opf_isa_wg/discussion.mdwn b/nlnet_2022_opf_isa_wg/discussion.mdwn
index ea8974849f31c5383757b5029688d89f19006e86..dc50eb14a884aa880e5287f360db88d8dc49ea80 100644 (file)
--- a/nlnet_2022_opf_isa_wg/discussion.mdwn
+++ b/nlnet_2022_opf_isa_wg/discussion.mdwn
@@ -2,10 +2,12 @@
 
 you applied to the 2022-08 open call from NLnet. We have some questions regarding your project proposal Libre-SOC OpenPOWER ISA WG, but obviously we are incurring some delays due to the deluge of payment requests ;)
 
+**
     You requested a neat round sum of 100000 euro.
     Can you provide some more detail on how you arrived at this amount?
     Could you provide a breakdown of the main tasks, and the
     associated effort? What rates did you use?
+**
 
 last question first: we've learned (painfully, by losing opportunities
 and team members) that the prior rates which were around EUR 1500 per
@@ -35,17 +37,19 @@ these are the tasks:
 * binutils needs ongoing updates, an estimated budget covering
   10-14 weeks would be good.
 
+**
     Is there meanwhile news on the requirements of IBM and the ISA WG?
+**
 
 somewhat.  the page is now open - https://openpower.foundation/isarfc/ -
 and they have prepared a process/procedure document (legally required
 to be followed, under the OPF's ByLaws), which is adapting as we're
 literally the first people to use it.
 
-
-
+**
     A request for 100k is very large, and the timelines are
     pretty long too.
+**
 
 yes and no. if we assume 3 people (one junior editor, two and a half
 programmers: simulator, unit tests, binutils) it actually doesn't go far.
@@ -57,10 +61,12 @@ realistically that would mean we would actually need to begin the
 submission process on the very next cycle! (2022-10E - 2022-12E would
 be more likely, but slightly pushing our luck)
 
+**
    It would be better for us to achieve this incrementally, as in:
    start with a smaller amount for meeting submission criteria for
    the block of instructions, deliver initial code, tests,
    documentation - and when more budget is needed, a new chunk is added.
+**
 
 I don't have a problem with that, if you are fine with the extra admin
 work :)
@@ -76,8 +82,10 @@ any patents that those will be assigned to the OPF immediately.
 Perhaps some legal assistance in reviewing that agreement might
 be a good idea?
 
+**
     How would you manage such a large amount of RFCs, which must
     be perceived as a denial of service at the WG?
+**
 
 carefully!  we have been warning them consistently and persistently
 for 24 months.  each RFC when it gets to the "Presentation as
@@ -86,12 +94,20 @@ hardware experts for their consideration.  IBM has had many many
 RFCs in-house over the years: this isn't something that's new to
 them.
 
+**
     Is there infrastructure in place to manage the lifecycle of each RFC?
+**
 
 yes.  the bugtracker, wiki, and mailing list, and the RFCs themselves
 are in the git repository that's behind the wiki.  full cross-referencing
 in each has been found over a 4 year period of managing this project.
-Example:
+
+then there is also the "main" page tracking *all* RFCs (which will
+get its own bugreport at some point)
+
+* https://libre-soc.org/openpower/sv/rfc/
+
+Example of the cross-referencing so far:
 
 * https://libre-soc.org/openpower/sv/rfc/ls001/
 * https://git.libre-soc.org/?p=libreriscv.git;a=history;f=openpower/sv/rfc/ls001.mdwn
@@ -99,13 +115,17 @@ Example:
 * https://bugs.libre-soc.org/show_bug.cgi?id=924, note the discussion
 * https://libre-soc.org/openpower/sv/rfc/ls001/discussion/
 
+**
     How are discussions going to be linked to each RFC?
+**
 
 By a cross-referenced URL in each one, and the standard practice
 of adding a "discussion" page in the wiki if necessary, although
 this is often subsumed by the bugtracker.
 
+**
     What are the timelines?
+**
 
 based on 3.5 people, only around 10 months.