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.
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.
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 https://github.com/opensearch-project/opensearch-build/issues/5171.