For our monthly issue metrics, Include the date range in the title and label "metrics"

[jhkennedy]

Makes it so we can search for all the reports easily:
https://github.com/nsidc/earthaccess/issues?q=is%3Aissue+label%3Ametrics+

And that the specific date range of the report is clear.

Pull Request (PR) draft checklist - click to expand

• Please review our
  contributing documentation
  before getting started.
• Populate a descriptive title. For example, instead of "Updated README.md", use a
  title such as "Add testing details to the contributor section of the README".
  Example PRs: #763
• Populate the body of the pull request with:
  • A clear description of the change you are proposing.
  • Links to any issues resolved by this PR with text in the PR description, for
    example closes #1. See
    GitHub docs - Linking a pull request to an issue.
• Update CHANGELOG.md with details about your change in a section titled
  ## Unreleased. If such a section does not exist, please create one. Follow
  Common Changelog for your additions.
  Example PRs: #763
• Update the documentation and/or the README.md with details of changes to the
  earthaccess interface, if any. Consider new environment variables, function names,
  decorators, etc.

Click the "Ready for review" button at the bottom of the "Conversation" tab in GitHub
once these requirements are fulfilled. Don't worry if you see any test failures in
GitHub at this point!

Pull Request (PR) merge checklist - click to expand

Please do your best to complete these requirements! If you need help with any of these
requirements, you can ping the @nsidc/earthaccess-support team in a comment and we
will help you out!

• Add unit tests for any new features.
• Apply formatting and linting autofixes. You can add a GitHub comment in this Pull
  Request containing "pre-commit.ci autofix" to automate this.
• Ensure all automated PR checks (seen at the bottom of the "conversation" tab) pass.
• Get at least one approving review.

---

📚 Documentation preview 📚: https://earthaccess--841.org.readthedocs.build/en/841/

[github-actions]

👈 Launch a binder notebook on this branch for commit cae6ac4

I will automatically update this comment whenever this PR is modified

👈 Launch a binder notebook on this branch for commit e9c671f

[jhkennedy]

Question: Should we also close the metrics issues after X time?

[mfisher87]

I don't see a reason for metrics issues to have an open status. I think we'll get notified when they're created either way? We could even mark them as "not planned" instead of "closed" to keep them out of the "business as usual" views of issues.

[mfisher87]

Nice :)

[jhkennedy]

I don't see a reason for metrics issues to have an open status. I think we'll get notified when they're created either way? We could even mark them as "not planned" instead of "closed" to keep them out of the "business as usual" views of issues.

@mfisher87 yep, anyone watching issues should get notified on create.

I've updated the action to close it right after it's created as "not planned". Relevant gh docs: https://cli.github.com/manual/gh_issue_close

(I wonder if we should sleep a little between open and close?)

[jhkennedy]

@mfisher87 would you say this satisfies #588?

If you do want it a discussion, it should be straight forward to switch to:
https://github.com/marketplace/actions/create-github-discussion

[mfisher87]

Yeah, I think closing as not-planned addresses the original need. 🚀