Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

intro changes for smooth migration zeebe user tasks next #4723

Open
wants to merge 15 commits into
base: main
Choose a base branch
from

Conversation

christinaausley
Copy link
Contributor

@christinaausley christinaausley commented Dec 6, 2024

Description

Resolves remaining changes for https://github.com/camunda/product-hub/issues/2126/.

Note a few open questions below, but the overall goal:

- Should the references in the docs be "Camunda user tasks" or "Job worker-based user tasks managed by Camunda"? The latter is rather wordy, but maybe we can figure out a solution. Regardless, this should only be for the 8.7 docs, yes? Should they still be called "Zeebe user tasks" in 8.6 and 8.5?

Additionally, I am planning to make the following changes:

For 8.6

  • Document that user tasks with Job worker implementation are deprecated (but supported).
  • Explicitly state in migration guide why it is recommended to design a process with one implementation type.

For 8.7

  • Note that the Tasklist API will no longer be supported with 8.9 and recommend migrating. Do we need to mark this as deprecated, or rather just note that it is going to be removed but is still supported?
  • Remove interactive questionnaire in migration guide
  • Rename Zeebe user task to job worker-based user tasks managed by Camunda and note terminology change with admonition as the XML may still show Zeebe user task.
  • Document that the C8 REST API only supports user tasks with the Camunda user task implementation.
  • Document that embedded forms are supported only for Job worker-based user tasks. Is this only for next or also should be backported?
    E.g. this section needs to be updated: https://docs.camunda.io/docs/next/components/modeler/web-modeler/advanced-modeling/form-linking/#camunda-form-embedded
  • Add a clear announcement.
  • Add terminology to glossary.

A majority of changes for 8.5 and 8.6 have been launched via PR here, though I plan to launch a separate PR for the changes above.

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/).

Copy link
Contributor

github-actions bot commented Dec 6, 2024

👋 🤖 🤔 Hello, @christinaausley! 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.6/.

  • docs/apis-tools/camunda-api-rest/camunda-api-rest-overview.md
  • docs/apis-tools/frontend-development/01-task-applications/02-user-task-lifecycle.md
  • docs/apis-tools/java-client/zeebe-process-test.md
  • docs/apis-tools/migration-manuals/migrate-to-camunda-user-tasks.md
  • docs/apis-tools/tasklist-api-rest/assets/forms/userTaskMigrationDecisionHelperForm.js
  • docs/apis-tools/tasklist-api-rest/assets/img/camunda-user-task-selection.png
  • docs/apis-tools/tasklist-api-rest/assets/img/zeebe-user-task-selection.png
  • docs/apis-tools/tasklist-api-rest/specifications/search-tasks.api.mdx
  • docs/apis-tools/zeebe-api-rest/zeebe-api-rest-overview.md
  • docs/components/concepts/process-instance-migration.md
  • docs/reference/announcements/870.md
  • docs/reference/glossary.md
  • docs/reference/release-notes/850.md
These files were changed only in versioned_docs/version-8.6/. You might want to duplicate these changes in docs/.
  • versioned_docs/version-8.6/apis-tools/frontend-development/01-task-applications/01-introduction-to-task-applications.md
  • versioned_docs/version-8.6/apis-tools/migration-manuals/migrate-to-zeebe-user-tasks.md
  • versioned_docs/version-8.6/apis-tools/tasklist-api-rest/tasklist-api-rest-overview.md
These files were changed only in optimize/. You might want to duplicate these changes in optimize_versioned_docs/version-3.14.0/.
  • optimize/components/userguide/process-analysis/user-task-analytics.md
  • optimize/self-managed/optimize-deployment/configuration/system-configuration-platform-8.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.

@christinaausley christinaausley added the 8.7.0-alpha3 January 2024 alpha release label Dec 6, 2024
@volodymyr-melnykc
Copy link
Contributor

  • Should the references in the docs be "Camunda user tasks" or "Job worker-based user tasks managed by Camunda"? The latter is rather wordy, but maybe we can figure out a solution. Regardless, this should only be for the 8.7 docs, yes? Should they still be called "Zeebe user tasks" in 8.6 and 8.5?

@christinaausley In the documentation we should describe how to migrate from Job worker-based user tasks to Camunda user tasks. We can cover it on the page https://docs.camunda.io/docs/next/apis-tools/migration-manuals/migrate-to-zeebe-user-tasks/.

Job worker-based user tasks are deprecated by Camunda with the 8.6 release, but they will continue to be supported to accommodate custom use cases. Either @aleksander-dytko or I can help document this.

  • It is to be covered in the 8.7 docs and backported for 8.6.

Regarding the renaming of "Zeebe user tasks" to "Camunda user tasks," we should document the renaming in the 8.7 docs. In the 8.5 and 8.6 docs they can still be called "Zeebe user tasks" (as this is the term that was initially communicated to customers).

@christinaausley
Copy link
Contributor Author

@volodymyr-melnykc I will have a thorough look through this and make any of the additional adjustments in the PR description by the end of this week 👍

@christinaausley
Copy link
Contributor Author

@volodymyr-melnykc I have added a handful of changes if you would like to review. A few questions:

Explicitly state in migration guide why it is recommended to design a process with one implementation type.

Can you please add this to this PR, or let me know how you would like to phrase it and I can add it for you?

Note that the Tasklist API will no longer be supported with 8.9 and recommend migrating.

@volodymyr-melnykc Would you like me to move the Tasklist REST API into the Deprecated folder with this note?

@christinaausley christinaausley marked this pull request as ready for review December 13, 2024 16:58
@christinaausley
Copy link
Contributor Author

christinaausley commented Dec 13, 2024

@camunda/tech-writers I'd like to loop you into this sooner rather than later given the quantity of terminology changes across versions here -- without much context, and without looking too closely at the PR description 😉, do you understand what we are trying to do here in the files changed, or does it confuse your use/knowledge of the product?

I think my only concern is if users really understand the difference between the old job-based user tasks and job-based user tasks supported by Camunda/Camunda user tasks (formerly Zeebe user tasks).

@barmac
Copy link
Contributor

barmac commented Dec 17, 2024

Hi,
I noticed something that I'd like to clarify. @christinaausley you wrote:

job-based user tasks supported by Camunda/Camunda user tasks (formerly Zeebe user tasks)

These names are not equivalent. The options for user task implementation are:

  • job worker:
    • unmanaged (not depreacted; equivalent to Service task but with User task semantic on the diagram; typical for custom tasklist) - option 1
    • managed by Camunda (uses Tasklist v1 API; this is the implementation deprecated from 8.6) - option 2
  • Camunda user task (former Zeebe user task, also managed by Camunda but within the runtime; this is the preferred implementation) - option 3

So there are two different solutions managed by Camunda, one of which is being deprecated (option 2).

Please let me know if it's clear. Also let's include @Skaiir in this.

mesellings
mesellings previously approved these changes Dec 17, 2024
Copy link
Contributor

@mesellings mesellings left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work - I reviewed the code without looking at the description, and it is pretty clear what you are trying to achieve here - I think this will be really helpful for users! It would help if we make sure the guide and change is highly visible in the announcements and release notes pages as well.

Just some non-blocking review suggestions as well, but nothing major at all, just some ideas as I went through it 👍

docs/apis-tools/java-client/zeebe-process-test.md Outdated Show resolved Hide resolved

#### [`POST /user-tasks/:taskKey/assignment`](/apis-tools/zeebe-api-rest/specifications/assign-a-user-task.api.mdx)
The endpoints above (except `DELETE`) allow you to send a custom `action` attribute via the payload. The `action` attribute carries any arbitrary string and can be used to track any life cycle event, including those mentioned above.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Non-blocking suggestion: Should we say above twice? If the content is moved, this reference then becomes wrong/orphaned - it is always useful where possible to not directly refer to the physical location of content, e.g. you could say instead:

Task life cycle events can be tracked via the following API endpoints.

You can use these endpoints (except DELETE) to send a custom action attribute via the payload. The action attribute carries any arbitrary string and can be used to track any life cycle event.

@@ -329,7 +324,7 @@ The following table outlines the respective endpoints. Click the endpoints to fo
</tr>
<tr>
<th style={{ textAlign: "end" }}>Update task</th>
<td style={{color: "gray"}}>-</td>
<td style={{color: "gray"}}>Not supported</td>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Non-blocking: One for the tech-writing team - do we say "unsupported" or "not supported"?

Copy link
Contributor Author

@christinaausley christinaausley Dec 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have a strong opinion, but can add to the glossary. WDYT? What is you experience with this terminology?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unsupported is marginally smaller, so can be better in a table of supported/unsupported items, but it is quite a niche case - we can discuss in a tech sync 👍

docs/apis-tools/zeebe-api-rest/tutorial.md Outdated Show resolved Hide resolved
docs/apis-tools/zeebe-api-rest/tutorial.md Outdated Show resolved Hide resolved
docs/components/concepts/process-instance-migration.md Outdated Show resolved Hide resolved
@christinaausley
Copy link
Contributor Author

Thank you all for your review -- I will have this cleaned up for a second review either today or tomorrow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
8.7.0-alpha3 January 2024 alpha release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants