repo: mandatory issue templates (AIDM-426) #4235

tlhunter · 2024-12-17T22:52:20Z

What does this PR do?

disable freeform issues
adds two issue templates
adds a security document

Motivation:

standardizes the create issue experience across tracers

Additional Notes:

see the node.js create issue screen for an example of how this will look
I don't know the Ruby ecosystem so feel free to recommend any changes
- e.g. are ruby gems the main unit of packaging?

Change log entry
None.

github-actions · 2024-12-17T22:52:32Z

Thank you for updating Change log entry section 👏

^{Visited at: 2024-12-17 23:46:28 UTC}

datadog-datadog-prod-us1 · 2024-12-17T23:00:33Z

Datadog Report

Branch report: tlhunter/create-issue-standard
Commit report: 0e3b656
Test service: dd-trace-rb

❌ 1 Failed (0 Known Flaky), 21970 Passed, 1475 Skipped, 5m 21.27s Total Time
❄️ 1 New Flaky

❌ Failed Tests (1)

gem release process datadog.gemspec files includes all important files - rspec - Details

Expand for error

 the missing elements were:      ["SECURITY.md"]
 
 Failure/Error:
   expect(gemspec.files)
     .to match_array(
       \`git ls-files -z\`
         .split("\x0")
         .reject { |f| f.match(directories_excluded) }
         .reject { |f| f.match(single_files_excluded) }
     )
 ...

New Flaky Tests (1)

Datadog integration graceful shutdown for file descriptors closes tracer file descriptors (known flaky test) - rspec - Last Failure

Expand for error

 Wait time exhausted!
 
 Failure/Error: raise('Wait time exhausted!')
 
 RuntimeError:
   Wait time exhausted!
 ./spec/support/synchronization_helpers.rb:97:in \`try_wait_until'
 ./spec/datadog/integration_spec.rb:21:in \`wait_for_tracer_sent'
 ./spec/datadog/integration_spec.rb:64:in \`block (4 levels) in <top (required)>'
 ./spec/spec_helper.rb:237:in \`block (2 levels) in <top (required)>'
 ...

pr-commenter · 2024-12-17T23:13:13Z

Benchmarks

Benchmark execution time: 2024-12-19 00:20:27

Comparing candidate commit 0e3b656 in PR branch tlhunter/create-issue-standard with baseline commit 61ca49f in branch master.

Found 0 performance improvements and 0 performance regressions! Performance is the same for 31 metrics, 2 unstable metrics.

.github/ISSUE_TEMPLATE/bug_report.yaml

.github/ISSUE_TEMPLATE/config.yml

marcotc

Left one comment, suggesting we keep one of the existing sections, but overall super great work!

Co-authored-by: Marco Costa <[email protected]>

p-datadog · 2024-12-18T05:56:01Z

.github/ISSUE_TEMPLATE/feature_request.yaml

+  - type: input
+    attributes:
+      label: Gem Name
+      description: "If your feature request is to add instrumentation support for a Ruby gem please provide the name here"


I think "please provide the gem name here" would be more clear.

p-datadog · 2024-12-18T05:56:46Z

.github/ISSUE_TEMPLATE/feature_request.yaml

+  - type: input
+    attributes:
+      label: Gem Version(s)
+      description: "If your feature request is to add instrumentation support for a Ruby gem please provide the version you use"


Also here, "please provide the version of the above gem that you use"

p-datadog · 2024-12-18T05:59:12Z

SECURITY.md

+
+## Supported Versions
+
+We accept vulnerability submissions for the [currently maintained release](https://github.com/DataDog/dd-trace-rb/releases).


I don't think it is clear what "the currently maintained release" is. My understanding is there are at least two since we do maintain both 1.x and 2.x branches. But we don't indicate which releases are maintained on the releases page - it just lists available releases.

I am not sure what the correct wording should be here but I think it would be helpful to provide at least a link to where one can figure out whether a particular release is maintained or not.

I can make "release" plural:

We accept vulnerability submissions for the [currently maintained releases](https://github.com/DataDog/dd-trace-rb/releases).

Essentially the visitor visits the releases page, sees that 1.x and 2.x is maintained, and knows not to file a bug report for an issue that they discover in a 0.x release.

All tracers have a releases page so that's the easiest way to ascertain what is current. The Node.js tracer goes further and explicitly maintains a tables of releases and their status but that might be too much to ask of other tracers:
https://github.com/DataDog/dd-trace-js?tab=readme-ov-file#version-release-lines-and-maintenance

ivoanjo · 2024-12-18T09:00:31Z

.github/ISSUE_TEMPLATE/bug_report.md

-**How does `datadog` help you?**
-<!-- Optionally, tell us why and how you're using datadog, and what your overall experience with it is! -->


I kinda liked this part -- I think it's nice to have a little corner where customers can say "I'm actually quite happy with this, helped with X or Y so far".

It's not strictly related to fixing an issue or a feature request, but it provides a bit of a balance, and it's always optional :)

I can add it, it's certainly easy to do, but I'm not sure if an issue report is the appropriate place to collect this information. Is it actionable? None of the other tracers ask for it. It's also not Ruby specific.

So... I argue that not everything needs to exist for a purely functional purpose. That's why our offices have great views and cool art on the wall ;)

/me drags over his soap box, gets on top of it

An issue report is often something that can sound quite negative/disappointing. Customers are coming to us and saying "hey, this thing is breaking my app! I'm unable to get this to work! This is not doing what I wanted".

Having this section is an optional opportunity to mix it up a bit. To pause and say "yeah, I've been a very happy user so far, and I use it every day" kinda thing.

Here's 5 examples of customers filling it:

How does datadog help you?

We use it for tracing, logging, CI management and security (https://github.com/DataDog/dd-trace-rb/issues/4191)

We are using the Ruby profiler as part of our observability stack to profile Ruby applications. (https://github.com/DataDog/dd-trace-rb/issues/3853)

I'm trying to understand a trace with lots of cache spans but can't determine where to improve the application because the span is missing the necessary information. (https://github.com/DataDog/dd-trace-rb/issues/3808)

Some great tracing and profiling :) (https://github.com/DataDog/dd-trace-rb/issues/3804)

My team and I benefit immensely from Datadog observability! Quick debugging, performance optimization and proactive alerting. (https://github.com/DataDog/dd-trace-rb/issues/3784)

To extend our log by helpful information to support customers (https://github.com/DataDog/dd-trace-rb/issues/3773)

Could we have tackled these issues without this info? Yeah, most definitely. And yet... it's nice to read these, and sometimes even useful because it hints at the wider use-case!

Every opportunity we have to interact with a customer is an opportunity to open a dialog, to understand what's good and bad about our software, to see how we can make them more successful and also of course to sell our product and brand!

We're not computers, and neither are our customers, so in my humble opinion we shouldn't over-optimize to treat this process like a computational one. This is a conversation, between humans, not an API call between computers!

/me puts away his soapbox and fades away

repo: mandatory issue templates

c07420f

tlhunter added docs Involves documentation dev/github Github repository maintenance and automation dev/internal Other internal work that does not need to be included in the changelog labels Dec 17, 2024

tlhunter requested a review from a team as a code owner December 17, 2024 22:52

marcotc reviewed Dec 17, 2024

View reviewed changes

.github/ISSUE_TEMPLATE/bug_report.yaml Show resolved Hide resolved

marcotc reviewed Dec 17, 2024

View reviewed changes

.github/ISSUE_TEMPLATE/config.yml Outdated Show resolved Hide resolved

marcotc reviewed Dec 17, 2024

View reviewed changes

.github/ISSUE_TEMPLATE/config.yml Outdated Show resolved Hide resolved

marcotc approved these changes Dec 17, 2024

View reviewed changes

tlhunter and others added 3 commits December 17, 2024 15:33

Update .github/ISSUE_TEMPLATE/config.yml

def1e38

Co-authored-by: Marco Costa <[email protected]>

Update .github/ISSUE_TEMPLATE/config.yml

86153b8

Co-authored-by: Marco Costa <[email protected]>

prompt for library name and version

cf94d29

p-datadog reviewed Dec 18, 2024

View reviewed changes

ivoanjo reviewed Dec 18, 2024

View reviewed changes

tlhunter enabled auto-merge (squash) December 18, 2024 15:59

tweaks

0e3b656

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

repo: mandatory issue templates (AIDM-426) #4235

repo: mandatory issue templates (AIDM-426) #4235

tlhunter commented Dec 17, 2024 •

edited

Loading

github-actions bot commented Dec 17, 2024 •

edited

Loading

datadog-datadog-prod-us1 bot commented Dec 17, 2024 •

edited

Loading

pr-commenter bot commented Dec 17, 2024 •

edited

Loading

marcotc left a comment

p-datadog Dec 18, 2024

p-datadog Dec 18, 2024

tlhunter Dec 18, 2024

p-datadog Dec 18, 2024 •

edited

Loading

tlhunter Dec 18, 2024

ivoanjo Dec 18, 2024

tlhunter Dec 18, 2024

ivoanjo Dec 19, 2024 •

edited

Loading


		## Supported Versions

		We accept vulnerability submissions for the [currently maintained release](https://github.com/DataDog/dd-trace-rb/releases).

		How does `datadog` help you?
		<!-- Optionally, tell us why and how you're using datadog, and what your overall experience with it is! -->

repo: mandatory issue templates (AIDM-426) #4235

Are you sure you want to change the base?

repo: mandatory issue templates (AIDM-426) #4235

Conversation

tlhunter commented Dec 17, 2024 • edited Loading

github-actions bot commented Dec 17, 2024 • edited Loading

datadog-datadog-prod-us1 bot commented Dec 17, 2024 • edited Loading

Datadog Report

❌ Failed Tests (1)

New Flaky Tests (1)

pr-commenter bot commented Dec 17, 2024 • edited Loading

Benchmarks

marcotc left a comment

Choose a reason for hiding this comment

p-datadog Dec 18, 2024

Choose a reason for hiding this comment

p-datadog Dec 18, 2024

Choose a reason for hiding this comment

tlhunter Dec 18, 2024

Choose a reason for hiding this comment

p-datadog Dec 18, 2024 • edited Loading

Choose a reason for hiding this comment

tlhunter Dec 18, 2024

Choose a reason for hiding this comment

ivoanjo Dec 18, 2024

Choose a reason for hiding this comment

tlhunter Dec 18, 2024

Choose a reason for hiding this comment

ivoanjo Dec 19, 2024 • edited Loading

Choose a reason for hiding this comment

tlhunter commented Dec 17, 2024 •

edited

Loading

github-actions bot commented Dec 17, 2024 •

edited

Loading

datadog-datadog-prod-us1 bot commented Dec 17, 2024 •

edited

Loading

pr-commenter bot commented Dec 17, 2024 •

edited

Loading

p-datadog Dec 18, 2024 •

edited

Loading

ivoanjo Dec 19, 2024 •

edited

Loading