About

• Version: 1.2

• Creation date: 11/25/2020

• One line description: Processes regarding being a development partner and contributing to projects to help Task Groups complete Acceptance Criteria tasks for public review and ratification

• Author(s): Mark Himelstein

Background

We are starting to work with Development Partners (i.e. institutions or groups that are volunteering to take on Development tasks for RISC-V TGs). 

We developed this Model so that we could get help for architects working on RISC-V projects requiring their skills who may be spending their time instead both architecting and delivering Ecosystem components that could be done by non-architect level Developments. In this way architects could spend their time on architecture and help get the extensions and work products finished.

We also have accumulated technical debt (i.e. things we did not do -- for example we did not do the architecture tests for floating point when we ratified the extension). This model will also be used to address the technical debt.

Details

Ramp project to on board get a Development Partner productive :

1. RISC-V folks pick a ramp project. This should be a project where the initial results can be visible in a month (not including holidays). When we make enough progress to know we are being productive, we can expand the work to include more projects.

General process

1. The RISC-V group driving the work (IC, HC, HSC, or TG) picks a liaison to work with the Development Partner.

2. Development Partner picks a non-student liaison to work with RISC-V.

3. Liaisons should be both technically and organizationally capable

4. While RISC-V TGs have oversight, the liaisons will be the main point of interaction. This is done to minimize the impact on the RISC-V architects and ensure that RISC-V architects are not managing the Development Partner Developments directly. The hope is that we can have one liaison from each organization but there may have to be more depending on the variation in project skills and areas needed. If we have more than one liaison, we will pick a primary one from RISC-V and the Development Partner to coordinate across a number of projects and liaisons as appropriate.

5. The SOW and status are stored on the shared drive here and the README in that directory has conventions including templates for the SOW and status.

6. RISC-V will provide the following initial deliverables to start a project: requirements, deliverables, and acceptance criteria which make up the SOW. For a small project this should all fit on one page. An example of acceptance criteria in the industry from the GNU toolchain is available here.

7. Once you develop a SOW, the liaison sends an email to the cto-group-contributor http://lists.riscv.org email group asking for a resource and places the task in the status spreadsheet tab used to identify tasks you need resource help with. Please do not approach Development Partners yourself as the TSC has set priorities and we are working to address their priorities first.

8. The Development Partner and RISC-V will review the RISC-V initial deliverables until both teams feel the Development Partner understands the task and has the beginnings of a plan to get the work done as per the requirements.

9. Regular status is due monthly and will be reported to the appropriate groups (chairs, BOD, etc.). There is a self-serve status spreadsheet on the shared drive in the status folder with a projects tab where we will track progress rollup. The full report is in the directory specified above.

10. The RISC-V liaison will drive the review of deliverables and adherence to acceptance criteria with the RISC-V TG and work with the Development Partner liaison to resolve any issues.

11. The following skillsets are needed:

    1. Formal model (SAIL)

    2. Architecture tests (ISA, assembler)

    3. Toolchain support (GCC, LLVM, debugger, profiler, …)

    4. Simulators (SPIKE, QEMU, SAIL generated, …)

    5. Hypervisors (KVM, etc.)

    6. Operating Systems (both Linux like and RTOS like)

    7. Library support (e.g. crypto libs, npi libs, ml libs, java runtime, …)

    8. Prototyping (FPGA, simulator, RTL, etc.)

    9. Documentation

12. A Development Partner should be able to support a minimum of 3 medium sized projects simultaneously after the proof of concept project. It takes effort to spin up a Development Partner and we would like to leverage that effort on the RISC-V side).

13. Development Partners should have approximately 1 non-student manager/project leader per 15 students or junior Developments maximum (so a big project may need both a liaison and some managers).

Exception handling

Not applicable

Version History