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.

Sign up for GitHub

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

Jump to bottom

Nitpicking the 8.0 Breaking Change issue template #81678

Merged
merged 2 commits into from
Oct 26, 2020
Merged

Nitpicking the 8.0 Breaking Change issue template #81678

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
0998143
Nitpicking the 8.0 Breaking Change issue template
kobelb Oct 26, 2020
fa28829
Rewording the percentage of users impacted question
kobelb Oct 26, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions .github/ISSUE_TEMPLATE/v8_breaking_change.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@
name: 8.0 Breaking change
about: Breaking changes from 7.x -> 8.0
title: "[Breaking change]"
labels: Team:Elasticsearch UI, Feature:Upgrade Assistant
labels: Team:Elasticsearch UI, Feature:Upgrade Assistant, Breaking Change
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I added the "Breaking Change" label to differentiate these from the other issues associated with the Upgrade Assistant. This would be a new label, I'm not tied to the name. I also considered making it Feature:Upgrade Assistant - Breaking Change. Any preference or thoughts on a different way to classify the two different types of issues?

Copy link
Contributor

Choose a reason for hiding this comment

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

Love it! What do you think of using the "Breaking change" label as a dimension for categorizing it by how it will be surfaced? We can create three labels:

Breaking Change
Breaking Change:Deprecation Log
Breaking Change:Deprecation API

By default, we can apply Breaking Change via this template. As these issues are created we'll triage them by swapping this label out for one of the others. Or do you think this overloads the label too much / adds too much complexity?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sounds good to me!

assignees: ''

---
Expand All @@ -11,15 +11,15 @@ assignees: ''

**Which release will ship the breaking change?**

<!-- e.g., v7.6.2 -->
8.0
Copy link
Contributor Author

Choose a reason for hiding this comment

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

The issue template states that it's an 8.0 breaking change, so it feels like this will be 8.0 for all of these? Or perhaps we should change Which release will ship the breaking change? to Which release first included the deprecation?, but I'm not sure how the answer to this new question impacts anything.

Copy link
Contributor

Choose a reason for hiding this comment

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

Good call hardcoding this in here. I don't think we'll ever encounter a scenario where we'll need to change this between now and the time 8.0 is GA.


**Describe the change. How will it manifest to users?**

**What percentage of users will be affected?**

<!-- e.g., Roughly 75% will need to make changes to x. -->
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This one is hard to answer if we don't have telemetry data, which is unfortunately rather common. I feel like we should be differentiating "guesses" from "data-driven" percentages... Thoughts? I answered the following when creating #81674

Based on data: ??
Based on hunches: a lot

Copy link
Contributor

@cjcenizal cjcenizal Oct 26, 2020 •
edited
Loading

Choose a reason for hiding this comment

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

Good point. I think we should change this question to be "What's the impact of this breaking change?" or "How many users will be impacted by this breaking change?" and then use the comment to prompt the author to explain their reasoning and whether they have data to measure the impact or some other heuristic.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Cool, sounds good. Lemme give it a shot real quick


**What can users to do to address the change manually?**
**What can users do to address the change manually?**

<!-- If applicable, describe the manual workaround -->

Expand Down