Feature Overview (aka. Goal Summary)

An elevator pitch (value statement) that describes the Feature in a clear, concise way.

In addition to reporting on metrics pulled from other systems/data sources (such as Jira), another type of check that some customers may want to utilize and customize for their needs would be a file level / repo best practice compliance report, to verify the presence of corporate best practices (such as ensuring that repositories have a CODEOWNERS or license file).  

Goals (aka. expected user outcomes)

The observable functionality that the user now has as a result of receiving this feature. Include the anticipated primary user type/persona and which existing features, if any, will be expanded. 

• Support platform engineers have visibility across their orgs to ensure that best practices are followed, beginning with the ability to verify developers are including specific files
  • Add ability for Scorecard to verify if a list of required files (one or more) is present (such as a license, CODEOWNERS, dockerfile, .gitignore, etc)
  • The exact filenames/paths should be configurable, so that customers can extend it to their use cases

Requirements (aka. Acceptance Criteria):

A list of specific needs or objectives that a feature must deliver in order to be considered complete. If the feature spans across releases then good to have scope for each release with acceptance criteria. Be sure to include nonfunctional requirements such as security, reliability, performance, maintainability, scalability, usability, etc.

• Scorecard can be configured to scan for the presence of a filename across repositories it is aware of
• Scorecard can display metrics based on that data and report if the desired file is present or missing
  • This could be a single check at the entity level, or an aggregated view on a homepage scorecard looking across multiple entities ** 
• Users can click through a card to see affected entities, so they can follow up if needed, and validate the reported data 
• RBAC should limit viewable file checks as necessary, so users only see entities they have permissions for
• An example card checking for license and Codeowners is available to install and configure

Out of Scope (Optional)

High-level list of items that are out of scope.

• Handling multiple similar checks in a single card can be deferred until the grouping feature (RHDHPLAN-904)
• Alternate ways to report and visualize the metric can be evaluated later, which could result in grouping/higher density data layouts
  • We could consider looking at a boolean card type in the future, as one example, which could be better suited for some types of checks
• Examining the file to determine if it contains the expected data 
  • We can start with making sure there is a named file

Customer Considerations (Optional)

Provide any additional customer-specific considerations that must be made
when designing and delivering the Feature. Initial completion during
Refinement status.

• Customers may want to look for a different file, and should be able to configure their own similar check.

Documentation Considerations

Provide information that needs to be considered and planned so that
documentation will meet customer needs. If the feature extends existing
functionality, provide a link to its current documentation.

• Admins will need to know that scorecard metrics can include file level checks, and how to customize it for their needs.