Adding project monthly report template

[DBees]

This template will be used by each project to create a concise report that will live in the appropriate task group folder in the programs repo. The template has a link to the project gate information for that project with schedule.

[jquevremont]

How do we address projects that span over multiple TGs, e.g. cores that span over Cores TG, Verification TG and Software TG?

[jeremybennett]

I think this is fine for resourced hardware projects, but doesn't work quite so well for software projects. I suggest you have two templates, one for hardware (this one) and one for software. We particularly want to keep the reporting burden proportionate - several SW projects are still severely resource constrained and are also relatively small. I have made some suggestions below, based on how I report Embecosm's commercial projects to customers.

General comments

I don't think you need the "Prepared By", since that is implicit in the git commit for the report.

Suggested structure for Software reports

(done as bullets, rather than titles due to limitations of Markdown)

1. Title & current gate

2. Activities completed in past month

   • planned activities (from previous report)
   • unplanned activities

3. Statistics (always strictly quantitative)

   • Examples:
     • task completion status (Kanban chart)
     • timeline (likely only for resourced projects)
     • regression test results
     • issue tracker statistics
     • risk register update

4. Plans for next month/reporting period

   • this is the list of tasks that will form the basis of item 1 in the next report

Typography comments

Capitalization of titles is inconsistent. I suggest following the Wikipedia convention of first word only apart from proper nouns.

[jeremybennett]

Forgot to set the status of my earlier review

[hpollittsmith]

Report format seems fine.

[MikeOpenHWGroup]

How do we address projects that span over multiple TGs, e.g. cores that span over Cores TG, Verification TG and Software TG?

There will be few such projects and currently there are none. Core design and verification efforts are managed as CTG projects, and this is appropriate. For example, the CV32E40X project has both design and verification tasks and is well managed as a CTG, not VTG project. CORE-V-MCU-UVM is a VTG project which makes sense given the design is static, save for bug fixes in the RTL. In the case of our existing software projects, the division is even easier to see.

If OpenHW should ever launch a project that truly does span multiple TGs, we can address it at that time.

[MikeOpenHWGroup]

I think this is fine for resourced hardware projects, but doesn't work quite so well for software projects.

Your point is well taken @jeremybennett. Perhaps we can merge the two templates into a single format that serves the needs of both.

[DBees]

@jeremybennett I specifically want to include the project gate context into the monthly report. Tying the monthly activities into the bigger plan is, I think the missing link. The software projects specifically all remain at the initial gate and have done for extended periods. I don't think adding the gate schedule requires any effort other than establishing the schedule and then updating where the project stands from time to time.

[DBees]

@MikeOpenHWGroup Yes let's edit so we have one common template

[DBees]

@jeremybennett It is now updated and almost the same as the SW template, except that the gate table is included at the end, and "issues and difficulties" section is added in bullet form.

[MikeOpenHWGroup]

LGTM.

[jeremybennett]

Thanks @DBees - this all looks good.