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
84 changes: 84 additions & 0 deletions SPEC-CHANGE-GUIDLINES.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,84 @@
# 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.


## 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