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

Change Process Guidelines #684

Draft
wants to merge 7 commits into
base: working_draft
Choose a base branch
from
48 changes: 30 additions & 18 deletions CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -65,24 +65,36 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),

**Added:**

- `String handling` attribute
- `ChargeClass` column
- `CommitmentDiscountStatus` column
- `ContractedCost` column
- `ContractedUnitPrice` column
- `RegionId` column
- `RegionName` column
- `DataGenerator` metadata property
- `CreationDate` metadata schema property
- `FocusVersion` metadata schema property
- `SchemaId` metadata schema property
- `ColumnName` metadata column definition property
- `DataType` metadata column definition property
- `NumberScale` metadata column definition property
- `NumberPrecision` metadata column definition property
- `ProviderTagPrefix` metadata column definition property
- `StringEncoding` metadata column definition property
- `StringMaxLength` metadata column definition property
New use cases:
- Compare billed cost per subaccount to budget
Copy link
Contributor

@flanakin flanakin Jan 22, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where should use cases go? First to show that we're scenario-driven? After columns since they depend on the columns anyway? Or last so they can also span metadata?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the change log there would be an indication that we added a new use case to the supported use cases list. In the actual list the use case would be added.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ljadvey Curious to hear you weigh in here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note to self: I need to show how we flag use cases that have been impacted by a change. I don't think this use case has been changed yet, tho.


New attributes:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm suggesting a change to how we organize the changes to group similar areas together so it's easier to identify use cases separately from column changes. I have not applied this everywhere. If others are good with this, I can apply everywhere in this PR or a separate one, if preferred.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I think that would be a good add to structure the change log so that it is a little more organized.

- `String handling`

New columns:
- `ChargeClass`
- `CommitmentDiscountStatus`
- `ContractedCost`
- `ContractedUnitPrice`
- `RegionId`
- `RegionName`

New metadata properties:
- `DataGenerator`

New metadata schema properties:
- `CreationDate`
- `FocusVersion`
- `SchemaId`

New metadata column definition properties:
- `ColumnName`
- `DataType`
- `NumberScale`
- `NumberPrecision`
- `ProviderTagPrefix`
- `StringEncoding`
- `StringMaxLength`

**Changed:**

Expand Down
98 changes: 98 additions & 0 deletions SPEC-CHANGE-GUIDLINES.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,98 @@
# FOCUS Specification Change Guidelines

The FOCUS specification is designed to be updated over time to support new use cases and to adapt to changes in the industry. Communication, specificity, and impact are considered as changes are made. While data using the FOCUS specification facilitates a wide range of analysis, the specification and the change process are scoped to the <official use cases> and to the schema described in the FOCUS specification and not to all possible analysis of the data. While example queries may be provided specific queries are not considered expressly supported content.


## Versions

The FOCUS specification is released periodically. For each release a version number is assigned. Version numbers at this time are not strictly representative of compatibility. The version number is used to identify the release and to provide a reference point for changes.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

spelling


## Version Changelog
A changelog is provided specifying helpful information to consumers of focus data. The changelog for each version identifies the following:
- The version number
- Impact Classification
- Change Type Classification
- Designation of deprecation of a feature or column
- Designation of the addition of a new feature or column
- Description of the change
- Examples of the change if needed



## Change Process

TODO: A series of guidelines of how changes are proposed, reviewed, and accepted.

### Addition of a New Feature or Column

When a new feature or column is introduced to the FOCUS specification, depending on the circumstances of the change, the support of the column may be initially optional. This is to allow for the adoption of a new feature or columne by prodivers that support it, without restricting other adopters from using newer versions of the specification.
- The feature or item addition is proposed, which, in addition to the proposed specification change, includes the appropriate indication as to the optionality of the feature or column. ??Do we require a future optionality is solidified version??
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removal indication of optionality just say it is a new thing.

- example: "Example Column 1 will be deprecated in version 2.1 and removed in version 2.4"


### Removal of a Feature or Column

When a feature or column is removed from the FOCUS specification, the following steps are taken:
- The feature or item removal is proposed, which, in addition to the proposed specification change, includes a deprecation period expressed in terms of Focus versions
- example: "Example Column 1 will be deprecated in version 2.1 and removed in version 2.4"



## Change Type Classification

Changes to the FOCUS specification are classified into one of the following types:

### Addition:
The addition of a new feature or column to the FOCUS specification.

### Deprecation:
A feature or column from the FOCUS specification is moving to deprecated status discouraging use and indicating that will the same will be removed in a future version

### Removal:
The removal of a feature or column from the FOCUS specification.

### Improvement:
Modification to improve or refine a feature or column in the FOCUS specification, that was not considered broken.

### Bug Fix:
Modification to correct an error in the FOCUS specification, that was considered broken.

### Editorial:
Modification to correct a spelling, grammar, or formatting error in the FOCUS specification, that does not impact the intended logic of the specification contents.


## Change Impact Classification

The FOCUS specification is designed to be updated overtime to increase it use and to adapt to changes in the industry over time. In order to provide insight into the impact of the change, changes are classified into one of the following categories Change Impact categories. :


### Compatible Change:

Any change in the spec that does not require modification by the consumer to continue using the spec for published use cases.

Examples:
- Adding a new column for a new use case or
- Adding a new category for an existing that does not require splitting or re-categorization.

### Migration Compatible Change:

Any change that still supports the Published Use Cases, but may require modification to query or ingestion by consumers of a FOCUS dataset.

Examples:
- An existing categorization column is changes to split a category into two different categories
- An existing column that contains a numerical value is has its units changed, requireing a modification to queries using the column. The ability to use the column is preserved but a new query must be written

### Incompatible Change:
Any change to the spec that ends the support of a Published Use Case. The removal of a Use Case or a column without an alternative source for the data supplied by the column. Incompatible Changes, require prior notification and

Examples:
- Removing a column






## Supported Features


Original file line number Diff line number Diff line change
@@ -0,0 +1,53 @@
# Use Case

Compare billed cost per subaccount to budget

## Use Case ID
14383

## Supported Specification Version
1.0

## Description
Product wants to confirm charges are in line with expectations (budgets) for a business which has all its cost within a single subaccount. The ChargePeriod is used for filtering to capture items that apply to the period only (excludes adjustments from previous periods that were applied in the current BillingPeriod).

## Directly Dependent Columns
* Provider
* Sub Account ID
* Sub Account Name
* Billed Cost
* Charge Category
* Charge Period Start
* Charge Period End

## Indirectly Dependent Columns



## Example SQL Query
```
SELECT
ProviderName,
SubAccountId,
SubAccountName,
SUM(BilledCost) AS TotalBilledCost
FROM focus_data_table
WHERE ChargeCategory = 'Usage'
AND ChargePeriodStart >= ? and ChargePeriodEnd <= ?
AND ProviderName = ?
AND SubAccountId = ?
GROUP BY
ProviderName,
SubAccountId,
SubAccountName
```

## Parameters
* ChargePeriodStart
* ChargePeriodEnd
* ProviderName
* SubAccountId

## Use Case Change Log
| Version | Change | Purpose |
| :-------| :------| :-----------|
12 changes: 12 additions & 0 deletions specification/use_cases/use_cases.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,12 @@
# Use Case Template

# Parts
* Use Case - the title & short description of the use case
* Use Case ID - the ID from the FinOps Foundation
* Supported Specification Version - 1.0, 1.1, etc.
* Description - Description of the use case from the FinOps foundation
* Directly Dependent Columns - Colums directly used in the query
* Indirectly Dependent Columns - Columns indirectly used, or related to the used columns through the supported specifications.
* Example SQL Query - the query used, including placeholders for parameters
* Query Parameters - the format of the parameters used
* Use Case Change Log - a description of the changes in the use case by version (version where the change was made), change (a description of the change made) & purpose (the reason for the change)