8.6.0-alpha4 release notes

[akeller]

Description

Based on labeled epics

When should this change go live?

• This is a bug fix, security concern, or something that needs urgent release support.
• This is already available but undocumented and should be released within a week.
• This on a specific schedule and the assignee will coordinate a release with the DevEx team. (apply hold label or convert to draft PR)
• This is part of a scheduled alpha or minor. (apply alpha or minor label)
• There is no urgency with this change and can be released at any time.

PR Checklist

• My changes are for an already released minor and are in /versioned_docs directory.
• My changes are for the next minor and are in /docs directory (aka /next/).

• My changes require an Engineering review, and I've assigned the Engineering DRI or delegate.
• My changes require a technical writer review, and I've assigned @camunda/tech-writers as a reviewer.

[github-actions]

👋 🤖 🤔 Hello! Did you make your changes in all the right places?

These files were changed only in docs/. You might want to duplicate these changes in versioned_docs/version-8.5/.

• docs/reference/release-notes/860.md

You may have done this intentionally, but we wanted to point it out in case you didn't. You can read more about the versioning within our docs in our documentation guidelines.

[akeller]

‼️ This needs a link from #4053 before merging! ‼️

[mesellings]

@christinaausley @conceptualshark I'll perform an initial review 👍

[mesellings]

@akeller Looks good, just a few edits I made directly to the branch.
@christinaausley @conceptualshark I have performed an initial review and made edit commits directly:

• Some grammatical edits
• Readability edits for conciseness and clarity
  I haven't approved as I think this PR is set to auto-merge on approval, so I will hold off on approving until you are happy with your review.

Some non-blocking open questions I had:

• Do we leave out links to docs from the RN for a reason, e.g. for new connectors it would be good to loink to the new connector doc?
• How do we decide what the order is for entries - is it by 'importance' as it were?
• If features are public in Github, is it of any value to include issue #s for users, e.g. as a bracketed (Issue Origin/editorialreview cloudconsole #333) somewhere? Just an idea - if customers are tracking an issue, this helps them tie this together with the RN entries.

[akeller]

• Do we leave out links to docs from the RN for a reason, e.g. for new connectors it would be good to loink to the new connector doc?
• How do we decide what the order is for entries - is it by 'importance' as it were?
• If features are public in Github, is it of any value to include issue #s for users, e.g. as a bracketed (Issue Origin/editorialreview cloudconsole #333) somewhere? Just an idea - if customers are tracking an issue, this helps them tie this together with the RN entries.

There is a lot of room for improvement with this, so most of my answers will be the same—this is best effort while we work out the internal process and habits of adding release notes to epics! We've iterated and improved over every release notes PR since introducing them in 8.5.

Re: links - I would love to link from each epic into the docs, but we usually have a 🐔 🥚 problem where the docs PRs are still coming in as we are building the release notes. We can also follow up with a subsequent PR on or after release day, particularly for alpha releases.

Re: order - it's typically how I see them in Product Hub. There is an open draft PR for more visual grouping, but not ordering.

Re: public issues and epics - these can be hard to find. Some are on a team task board, some are on the docs repo, and some are a combination of private/public epics. I would like to formalize a process here in the future.

Is this something you'd like to get involved with @mesellings?

[mesellings]

@akeller Happy to help/get involved with/lead (whichever is most suitable) - although release notes can be a pain, they also help to really showcase docs sometimes as a single point in time where everybody reads the same new docs at once - it's a great opportunity, look at what it has done for Slack docs in the past for example.