• Icon: Task Task
    • Resolution: Fixed
    • Icon: L3 - Default L3 - Default
    • 7.6.0, 7.6.0-alpha3
    • 7.6.0-alpha3
    • None
    • None

      Write Blogpost for 7.6.0-alpha3

        This is the controller panel for Smart Panels app

            [CAM-6567] Blog post for 7.6.0-alpha3

            Christopher Kujawa created issue -

            Hey thorben.lindhauer,

            please review the blogpost, which is pushed on 7.6.0-alpha3 branch.

            Greets,
            Chris

            Christopher Kujawa added a comment - Hey thorben.lindhauer , please review the blogpost, which is pushed on 7.6.0-alpha3 branch. Greets, Chris
            Christopher Kujawa made changes -
            Assignee Original: Christopher Kujawa [ christopher.zell ] New: Thorben Lindhauer [ thorben.lindhauer ]
            Resolution New: Fixed [ 1 ]
            Status Original: Open [ 1 ] New: Resolved [ 5 ]
            Remaining Estimate New: 0 minutes [ 0 ]
            Original Estimate New: 0 minutes [ 0 ]
            Thorben Lindhauer made changes -
            Fix Version/s New: 7.6.0 [ 14490 ]
            Fix Version/s New: 7.6.0-alpha3 [ 14609 ]

            Review:

            • General
              • a blog post should not be much longer than that, especially if it contains a lot of text like this post. Not all readers are as excited about this as we are
              • less is sometimes more: The blogpost should provide an overview of what is new and link to appropriate documentation sections that describe the new features in detail. Then readers can dive deeper where they like instead of having to read through a large amount of text (and we need good in detail descriptions in the docs anyway).
              • Paragraphs should contain more than one sentence.
            • Reporting for Tasks
              • Is there documentation on the Java API part of this? => If yes, link to it
              • Given that we have such documentation, the entire section could be reduced to one paragraph of introduction and then a list of two bullet points that shortly describe each type of report and link to the docs (compare for example the sections "Reporting API and Duration Report" and "External Task Improvements" in the the 7.5.0 blogpost https://blog.camunda.org/post/2016/05/camunda-bpm-750-released/)
            • Support for Decisions with Literal Expressions
              • The first sentence is negatively phrased. Perhaps something like "In addition to decision tables, the DMN engine now supports literal expressions as decision implementations."
              • Similar for the last paragraph: "Expect Camunda Modeler support for literal expressions in the future." sounds more optimistic
            • Extended Queries for Decision Requirements Definitions
              • Link to the last alpha blog post or the docs for anyone who does not know what "Decision Requirements Definitions" are
              • I'm also not sure if these two query methods are worth mentioning at all
            • CMMN Engine Improvements
              • Consider making a list with one bullet point for every CMMN aspect
            • CMMN Cockpit
              • I would put this into the concluding section since it is not a feature of the new alpha
            • Rolling Upgrades
              • I would not mention the limitations. They are the first thing you find in the docs anyway.
              • The sentence "In the current release, we add support for rolling upgrades." sounds to me like there will be a Camunda feature (e.g. a tool) to orchestrate a rolling upgrade. Perhaps it would be more clear to write that we support backwards compatibility of the database schema which enables users performing rolling upgrades.
              • Since the documentation is quite extensive, I think that this section can be shortened. Instead of outlining the rolling upgrade process, just say what the benefits of a rolling upgrade are and link to the docs.
              • I find this diagram better fitting to represent the rolling upgrade process: https://docs.camunda.org/manual/latest/update/img/architecture-step5.png

            Thorben Lindhauer added a comment - Review: General a blog post should not be much longer than that, especially if it contains a lot of text like this post. Not all readers are as excited about this as we are less is sometimes more: The blogpost should provide an overview of what is new and link to appropriate documentation sections that describe the new features in detail. Then readers can dive deeper where they like instead of having to read through a large amount of text (and we need good in detail descriptions in the docs anyway). Paragraphs should contain more than one sentence. Reporting for Tasks Is there documentation on the Java API part of this? => If yes, link to it Given that we have such documentation, the entire section could be reduced to one paragraph of introduction and then a list of two bullet points that shortly describe each type of report and link to the docs (compare for example the sections "Reporting API and Duration Report" and "External Task Improvements" in the the 7.5.0 blogpost https://blog.camunda.org/post/2016/05/camunda-bpm-750-released/ ) Support for Decisions with Literal Expressions The first sentence is negatively phrased. Perhaps something like "In addition to decision tables, the DMN engine now supports literal expressions as decision implementations." Similar for the last paragraph: "Expect Camunda Modeler support for literal expressions in the future." sounds more optimistic Extended Queries for Decision Requirements Definitions Link to the last alpha blog post or the docs for anyone who does not know what "Decision Requirements Definitions" are I'm also not sure if these two query methods are worth mentioning at all CMMN Engine Improvements Consider making a list with one bullet point for every CMMN aspect CMMN Cockpit I would put this into the concluding section since it is not a feature of the new alpha Rolling Upgrades I would not mention the limitations. They are the first thing you find in the docs anyway. The sentence "In the current release, we add support for rolling upgrades." sounds to me like there will be a Camunda feature (e.g. a tool) to orchestrate a rolling upgrade. Perhaps it would be more clear to write that we support backwards compatibility of the database schema which enables users performing rolling upgrades. Since the documentation is quite extensive, I think that this section can be shortened. Instead of outlining the rolling upgrade process, just say what the benefits of a rolling upgrade are and link to the docs. I find this diagram better fitting to represent the rolling upgrade process: https://docs.camunda.org/manual/latest/update/img/architecture-step5.png
            Thorben Lindhauer made changes -
            Status Original: Resolved [ 5 ] New: Closed [ 6 ]
            Thorben Lindhauer made changes -
            Workflow Original: camunda BPM [ 39453 ] New: Backup_camunda BPM [ 62027 ]

              thorben.lindhauer Thorben Lindhauer
              christopher.zell Christopher Kujawa
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: