Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UC: Software Boundary Redefinition #62

Open
Tracked by #61 ...
jawache opened this issue Jun 5, 2024 · 0 comments
Open
Tracked by #61 ...

UC: Software Boundary Redefinition #62

jawache opened this issue Jun 5, 2024 · 0 comments
Assignees
Labels
documentation Improvements or additions to documentation

Comments

@jawache
Copy link
Contributor

jawache commented Jun 5, 2024

Redefining the boundary of what you are measuring can improve your score and increase your rating compared to past scores or competitors' scores.

For physical products, that might be similar to deciding not to include the accessories. For digital, it's redefining what you consider a component of your software system, e.g. moving a database away from your DC to a SaaS provider and then deciding not to include it in your measurement.

This is a core discussion point of the SCI since inception and the reason the SCI has provision to ensure that the software boundary is documented in any report of an SCI score. The first step is transparency, the next step is defining the expected boundary for different categories of products.

Equivalence

  • In the physical world, this is not a problem; you can't submit a fridge that is missing a door to be scored. So, methods like the Nutri-score and Energy Star do not need to be so concerned about boundary redefinition; it's objectively true what the boundaries of their products are.
  • The closest equivalent is perhaps the ingredient label on a food product and the nutri-score, the list of ingredients is a statement of what is actually being measured, and the score is the rating but it's based off a transparent record of exactly what the food contains.
  • The nutri-score scale might be voluntary but it is based on decades of transparent ingredient data enforced and regulated by government agencies, with many follow on studies run on the data.

Counter

  • Any claim made needs to be backed up by evidence and a clear statement regarding what is being included and excluded in the computation.
  • Any change to the claimed metric needs to be backed up by a document explaining what triggered the change, a boundary redefinition, or a re-engineering effort.
  • If this is an SCI score, then SCI should make it clear exactly what should be included and excluded in the boundary for different domains.
  • The impact manifest file format is a good candidate for this type of reporting, as it is transparent about what is being included in the computation, how that computation was made, and the aggregate emissions values.
@seanmcilroy29 seanmcilroy29 added the documentation Improvements or additions to documentation label Jun 6, 2024
@seanmcilroy29 seanmcilroy29 mentioned this issue Jun 7, 2024
24 tasks
@seanmcilroy29 seanmcilroy29 mentioned this issue Jul 3, 2024
18 tasks
@seanmcilroy29 seanmcilroy29 mentioned this issue Aug 7, 2024
18 tasks
@seanmcilroy29 seanmcilroy29 mentioned this issue Sep 4, 2024
23 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

4 participants