From f7e7a522e11fe19884335cd4fc458912307f2ad8 Mon Sep 17 00:00:00 2001
From: Dana Robinson <43805+derobins@users.noreply.github.com>
Date: Fri, 15 Mar 2024 10:36:18 -0700
Subject: [PATCH] Make the newsletter scheme work like HDF4 (#4149)

---
 release_docs/NEWSLETTER_README.txt | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)
 create mode 100644 release_docs/NEWSLETTER_README.txt

diff --git a/release_docs/NEWSLETTER_README.txt b/release_docs/NEWSLETTER_README.txt
new file mode 100644
index 00000000000..f03f710d717
--- /dev/null
+++ b/release_docs/NEWSLETTER_README.txt
@@ -0,0 +1,25 @@
+INTRODUCTION
+============
+
+This purpose of this document is to contain entries that can be used to quickly
+produce a release newsletter. When something is added to the library that is
+"newsletter worthy" (i.e., new feature, CVE fix, etc.) a summary note should
+be added here.
+
+The format should look like this:
+
+* SUMMARY OF NEWSLETTER-WORTHY THING
+
+    Here is where you describe the summary. Summarize the feature, fix, or
+    change in general language. Remember, RELEASE.txt is for communicating
+    technical specifics. Text entered here is more like advertising.
+
+    (GitHub #123, #125)
+
+The GitHub #s could be relevant issues or PRs. They will probably not appear
+in the final newsletter, but are so that the person writing the newsletter
+has easy access to context if they have questions.
+
+Every entry in RELEASE.txt does NOT require an entry here. The newsletter is
+for communicating major changes that are of interest to anyone. Minor bugfixes,
+memory leak fixes, etc. do not require entries.