Reporting project- SCI

[Sealjay]

Requirements for reporting SCI

A new project, SCI-Reporting, etc.

Copying comments from @jawache on #123

Also not sure about individuals, do we want to accept any SCI report like even for a school homework? What is the bar for entry into this repository?

Do we need to decide how our SCI spec is version controlled? What constitutes a major/minor change? Should the first folder be our version number? Or should the filename contain the version number?

1.0/Org/AppName/32413423422.yaml
1.1/Org/AppName/134143443424.yaml

Or

Org/AppName/v1.0(date?)(file version number?).yaml
Org/AppName/v1.1(date?)(file version number?).yaml

I'm starting to think this might be a broader discussion... lots of questions are popping up in my head.
BTW, I'm starting to think this has enough merit to be run as a separate GSF project? The reporting of SCI numbers feels as big, if not bigger, than the SCI itself. Perhaps the SCI contains details of the format of the reporting file, but the actual method of reporting we strip this out of the SCI itself, and we'll kickstart another project. I think it deserves more discussion and thought and don't want to rush it for the V1 release. What do you think @Sealjay?

---

@Sealjay

I think this should be a separate project to be honest - I think trying to get this into the specification before COP26 will be difficult, with all of the various edge cases we need to handle. I'll change the text to proscribe the format, but strip out the process for reporting.

[Sealjay]

Extracting report section

### Submitting a report
Reports can be made to the `GSF`  using a [Pull Request](https://guides.github.com/introduction/flow/).

Only one machine-readable submission MUST exist per unique GUID. Each GUID MUST reference and relate to only one product name.

When a new SCI report is made, to replace an existing report for a unique product or entity, the pull request MUST update or replace the same file.

Each report must be placed into a unique folder, named after the GUID associated with the product or entity.

[Pull Requests](https://guides.github.com/introduction/flow/) should point at this repository:

NOTE - ADD GH REPO URL HERE

[Sealjay]

preserving comment from @jawache

I was thinking to make this more human readable to structure under organisation than GUID.

Organisation/Application/GUID.... (data)

Would be nice to be able to just quickly click to Microsoft/Teams and see the latest report otherwise we would need another lookup table.

[Sealjay]

Hey folks, you can join in on this project here now: https://github.com/Green-Software-Foundation/sci-reporting

[Sealjay]

Discussion on reporting benchmarks @jawache @atg-abhishek

Diagram generated here

title Benchmark hash flow

entity Software Being Measured
entity Benchmark
actor User
entity GitHub
abox right of GitHub:Could be another tool or API
User->Benchmark:Creates benchmark
User->GitHub:Commits current benchmark
note over GitHub:Hash Generated for the commit
database Report Store
User->Software Being Measured:Runs benchmark against software
User->GitHub:Makes a report referencing the benchmark used
GitHub-->Report Store:save the commit ID to our reporting tool, whatever that is
note over Report Store:Report store could also be GitHub
User->Benchmark:Changes benchmark
User->GitHub:Makes new report, attaches new benchmark commit ID
GitHub-->Report Store:save the updated commit ID to our reporting tool, to show benchmark has changed

[Sealjay]

Speaking with @navveenb and @seanmcilroy29 about a similar idea from the innovation WG:)

[Sealjay]

Have created a standards wg issue here to set up the reporting project: Green-Software-Foundation/software-standards-wg#2

[Sealjay]

Following discussion in #190 - should also talk about best/worst case scenarios and comparisons

[atg-abhishek]

Approved as a project by the WG during the call.