Skip to content

Commit

Permalink
Merge branch 'working_draft' into editorial-update-chargeperiodend
Browse files Browse the repository at this point in the history
  • Loading branch information
ijurica authored Oct 29, 2024
2 parents 0febf83 + fbb9ddf commit e582982
Show file tree
Hide file tree
Showing 99 changed files with 628 additions and 443 deletions.
2 changes: 1 addition & 1 deletion .github/ISSUE_TEMPLATE/discussion-topic.yml
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@ name: Discussion Topic
description: Initiate discussion on broad topics within the FOCUS community.
title: "[DISCUSSION]: "
labels: ["discussion topic"]
assignees: ["mike-finopsorg,udam-f2"]
assignees: ["shawnalpay"]
body:
- type: textarea
attributes:
Expand Down
25 changes: 16 additions & 9 deletions .github/ISSUE_TEMPLATE/feedback.yml
Original file line number Diff line number Diff line change
@@ -1,14 +1,14 @@
name: FinOps Use Case Feedback
description: Provide feedback on FinOps use cases that cannot be performed with the current FOCUS specification.
name: Feature Request and Use Case Feedback
description: Provide feedback on unsupported use cases or features in the FOCUS specification, including FinOps scenarios, to help prioritize updates. Avoid sharing proprietary information.
title: "[FEEDBACK]: "
labels: [""]
assignees: ["mike-finopsorg,udam-f2"]
labels: ["use case"]
assignees: ["shawnalpay, jpradocueva,"]
body:
- type: markdown
attributes:
value: "The FOCUS working group wants to understand what FinOps use cases cannot be performed today using the current specification so they can be prioritized for upcoming release. Please do not provide any information that may be considered Intellectual Property by any individual or organization."
value: "FOCUS working group seeks gaps in the current specification for FinOps and beyond. Share unsupported use cases or features to prioritize updates. Avoid sharing proprietary information."

- type: input
- type: textarea
attributes:
label: Proposed Change
description: Short description of the change and why it is necessary.
Expand All @@ -18,8 +18,8 @@ body:

- type: textarea
attributes:
label: What FinOps use cases cannot be performed without the proposed change?
description: Describe in detail the current FinOps use cases your organization cannot perform without the proposed change
label: What use cases, FinOps or others, can't be performed with the current specification without this change?
description: Describe in detail the use cases, whether FinOps-related or otherwise, that your organization cannot perform with the current specification without the proposed change.
validations:
required: true

Expand Down Expand Up @@ -51,6 +51,14 @@ body:
validations:
required: true

- type: textarea
attributes:
label: Key Metrics and KPIs
description: List the metrics and KPIs that will measure the success of this use case (e.g., cost per service, spend reduction percentage).
placeholder: e.g., cost per service, spend reduction percentage, etc.
validations:
required: false

- type: textarea
attributes:
label: Context / Supporting information
Expand All @@ -66,4 +74,3 @@ body:
placeholder: Attach sample data or data extracts here. Ensure compliance with data privacy guidelines.
validations:
required: false

2 changes: 1 addition & 1 deletion .github/ISSUE_TEMPLATE/maintenance.yml
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@ name: Maintenance Task
description: Create tasks related to work on the GitHub Repository or GitHub Actions.
title: "[MAINTENANCE]: "
labels: ["repo maintenance"]
assignees: ["mike-finopsorg,udam-f2"]
assignees: ["shawnalpay"]
body:
- type: textarea
attributes:
Expand Down
2 changes: 1 addition & 1 deletion .github/ISSUE_TEMPLATE/spec-change.yml
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@ name: Spec Change
description: Submit changes or updates to the current specification.
title: "[SPEC CHANGE]: "
labels: ["discussion topic"]
assignees: ["mike-finopsorg,udam-f2"]
assignees: ["shawnalpay"]
body:
- type: dropdown
attributes:
Expand Down
53 changes: 53 additions & 0 deletions .github/ISSUE_TEMPLATE/work-item.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,53 @@
# Work Item Issue Template
description:
title: "[Work_Item]"
labels: ["work item"]
assignees: [shawnalpay, jpradocueva]

### **Template Usage Notes**:
1. All fields marked as **mandatory** [*] must be filled before submission. While some datapoints are optional for the initial creation of the work item, all datapoints must be provided in order to be considered for spec development.
2. If you have suggestions for the specification but cannot fill out all fields in this issue template, please fill out a [Feedback] or [Discussion] issue template instead.
3. For **Supporting Documentation**, ensure that linked files are accessible to relevant stakeholders.

---

## 1. **Problem Statement** *
Describe the problem, issue, use case, or opportunity that this work item addresses.
Include practitioner quotes illustrating real examples a) of questions being asked by practitioners and b) value unlocked by answering these questions, if available.
- **What is the problem?**: Explain the context and why it needs resolution.
- **Impact**: Describe how the problem affects users, systems, or the project.

Your input ...

## 2. **Objective** *
State the objective of this work item. What outcome is expected?
- **Success Criteria**: Define how success will be measured (e.g. metrics and KPIs).

Your input ...

## 3. **Supporting Documentation** *
Include links to supporting documents such as:
- Data Examples: [Link to data or relevant files; DO NOT share proprietary information]
- Related Use Cases or Discussion Documents: [Link to discussion]
- PRs or Other References: [Link to relevant references]

Your input ...

## 4. **Proposed Solution / Approach**
Outline any proposed solutions, approaches, or potential paths forward. Do not submit detailed solutions; please keep suggestions high-level.
- **Initial Ideas**: Describe potential solution paths, tools, or technologies.
- **Considerations**: Include any constraints, dependencies, or risks.
- **Feasibility**: Include any information that helps quantify feasibility, such as perceived level of effort to augment the spec, or existing fields in current data generator exports.
- **Benchmarks**: Are there established best practices for solving this problem available to practitioners today (e.g. mappings from existing CSP exports that are widely used)?

Your input ...

## 5. **Epic or Theme Association**
> This section will be completed by the Maintainers.
> - **Epic**: [Epic Name]
> - **Theme**: [Theme Name, if applicable]
## 6. **Stakeholders** *
List the main stakeholders for this issue.
- **Primary Stakeholders**: [Name/Role]
- **Other Involved Parties**: [Names/Roles]
121 changes: 121 additions & 0 deletions .github/ISSUE_TEMPLATE/work-item.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,121 @@
name: "Work Item Issue Template"
description: "Template for creating new work item issues"
title: "[Work_Item]"
labels:
- "work item"
assignees:
- "shawnalpay"
- "jpradocueva"
body:
- type: markdown
attributes:
value: |
---
### **Template Usage Notes**:
1. All fields marked as **mandatory** [*] must be filled before submission. While some datapoints are optional for the initial creation of the work item, all datapoints must be provided in order to be considered for spec development.
2. If you have suggestions for the specification but cannot fill out all fields in this issue template, please fill out a [Feedback] or [Discussion] issue template instead.
3. For **Supporting Documentation**, ensure that linked files are accessible to relevant stakeholders.
- type: markdown
attributes:
value: |
## 1. **Problem Statement**
Describe the problem, issue, use case, or opportunity that this work item addresses.
Include practitioner quotes illustrating real examples a) of questions being asked by practitioners and b) value unlocked by answering these questions, if available.
- **What is the problem?**: Explain the context and why it needs resolution.
- **Impact**: Describe how the problem affects users, systems, or the project.
- type: textarea
id: problem_statement
attributes:
label: "Problem Statement"
description: "Provide a detailed explanation of the problem or issue."
placeholder: "Your input here..."
value: "Provide details of the problem statement here."
validations:
required: true

- type: markdown
attributes:
value: |
## 2. **Objective**
State the objective of this work item. What outcome is expected?
- **Success Criteria**: Define how success will be measured (e.g. metrics and KPIs).
- type: textarea
id: objective
attributes:
label: "Objective"
description: "Describe the expected outcome and success criteria."
placeholder: "Your input here..."
value: "Outline the expected outcome and success criteria."
validations:
required: true

- type: markdown
attributes:
value: |
## 3. **Supporting Documentation**
- Data Examples: [Link to data or relevant files; DO NOT share proprietary information]
- Related Use Cases or Discussion Documents: [Link to discussion]
- PRs or Other References: [Link to relevant references]
- type: textarea
id: supporting_documentation
attributes:
label: "Supporting Documentation"
description: "Provide links to data examples, use cases, PRs, or other relevant documents."
placeholder: "Your input here..."
value: "Include links to supporting documentation, if applicable."
validations:
required: true

- type: markdown
attributes:
value: |
## 4. **Proposed Solution / Approach**
Outline any proposed solutions, approaches, or potential paths forward. Do not submit detailed solutions; please keep suggestions high-level.
- **Initial Ideas**: Describe potential solution paths, tools, or technologies.
- **Considerations**: Include any constraints, dependencies, or risks.
- **Feasibility**: Include any information that helps quantify feasibility, such as perceived level of effort to augment the spec, or existing fields in current data generator exports.
- **Benchmarks**: Are there established best practices for solving this problem available to practitioners today (e.g. mappings from existing CSP exports that are widely used)?
- type: textarea
id: proposed_solution
attributes:
label: "Proposed Solution / Approach"
description: "Outline potential solutions or approaches."
placeholder: "Your input here..."
value: "Summarize the proposed solution or approach."

- type: markdown
attributes:
value: |
## 5. **Epic or Theme Association**
> This section will be completed by the Maintainers.
> - **Epic**: [Epic Name]
> - **Theme**: [Theme Name, if applicable]
- type: textarea
id: epic_theme
attributes:
label: "Epic or Theme Association"
description: "Provide potential epics or themes"
placeholder: "Your input here..."
value: "Provide the rational for the Epic or Theme."

- type: markdown
attributes:
value: |
## 6. **Stakeholders**
List the main stakeholders for this issue.
- **Primary Stakeholder**: [Name/Role]
- **Other Involved Parties**: [Names/Roles]
- type: textarea
id: stakeholders
attributes:
label: "Stakeholders"
description: "List the main stakeholders for this work item."
placeholder: "Your input here..."
value: "Provide names and roles of key stakeholders."
75 changes: 47 additions & 28 deletions EDITORIAL_GUIDELINES.md
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,6 @@ The "Editorial Style Guidelines" section ensures consistency and clarity across

These guidelines can be modified through a Pull Request (PR), which the members must review and agree upon. This process ensures that any changes are thoughtfully considered and maintains the overall integrity of our editorial standards.


<table>
<tr>
<th>Component</th>
Expand All @@ -12,27 +11,26 @@ These guidelines can be modified through a Pull Request (PR), which the members
<th>Editorial Guidelines</th>
</tr>
<tr>
<td><strong>Column &amp; Attribute Names</strong>:</td>
<td><strong>Column &amp; Attribute Names:</strong></td>
<td>
<strong>Column Names</strong>:<br>
- <strong>Pricing Quantity</strong><br>
- <strong>Pricing Unit</strong><br>
- <strong>Provider</strong> <br><br>
- Pricing Quantity<br>
- Pricing Unit<br>
- Provider <br><br>
<strong>Attribute Names</strong>:<br>
- <strong>Currency Code Format</strong><br>
- <strong>Date/Time Format</strong>
- Currency Code Format<br>
- Date/Time Format
</td>
<td>
<strong>Column Names</strong>:<br>
&nbsp;&nbsp; **Pricing Quantity**<br>
&nbsp;&nbsp; **Pricing Unit**<br>
&nbsp;&nbsp; **Provider**<br><br>
<strong>Column Names:</strong><br>
&nbsp;&nbsp; Pricing Quantity<br>
&nbsp;&nbsp; Pricing Unit<br>
&nbsp;&nbsp; Provider<br><br>
<strong>Attribute Names</strong>:<br>
&nbsp;&nbsp; **Currency Code Format**<br>
&nbsp;&nbsp; **Date/Time Format**<br>
&nbsp;&nbsp; Currency Code Format<br>
&nbsp;&nbsp; Date/Time Format<br>
</td>
<td>
- Bold <br>
- Use the display name in the non-normative section.<br>
- The first occurrence in a section is linked to the section.
</td>
Expand All @@ -41,28 +39,44 @@ These guidelines can be modified through a Pull Request (PR), which the members
<td><strong>Column &amp; Attribute IDs:</strong></td>
<td>
<strong>Columns IDs</strong>:<br>
- PricingQuantity</strong><br>
- PricingUnit</strong><br>
- ProviderName</strong> <br><br>
- PricingQuantity<br>
- PricingUnit<br>
- ProviderName<br><br>
<strong>Attributes IDs</strong>:<br>
- CurrencyCodeFormat <br>
- DateTimeFormat <br>
</td>
<td>
<strong>Columns IDs:</strong>:<br>
<strong>Columns IDs:</strong><br>
&nbsp;&nbsp; PricingQuantity <br>
&nbsp;&nbsp; PricingUnit</strong><br>
&nbsp;&nbsp; ProviderName</strong> <br><br>
&nbsp;&nbsp; PricingUnit<br>
&nbsp;&nbsp; ProviderName <br><br>
<strong>Attributes IDs:</strong> </br>
&nbsp;&nbsp; CurrencyCodeFormat </br>
&nbsp;&nbsp; DateTimeFormat <br>
</td>
<td>
- Use PascalCamel case (the first letter of every word, is capitalized)
- Use PascalCamel case (the first letter of every word, is capitalized)<br>
- Normal text without bold or italics.<br>
- The first occurrence in a section is linked to the section.
</td>
</tr>
<tr>
<td><strong>Column Values:</strong></td>
<td>
- "Usage"<br>
- "Tax"<br>
- "TB"<br>
</td>
<td>
This column:<br>
&nbsp;&nbsp; * MUST be null when ChargeCategory is "Tax" ...
</td>
<td>
- Enclosed in double quotation marks<br>
- Normal text without bold or italics
</td>
</tr>
<tr>
<td><strong>Normative Keywords &amp; Statements</strong></td>
<td>
Expand Down Expand Up @@ -130,21 +144,26 @@ These guidelines can be modified through a Pull Request (PR), which the members

* **Normative Requirements as a Bullet List**: Normative statements (those using Normative Keywords) should be written as bullet points instead of lengthy sentences.

* **Column IDs:** They SHOULD be used in normative text sections, such as when specifying mandatory rules, schema definitions, or other implementation-related content. These Column IDs should be formatted without spaces and should match the exact naming conventions used in the schema (e.g., CommitmentDiscountID).

* **Display Names:** They SHOULD be used in introductory or explanatory sections where natural language context is more appropriate. In these sections, display names should follow normal text conventions, including spaces between words (e.g., Commitment Discount ID).


### Example

> **2.28. Pricing Quantity**
>
> The **[Pricing Quantity](#pricing-quantity)** represents the volume of a given [SKU](#glossary:sku) associated with a [resource](#glossary:resource) or [service](#glossary:service) used or purchased, based on the **[Pricing Unit](#pricing-unit)**. Distinct from **[Consumed Quantity](#consumed-quantity)** (complementary to **[Consumed Unit](#consumed-unit)**), it focuses on pricing and cost, not resource and service consumption.
> The Pricing Quantity represents the volume of a given SKU associated with a [*resource*](#glossary:resource) or [*service*](#glossary:service) used or purchased, based on the [Pricing Unit](#pricingunit). Distinct from [Consumed Quantity](#consumedquantity) (complementary to [Consumed Unit](#consumedunit)), it focuses on pricing and cost, not *resource* and *service* consumption.
>
> * The PricingQuantity column MUST be present in the billing data.
> * This column MUST be of type Decimal and MUST conform to Numeric Format requirements.
> * The value MAY be negative in cases where ChargeClass is "Correction".
> * The PricingQuantity column MUST be present in a [*FOCUS dataset*](#glossary:FOCUS-dataset).
> * This column MUST be of type Decimal and MUST conform to [Numeric Format](#numericformat) requirements
> * The value MAY be negative in cases where [ChargeClass](#chargeclass) is "Correction".
>
> This column:
> * MUST NOT be null when ChargeClass is not "Correction" and ChargeCategory is "Usage" or "Purchase",
> * MUST NOT be null when [ChargeClass](#chargeclass) is not "Correction" and [ChargeCategory](#chargecategory) is "Usage" or "Purchase",
> * MUST be null when ChargeCategory is "Tax", and
> * MAY be null for all other combinations of ChargeClass and ChargeCategory.
> * When unit prices are not null, multiplying PricingQuantity by a unit price MUST produce a result equal to the corresponding cost metric, except in cases of ChargeClass "Correction", which may address PricingQuantity or any cost discrepancies independently.
> * When unit prices are not null, multiplying PricingQuantity by a unit price MUST produce a result equal to the corresponding cost metric, except in cases of ChargeClass "Correction", which may address PricingQuantity or any cost discrepancies independently.
>
> **2.28.1. Column ID**
>
Expand All @@ -156,7 +175,7 @@ These guidelines can be modified through a Pull Request (PR), which the members
>
> **2.28.3. Description**
>
> The volume of a given SKU associated with a resource or service used or purchased, based on the Pricing Unit.
> The volume of a given SKU associated with a *resource* or *service* used or purchased, based on the Pricing Unit.
>
> **2.28.4. Content Constraints Constraint**
>
Expand Down
Loading

0 comments on commit e582982

Please sign in to comment.