[META] Update process for collecting inputs to project release blog posts

[jhmcintyre]

The blog posts the OpenSearch Project publishes on opensearch.org/blog to announce each new major or minor version release consistently rank among the project’s most well-read publications. For the past several releases, these blog posts have been developed following a process by which the project's developer relations team reaches out directly to feature owners to solicit and collect writeups for each feature on an individual basis. Relying on one-to-many and one-to-one outreach and information-gathering across a wide range of stakeholders for each release is an inefficient way to identify the key features to highlight and source descriptions of those features. This is even more the case as releases grow in scale.

To streamline the process of gathering the necessary inputs for release blogs, the project’s developer relations team and software development leadership are proposing a process designed to centralize much of the content collection inside GitHub, using meta issues that feature owners are already obligated to create and maintain. An overview of the process follows.

• Feature owners will open a meta issue for each new or enhanced feature that focuses on the functionality planned for the particular release
• When a new meta issue is created, the creator will be prompted to provide:
  • a release" label (e.g “2.19”) that assigns the issue to its corresponding release
  • an “add-to-release-blog” label (to be assigned if the creator believes the new or enhanced feature is appropriate for inclusion in the release blog post)
• If the meta issue is tagged with “add-to-release-blog,” the creator will be prompted to provide a “release blog synopsis” of the feature using a comment field (this could potentially also be incorporated into the meta issue body).
• The project’s developer relations team will use GitHub’s functionality to filter meta issues by release label and add-to-release-blog label, allowing us to filter the “release blog synopsis” comments to harvest all relevant feature summaries for the given release.
• The developer relations function will take the lead on compiling the feature synopses into a cohesive announcement, working with documentation and project editorial to ensure quality and accuracy as per the current process. Drafts and editorial review will be published & managed via GitHub.
• Over time, this process will lend itself to further automation and simplification.

By providing summaries of new or enhanced features through this process, feature owners can assure that their features will be included in the corresponding release blog post with an accurate overview of the feature’s functionality and benefits for users. Note that this process depends on feature owners opening dedicated meta issues that capture the specific functionality planned for the particular release and providing writeups that reflect that release’s functionality.

These process updates are also designed to support ongoing efforts to improve release efficiency as described in #5171.

[jhmcintyre]

Commenting to invite input from @getsaurabh02 @gaiksaya @krisfreedain @pajuric @natebower @kolchfa-aws

[gaiksaya]

Thanks for detail information @jhmcintyre . This looks promising and would definitely avoid the chase for consolidating the features to go in the release blog.
Couple of questions:

1. When it is being asked to open the META issue, am I right to assume this issue goes in respective repository? While scanning for the issues, we will be scanning the entire project repos right?
2. Can you also add some blog posts as an example?
3. Are release highlights (the ones that are added in the consolidated release notes) in scope of this issue or is that something that would be tracked separately?

I like the idea of just adding a label and having a check in the META body issue what the release highlight would look like when developers start working on the issues rather than adding a comment. Comments tend to grow overtime and convert into discussions making it hard to track.

[peterzhuamazon]

Hi @jhmcintyre,

I am more commenting on the technical level to achieve this in an automated way.

If the core ask is to:

• Add a label to an issue such as "add-to-release-blog"
• Then a comment with the detailed steps are shown in a followup comment
• Add related issue to a specific project board

Then this can be done through automation app: https://github.com/opensearch-project/automation-app.

Sample operation yaml (need more tweaks):

---
name: Add Blog Issue to Project Board

events:
  - issues.labeled

tasks:
  - name: Add a comment
    call: create-issue-comment@default
    args:
      text: |
        Steps to add your issue to a release blog:
          1. <>
          2. <>
  - name: Add issue to project
    call: add-issue-to-github-project-v2@default
    args:
      labels:
        - v2.19.0
        - add-to-release-blog
      projects:
        - opensearch-project/111
   - more tasks......

Once deployed it will act as a github app and process automation for you. More calls/tasks can be added per request.

Thanks.

[jhmcintyre]

Thanks for detail information @jhmcintyre . This looks promising and would definitely avoid the chase for consolidating the features to go in the release blog. Couple of questions:

1. When it is being asked to open the META issue, am I right to assume this issue goes in respective repository? While scanning for the issues, we will be scanning the entire project repos right?
2. Can you also add some blog posts as an example?
3. Are release highlights (the ones that are added in the consolidated release notes) in scope of this issue or is that something that would be tracked separately?

I like the idea of just adding a label and having a check in the META body issue what the release highlight would look like when developers start working on the issues rather than adding a comment. Comments tend to grow overtime and convert into discussions making it hard to track.

Thanks for the feedback @gaiksaya.

1. I think that's correct.
2. please see as examples: https://opensearch.org/blog/get-started-with-opensearch-2-18/, https://opensearch.org/blog/introducing-opensearch-2-17/, https://opensearch.org/blog/introducing-opensearch-2-16/
3. It's a good question. I typically solicit input for the release highlights through the same process and usually edit down what is submitted for the blog into shorter blurbs for the highlights. I think it probably makes sense to ask feature owners to provide either only an entry for release highlights (for a feature that may not be "blog worthy" but ought to be mentioned in the highlights) or to provide both (long-form paragraph for blog and short-form blurb for highlights). What are your thoughts on this?

To your last note, I'm very open to including this in the META body as opposed to a comments field if that's going to be useful for feature owners to populate & submit and usable for content collection.

[jhmcintyre]

Hi @jhmcintyre,

I am more commenting on the technical level to achieve this in an automated way.

If the core ask is to:

• Add a label to an issue such as "add-to-release-blog"
• Then a comment with the detailed steps are shown in a followup comment
• Add related issue to a specific project board

Then this can be done through automation app: https://github.com/opensearch-project/automation-app.

Sample operation yaml (need more tweaks):

---
name: Add Blog Issue to Project Board

events:
  - issues.labeled

tasks:
  - name: Add a comment
    call: create-issue-comment@default
    args:
      text: |
        Steps to add your issue to a release blog:
          1. <>
          2. <>
  - name: Add issue to project
    call: add-issue-to-github-project-v2@default
    args:
      labels:
        - v2.19.0
        - add-to-release-blog
      projects:
        - opensearch-project/111
   - more tasks......

Once deployed it will act as a github app and process automation for you. More calls/tasks can be added per request.

Thanks.

This is really interesting, @peterzhuamazon. I'd love to work with you to help implement this when the process is defined. To the question Sayali raises, would this sort of automation still work if the blog content were populated in the META issue body rather than in a comment?

[gaiksaya]

3. It's a good question. I typically solicit input for the release highlights through the same process and usually edit down what is submitted for the blog into shorter blurbs for the highlights. I think it probably makes sense to ask feature owners to provide either only an entry for release highlights (for a feature that may not be "blog worthy" but ought to be mentioned in the highlights) or to provide both (long-form paragraph for blog and short-form blurb for highlights). What are your thoughts on this?

Sounds good. Something like:

### Release blog

OR

### Release highlights

To your last note, I'm very open to including this in the META body as opposed to a comments field if that's going to be useful for feature owners to populate & submit and usable for content collection.

👍

[jhmcintyre]

Thank you @gaiksaya. I think we're close to arriving at a new process here. To recap where I think we've landed:

• Feature owners will open a meta issue for each new or enhanced feature that focuses on the functionality planned for the particular release
• When a new meta issue is created, the creator will be prompted to provide a release" label (e.g “2.20”) that assigns the issue to its corresponding release
• They will also be able to select an “add-to-release-blog” and "add-to-release-highlights" label (to be assigned if the creator believes the new or enhanced feature is appropriate for inclusion)
• The meta issue will include checks for for ### Release Blog and ### Release Highlights.
• If the issue creator believes the feature ought to be included in either or both of these, they are asked to populate these fields with draft summaries. If they do not wish to propose them for inclusion on one or both, they will populate those fields with "n/a"
• The project’s developer relations team will use GitHub’s functionality to filter meta issues by the release labels and extract the appropriate fields
• The developer relations function will take the lead on compiling the feature synopses into a cohesive announcement, working with documentation and project editorial to ensure quality and accuracy as per the current process. Drafts and editorial review will be published & managed via GitHub.

Does this track with your understanding? And, does this approach still lend itself to the type of automation @peterzhuamazon proposes above since it doesn't rely on comments?

Lastly, with this taking shape, can we decide which release we want to aim for implementing this? With development for 2.19 features well underway, I'm wondering if it makes sense to aim for the 2.20 cycle for this.

Appreciate the team's thoughts!

[peterzhuamazon]

Technically, as long as the trigger method is a github event, automation-app should be able to listen to it, and react accordingly based on the event.

Adding label is one of the easiest way to achieve that but I think only maintainers have access to add labels unless users open the issue with a template that already assigned a label.

Thanks.