├── .github ├── .DS_Store └── ISSUE_TEMPLATE │ ├── abandoned-extension-maintainer-proposal.md │ ├── camunda-community-hub-pull-request-template.md │ ├── new-community-extension-proposal-template.md │ └── report-unmaintained-extension.md ├── .vscode └── settings.json ├── CONTRIBUTING.MD ├── README.md ├── assets ├── .gitkeep └── release-new-version (1).png ├── docs ├── CODEOWNERS ├── CODE_OF_CONDUCT.MD ├── LICENSE └── SECURITY.md ├── extension-lifecycle.md ├── issue-triage.md ├── maintainers-reviewers ├── RELEASE.MD ├── abandoned-extension-maintainer-guidelines.MD ├── creating-new-extensions.md ├── groupId.md ├── maintainer-best-practices.md ├── maintainer-reviewer-expectations.md └── transferring-extensions.md ├── pull-request-process.md └── workflows └── addtogithubprojects.yml /.github/.DS_Store: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/camunda-community-hub/community/e1efbee729ab68bbfd7323199ae9713ea1cfcb33/.github/.DS_Store -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/abandoned-extension-maintainer-proposal.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Maintainer Proposal 3 | about: Apply to become a maintainer of a currently unmaintained repo or one that is marked as looking for maintainers 4 | title: Extension Maintainer Proposal 5 | labels: abandoned-extension-maintainer-proposal 6 | assignees: '' 7 | 8 | --- 9 | 10 | # Camunda Community Hub extension maintainer proposal 11 | 12 | 13 | 14 | Please describe the changes and proposed roadmap you would implement as the Maintainer for this extension, and detail how you plan to support these goals. 15 | 16 | 18 | 19 | Your background 20 | 21 | 22 | 23 | 24 | 25 | Testing and CI/CD 26 | 27 | 28 | 29 | 30 | Checklist: 31 | 32 | 33 | 34 | 35 | I agree that I have either: 36 | - [ ] Made a good faith effort to contact the extension's original maintainer. 37 | - [ ] Successfully reached the extension’s original maintainer and they are in agreement that I am to maintain this extension moving forward. 38 | - [ ] I will update the documentation accordingly to reflect my status as this extension's Maintainer. 39 | - [ ] I have read the **Camunda Community Hub** [documentation](https://github.com/Camunda-Community-Hub/community). 40 | - [ ] I have read the Camunda Community Hub **abandoned extension Maintainer proposal** documentation. 41 | - [ ] I will /assign myself this issue, and add the relevant [issue labels](https://github.com/camunda-community-hub/community/blob/main/issue-triage.md) to it if they are not automatically generated by Probot. 42 | - [ ] I will tag @camunda-community-hub/devrel in a new comment on this issue if 30 days have passed since my pull request was opened and I haven't received a response from the extension's original maintainer. 43 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/camunda-community-hub-pull-request-template.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Camunda Community Hub Pull Request 3 | about: Template for a new pull request in a Camunda Community Hub repository 4 | title: Pull Request 5 | labels: '' 6 | assignees: '' 7 | 8 | --- 9 | 10 | # Camunda Community Hub Pull Request Template 11 | 12 | 13 | 14 | ## Description 15 | 16 | 17 | ## Additional context 18 | 19 | 20 | 21 | ## Testing your changes 22 | 23 | 24 | 25 | ## Types of changes 26 | 27 | - [ ] Bug fix (non-breaking change which fixes an existing open issue) 28 | - [ ] New feature (non-breaking change which adds functionality to an extension) 29 | - [ ] Breaking change (fix or feature that would cause existing functionality of an extension to change) 30 | - [ ] Documentation update (changes made to an existing piece of documentation) 31 | 32 | ## Checklist: 33 | 34 | 35 | - [ ] My code adheres to the syntax used by this extension. 36 | - [ ] My pull request requires a change to the documentation. 37 | - [ ] I have updated the documentation accordingly. 38 | - [ ] I have read the **Camunda Community Hub** documentation. 39 | - [ ] I have read the **Pull Request Process** documentation. 40 | - [ ] I have added or suggested tests to cover my changes suggested in this pull request. 41 | - [ ] All new and existing CI/CD tests passed. 42 | - [ ] I will /assign myself this issue, and add the relevant [issue labels] to it if they are not automatically generated by Probot. 43 | - [ ] I will tag @camunda-community-hub/devrel in a new comment on this issue if 30 days have passed since my pull request was opened and I have not received a response from the extension's maintainer. -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/new-community-extension-proposal-template.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: New Community Extension Proposal 3 | about: Propose a new Camunda Community Hub Extension 4 | title: '' 5 | labels: '' 6 | assignees: '' 7 | 8 | --- 9 | 10 | # Camunda Community Hub extension proposal 11 | 12 | 13 | 14 | ### Extension description 15 | 16 | 17 | ### Suggested use case 18 | 19 | 20 | ### Configuration 21 | 22 | 23 | ### Dependencies 24 | 25 | 26 | ### Issues/Challenges 27 | 28 | 29 | ### Extension lifecycle 30 | 31 | 32 | ### Additional context 33 | 34 | 35 | ### Maintainer eeded? 36 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/report-unmaintained-extension.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Report an Unmaintained Repo 3 | about: Alert the team to an unmaintained repo 4 | title: '' 5 | labels: '' 6 | assignees: '' 7 | 8 | --- 9 | 10 | # Camunda Community Hub - Report unmaintained repo template 11 | 12 | 13 | 14 | ## Repo URL 15 | 16 | 17 | ## Additional context 18 | 19 | -------------------------------------------------------------------------------- /.vscode/settings.json: -------------------------------------------------------------------------------- 1 | { 2 | "files.autoSave": "afterDelay", 3 | "git.autofetch": "all" 4 | } -------------------------------------------------------------------------------- /CONTRIBUTING.MD: -------------------------------------------------------------------------------- 1 | # Contributor Guide 2 | 3 | [fork]: /fork 4 | [pr]: /compare 5 | [CODE_OF_CONDUCT]: CODE_OF_CONDUCT.MD 6 | 7 | Hi there! We're thrilled that you'd like to contribute to this or other projects in the Camunda Community Hub. 8 | 9 | Please note that this project is released with a [Contributor Code of Conduct](docs/CODE_OF_CONDUCT.MD). By participating in this organization, you agree to abide by its terms. 10 | 11 | - [Issues and PRs](#issues-and-prs) 12 | - [Code contributions](#code-contributions) 13 | - [Non-code contributions](#non-code-contributions) 14 | - [Event-based community roles](#event-based-community-roles) 15 | - [Community education and onboarding](#community-education-and-onboarding) 16 | - [Issue triage](#issue-triage) 17 | - [Post-code specific contributions](#post-code-specific-contributions) 18 | - [Help project maintainers write release notes for their extension](#help-project-maintainers-write-release-notes-for-their-extension) 19 | - [Resources](#resources) 20 | - [Camunda contributions](#camunda-contributions) 21 | - [Getting started with open source](#getting-started-with-open-source) 22 | 23 | ## Issues and PRs 24 | 25 | If you have suggestions for how this project could be improved, or want to report a bug, open an issue! We'd love all and any contributions. If you have questions, too, we'd love to hear them. 26 | 27 | We'd also love PRs. If you're thinking of a large PR, we advise opening up an issue first to talk about it. Look at the links in [Resources](#resources) if you're not sure how to open a PR. 28 | 29 | Work in Progress pull requests are also welcome to get feedback early on, or if there is something blocking you that you would like an additional person to take a look at. 30 | 31 | For more guidance around pull requests, visit our [Pull Request Process](/pull-request-process.md). 32 | 33 | ## Code contributions 34 | 35 | While we have general guidelines, each community extension has its own preferences for accepting contributions. Check the repo for any specific guidance for contributing code. 36 | We also have guidelines for [Maintainer and Reviewer expectations.](maintainers-reviewers/maintainer-reviewer-expectations.md) 37 | 38 | ## Non-code contributions 39 | 40 | If you are interested in contributing to any Camunda Community Hub extension, there are a variety of ways to get involved without needing coding skills. These include issue triage, writing documentation, and much, much more. 41 | 42 | ### Event-based community roles 43 | 44 | * Host or organize a [Camunda meet-up](https://community.camunda.com/), in person or virtually 45 | * Present your work with Camunda at meet-ups 46 | * Start [a new Camunda event](https://community.camunda.com/) near you 47 | 48 | ### Community education and onboarding 49 | 50 | * Help new contributors get started working with the Hub, finding a repository to contribute to, forking a repo, and making their first pull request 51 | * Getting people involved in writing documentation and issue triage 52 | * Spreading the word about the Camunda Community Hub to the broader open source community 53 | * Answering questions on the Camunda forums, Stack Overflow, GitHub Project boards 54 | * Create content around Camunda and Community Hub projects 55 | * Write a blog post about your experience with Camunda, how you built a Community Hub extension, etc. 56 | * Be a guest on our [Camunda Community](https://www.buzzsprout.com/454051) podcast 57 | * Write walkthroughs, how-to guides, and more 58 | 59 | ### Issue triage 60 | 61 | * Labelling issues in Camunda Community Extension repositories 62 | * Helping to triage issues by following up where needed, closing stale issues, and more 63 | * For more information on how to get started with issue triage and labelling, including what issue labels and pull request automation we use in the Camunda Community Hub, please read the [documentation.](/issue-triage.md) 64 | 65 | ### Post-code specific contributions 66 | 67 | These are roles that are not code-based, but require some knowledge in that you will need to have an understanding of the Camunda community extension ecosystem, the Camunda codebase, or general programming knowledge. 68 | 69 | ### Help project maintainers write release notes for their extension 70 | 71 | * GitHub management (tags, repositories, etc.) 72 | * Mentoring new contributors and ensuring they have the tools they need to succeed when contributing to a Camunda Community Hub open source project 73 | * Writing new or editing existing documentation 74 | * Updating communication guidelines and expectations 75 | 76 | ## Resources 77 | 78 | ### Camunda contributions 79 | - [How to Contribute to Camunda](https://camunda.com/developers/how-to-contribute/) 80 | - [Camunda Code of Conduct](/docs/CODE_OF_CONDUCT.MD) 81 | - [Camunda Community Values](https://camunda.com/developers/community-values/) 82 | 83 | ### Getting started with open source 84 | - [How to Contribute to Open Source](https://opensource.guide/how-to-contribute/) 85 | - [Using Pull Requests](https://help.github.com/articles/about-pull-requests/) 86 | - [GitHub help](https://help.github.com) -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | ![Camunda-Community-Hub_1500x500](https://user-images.githubusercontent.com/43454823/224776667-3f90e92b-4df6-4978-a7d6-ea505df806a2.png) 2 | 3 | # Welcome to the Camunda Community Hub! 4 | A project to empower our open source community extension maintainers, and encourage new contributors to get started contributing to the Camunda open source ecosystem. 5 | 6 | # Table of Contents 7 | 8 | - [What is the Camunda Community Hub?](#what-is-the-camunda-community-hub) 9 | - [How to contribute](#how-to-contribute) 10 | - [Contributor resources \& documentation](#contributor-resources--documentation) 11 | - [Communication guidelines and expectations](#communication-guidelines-and-expectations) 12 | - [Troubleshooting and community support](#troubleshooting-and-community-support) 13 | - [Meet the Camunda Developer Relations team](#meet-the-camunda-developer-relations-team) 14 | - [Inspiration](#inspiration) 15 | 16 | ## What is the Camunda Community Hub? 17 | 18 | The Camunda Community Hub is a GitHub Organization for all of our community-contributed extensions. 19 | 20 | Extensions in the Camunda Community Hub organization are independently led and maintained projects by members of the broader Camunda open source community, some of whom happen to be Camunda employees, or are projects/tutorials that are created and maintained by the Camunda Developer Relations team! 21 | 22 | We’ve put together some commonly asked questions and answers about the Camunda Community Hub, our approach to open source contributions and maintainership, and how we hope to empower our open source community in the future. 23 | 24 | ## How to contribute 25 | * **Start a new community extension** by [opening an issue](https://github.com/Camunda-Community-Hub/community/issues/new/choose) using the `New Community Extension Proposal` template. Follow our complete documentation on [creating a new extension here.](maintainers-reviewers/creating-new-extensions.md) 26 | * **Transfer your existing repository** into the Camunda Community Hub (do not fork it into the Hub) following [these instructions.](maintainers-reviewers/transferring-extensions.md) 27 | * **Browse our existing projects and [contribute](/docs/CONTRIBUTING.MD)** -- code and non-code contributions welcome! 28 | 29 | All contributors also must sign our [CLA](https://cla-assistant.io/camunda-community-hub/community) and agree to our [Code of Conduct](https://camunda.com/events/code-conduct/). Then, review our [Contributor Guide](/docs/CONTRIBUTING.MD). 30 | 31 | 32 | ### Contributor resources & documentation 33 | * [Contributor guide](/CONTRIBUTING.MD) 34 | * [Issue triage and labeling](/issue-triage.md) 35 | * [Maintainers, start here](maintainers-reviewers/maintainers-start-here.md) 36 | * [Maintainer & reviewer expectations](maintainers-reviewers/maintainer-reviewer-expectations.md) 37 | * [Automated release documentation](/maintainers-reviewers/RELEASE.MD) 38 | * [Using our groupId for Java builds](/maintainers-reviewers/groupId.md) 39 | 40 | ## Communication guidelines and expectations 41 | 42 | As is the nature of open source software, maintainers and extension creators often wear many hats. These range from administrative, to QA, and much more. As extensions in the Camunda Community Hub are community led, it is crucial that users of extensions understand that maintainers are often working on community extensions in their free time. Please remember to be kind, and follow the [Camunda Community Code of Conduct](https://camunda.com/events/code-conduct/) and [Camunda Community Values](https://camunda.com/developers/community-values/) when interacting with project maintainers. 43 | 44 | Keep in mind that communication styles vary, and no two individuals communicate in the same way. Please do your best to remain helpful, and try to avoid making sweeping demands or generalizations whenever possible. It is expected that Maintainers will follow the Camunda Code of Conduct when interacting with community members, and the same holds true for community members interacting with extension maintainers. 45 | 46 | > **Not ideal:** “This feature doesn’t work, please fix it!” 47 | 48 | > **Preferred:** “This feature doesn’t work as expected when I [do XYZ], do you have any suggestions as to how I can fix it? Thank you so much!” 49 | 50 | When closing a pull request as a community extension maintainer, please keep in mind the following examples of helpful communication: 51 | 52 | > **Not ideal** “This is not following the current pull request conventions! I’m closing this issue.” 53 | 54 | > **Preferred:** “I am closing this PR because this extension can’t support [use case]. In its current form, it would be improved by/better contributed to [XYZ]. Thank you so much for your work on this!” 55 | 56 | ## Troubleshooting and community support 57 | 58 | If you’re encountering a problem with an extension or the Community Hub, remember that the community is here to help! Please feel free to start a post on the [Camunda community forums](https://forum.camunda.io), or the Camunda Community Hub [GitHub Discussions](https://github.com/camunda-community-hub/community/discussions). 59 | 60 | If you have a question related to getting started contributing to the Camunda open source ecosystem, or need to reach out to the Camunda team, you can start a topic in our [Discussions](https://github.com/camunda-community-hub/community/discussions), tag the [Camunda DevRel team](https://github.com/orgs/camunda-community-hub/teams/devrel) in an Issue or PR, or reach out via email: community@camunda.com. 61 | 62 | We highly encourage you to post on the Camunda community forums about your extension, its wider impact for the open source community, and what made you decide to build a community extension. 63 | 64 | * [Camunda forum](https://forum.camunda.io/) 65 | * [BPMN.io forum](https://forum.bpmn.io/) 66 | 67 | ### Meet the Camunda Developer Relations team 68 | 69 | The [Camunda Developer Relations team](https://github.com/Camunda-Community-Hub/devrel-team) exists to serve the Camunda developer community, from internal employees to open source contributors, Enterprise customers, and the broader tech community. It is our goal to provide opportunities for developers to be more successful by making them aware of our solutions, enabling them to be successful through great experiences, and fostering a culture of collaboration. 70 | 71 | ## Inspiration 72 | 73 | This documentation was inspired by the following resources: 74 | 75 | * [Kubernetes Contributors](https://www.kubernetes.dev/) 76 | * [Quarkiverse](https://quarkus.io/blog/quarkiverse/) 77 | * [KNIME](https://docs.knime.com) 78 | * [CiviCRM](https://docs.civicrm.org/) 79 | * [OpenSauced](https://github.com/open-sauced/open-sauced) 80 | -------------------------------------------------------------------------------- /assets/.gitkeep: -------------------------------------------------------------------------------- 1 | This is the assets folder for the Camunda Community Hub 2 | -------------------------------------------------------------------------------- /assets/release-new-version (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/camunda-community-hub/community/e1efbee729ab68bbfd7323199ae9713ea1cfcb33/assets/release-new-version (1).png -------------------------------------------------------------------------------- /docs/CODEOWNERS: -------------------------------------------------------------------------------- 1 | # These owners will be the default owners for everything in the repo. 2 | * @xomiamoore 3 | -------------------------------------------------------------------------------- /docs/CODE_OF_CONDUCT.MD: -------------------------------------------------------------------------------- 1 | # Code of Conduct 2 | 3 | ### View the [Camunda Code of Conduct](https://camunda.com/events/code-conduct/) and find ways to report violations. 4 | -------------------------------------------------------------------------------- /docs/LICENSE: -------------------------------------------------------------------------------- 1 | Apache License 2 | Version 2.0, January 2004 3 | http://www.apache.org/licenses/ 4 | 5 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 6 | 7 | 1. Definitions. 8 | 9 | "License" shall mean the terms and conditions for use, reproduction, 10 | and distribution as defined by Sections 1 through 9 of this document. 11 | 12 | "Licensor" shall mean the copyright owner or entity authorized by 13 | the copyright owner that is granting the License. 14 | 15 | "Legal Entity" shall mean the union of the acting entity and all 16 | other entities that control, are controlled by, or are under common 17 | control with that entity. For the purposes of this definition, 18 | "control" means (i) the power, direct or indirect, to cause the 19 | direction or management of such entity, whether by contract or 20 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 21 | outstanding shares, or (iii) beneficial ownership of such entity. 22 | 23 | "You" (or "Your") shall mean an individual or Legal Entity 24 | exercising permissions granted by this License. 25 | 26 | "Source" form shall mean the preferred form for making modifications, 27 | including but not limited to software source code, documentation 28 | source, and configuration files. 29 | 30 | "Object" form shall mean any form resulting from mechanical 31 | transformation or translation of a Source form, including but 32 | not limited to compiled object code, generated documentation, 33 | and conversions to other media types. 34 | 35 | "Work" shall mean the work of authorship, whether in Source or 36 | Object form, made available under the License, as indicated by a 37 | copyright notice that is included in or attached to the work 38 | (an example is provided in the Appendix below). 39 | 40 | "Derivative Works" shall mean any work, whether in Source or Object 41 | form, that is based on (or derived from) the Work and for which the 42 | editorial revisions, annotations, elaborations, or other modifications 43 | represent, as a whole, an original work of authorship. For the purposes 44 | of this License, Derivative Works shall not include works that remain 45 | separable from, or merely link (or bind by name) to the interfaces of, 46 | the Work and Derivative Works thereof. 47 | 48 | "Contribution" shall mean any work of authorship, including 49 | the original version of the Work and any modifications or additions 50 | to that Work or Derivative Works thereof, that is intentionally 51 | submitted to Licensor for inclusion in the Work by the copyright owner 52 | or by an individual or Legal Entity authorized to submit on behalf of 53 | the copyright owner. For the purposes of this definition, "submitted" 54 | means any form of electronic, verbal, or written communication sent 55 | to the Licensor or its representatives, including but not limited to 56 | communication on electronic mailing lists, source code control systems, 57 | and issue tracking systems that are managed by, or on behalf of, the 58 | Licensor for the purpose of discussing and improving the Work, but 59 | excluding communication that is conspicuously marked or otherwise 60 | designated in writing by the copyright owner as "Not a Contribution." 61 | 62 | "Contributor" shall mean Licensor and any individual or Legal Entity 63 | on behalf of whom a Contribution has been received by Licensor and 64 | subsequently incorporated within the Work. 65 | 66 | 2. Grant of Copyright License. Subject to the terms and conditions of 67 | this License, each Contributor hereby grants to You a perpetual, 68 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 69 | copyright license to reproduce, prepare Derivative Works of, 70 | publicly display, publicly perform, sublicense, and distribute the 71 | Work and such Derivative Works in Source or Object form. 72 | 73 | 3. Grant of Patent License. Subject to the terms and conditions of 74 | this License, each Contributor hereby grants to You a perpetual, 75 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 76 | (except as stated in this section) patent license to make, have made, 77 | use, offer to sell, sell, import, and otherwise transfer the Work, 78 | where such license applies only to those patent claims licensable 79 | by such Contributor that are necessarily infringed by their 80 | Contribution(s) alone or by combination of their Contribution(s) 81 | with the Work to which such Contribution(s) was submitted. If You 82 | institute patent litigation against any entity (including a 83 | cross-claim or counterclaim in a lawsuit) alleging that the Work 84 | or a Contribution incorporated within the Work constitutes direct 85 | or contributory patent infringement, then any patent licenses 86 | granted to You under this License for that Work shall terminate 87 | as of the date such litigation is filed. 88 | 89 | 4. Redistribution. You may reproduce and distribute copies of the 90 | Work or Derivative Works thereof in any medium, with or without 91 | modifications, and in Source or Object form, provided that You 92 | meet the following conditions: 93 | 94 | (a) You must give any other recipients of the Work or 95 | Derivative Works a copy of this License; and 96 | 97 | (b) You must cause any modified files to carry prominent notices 98 | stating that You changed the files; and 99 | 100 | (c) You must retain, in the Source form of any Derivative Works 101 | that You distribute, all copyright, patent, trademark, and 102 | attribution notices from the Source form of the Work, 103 | excluding those notices that do not pertain to any part of 104 | the Derivative Works; and 105 | 106 | (d) If the Work includes a "NOTICE" text file as part of its 107 | distribution, then any Derivative Works that You distribute must 108 | include a readable copy of the attribution notices contained 109 | within such NOTICE file, excluding those notices that do not 110 | pertain to any part of the Derivative Works, in at least one 111 | of the following places: within a NOTICE text file distributed 112 | as part of the Derivative Works; within the Source form or 113 | documentation, if provided along with the Derivative Works; or, 114 | within a display generated by the Derivative Works, if and 115 | wherever such third-party notices normally appear. The contents 116 | of the NOTICE file are for informational purposes only and 117 | do not modify the License. You may add Your own attribution 118 | notices within Derivative Works that You distribute, alongside 119 | or as an addendum to the NOTICE text from the Work, provided 120 | that such additional attribution notices cannot be construed 121 | as modifying the License. 122 | 123 | You may add Your own copyright statement to Your modifications and 124 | may provide additional or different license terms and conditions 125 | for use, reproduction, or distribution of Your modifications, or 126 | for any such Derivative Works as a whole, provided Your use, 127 | reproduction, and distribution of the Work otherwise complies with 128 | the conditions stated in this License. 129 | 130 | 5. Submission of Contributions. Unless You explicitly state otherwise, 131 | any Contribution intentionally submitted for inclusion in the Work 132 | by You to the Licensor shall be under the terms and conditions of 133 | this License, without any additional terms or conditions. 134 | Notwithstanding the above, nothing herein shall supersede or modify 135 | the terms of any separate license agreement you may have executed 136 | with Licensor regarding such Contributions. 137 | 138 | 6. Trademarks. This License does not grant permission to use the trade 139 | names, trademarks, service marks, or product names of the Licensor, 140 | except as required for reasonable and customary use in describing the 141 | origin of the Work and reproducing the content of the NOTICE file. 142 | 143 | 7. Disclaimer of Warranty. Unless required by applicable law or 144 | agreed to in writing, Licensor provides the Work (and each 145 | Contributor provides its Contributions) on an "AS IS" BASIS, 146 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 147 | implied, including, without limitation, any warranties or conditions 148 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 149 | PARTICULAR PURPOSE. You are solely responsible for determining the 150 | appropriateness of using or redistributing the Work and assume any 151 | risks associated with Your exercise of permissions under this License. 152 | 153 | 8. Limitation of Liability. In no event and under no legal theory, 154 | whether in tort (including negligence), contract, or otherwise, 155 | unless required by applicable law (such as deliberate and grossly 156 | negligent acts) or agreed to in writing, shall any Contributor be 157 | liable to You for damages, including any direct, indirect, special, 158 | incidental, or consequential damages of any character arising as a 159 | result of this License or out of the use or inability to use the 160 | Work (including but not limited to damages for loss of goodwill, 161 | work stoppage, computer failure or malfunction, or any and all 162 | other commercial damages or losses), even if such Contributor 163 | has been advised of the possibility of such damages. 164 | 165 | 9. Accepting Warranty or Additional Liability. While redistributing 166 | the Work or Derivative Works thereof, You may choose to offer, 167 | and charge a fee for, acceptance of support, warranty, indemnity, 168 | or other liability obligations and/or rights consistent with this 169 | License. However, in accepting such obligations, You may act only 170 | on Your own behalf and on Your sole responsibility, not on behalf 171 | of any other Contributor, and only if You agree to indemnify, 172 | defend, and hold each Contributor harmless for any liability 173 | incurred by, or claims asserted against, such Contributor by reason 174 | of your accepting any such warranty or additional liability. 175 | 176 | END OF TERMS AND CONDITIONS 177 | 178 | APPENDIX: How to apply the Apache License to your work. 179 | 180 | To apply the Apache License to your work, attach the following 181 | boilerplate notice, with the fields enclosed by brackets "[]" 182 | replaced with your own identifying information. (Don't include 183 | the brackets!) The text should be enclosed in the appropriate 184 | comment syntax for the file format. We also recommend that a 185 | file or class name and description of purpose be included on the 186 | same "printed page" as the copyright notice for easier 187 | identification within third-party archives. 188 | 189 | Copyright [yyyy] [name of copyright owner] 190 | 191 | Licensed under the Apache License, Version 2.0 (the "License"); 192 | you may not use this file except in compliance with the License. 193 | You may obtain a copy of the License at 194 | 195 | http://www.apache.org/licenses/LICENSE-2.0 196 | 197 | Unless required by applicable law or agreed to in writing, software 198 | distributed under the License is distributed on an "AS IS" BASIS, 199 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 200 | See the License for the specific language governing permissions and 201 | limitations under the License. 202 | -------------------------------------------------------------------------------- /docs/SECURITY.md: -------------------------------------------------------------------------------- 1 | # Security and Dependency Management Policy 2 | - [Security Tools in Place](#security-tools-in-place) 3 | - [When should I report a vulnerability?](#when-should-i-report-a-vulnerability) 4 | - [When should I **not** report a vulnerability?](#when-should-i-not-report-a-vulnerability) 5 | - [Public disclosure timelines](#public-disclosure-timelines) 6 | - [Publishing information on a vulnerability](#publishing-information-on-a-vulnerability) 7 | - [Handling possible vulnerabilities](#handling-possible-vulnerabilities) 8 | - [Dependency management policy](#dependency-management-policy) 9 | - [Dependency issues](#dependency-issues) 10 | - [Who handles dependency management if a maintainer is away, or a project is unmaintained?](#who-handles-dependency-management-if-a-maintainer-is-away-or-a-project-is-unmaintained) 11 | - [Types of dependencies](#types-of-dependencies) 12 | - [Why dependency classifications matter](#why-dependency-classifications-matter) 13 | - [How to update open source dependencies](#how-to-update-open-source-dependencies) 14 | - [Potential consequences of using outdated dependencies](#potential-consequences-of-using-outdated-dependencies) 15 | - [Dependabot](#dependabot) 16 | - [Inspiration](#inspiration) 17 | 18 | This document provides help and advice to projects in the Camunda Community Hub regarding security issues and how to handle reporting of security vulnerabilities. 19 | As projects in the Camunda Community Hub are community maintained, **security prevention is the responsibility of a project’s maintainer.** 20 | 21 | In the Camunda Community Hub, we take security seriously. As open source practitioners, it is our aim to empower those in this space to develop extensions with security best practices in mind. 22 | 23 | We aim to enable our community to work together to provide assistance to all of those involved in the community hub on the ongoing topic of 24 | DevSecOps, security, and dependency management. We encourage the community as a whole to work with maintainers, and to open issues that 25 | address any security vulnerabilities in a repository according to the guidelines listed in this documentation. 26 | 27 | ## Security Tools in Place 28 | 29 | * [Dependabot](https://dependabot.com/) - Enabled at the Organization level 30 | * [Renovate](https://github.com/renovatebot/renovate) - Opt in 31 | * The [Community Action Maven Release](https://github.com/camunda-community-hub/community-action-maven-release#security-scanning) allows 32 | maintainers to opt-in to Aqua Security’s Trivy container security scanning tool, 33 | and uploads the results of HIGH and CRITICAL vulnerabilities to the GitHub Security tab. 34 | 35 | 36 | ## When should I report a vulnerability? 37 | 38 | * You think you have discovered a security vulnerability in a Camunda Community Hub extension 39 | * You aren’t sure of, or if, a vulnerability impacts a Camunda Community Hub extension you are using 40 | * You think you’ve discovered a security vulnerability in another project that a Camunda Community Hub extension is dependent on 41 | * For projects that have their own vulnerability processes and disclosure policies, please report your vulnerability there, following that project’s 42 | stated guidelines 43 | 44 | ## When should I **not** report a vulnerability? 45 | 46 | * You need help fine-tuning an extension in the Camunda Community Hub for adherence to security best practices 47 | * You have a question about the security of an extension in the Camunda Community Hub 48 | * Your question or issue isn’t related to the security of an extension in the Camunda Community Hub 49 | 50 | ## Public disclosure timelines 51 | 52 | * Public disclosure dates will be discussed between the vulnerability reporter and the impacted project’s Maintainer. 53 | * When a fix is available, we will then disclose the bug to the public. 54 | * If a vulnerability is not fully understood or a fix is not yet implemented, a disclosure date may be modified or pushed back to allow for further research, 55 | * coordination, or additional time to fix the issue. The estimated time frame for disclosure ranges from immediate (in the case of vulnerabilities which are already known to the public) to a few weeks. 56 | 57 | ## Publishing information on a vulnerability 58 | 59 | Projects with known, published security vulnerabilities should provide information about those vulnerabilities on their repository’s GitHub Security 60 | page if they have the permissions to do so. If you do not have the permissions level needed, and would like to publish a security advisory, 61 | please open an issue in your repository, apply the waiting-for-camunda issue label and tag @celanthe. As an alternative, 62 | maintainers can opt to provide a clear link in their README or on the project’s website to their security information, current vulnerabilities, 63 | and their security, testing, and/or dependency management policies for their extension. 64 | 65 | When reporting a vulnerability or issue, please keep security best practices in mind, and try to eliminate publicly posting information 66 | that may result in the potential for an increased attack surface (e.g. by entering details in a public bug tracker, public-facing issue, or pull request). 67 | 68 | ## Handling possible vulnerabilities 69 | 70 | Project maintainers in the Camunda Community Hub are responsible for ensuring that their extensions are secure and free from vulnerabilities 71 | to the best of their ability. For all potential vulnerabilities related to Apache-specific distributions, dependencies, tools, or services, 72 | please follow the Apache Software Foundation (ASF) [guidelines and procedures for reporting a vulnerability directly to the ASF](https://apache.org/security/#vulnerability-handling). 73 | 74 | * If your potential vulnerability does not impact a tool handled by the Apache Security foundation or that falls under its umbrella, 75 | you may report it privately in a secure channel to the project’s maintainer, and email community@camunda.com 76 | * The impacted project’s maintainer will work with you as the reporter of the vulnerability to investigate it 77 | * The project’s maintainer and the issue reporter will work together to resolve the vulnerability 78 | * The project maintainer and the issue reporter will work together to write documentation and a report on the vulnerability and its fix. This report and documentation should contain enough information that users will be able to assess the potential risks associated with the vulnerability for their own system/extension. This documentation does not include how to reproduce the vulnerability. 79 | * The team agrees on an acceptable release timeline for the vulnerability to be resolved, or raises concerns on issues that may impact a proposed timeline before one is agreed upon 80 | * The project maintainer publishes a new release of the extension with the dependencies/tools impacted by the vulnerability and delivers a fix 81 | * The Camunda team publishes the new release if the extension is using the GitHub Actions Maven Release CI/CD workflow 82 | * The maintainer announces the vulnerability publicly on the GitHub security page, and details how to apply the fix 83 | * This is the first point that any information about a vulnerability should be made public 84 | 85 | 86 | ## Dependency management policy 87 | 88 | 89 | Dependencies are the files, libraries, packages, and/or plugins integrated into a project to complete a set of tasks. 90 | 91 | These dependencies are the responsibility of project maintainers to manage and keep up to date. 92 | Projects that have vulnerable dependencies that are not resolved within 30 days may be removed from the Camunda Community Hub. 93 | 94 | ## Dependency issues 95 | 96 | Applications can encounter dependency issues for a number of reasons: 97 | 98 | * Usage of outdated third-party libraries 99 | * Poorly implemented code 100 | * Using third-party databases 101 | * Using external, web-based services for a particular feature or functionality 102 | * Implementation of untested libraries for metrics collection 103 | 104 | External dependencies are often utilized in the open source community, and can lead to security issues. 105 | These can be the addition of malicious code, hidden cryptocurrency miners, performance issues, and more. 106 | In order to avoid these issues, extension dependencies need to be actively managed, maintained, and kept up-to-date. By keeping dependencies in the 107 | Camunda Community Hub up-to-date, we ensure that community extensions avoid security implications or issues that may arise from using outdated libraries, code, 108 | or services. 109 | 110 | ### Who handles dependency management if a maintainer is away, or a project is unmaintained? 111 | 112 | Ideally, it is the responsibility of the community to help manage dependency management. If a project has multiple collaborators and the code owner 113 | will be unavailable for an extended period of time, outside collaborators should make an effort to update the project’s dependencies when needed. 114 | 115 | When needed, the Camunda DevRel team may update an unmaintained project’s dependencies if it is deemed necessary. 116 | 117 | ### Types of dependencies 118 | 119 | * Direct dependencies - Libraries or plugins that directly integrate with an application. 120 | * Development dependencies - These are included in a project’s package.json and are executed by files in the development phase. 121 | These can be used by remote hosts such as linters and presets. 122 | * Transitive dependencies - A library called by a direct dependency. 123 | Conflicts and issues can arise when a direct dependency doesn’t support updated versions of its transitive dependencies. 124 | We recommend avoiding the use of implicit transitive dependencies, and suggest explicitly maintaining any transitive dependencies in use by 125 | your project’s direct dependencies. 126 | * Runtime dependencies - These include frontend dependencies which run in the user’s browser, and backend dependencies which run in the backend for 127 | http communications with a server or database. 128 | 129 | ### Why dependency classifications matter 130 | 131 | Dependencies can be classified as mandatory, discrete, or external. 132 | 133 | * Mandatory dependencies are those that your project needs to function. Without this particular dependency, your application will not work as expected. 134 | * Discrete dependencies are defined sequences between activities. This is a certain order of activities that happen based on the structure of a particular project and its codebase. 135 | * External dependencies do not involve a project’s team. Internal dependencies, on the other hand, impact maintainers and any outside collaborators on a project. 136 | 137 | 138 | ### How to update open source dependencies 139 | 140 | * Assign yourself as a reviewer of the pull request in question, if there is no CODEOWNERS file present to automatically assign reviewers. 141 | * Review the changes in the pull request to better understand how the changes will impact the extension if applied 142 | * Determine where this dependency is used in the code to ascertain its impact on the extension 143 | * Conduct a regression test to ensure that the proposed changes do not break functionality of the existing application, plugin, or extension 144 | * Merge automated dependency updates individually, rather than in bulk. By merging changes individually, if there is a problem, you can quickly determine the upgrade that caused the issue. 145 | 146 | ### Potential consequences of using outdated dependencies 147 | 148 | Maintainers may delay updating dependencies out of fear that they will break their extension’s functionality, which may result in downtime for customers and end users. Using outdated or improperly configured dependencies exposes you to a variety of security risks such as: 149 | 150 | * Security vulnerabilities 151 | * Reduced extension, plugin, or application performance 152 | * Conflicts in coupled processes 153 | * Increased technical debt 154 | * Increased project maintenance 155 | * Greater exposed attack surfaces 156 | 157 | Open source tools such as Maven also pull in their own external third-party dependencies. 158 | While it can be challenging to update these dependencies, it is not impossible. 159 | 160 | * Ensure that your extensions comply with the license listed by the open source libraries integrated in your application. 161 | * Make use of open source tools such as Snyk, Trivy, JFrog X-Ray, and more to help ensure your Maven dependencies are up-to-date. 162 | * Perform regression tests 163 | * Make regression tests and dependency management a part of your CI/CD workflow 164 | * Using Dependabot and Renovate for dependency management 165 | 166 | ### Dependabot 167 | 168 | Repositories in the Camunda Community Hub have the automated dependency tool Dependabot installed at the Organizational level. 169 | 170 | Dependabot is integrated with GitHub, and powers GitHub’s automated security update feature introduced in 2019. Repository Administrators can interact with Dependabot directly from the GitHub UI. To enable dependabot security updates, go to your repository’s **Settings** page, click the **Security & Analysi**s tab, and then click **Enable** next to `Dependabot security updates`. 171 | 172 | Administrators have the following permissions when accessing security features in GitHub repositories within the Camunda Community Hub: 173 | 174 | * Receive dependabot alerts for vulnerable dependencies 175 | * Dismiss alerts from dependabot 176 | * Designate additional teams/people to receive dependabot alerts 177 | * Create security advisories 178 | * Manage access to advanced security features on GitHub 179 | * Enable dependency graphs for private repositories 180 | 181 | Administrators and Maintainers have the following permissions when accessing security features in GitHub repositories within the Camunda Community Hub: 182 | 183 | * View dependency reviews 184 | * View code scanning alerts on open pull requests 185 | * List, dismiss, or delete code scanning alerts 186 | * View secret scan alerts in a repository* 187 | ** Repository writers and maintainers can only see alert information for their own commits. 188 | * Resolve, revoke, or re-open secret scan alerts 189 | * Repository writers and maintainers can only see alert information for their own commits. 190 | 191 | 192 | Maintainers are also able to request that renovate be added to their repository for dependency management. 193 | At this time, we strongly recommend maintainers evaluate using renovate for dependency management in their repositories. 194 | Renovate offers maintainers fine-grained control and configuration when deciding when to auto-merge pull requests for dependencies. 195 | These are based on rules that a maintainer sets in their repository’s renovate configuration file. 196 | 197 | Renovate works with JavaScript, NPM, Yarn, Go, Bazel, Docker, Nugget, PHP, Python, and Ruby. 198 | 199 | Ultimately, we leave this decision of which dependency management tool to use in the hands of extension maintainers and their communities. 200 | We look forward to steering the conversation surrounding these tools, and continuing to improve dependency management and the experience of developers in the Camunda Community Hub moving forward. 201 | 202 | ## Inspiration 203 | 204 | This documentation was inspired by the [Apache Security Team](https://apache.org/security), [Crowdbotics](https://blog.crowdbotics.com/how-to-ensure-that-your-dependencies-are-up-to-date/), 205 | [The Diana Initiative Slack community](https://join.slack.com/t/dianainitiative/shared_invite/zt-t4m9w3zp-3bUr~WDv~GIRJkT8W0lXLg), and the [Kubernetes Security and Disclosure information](https://kubernetes.io/docs/reference/issues-security/security/#report-a-vulnerability). 206 | 207 | -------------------------------------------------------------------------------- /extension-lifecycle.md: -------------------------------------------------------------------------------- 1 | # The extension lifecycle & badges 2 | Camunda community extensions adhere to a project lifecycle that aims to balance the needs of the broader community with that of the Camunda ecosystem as a whole. This section will also detail the process for reporting abandoned/unmaintained extensions. 3 | 4 | Community extensions will have the following badges applied to them in addition to the `Community Extension` label/badge, designating where they are in terms of current usability, project stability, and overall lifecycle status. 5 | 6 | ## Required Badges 7 | *This badge is required for all extensions in the Community Hub.* 8 | ### Community Extension an orange badge that reads 'Community Extension: An open source community maintained project 9 | 10 | * Designates that an extension is maintained by the open source community 11 | * To add this badge to your repository, add the following code at the top of your extension's README file ```[![](https://img.shields.io/badge/Community%20Extension-An%20open%20source%20community%20maintained%20project-FF4700)](https://github.com/camunda-community-hub/community)``` 12 | 13 | ### Compatiblilty 14 | 15 | *One of these compatability badges is required for all repos in the Community Hub.* 16 | 17 | 18 | 19 | * Indicates compatibility with Camunda 8 20 | * To add this badge to your repo, add the following code in your extension's README file ```![Compatible with: Camunda 8](https://img.shields.io/badge/Compatible%20with-Camunda%208-0072Ce)``` 21 | 22 | 23 | 24 | * Indicates compatibility with Camunda 7 25 | * To add this badge to your repo, add the following code in your extension's README file ```![Compatible with: Camunda 7](https://img.shields.io/badge/Compatible%20with-Camunda%207-26d07c)``` 26 | 27 | 28 | ## Lifecycle Badges 29 | *One of these lifecycle badges is required for all repos in the Community Hub.* 30 | 31 | ### Proof-of-Concept Violet purple Shields.io badge that reads Lifecycle: Proof of Concept 32 | * `Proof-of-Concept`/experimental extensions are just that, ideas that community members would like to explore further. They offer little support, nor do they promise any stability. 33 | * To add this badge to your repository, add the following code at the top of your extension's README file: ```![](https://img.shields.io/badge/Lifecycle-Proof%20of%20Concept-blueviolet)](https://github.com/Camunda-Community-Hub/community/blob/main/extension-lifecycle.md#proof-of-concept-)``` 34 | 35 | ### Incubating Blue Shields.io badge that reads Lifecycle: Incubating 36 | * Extensions with the `Incubating` label provide some degree of stability which is defined and adhered to by the project’s maintainer, community support, and are actively maintained and updated. Documentation gaps, roadblocks, bugs, and other issues are to be expected. 37 | * To add this badge to your repository, add the following code at the top of your extension's README file: ```![](https://img.shields.io/badge/Lifecycle-Incubating-blue)](https://github.com/Camunda-Community-Hub/community/blob/main/extension-lifecycle.md#incubating-)``` 38 | 39 | ### Stable Green Shields.io badge that reads Lifecycle: Stable 40 | * An extension with the `Stable` label has an active, thriving community surrounding it. It releases updates on a regular basis, has active maintainers and community participants, and may be actively used at an organizational level. 41 | * See [Maintainer Expectations](https://github.com/camunda-community-hub/community/blob/da53e7a16d4048b8f5910a573d16a355ab488a8b/maintainer-reviewer-expectations.md#L47) for more information on what it means to be a Stable extension. 42 | * To add this badge to your repository, add the following code at the top of your extension's README file: ```![](https://img.shields.io/badge/Lifecycle-Stable-brightgreen)](https://github.com/Camunda-Community-Hub/community/blob/main/extension-lifecycle.md#stable-)``` 43 | 44 | ### Deprecated Yellow Shields.io badge that reads Lifecycle: Deprecated 45 | * An extension with the `Deprecated` label is no longer being maintained. It may have been deprecated due to an official feature or other solution. Be sure to review the README and see if there is an alternative presented. 46 | * While it may work on your machine just fine today, there is no guarantee that it will work in the future. **Use these extensions at your own risk.** 47 | 48 | * To add this badge to your repository, add the following code at the top of your extension's README file: ```![](https://img.shields.io/badge/Lifecycle-Deprecated-yellowgreen)](https://github.com/Camunda-Community-Hub/community/blob/main/extension-lifecycle.md#deprecated-)``` 49 | 50 | ### Unmaintained Light gray Shields.io badge that reads Lifecycle: Unmaintained 51 | * Extensions are considered unmaintained when the project’s owner is no longer updating the extension, or has not responded to open issues or pull requests within 30 days, or has notified a Camunda team member that they are no longer actively maintaining the extension. 52 | * To add this badge to your repository, add the following code at the top of your extension's README file: ```![](https://img.shields.io/badge/Lifecycle-Unmaintained-lightgrey)](https://github.com/Camunda-Community-Hub/community/blob/main/extension-lifecycle.md#Unmaintained-)``` 53 | 54 | ### Needs Maintainer Hot pink Shields.io badge that reads Lifecycle: Needs Maintainer 55 | 56 | If you are a maintainer that is no longer able to maintain your extension, or you would like an additional maintainer, you can add the `Needs Maintainer` badge to your extension's README file to help notify others that the extension is in need of a maintainer. 57 | * To add this badge to your repository, add the following code at the top of your extension's README file: ```![](https://img.shields.io/badge/Maintainer%20Wanted-This%20extension%20is%20in%20search%20of%20a%20Maintainer-ff69b4)``` 58 | 59 | 60 | > To report an extension as unmaintained, please [open a new issue using the Report Unmaintained Repo template](https://github.com/camunda-community-hub/community/issues/new/choose) template. 61 | > 62 | > 63 | > If you are interested in stepping up to maintain a previously unmaintained extension, please [open a new issue using the Extension Maintainer Proposal template](https://github.com/camunda-community-hub/community/issues/new/choose). 64 | 65 | 66 | ## Optional Badges 67 | 68 | ### Educational Tooling a purple badge that reads 'Educational Tooling - Project for getting started with Camunda for educators' 69 | 70 | * This badge designates that an extension is used for getting started with Camunda for educators and university programs 71 | * To add this badge to your repository, add the following code at the top of your extension's README file ```![](https://img.shields.io/badge/Educational%20Tooling-Project%20for%20getting%20started%20with%20Camunda%20for%20educators-%239F2B68)``` 72 | 73 | ### Tutorial Reference Project A blue badge that reads: 'Tutorial Reference Project - Tutorials for getting started with Camunda' 74 | 75 | * This badge designates that an extension is a tutorial or part of a video tutorial series used for getting started with Camunda 76 | * To add this badge to your repository, add the following code at the top of your extension's README file ```![](https://img.shields.io/badge/Tutorial%20Reference%20Project-Tutorials%20for%20getting%20started%20with%20Camunda-%2338A3E1)``` 77 | -------------------------------------------------------------------------------- /issue-triage.md: -------------------------------------------------------------------------------- 1 | # Issue triage and labelling 2 | 3 | Issue labels can be added directly to issues via GitHub. We also encourage community members to triage issues by adding or removing labels if they see an open pull request or issue without a label they feel it may need to improve its context, visibility, or move it forward in the issue triage process. 4 | 5 | The following labels apply to community extension pull requests and issues: 6 | 7 | ## Kind 8 | 9 | * Kind: Work-in-Progress 10 | * Kind: Bug 11 | * Kind: Needs Triage 12 | * Kind: Needs Review 13 | * Kind: Backlog 14 | * Kind: Enhancement 15 | * Kind: Dependency 16 | * Kind: Code of Conduct 17 | * Kind: Cleanup - Relating to code cleanup, resolving technical debt, or process cleanup 18 | * Kind: Documentation 19 | * Kind: Accessibility 20 | * Kind: Failing Test 21 | * Kind: Feature 22 | * Kind: Templates 23 | * Kind: Good first issue 24 | 25 | ## Area 26 | 27 | * Area: API 28 | * Area: Library 29 | * Area: Security 30 | 31 | ## Priority 32 | 33 | * Priority: Needs more evidence 34 | * Priority: Backlog 35 | * Priority: Active 36 | * Priority: Important 37 | * Priority: Critical/Urgent 38 | * Priority: Long-Term 39 | 40 | ## Triage 41 | * Triage: Needs Information 42 | * Triage: Not reproducible 43 | * Triage: Unresolved 44 | * Triage: Help wanted -------------------------------------------------------------------------------- /maintainers-reviewers/RELEASE.MD: -------------------------------------------------------------------------------- 1 | # How to build and release projects on the Camunda Community Hub 2 | 3 | ## Maven 4 | 5 | In order to build and release your Maven projects properly, you need to prepare: 6 | 7 | 1. **[Onboard](#onboarding-your-repository) your repository** (which makes sure you will have all necessary credentials available) 8 | 2. Use the **[release parent pom](https://github.com/camunda-community-hub/community-hub-release-parent) in your Maven project (which will take care of distribution management)** 9 | 3. Setup a GitHub workflow leveraging the [Community Hub Maven Release **GitHub Action**](https://github.com/camunda-community-hub/community-action-maven-release) (which will take care to do the proper releases) 10 | 11 | Then you can simply create GitHub releases, which will also trigger all necessary Maven magic to deploy to 12 | 13 | - [Camunda Artifactory](https://artifacts.camunda.com/) 14 | - [Maven Central](https://central.sonatype.com/publishing/deployments) 15 | 16 | > View an example repository demonstrating the setup of Maven Build Management and CI/CD [here.](https://github.com/camunda-community-hub/community-hub-extension-example) 17 | 18 | More information [below](#maven-1). 19 | 20 | 21 | ## Docker 22 | 23 | In order to build and release Docker images, you need to prepare: 24 | 25 | 1. **[Onboard](#onboarding-your-repository) your repository** (which makes sure you will have all necessary credentials available) 26 | 2. Use the **image name** `camundacommunityhub/*` 27 | 3. Setup a GitHub workflow to push your Docker images to Dockerhub. We recommend using the [official Docker login GitHub Action.](https://github.com/marketplace/actions/docker-login) 28 | 29 | More information [below](#docker-1). 30 | 31 | 32 | # Detailed instructions 33 | 34 | ## Onboarding your repository 35 | 36 | You need to register your repository by opening a pull request in the [Camunda Infrastructure](https://github.com/camunda-community-hub/infrastructure) repo and follow the instructions listed for [onboarding a new repository](https://github.com/camunda-community-hub/infrastructure#use-case-onboarding-a-new-community-hub-repository). 37 | 38 | 39 | ## Maven 40 | 41 | > View an example repository demonstrating the setup of Maven Build Management and CI/CD [here.](https://github.com/camunda-community-hub/community-hub-extension-example) 42 | 43 | ### Use the Camunda Community Hub groupId 44 | 45 | The Camunda Community Hub decided on a unified groupId. Use a Maven groupId based on: `org.camunda.community`, so for example: `org.camunda.community.awesomeextension` 46 | 47 | ### Add release parent to POM 48 | 49 | Any project needs to use the [community-hub-release-parent](https://github.com/camunda-community-hub/community-hub-release-parent) in their POM: 50 | 51 | ```xml 52 | 53 | org.camunda.community 54 | community-hub-release-parent 55 | 56 | 57 | 58 | ``` 59 | 60 | This parent POM contains all necessary settings for the GitHub Action to function properly. 61 | 62 | ### Add GitHub workflow 63 | 64 | Add a GitHub workflow (e.g. by adding a file `.github/workflows/deploy.yaml` to your) to your project [as described here.](https://github.com/camunda-community-hub/community-action-maven-release#add-github-workflow) 65 | 66 | ### Performing a release 67 | 68 | Create a new Release using https://github.com/camunda-community-hub/:repo/releases/new (replace `:repo` with name of repository). 69 | 70 | This will trigger the release flow, to build, sign, and publish the released version to Maven Central, and will push the generated tags once the process has completed. 71 | 72 | There are two options: 73 | 74 | 1. Use the **auto release property** in your GitHub workflow (**recommended**), so that all releases will be automatically be released to Maven Central: 75 | 76 | ```yaml 77 | # ...snip... 78 | 79 | - name: Deploy SNAPSHOT / Release 80 | uses: camunda-community-hub/community-action-maven-release@v2 81 | with: 82 | maven-auto-release-after-close: true 83 | # ... 84 | 85 | # ...snip... 86 | ``` 87 | 88 | 2. Open an issue to let [@camunda-community-hub/devrel](https://github.com/orgs/camunda-community-hub/teams/devrel) review and release your artifact. Therefore, open a new issue in your repository and include [@camunda-community-hub/devrel](https://github.com/orgs/camunda-community-hub/teams/devrel) in a comment with a waiting-for-camunda [issue label](https://github.com/camunda-community-hub/template-repo/labels) applied. 89 | 90 | After an artifact has been released, it can take up to an hour to be retrievable, and 2-3 hours for it to be reflected on the public page of the artifact. 91 | 92 | 93 | ## Docker 94 | 95 | [TBD] 96 | 97 | 98 | # FAQ 99 | 100 | ## Migration to Sonatype Central Portal — How To? 101 | 102 | ### What You Need to Know 103 | 104 | Sonatype is [retiring OSSRH](https://central.sonatype.org/news/20250326_ossrh_sunset/) in favor of their new [Central Portal](https://central.sonatype.org/faq/what-is-different-between-central-portal-and-legacy-ossrh/) for publishing artifacts. 105 | 106 | As part of this change, all Camunda namespaces (`io.camunda`, `io.zeebe`, and `org.camunda`) will be migrated to the new Central Portal. 107 | > **Note:** This migration is one-way, once a namespace is migrated, publishing via OSSRH will no longer be possible. 108 | 109 | ### What’s Changing for You 110 | 111 | To support this transition, we have added a new Maven profile in the parent POM used by community projects: 112 | 113 | - ✅ `central-sonatype-publish` (for Central Portal) 114 | - ⚠️ `oss-maven-central` (now deprecated) 115 | 116 | The composite GitHub Action `camunda-community-hub/community-action-maven-release@v2` handles failover per namespace, from OSSRH to the Central Portal. 117 | You do **not** need to track namespace-specific timelines yourself, as long as you are using the latest `@v2` version of the action. 118 | 119 | ### What You Need to Do 120 | 121 | To ensure a seamless migration for your Camunda community project, it’s recommended to take the following steps now, you don’t need to wait for the namespace migration to be completed: 122 | 123 | 1. **Update the parent POM** to get the new `central-sonatype-publish` profile available: 124 | - `org.camunda.community:community-hub-release-parent` → version `2.0.0` (or higher) 125 | 126 | 2. **Update the GitHub Action** to use `@v2`: 127 | - Use `camunda-community-hub/community-action-maven-release@v2` 128 | - if you prefer not to use the @v2 tag, make sure to regularly update to the latest v2 release. The automatic fallback from the deprecated `oss-maven-central` profile to the new `central-sonatype-publish` profile will be handled via v2 patch releases, aligned with the migration timeline of each namespace 129 | - Ensure the following changes are applied to its configuration: 130 | - ✅ **Use the new default central release profile** by removing any explicit `central-release-profile` value (default is now `central-sonatype-publish`) 131 | - as long as the `central-sonatype-publish` profile is used, a fallback from OSSRH to the Central Portal is handled by the action for a smooth transition 132 | - 🆕 Add new credentials for the Central Portal: 133 | ```yaml 134 | central-sonatype-usr: ${{ secrets.COMMUNITY_HUB_MAVEN_CENTRAL_CP_USR }} 135 | central-sonatype-psw: ${{ secrets.COMMUNITY_HUB_MAVEN_CENTRAL_CP_PSW }} 136 | ``` 137 | - 🧩 Keep the following **deprecated parameters** for now, at least until the concerned namespaces are migrated (they will be ignored afterwards and removed in `@v3`): 138 | ```yaml 139 | maven-usr: ${{ secrets.<...> }} 140 | maven-psw: ${{ secrets.<...> }} 141 | maven-url: (s01.)?oss.sonatype.org 142 | ``` 143 | 144 | > ✅ When the namespace migration occurs, no further changes will be needed. The `@v2` (and subsequent patch versions) of the action will use the appropriate profile and credentials. 145 | 146 | > 📌 For a concrete example of the required changes, see this sample [PR](https://github.com/camunda-community-hub/community-hub-extension-example/pull/30 147 | ) in the `camunda-community-hub/community-hub-extension-example` project. 148 | 149 | ### What About SNAPSHOT and Release Builds? 150 | 151 | Publishing both SNAPSHOT and release builds will continue to work as before—just now via the [Central Portal](https://central.sonatype.org/publish/publish-portal-guide). 152 | 153 | > [!IMPORTANT] 154 | > If you consume Maven SNAPSHOT artifacts, you **must update the repository URL** in your local setup: 155 | > [Guide for consuming SNAPSHOT releases](https://central.sonatype.org/publish/publish-portal-snapshots/#consuming-snapshot-releases-for-your-project) 156 | > New URL: `https://central.sonatype.com/repository/maven-snapshots/` 157 | 158 | ## What if my release fails while deploying integration tests? 159 | 160 | Integration tests should be versioned when preparing a release, but should never be deployed to Maven Central. If you have an integration-tests module in your project, add the following profile to your parent POM: 161 | 162 | ``` 163 | 164 | 165 | it 166 | 167 | 168 | performRelease 169 | !true 170 | 171 | 172 | 173 | integration-test 174 | 175 | 176 | 177 | ``` 178 | 179 | This will ensure that when the `mvn release:perform `is triggered (with the `-DperformRelease` flag set) the `integration-tests` module is skipped. 180 | 181 | 182 | ## What if my release says it's missing a key for GPG? 183 | 184 | Verify that you have adjusted your extension's release workflow GPG files to match the example shown in the [Community Action Maven Release](https://github.com/camunda-community-hub/community-action-maven-release/blob/22004c20cb61979859e889cf17081b3e886849b8/example-workflows/java11/deploy.yml#L25-L30) documentation. For more information on Java setup actions and what GPG does, review the [documentation on GitHub](https://github.com/actions/setup-java/blob/main/docs/advanced-usage.md#gpg). 185 | 186 | 187 | ## Integrating GitHub Actions with Zeebe on Camunda 8 188 | 189 | If you are interested in working with GitHub Actions using Zeebe on Camunda 8, visit our [Camunda 8 GitHub Action](https://github.com/camunda-community-hub/camunda-cloud-github-action) repository to get started. 190 | 191 | 192 | ## Troubleshooting 193 | 194 | 1. If you are facing any issues regarding your extension's release process, please [open an issue](https://github.com/camunda-community-hub/community-action-maven-release/issues) and assign it to [@camunda-community-hub/devrel](https://github.com/orgs/camunda-community-hub/teams/devrel) with applicable issue labels applied. 195 | 2. If you see an update or improvement that can be made to the release process in the Camunda Community Hub, we encourage you to submit an issue with your request, and thank you for your suggestion! 196 | 3. Please make use of the [Camunda Community Hub Pull Request Template](https://github.com/camunda-community-hub/community/issues/new?assignees=&labels=&template=camunda-community-hub-pull-request-template.md&title=Pull+Request) when opening a troubleshooting pull request and include as much information as possible in order to help reviewers better understand the issue you are facing. 197 | -------------------------------------------------------------------------------- /maintainers-reviewers/abandoned-extension-maintainer-guidelines.MD: -------------------------------------------------------------------------------- 1 | # Guidelines for becoming a maintainer of an abandoned community extension 2 | This documentation is intended for contributors who wish to apply to become a maintainer of an `Unmaintained` repository in the Camunda Community Hub, in addition to those repositories labelled as `Needs Maintainer`. 3 | 4 | 5 | - [Contact the original project maintainer](#contact-the-original-project-maintainer) 6 | - [Let the Camunda DevRel team know](#let-the-camunda-devrel-team-know) 7 | - [Fill out Abandoned Community Extension maintainer template](#fill-out-abandoned-community-extension-maintainer-template) 8 | - [Follow the maintainer expectations](#follow-the-maintainer-expectations) 9 | 10 | ***Note that all extension maintainers in the Camunda Community Hub are expected to follow our [maintainer expectations](/maintainers-reviewers/maintainer-reviewer-expectations.md).*** 11 | 12 | ### Contact the original project maintainer 13 | * Make an effort to contact the maintainer and ask them if they would be open to you taking over or adding to maintainership of the project. 14 | * In your request, please be sure to detail as much as possible your plans for maintaining the extension moving forward. 15 | 16 | ### Let the Camunda DevRel team know 17 | * If a maintainer confirms that they would like you to take over -- First of all, congratulations! Move on to the next step below. 18 | * If no response is received within 30 days, continue onward. 19 | 20 | ### Fill out Abandoned Community Extension maintainer template 21 | * Fill out the [Abandoned Community Extension maintainer Proposal](https://github.com/camunda-community-hub/community/issues/new?assignees=&labels=abandoned-extension-maintainer-proposal&template=abandoned-extension-maintainer-proposal.md&title=Abandoned+Extension+maintainer+Proposal) issue template. 22 | * * Link to a discussion or screenshot of a discussion that shows you have made a good faith effort to contact the extension’s original developer. 23 | * Communicate your plans for the extension in your proposal 24 | * If your plans are primarily code-based, please open a pull request with your proposed changes to the extension 25 | * What is your roadmap going to look like? 26 | * What features will you be prioritizing first? 27 | * Where would you like the extension to be in the future? 28 | * Tag the [Camunda DevRel Team](https://github.com/orgs/camunda-community-hub/teams/devrel) on the open issue containing your maintainer request so that they can assign you the correct repository permissions in the Camunda Community Hub GitHub Organization. 29 | 30 | ### Follow the maintainer expectations 31 | 32 | All extension maintainers in the Camunda Community Hub are expected to follow our [maintainer expectations](/maintainers-reviewers/maintainer-reviewer-expectations.md). 33 | -------------------------------------------------------------------------------- /maintainers-reviewers/creating-new-extensions.md: -------------------------------------------------------------------------------- 1 | # Creating a new Camunda community extension 2 | If you are interested in building a new Camunda Community Hub extension, follow these instructions: 3 | 4 | 1. Set and confirm your commit email address. For more information on how to set your email address in GitHub, read the [GitHub documentation](https://docs.github.com/en/github/setting-up-and-managing-your-github-user-account/setting-your-commit-email-address) which goes into much more detail on the subject. 5 | 2. Browse the Hub to see if there is an extension that already matches your idea. Alternatively, you can post your extension idea in the Community Hub's [Discussions](https://github.com/camunda-community-hub/community/discussions). 6 | 3. Sign the [CLA](https://cla-assistant.io/camunda-community-hub/community) and agree to abide by our [Code of Conduct](https://camunda.com/events/code-conduct/). 7 | 4. Create a new repository. Title the repository with the name of your proposed extension. 8 | 5. Open a New Community Extension proposal. 9 | * To open a new Community Extension Proposal in the Camunda Community Hub, you can do so by viewing the [issue tracker](https://github.com/Camunda-Community-Hub/community/issues/new/choose). Next, select `New Community Extension Proposal` from the available template options. After completing the template, open the issue and give it a meaningful title. 10 | 6. Evaluate your extension's lifecycle status. 11 | * Once your extension proposal issue has been opened, use your best judgement after reviewing our [community extension lifecycle documentation](/extension-lifecycle.md) to identify where in the development process your extension is currently and add it to your extension's README along with a community extension lifecycle label. 12 | 13 | *If your extension is new and/or untested, the label to apply to it should always be `proof-of-concept.`* 14 | 15 | ## Maintainer and reviewer expectations 16 | 17 | Review our [maintainer expectations](/maintainers-reviewers/maintainer-reviewer-expectations.md) and follow the checklist and guidelines for your repo. -------------------------------------------------------------------------------- /maintainers-reviewers/groupId.md: -------------------------------------------------------------------------------- 1 | # Relocation of the groupId 2 | 3 | The Camunda Community Hub decided for a unified groupId of `org.camunda.community`. Therefore, all contributors will require a bit of work to switch their repositories to the new groupId. 4 | 5 | ## Using the groupId for a new project 6 | 7 | If you develop a Java project, you can leverage the existing infrastructure for builds and releases to Maven Central. 8 | 9 | 1. Use a Maven groupId based on: `org.camunda.community` 10 | 2. Add release parent pom [as described here](https://github.com/camunda-community-hub/community-action-maven-release): 11 | 12 | ```xml 13 | 14 | org.camunda.community 15 | community-hub-release-parent 16 | 1.4.1 17 | 18 | ``` 19 | 20 | ## Performing a relocation for a future version 21 | 22 | Maven differentiates between two ways of how to approach this topic. Please look at the [official documentation](https://maven.apache.org/guides/mini/guide-relocation.html) for more information. 23 | The `Working on past versions` is not supported as the Camunda Nexus does not have an automatic nor manual sync to Maven Central. 24 | `Releasing the next version` on the other hand is something that can be utilized and will inform future users about the relocation. 25 | 26 | The following will describe a procedure of how one could tackle the relocation for future releases with the given tools (maven release action). 27 | In total, we'll do two releases with two different groupIds for the same version. If a person consumes the latest version of the old groupId, a warning will be issued that mentions the relocation to the new groupId. 28 | ``` 29 | [WARNING] While downloading org.camunda.infra.githubdemo:camunda-infra-githubdemo:2.0.0 30 | This artifact has been relocated to org.camunda.community.infra.githubdemo:camunda-infra-githubdemo:2.0.0. 31 | It was decided on a unified groupId 32 | ``` 33 | 34 | 1. Create a branch of the primary branch, e.g., called `relocation`. It will be used later to publish the relocation pom. 35 | 2. On the primary branch - Update your repository with the new groupId, e.g., in the `pom.xml` but also don't forget to move your src from `/foo/bar` to `/org/camunda/community/bar` 36 | 3. Create a new release based on the updated branch with the new groupId. As an example, we'll go with 2.0.0. 37 | 4. Switch back to the backup branch `relocation` and add the following to the `distributionManagement`. 38 | ``` 39 | 40 | org.camunda.community.bar 41 | Custom message that YOU can either omit or define for YOUR userbase. 42 | 43 | ``` 44 | 5. Rename your 2.0.0 tag to 2.0.0-new, e.g., by using the GitHub UI. `https://github.com/org/repo/releases/edit/2.0.0`. Editing the tag will create a new tag based on the latest primary branch commit but not cause an additional release. 45 | 6. Delete the old 2.0.0 tag as we have to reuse the tag to publish the old POM. Either use the GitHub UI or run `git push --delete origin 2.0.0` in your repo with the adjusted tag version. 46 | 7. Create a new release based on the backup branch `relocation` with the same version number 2.0.0. 47 | 48 | From then on, you can publish every new release under the new groupId. People using the old groupId will be informed about the change if they consume the old groupId. 49 | -------------------------------------------------------------------------------- /maintainers-reviewers/maintainer-best-practices.md: -------------------------------------------------------------------------------- 1 | # Best practices for maintainers 2 | Maintainers are often the first point of contact that new contributors have with an open source project, and significantly impact the way that the community is perceived. As such, community extension maintainers are a crucial part of the Camunda open source community, and in shaping the Camunda Community Hub. 3 | 4 | Having a clearly defined set of expectations that contributors can reference when interacting with your extension is the mark of an experienced maintainer. It lets people who might not be familiar with you, your circumstances, and your project know what to expect from you and when. 5 | 6 | Here are a few key questions to consider as a maintainer of a community extension: 7 | 8 | * How often you plan to review pull requests? 9 | * Do new PRs need tests before acceptance? 10 | * Are you utilizing Issue Templates? 11 | * Do you require issues be labelled in a certain way, or do you accept help from the community in regards to issue triage and management? 12 | * What contributions will you accept? If you don't want help with a certain piece of code, state this clearly. 13 | * How often you prefer people to follow up with you. For example, "You can expect a response from a maintainer on your open issue/PR within 7-10 days." 14 | * Your weekly time commitment on the project. For example, "I spend about 5-10 hours per week on this project, but I welcome new contributions, help with issue triage, and writing or updating of documentation any time!" 15 | 16 | Learning to say no, or even "Thanks for the pull request! We've added that to our backlog and will take a look at it in the next release cycle" is critical to the long term success of any community extension. 17 | 18 | For more information on being a great maintainer, [read this guide of best practices for maintainers](https://opensource.guide/best-practices/) from Open Source Guides. -------------------------------------------------------------------------------- /maintainers-reviewers/maintainer-reviewer-expectations.md: -------------------------------------------------------------------------------- 1 | # Maintainer and reviewer expectations 2 | 3 | - [What is a maintainer?](#what-is-a-maintainer) 4 | - [Becoming a maintainer](#becoming-a-maintainer) 5 | - [Maintainer expectations](#maintainer-expectations) 6 | - [Maintainer expectations checklist](#maintainer-expectations-checklist) 7 | - [Active maintainers](#active-maintainers) 8 | - [Maintainer inactivity and offboarding](#maintainer-inactivity-and-offboarding) 9 | - [Important links](#important-links) 10 | - [Extension lifecycle stages](#extension-lifecycle-stages) 11 | - [Proof-of-Concept](#proof-of-concept) 12 | - [Incubating](#incubating) 13 | - [Stable](#stable) 14 | - [Deprecated](#deprecated) 15 | - [Unmaintained](#unmaintained) 16 | - [What to include in your extension's README](#what-to-include-in-your-extensions-readme) 17 | - [Optional information to include in your README](#optional-information-to-include-in-your-readme) 18 | - [Reviewer expectations](#reviewer-expectations) 19 | - [Reviewer expectations checklist](#reviewer-expectations-checklist) 20 | 21 | ## What is a maintainer? 22 | In open source software, a maintainer is the project leader. They are the one setting the direction and processes for a project. 23 | 24 | Each Camunda community extension will have a maintainer listed whose responsibility it is to maintain the extension and drive its progression forward. Otherwise, it will be labeled as `Unmaintained`. 25 | 26 | However you maintain your extension, we at Camunda want to empower and enable our community hub extension maintainers to do what they do best, see projects through to completion. 27 | 28 | Whether it’s dusting off an abandoned extension, stepping up to help an overburdened maintainer of a busy project, or even creating and maintaining something new -- we're here to help you! 29 | 30 | ## Becoming a maintainer 31 | * [Creating a new extension]( 32 | maintainers-reviewers/creating-new-extensions.md) in the Community Hub 33 | * [Transferring an existing extension](maintainers-reviewers/transferring-extensions.md) to the Community Hub 34 | * If you are interested in stepping up to maintain a previously unmaintained extension, please [open a new issue using the Extension Maintainer Proposal template](https://github.com/camunda-community-hub/community/issues/new/choose). 35 | * [Maintainer best practices](maintainers-reviewers/maintainer-best-practices.md) 36 | 37 | ## Maintainer expectations 38 | 39 | ### Maintainer expectations checklist 40 | All maintainers must: 41 | - [ ] Follow [Code of Conduct](/docs/CODE_OF_CONDUCT.MD) and the [Camunda Community Values](https://camunda.com/developers/community-values/) 42 | - [ ] Determine [extension lifecycle stage](#extension-lifecycle-stages) 43 | - [ ] Review pull requests regularly according to lifecycle stage 44 | - [ ] Ensure README contains the correct badges and information as detailed in [this section](#what-to-include-in-your-extensions-readme) 45 | 46 | 47 | ### Active maintainers 48 | 49 | In the Camunda Community Hub, we define an active maintainer as someone who: 50 | - [ ] Responds to issues and pull requests in their project(s) within 30 days 51 | - [ ] Follow additional requirements based on their extension's [lifecycle stage, as outlined below](#extension-lifecycle-stages) 52 | 53 | Active maintainers are invited to join our private community Slack for centralized communication. If you have not received an invite, please reach out to ` @camunda-community-hub/devrel` in [an issue](https://github.com/camunda-community-hub/community/issues/new/choose). 54 | 55 | ## Maintainer inactivity and offboarding 56 | 57 | Open source maintainers are often working on their projects in their spare time, and we understand that life happens and you might not always be able to be involved at the same level. 58 | 59 | If the workload is becoming too much, consider bringing on a co-maintainer. 60 | 61 | If your extension is currently labeled as `Stable` and you can't keep up with it, consider moving to another lifecycle label to keep expectations around updates and responses clear. 62 | 63 | If you know you will not have bandwidth to maintain your project, either temporarily or long-term, please reach out to a Camunda team member (`@camunda-community-hub/devrel`) with[ an issue](https://github.com/camunda-community-hub/community/issues/new/choose). If you have an expected time that you can return, let us know, otherwise we will list the extension as [`unmaintained/needs maintainer`](#unmaintained). 64 | 65 | If a maintainer becomes inactive without contact, the Camunda team will reach out to check in. If there is 30 days of continued inactivity after this outreach, the Camunda team may take steps to revive the extension, including changing the lifecycle label, adding another maintainer, or removing the extension from the Camunda Community Hub. 66 | 67 | ## Important links 68 | * [RELEASE.md](maintainers-reviewers/RELEASE.MD) - how to release your extension via Maven or Docker 69 | 70 | --- 71 | ## Extension lifecycle stages 72 | 73 | Each part of the extension lifecycle has different requirements for reviewing and responding to isseus and pull requests. 74 | 75 | ### Proof-of-Concept 76 | * `Proof-of-Concept` extensions are just that, ideas that community members would like to explore further. 77 | * They offer little support, nor do they promise any stability. 78 | * This label is most often applied to extensions that are used to validate a Proof-of-Concept for working with Camunda 7 or Camunda 8, or for those interested in finding collaborators on a particular project that has the potential to grow into a `Stable` extension. 79 | 80 | ### Incubating 81 | * Extensions with the `Incubating` label provide some degree of stability which is defined and adhered to by the project’s maintainer, community support, and are actively maintained and updated. 82 | * Documentation gaps, roadblocks, bugs, and other issues are to be expected. 83 | * There is currently no set time limit for an extension to move out of incubation status. 84 | 85 | ### Stable 86 | If an extension maintainer wishes for an extension to be listed as a `Stable` community extension, they must agree to the following standards for pull request review and issue triage: 87 | * An extension with the `Stable` label has an active, thriving community surrounding it. It releases updates on a regular basis, has active maintainers and community participants, and may be actively used at an organizational level. 88 | * A Stable extension has at least one active maintainer. 89 | * Stable extensions must be kept current and maintained between [Camunda main releases.](https://camunda.com/release-policy/) 90 | * Maintainers of a stable Camunda community extension are expected to review open pull requests and issues in their extension's repository **within 30 days.** 91 | * Maintainers of stable extensions are actively in contact with the Camunda team, or may have one or more Camunda team members actively contributing to the extension. 92 | * Stable extension maintainers and reviewers are expected to adhere to [our expectations](https://github.com/camunda-community-hub/community#maintainer-expectations) surrounding PR reviews and communication. 93 | * Stable Community Extensions have agreed to follow the Camunda Community Extension [issue triage and pull request review process](https://github.com/camunda-community-hub/community/blob/main/issue-triage.md). 94 | * Your extension must contain and abide by the [Camunda Community Hub Code of Conduct](/docs/CODE_OF_CONDUCT.MD). 95 | * Your extension must have a [contributor guide](https://github.com/camunda-community-hub/community/blob/main/CONTRIBUTING.MD). 96 | * Having a stable community extension means that much of the heavy lifting of building/maintenance surrounding releases is done for you with the ability to implement GitHub actions to automatically publish your extension to [Maven Central](/maintainers-reviewers/RELEASE.MD) if applicable to your extension. Initially, by utilizing the above GitHub Workflow, maintainers of Java-based extensions can implement to automate the publishing of new artifacts to Maven Central. 97 | 98 | ### Deprecated 99 | * An extension with the `Deprecated` label is no longer being maintained. It may have been deprecated due to an official feature or other solution. Be sure to review the README and see if there is an alternative presented. 100 | 101 | ### Unmaintained 102 | * Extensions are considered `Unmaintained` when the project’s owner is no longer updating the extension, has not responded to open issues or pull requests within 30 days, and/or has notified a Camunda team member that they are no longer actively maintaining the extension. 103 | 104 | If you no longer wish to maintain your extension, please apply the `Maintainer Needed` badge and `Unmaintained` labels to your extension’s repository, issues, and open PRs. 105 | 106 | > To report an extension as unmaintained, please [open a new issue using the Report Unmaintained Repo template](https://github.com/camunda-community-hub/community/issues/new/choose) template. 107 | > 108 | > 109 | > If you are interested in stepping up to maintain a previously unmaintained extension, please [open a new issue using the Extension Maintainer Proposal template](https://github.com/camunda-community-hub/community/issues/new/choose). 110 | 111 | 112 | --- 113 | 114 | ## What to include in your extension's README 115 | 116 | - [ ] **Lifecycle labels**: Please review the [Camunda Community Hub extension lifecycle](https://github.com/Camunda-Community-Hub/community/blob/main/extension-lifecycle.md) and add a badge to your extension's README that indicates which area of the lifecycle it falls under. 117 | - [ ] Implement the **[Camunda community extension badge](https://img.shields.io/badge/Community%20Extension-An%20open%20source%20community%20maintained%20project-FF4700)**. 118 | - [ ] Include a **[compataibility badge](https://github.com/Camunda-Community-Hub/community/blob/main/extension-lifecycle.md)** to clarify which Camunda product(s) your extension is compatible with. 119 | - [ ] A name that clearly identifies your project. 120 | - [ ] **Installation**: If your project has certain dependencies that need to be installed, it is best practice to detail these in your README file. 121 | - [ ] **Using your extension**: Give examples of how one might use your extension. Example use cases are helpful, even if they are smaller in scope. For larger project implementation examples, provide links to these rather than having them in your README file. 122 | - [ ] **Troubleshooting**: Clearly state the maintainer(s) of your extension and how users can contact them with questions, or if they run into a problem. 123 | - [ ] **Contributing**: If your extension is open to outside contributions from the community, here’s where you should state that, and what your requirements are for accepting/merging a pull request. 124 | - [ ] Document any commands needed to run CI/CD tests, and be sure to include instructions for running tests. 125 | - [ ] **Licensing information**: Please list the open source licenses your project is under here, for example, Apache 2.0. 126 | 127 | ### Optional information to include in your README 128 | 129 | - [ ] **[Additional badges](https://github.com/Camunda-Community-Hub/community/blob/main/extension-lifecycle.md)**: These give community members a visual representation of your extension’s build status, lifecycle, release version, and other useful metadata. 130 | - [ ] Follow our established [Style Guide](https://camunda.com/brand/writing-style-guide/) when writing documentation. 131 | - [ ] **Visuals**: If your project relies on screenshots, please ensure that you also add alt text to screenshots to ensure accessibility for those using screen readers or that have visual disabilities. 132 | - [ ] Keep best practices in mind when using screenshots. Remember to obscure any API keys, secrets, or identifiers that could be exploited maliciously. 133 | - [ ] **Contributors, maintainers, and other acknowledgements:** If you would like to include this section, it is a nice way to show appreciation for the individuals who contributed to your project. 134 | - [ ] **Roadmap**: GitHub [project boards](https://docs.github.com/en/github/managing-your-work-on-github/about-project-boards) are a great way to showcase your roadmap for your extension. If you have one set up, it’s a good idea to link to it in your README. 135 | - [ ] Make the steps to get started with your extension clear to understand for those that may not have a similar background to yourself. 136 | --- 137 | ## Reviewer expectations 138 | ### Reviewer expectations checklist 139 | - [ ] Follow [Code of Conduct](/docs/CODE_OF_CONDUCT.MD) 140 | - [ ] Review PRs assigned in a timely manner 141 | 142 | Reviewers can be anyone who is interested in contributing to an extension. They are primarily responsible for reviewing open pull requests (PRs) in a project, are expected to leave helpful feedback where necessary, assign issue triage labels, ask clarifying questions, and to understand the inner workings of the extension whose pull requests they are reviewing. They are encouraged to review any open PRs on a regular basis, which is often determined by the extension's maintainer. 143 | 144 | Reviewers can also review open pull requests at any time that works for them outside of any set official issue triage time set by the extension's maintainer. If a maintainer wishes for an extension to be labeled as a stable community extension, they must agree to the following standards for pull request review and issue triage: 145 | 146 | * Reviewers contributing to a `stable` Camunda community extension are expected to review open pull requests assigned to them in a timely manner 147 | * If a reviewer fails to respond, a PR may be reassigned to another reviewer after three attempts to contact the reviewer. 148 | * If you are a Camunda community extension reviewer, and you are going to be away for an extended period, or no longer have time to dedicate to issue review, please notify the project maintainer, and remove yourself from any existing documentation that lists you as an active reviewer. 149 | * Reviewers and maintainers are expected to adhere to our guidelines surrounding [issue triage and labelling](https://github.com/Camunda-Community-Hub/community/blob/main/issue-triage.md) for stable community extensions. 150 | 151 | -------------------------------------------------------------------------------- /maintainers-reviewers/transferring-extensions.md: -------------------------------------------------------------------------------- 1 | # Transferring existing Camunda community extensions 2 | 3 | ## Why migrate to the hub? 4 | 5 | The Camunda Community Hub aims to make the process of contributing to, maintaining, and using Camunda Community Extensions more efficient. This reduces a number of issues regarding the continued maintenance and infrastructure related to community extensions, creating a better experience for users as well as maintainers. Here are some advantages to your extension being listed under the Camunda Community Hub: 6 | 7 | * Automated publishing of your Camunda extension's Maven releases to Maven Central, with more automation on the way for different programming languages 8 | * Automated releases 9 | * Automated issue and pull request labelling 10 | * Improved issue triage process 11 | * Improved visibility as to where an extension is in its lifecycle 12 | * Consistent formatting of new issues and releases with new templates and tooling 13 | * Visibility of your project for new contributors interested in getting involved with open source software 14 | 15 | The Camunda Community Hub aims to help extension maintainers coordinate, cross-test, and ensure that extensions hosted under the Hub can be used without causing conflict with other applications. 16 | 17 | 18 | ## Maintainer and reviewer expectations 19 | 20 | Please review our [maintainers guide](/maintainers-reviewers/maintainers-start-here.md) and [maintainer expectations](/docs/maintainer-reviewer-expectations.md) before initiating the process of transferring your repo. 21 | 22 | ## Transferring your repo 23 | 24 | In order to work within the Camunda Community Hub, Maintainers are asked to transfer their repository into the Camunda Community Hub rather than fork it into the Hub. 25 | 26 | ### Transferring a repository from your personal GitHub account or company's organization 27 | 28 | Open an issue in your repository titled "Transfer (your repository) into the Camunda Community Hub" and assign it to `@camunda-community-hub/DevRel`, or tag the [Camunda DevRel team](https://github.com/orgs/camunda-community-hub/teams/devrel) in a comment on the issue itself if you are unable to assign the issue to them. 29 | 30 | A DevRel team member will identify themselves as the person to transfer the repository to. [Follow these instructions for transferring the repository to them](https://docs.github.com/en/repositories/creating-and-managing-repositories/transferring-a-repository#transferring-a-repository-owned-by-your-personal-account), then they will transfer it to the Community Hub and give you Admin access. 31 | 32 | Once the repository has transferred, you can proceed to [the maintainer expectations page](/maintainers-reviewers/maintainer-reviewer-expectations.md) and follow the instructions there for what your README should contain. 33 | 34 | 35 | ## Maven and Docker setup 36 | When onboarding, you will be asked if you would like to use our infrastructure for Maven and Docker. If so, [follow the onboarding instructions here. ](/maintainers-reviewers/RELEASE.MD) 37 | 38 | ## Personal information 39 | When you migrate your extension into the Camunda Community Hub, we will receive your contact information and may occasionally reach out to you with questions, information, etc. 40 | 41 | You *will not* be added to any marketing lists, but you may be contacted by us or Camunda Community Hub open source contributors. -------------------------------------------------------------------------------- /pull-request-process.md: -------------------------------------------------------------------------------- 1 | # The pull request process 2 | Pull requests (commonly referred to as PRs) are the backbone of any open source project. This section will introduce you to the best practices for opening a pull request to a Camunda Community Hub extension, and aims to serve as a point of reference for not only new contributors, but those who may contribute to open source software less frequently. 3 | 4 | This guide is intended for those who already have a pull request to submit to a Camunda Community Hub extension. If you are interested in submitting a pull request that is related to the commercial offerings of Camunda Platform 7 and Camunda Platform 8, please visit [How to Contribute](https://camunda.com/developers/how-to-contribute/). 5 | 6 | ## Creating a pull request 7 | 8 | 1. Follow the directions included in the [pull request template](https://github.com/Camunda-Community-Hub/community/issues/new/choose). This will help the community members and/or extension maintainers who respond to your pull request. 9 | 2. If a pull request is a typo/grammatical error fix, please make sure that you review the entire document for potential errors. Don’t open separate PRs for small fixes included in the same document. 10 | 3. Reference any open issues that your PR can solve, or issues that it is related to. 11 | 4. Avoid making large changes in a single commit. Instead, break your request into smaller pieces. This will ensure that reviewers are able to review your PR in a timely manner. 12 | 5. Use comments where needed to add additional context 13 | 6. Don’t `/assign` an excessive amount of reviewers. If a reviewer is not automatically assigned via the Camunda Community Probot, assign the pull request to the most relevant project maintainer. 14 | 7. If your PR is considered a Work-in-Progress, adding that prefix `[WIP`] in your PR title will prevent the PR from being merged until the WIP or `/hold` command is lifted. 15 | * This can also be achieved by setting your PR as a [`Draft Pull Request`](https://github.blog/2019-02-14-introducing-draft-pull-requests/) on GitHub 16 | * Learn more about these slash commands in the [Camunda Community Hub Probot documentation](https://github.com/camunda-community-hub/camunda-community-hub-probot). 17 | 8. If your PR has not been reviewed within 14 days, please don’t close your PR and re-open it. Please tag your reviewer by commenting with an `@` followed by their username (i.e. `@xomiamoore`), and alert a Camunda team member, who will help you triage the pull request if need be. 18 | 9. If you feel that your PR isn’t getting the attention it deserves, please post it in the relevant extension’s thread on the [Community Forums](https://forum.camunda.org/c/community-extensions/13) to find additional reviewers. 19 | 20 | ## Example PR description: 21 | 22 | ``` 23 | References Issues #021 #009 24 | 25 | Fix to [xyz feature] was added to resolve bug referenced in #021, #009. All builds now pass, and the extension is performing as expected. 26 | 27 | /lm needs-review, community-extension, bug-fix 28 | /assign @approver1 @approver2 @approver3 29 | ``` 30 | ### What’s included in the example issue description: 31 | 32 | * Reference to other issues or PRs (#021, #009) 33 | * Additional context around the changes that were made in the PR 34 | * The /lm command automatically assigns the 'needs review', 'community extension', and 'bug fix' labels to the issue 35 | * The /assign command assigns reviewers to a pull request. Maintainers or reviewers will /approve a PR after it has been approved and no changes are requested. 36 | * Work-In-Progress pull requests 37 | 38 | If you are working on a pull request with many moving parts, we strongly recommend that you break up your request into smaller PRs, rather than one large PR with many lines of code to review. This helps Community Extension Maintainers review and approve your pull requests quickly. 39 | 40 | If you add a `[WIP] `title to your pull request, or issue a `/hold `comment, the [Camunda GitHub Probot](https://github.com/camunda-community-hub/camunda-community-hub-probot) will add the `do-not-merge/work in progress` label to your issue, and the `do-not-merge/hold` labels, respectively. While either of these labels is active on your pull request, it will not be considered for merging by a maintainer or a reviewer. 41 | -------------------------------------------------------------------------------- /workflows/addtogithubprojects.yml: -------------------------------------------------------------------------------- 1 | - name: Add Good First Issues to GitHub project 2 | uses: actions/add-to-project@v0.4.0 3 | with: 4 | # URL of the project to add issues to 5 | project-url: https://github.com/orgs/camunda-community-hub/projects/3/views/1 6 | # A GitHub personal access token with write access to the project 7 | github-token: ${{ secrets.ADD_TO_PROJECT_PAT }} 8 | # A comma-separated list of labels to use as a filter for issue to be added 9 | labeled: good-first-issue 10 | # The behavior of the labels filter, AND to match all labels, OR to match any label, NOT to exclude any listed label (default is OR) 11 | label-operator: # optional 12 | --------------------------------------------------------------------------------