From 72acb12be4d51672219acfeb5c3cf78649db2ff7 Mon Sep 17 00:00:00 2001 From: aeworxet Date: Fri, 8 May 2026 08:41:33 +0300 Subject: [PATCH] docs(bounty): rename 'Bounty Program' to 'Microgrant Program' (#3538) Co-authored-by: aeworxet Co-authored-by: aeworxet --- .../workflows/slack/channels/channels.yaml | 6 +- .github/workflows/slack/terraform.tfstate | 8 +- design/Holopin-Badges/README.md | 2 +- .../BOUNTY_PROGRAM.md | 270 ----------------- .../identifying-good-first-issues.md | 2 +- docs/010-contribution-guidelines/index.md | 2 +- .../microgrant-program.md | 271 ++++++++++++++++++ .../PROJECT_FUNDING.md | 4 +- .../TSC_MEMBERSHIP.md | 2 +- .../initiative-inventory.md | 2 +- .../2026_Community_Goals.md | 6 +- 11 files changed, 288 insertions(+), 287 deletions(-) delete mode 100644 docs/010-contribution-guidelines/BOUNTY_PROGRAM.md create mode 100644 docs/010-contribution-guidelines/microgrant-program.md diff --git a/.github/workflows/slack/channels/channels.yaml b/.github/workflows/slack/channels/channels.yaml index 861911a197..67aceb386e 100644 --- a/.github/workflows/slack/channels/channels.yaml +++ b/.github/workflows/slack/channels/channels.yaml @@ -128,9 +128,9 @@ is_archived: false action_on_destroy: archive -- name: 17_bounty - topic: All about the AsyncAPI Bounty Program discussions. - purpose: This is the place where we discuss everything related to the Bounty Program. +- name: 17_microgrant + topic: All about the AsyncAPI Microgrant Program discussions. + purpose: This is the place where we discuss everything related to the Microgrant Program. is_private: false is_archived: false action_on_destroy: archive diff --git a/.github/workflows/slack/terraform.tfstate b/.github/workflows/slack/terraform.tfstate index 1034513753..7c3a73ddad 100644 --- a/.github/workflows/slack/terraform.tfstate +++ b/.github/workflows/slack/terraform.tfstate @@ -397,7 +397,7 @@ "private": "eyJzY2hlbWFfdmVyc2lvbiI6IjAifQ==" }, { - "index_key": "17_bounty", + "index_key": "17_microgrant", "schema_version": 0, "attributes": { "action_on_destroy": null, @@ -412,10 +412,10 @@ "is_org_shared": false, "is_private": false, "is_shared": false, - "name": "17_bounty", + "name": "17_microgrant", "permanent_members": null, - "purpose": "This is the place where we discuss everything related to the Bounty Program.", - "topic": "All about the AsyncAPI Bounty Program discussions." + "purpose": "This is the place where we discuss everything related to the Microgrant Program.", + "topic": "All about the AsyncAPI Microgrant Program discussions." }, "sensitive_attributes": [], "private": "eyJzY2hlbWFfdmVyc2lvbiI6IjAifQ==" diff --git a/design/Holopin-Badges/README.md b/design/Holopin-Badges/README.md index 72c722ef50..75aac977e3 100644 --- a/design/Holopin-Badges/README.md +++ b/design/Holopin-Badges/README.md @@ -65,7 +65,7 @@ These badges recognize members who actively participate in, support, and grow th Awarded to members who engage with the community by participating in issues, discussions, events, or any other form of interaction. - **Community Leader** : -Awarded to members who lead or coordinate major community initiatives like the Bounty Program, Ambassador Program, or Mentorship Program. +Awarded to members who lead or coordinate major community initiatives like the Microgrant Program, Ambassador Program, or Mentorship Program. - **Community Champion** : Awarded to members who consistently promote and support AsyncAPI through activities like volunteering at conferences or being long-term advocates. diff --git a/docs/010-contribution-guidelines/BOUNTY_PROGRAM.md b/docs/010-contribution-guidelines/BOUNTY_PROGRAM.md deleted file mode 100644 index 0e148d8740..0000000000 --- a/docs/010-contribution-guidelines/BOUNTY_PROGRAM.md +++ /dev/null @@ -1,270 +0,0 @@ ---- -title: AsyncAPI Bounty Program -weight: 160 ---- - -# AsyncAPI Bounty Program - - -## Preface - -The main motivation behind the AsyncAPI Bounty Program at its time was to create a sustainable model for [redistributing sponsor-contributed funds](https://github.com/orgs/asyncapi/discussions/541) directly to maintainers, ensuring they are financially rewarded for their work. The Program's approach helps provide at least a little compensation for the rendered selfless service and meaningful contributions. - - -## Overview - -The AsyncAPI Bounty Program is a specification of the software development process customized to meet the needs of the AsyncAPI Initiative. - -The AsyncAPI Bounty Program operates exclusively on donated funds, does not seek financial profit, uses publicly and freely available tools only, and has as its main purpose rewarding individual open source maintainers and contributors of **Middle** and **Senior** professional levels while creating an artificial set of time constraints to make the schedule for achieving assigned targets predictable. - -Anyone may implement this specification of the software development process with or without any modification in any way they find suitable. - - -## Budget - -Since 2026, the budget of the Bounty Program is twenty-one thousand four hundred US dollars and 00 cents (USD 21,400.00) per calendar year, detailed as follows: - -- One thousand six hundred US dollars and 00 cents (USD 1,600.00) per one calendar-month round (USD 19,200.00 per twelve calendar-month rounds). - - - The reward for completion of a Bounty Issue of Complexity Level `Medium` is two hundred US dollars and 00 cents (USD 200.00). - - - The reward for completion of a Bounty Issue of Complexity Level `Advanced` is four hundred US dollars and 00 cents (USD 400.00). - - The approximate maximum number of Bounty Issues per calendar-month round ranges from four to eight (from (4 * 400) to (8 * 200)). - -- Bounty Program Coordination: - - - One hundred fifty US dollars and 00 cents (USD 150.00) per one calendar-month round (USD 1,800.00 per twelve calendar-month rounds). - -- Open Collective's Fiscal Host, 'Open Source Collective,' commission for fund transfers: USD 400.00 for all payouts per twelve calendar-month rounds (approximate; the exact commission per transfer depends on the method chosen and the beneficiary's location and cannot be precisely calculated in advance). - - -## Prioritization Of Participants - -Bounty Program Participants are prioritized in the following order: - -1. AsyncAPI Maintainers (from the Bounty Issue's repository or from other AsyncAPI repositories who have a prior agreement with the Bounty Issue repository's Maintainers to work on the Bounty Issue), checked at [MAINTAINERS.yaml](../../MAINTAINERS.yaml) - -2. Regular contributors (GitHub users who have three or more Pull Requests merged throughout the AsyncAPI GitHub Organization, checked with https://github.com/search?q=org%3Aasyncapi+is%3Apr+is%3Amerged+author%3Agh_username). - -3. Other (if a GitHub user doesn't fall under the above categories, the AsyncAPI Maintainer can determine the criteria, i.e., regular volunteers, etc.) - -Assignment of the Bounty Issue on GitHub to users that fall under the first category can be performed immediately after the addition of the GitHub label `bounty` according to GitHub's timestamp. - -Assignment of the Bounty Issue on GitHub to users that fall under the second and third categories is performed not earlier than three calendar days after the addition of the GitHub label `bounty` according to GitHub's timestamp. - - -## Bounty Issues' Numbering - -To ensure ease of referencing, searching, and automation, a strictly defined format of Bounty Issues' numbering is used: - -1. In submissions of GitHub issues for the Bounty Program: `[repo]#[issue]` (`cli#38`) - -2. In invoices claiming reward: invoice's subject `Bounty [repo]#[issue]` (e.g., `Bounty cli#38`), tag `bounty` (two rewards can be joined into one sum, in this case a comma and a space must be used in the invoice's subject as a separator for Bounty Issues' numbers, e.g., `Bounty cli#38, cli#361`) - - -## Clarification Of Time Periods - -Due to the asynchronous nature of the AsyncAPI Initiative itself and thus its Bounty Program, UTC offset in Bounty Program Issues' starting and ending dates is used. Starting dates should be considered to have started at `00:00:00 UTC+12:00`, and ending dates should be considered to have ended at `23:59:59 UTC-12:00` (inclusive.) - - -## Bounty Issue's Submission - -GitHub issues for participation in the upcoming calendar-month round of the Bounty Program that are candidates to become Bounty Issues, and are agreed upon for participation in the Bounty Program by all active Maintainers of the given repository, are submitted during the second full (seven-day) calendar week of the month after the call for such submission, in the comments of the dedicated [AsyncAPI GitHub Organization's Discussion](https://github.com/orgs/asyncapi/discussions), by an AsyncAPI Maintainer who will be responsible for the resolution of the given Bounty Issue from the AsyncAPI's side, containing the following five fields: - -1. Number: `cli#361` - -2. Full GitHub link: https://github.com/asyncapi/cli/issues/361 - -3. Scope: `We need to extend the functionality of '--version' flag in AsyncAPI CLI to include info about versions of other AsyncAPI libraries used in the project` - -4. Complexity Level: `Medium` | `Advanced` - -5. Type: `Coding` | `DevOps` | `Docs` | `Design` - -Submitted GitHub issues undergo public pre-moderation by the AsyncAPI Community to ensure adherence to the values of the AsyncAPI Initiative. In case a GitHub issue does not pass pre-moderation, it is not accepted for participation in the upcoming calendar-month round of the Bounty Program. - -In case documentation must be provided together with the solution requested in the Bounty Issue, such requirement should be explicitly stated in the Scope. - -In case two Bounty Issues are inextricably linked and cannot be completed separately from each other, such connection must be explicitly stated in the Scope. - -In case the total reward for all submitted Bounty Issues exceeds the budget allocated for the upcoming calendar-month round of the Bounty Program, a full list of submitted Bounty Issues undergoes randomization using the randomization service provided by [random.org](https://random.org). Inextricably linked Bounty Issues, in this case, get joined into one generic issue (e.g., `cli#361-cli#38`) for the sake of randomization. After randomization, the resulting randomized list is crawled from the beginning until the total reward for the Bounty Issues reaches the amount of the budget allocated for the upcoming calendar-month round of the Bounty Program. - -In case the reward for the last Bounty Issue in the resulted randomized list generates an excess of the budget, this and all following issues until the end of the resulted randomized list are excluded from participation in the upcoming calendar-month round of the Bounty Program. Such Bounty Issues are allowed to be submitted during the submission of Bounty Issues for the next calendar-month round of the Bounty Program. - -All GitHub issues selected as Bounty Issues get labels on GitHub: - -- GitHub label `bounty` - -- text label indicating calendar-month round of the Bounty Program in which Bounty Issue participates (e.g., `bounty/2026-03`) - -- text labels `bounty/medium` | `bounty/advanced` according to the Complexity Level of the Bounty Issue - -- text labels `bounty/coding` | `bounty/devops` | `bounty/docs` | `bounty/design` according to the Type of the Bounty Issue - -GitHub issues selected as Bounty Issues can be viewed with GitHub's Project View tool at https://github.com/orgs/asyncapi/projects/36 -This project view is also visible to non-logged-in/non-GitHub users. - - -## Bounty Issue's Timeline - -The start date in the Bounty Program is counted from Monday of the next week when assignment of the Bounty Issue on GitHub happened. - -In case the Bounty Issue on GitHub was assigned during the third or fourth full (seven-day) calendar week of the month, the start date in the Bounty Program is counted from the first Monday of the new calendar-month round. - -For Bounty Issues of Complexity Level `Medium`: - -- Draft Pull Request, [linked to the Bounty Issue using a keyword](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) if applicable, must be submitted no later than Sunday of the second week from the start date and updated every week no later than Sunday, until submission of Final Pull Request and the start of its merging process - -- Final Pull Request must be submitted, and its merging process must start no later than Sunday of the fourth week from the start date, with the merging process' successful ending no later than Sunday of the sixth week from the start date - -For Bounty Issues of Complexity Level `Advanced`: - -- Draft Pull Request, [linked to the Bounty Issue using a keyword](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) if applicable, must be submitted no later than Sunday of the third week from the start date and updated every week no later than Sunday, until submission of Final Pull Request and the start of its merging process - -- Final Pull Request must be submitted, and its merging process must start no later than Sunday of the sixth week from the start date, with the merging process' successful ending no later than Sunday of the eighth week from the start date - -Updates to the Draft Pull Request are determined by: - -- activity in the `Commits` section of the Draft Pull Request - -- activity of the automated code analysis service that runs on every commit (`SonarCloud`) - -If no Pull Request is involved, updates on the Bounty Issue are determined by: - -- activity in the Bounty Issue's comments - -In case the Bounty Program Participant has not provided a weekly update to the Draft Pull Request and/or on the Bounty Issue (on Monday, the last activity of any of the abovementioned types was four or more calendar days before, e.g., on `2024-05-20`, the last activity of any type was on `2024-05-16` or earlier,) they are pinged as a reminder to do so. - -In case the Bounty Program Participant has not provided an update to the Draft Pull Request and/or on the Bounty Issue after two pings over two consecutive Mondays, on the third consecutive Monday it is assumed that the task cannot be completed within the rest of the time, and that the Bounty Program Participant has silently dropped the Bounty Issue. Suspension rules are applied to such Bounty Program Participants, and the End Of Life rules are applied to such Bounty Issues. - -In case the Bounty Program Participant has not provided the critical fixes required to make the Final Pull Request merging possible during the last week of the Timeline, they are pinged on Thursday, four days before the last day of the Timeline, to do so. - -In case the Bounty Program Participant has not provided critical fixes during the next four days, on Monday, after the last day of the Bounty Issues' Timeline, it is considered that the Bounty Program Participant did not complete the Bounty Issue within the assigned Timeline due to their own misperformance. Suspension rules are applied to such Bounty Program Participants and the End Of Life rules to such Bounty Issues. - - -### Bounty Issue's Timeline Example - -|Complexity Level|Assignment Date (by GitHub)|Start Date (by BP Rules)|End Date (by BP Rules)|Draft PR Submission|Final PR Merge Start|Final PR Merge End| -|----------------|---------------------------|------------------------|----------------------|-------------------|--------------------|------------------| -|Medium |2024-06-21 |2024-07-01 |**2024-08-11** |2024-07-14 |2024-07-28 |**2024-08-11** | -|Advanced |2024-06-25 |2024-07-01 |**2024-08-25** |2024-07-21 |2024-08-11 |**2024-08-25** | - - -## Extension Of Bounty Issue's Timeline - -In case a response critical for the technical resolution of the Bounty Issue is delayed in [GitHub](https://github.com) and/or [Slack](https://asyncapi.slack.com) for a period of three or more consecutive working days, all remaining target dates of the Bounty Issue's Timeline are shifted by one calendar week per each of the three consecutive working days the critically important response was delayed. 'Working days' are weekdays, from Monday through Friday, with any holidays regarded as standard weekdays. Friday and Monday are considered consecutive weekdays. - -In case of unpredicted [force majeure](https://iccwbo.org/wp-content/uploads/sites/3/2020/03/icc-forcemajeure-hardship-clauses-march2020.pdf) and/or circumstances that could not be foreseen and/or that are beyond the control of both the Bounty Program Participant and the AsyncAPI Maintainer, the Bounty Issue Timeline can be extended by a fixed or indefinite amount of time, with a fair explanation provided in the Bounty Issue's or Pull Request's comments. - -Communication on the necessity of the Bounty Issue Timeline extension should happen prior to any current milestone of the Bounty Issue's Timeline approaching, with a reflection of the start of such communication in the Bounty Issue's or Pull Request's comments, in case a communication platform other than GitHub is used. - - -## Bounty Issue's Reclassification - -Upon request of the AsyncAPI Maintainer, who is responsible for the resolution of the given Bounty Issue from the AsyncAPI's side in the Bounty Issue's comments in the process of resolution, the Complexity Level of the Bounty Issue can be reclassified in any direction (both lowered to `Medium` and heightened to `Advanced`), with corresponding changes to the Bounty Issue's Timeline in case of a need. - -Reclassified Bounty Issue gets one of the historical text labels `bounty/downgraded` or `bounty/upgraded` accordingly. - - -## Bounty Issue's Completion - -To avoid half-merges, unmet dependencies on the completion of other (inextricably linked) issues, waiting for merges of other separate PRs that provide critically important functionality for the given task, etc., and to avoid situations where AsyncAPI has already acquired an obligation to pay but factually the conditions of the Bounty Issue completion are not met yet, a system of double control with separation of concerns is exercised on the Bounty Issues: - -- After the Bounty Issue's closure on GitHub, the AsyncAPI Maintainer, who was responsible for the resolution of the given Bounty Issue from the AsyncAPI's side, confirms the Bounty Issue's technical resolution by posting a separate confirming comment in this Bounty Issue's comments (followed by another confirming comment from the AsyncAPI Maintainer of this specific repository, if these were two different persons.) - -- The Bounty Program Participant proceeds with the process of claiming the reward only after the second comment from the Bounty Program Coordinator, confirming the Bounty Issue completion and readiness to perform the payout. - - -## Bounty Issue's End Of Life - -GitHub issue participates in the Bounty Program and is considered a Bounty Issue starting from the second of addition of the GitHub label `bounty` according to GitHub's timestamp until the Bounty Issue's End Of Life, which starts after the last second of the last day of the calendar-month round of the Bounty Program it was introduced in, inclusive. - -In case a Bounty Issue gets an assignee before the End Of Life and continues to have an assignee after the End Of Life, it continues to be a Bounty Issue until completion. - -In case a Bounty Issue does not get an assignee before the End Of Life, after reaching End Of Life, it gets the historical text label `bounty/unpicked` and is considered the one that reached End Of Life. - -In case a Bounty Issue gets an assignee before the End Of Life and is dropped after the End Of Life, it gets the historical text label `bounty/dropped` and is considered the one that reached the End Of Life. - -In case a Bounty Issue gets an assignee before the End Of Life and does not get completed within the assigned Timeline after the End Of Life due to the Bounty Program Participant's misperformance, it gets the historical text label `bounty/misperformed` and is considered the one that reached End Of Life. - -In case a Bounty Issue gets an assignee before the End Of Life and, during its technical resolution, it becomes clear that this Bounty Issue cannot be completed due to unpredicted [force majeure](https://iccwbo.org/wp-content/uploads/sites/3/2020/03/icc-forcemajeure-hardship-clauses-march2020.pdf) and/or circumstances that could not be foreseen and/or that are beyond the control of both the Bounty Program Participant and the AsyncAPI Maintainer, it gets the historical text label `bounty/canceled` and is considered the one that reached End Of Life. - -Bounty Issue that reached End Of Life gets the historical text label `bounty/eol`, the reward for this Bounty Issue gets excluded from the budget allocated for the corresponding calendar-month round of the Bounty Program, and this Bounty Issue becomes a regular GitHub issue, which can be submitted again as a Bounty Issue Candidate. - -A dropped Bounty Issue cannot be assigned again to the same Bounty Program Participant who dropped it in the next calendar-month rounds of the Bounty Program. - - -## Additional Conditions - -The Bounty Program operates on a mutual-exclusion basis: during the time of participation of a GitHub issue in the Bounty Program, contributions (code, documentation, design, and other solutions) are accepted only from the assigned Bounty Program Participants. - -AsyncAPI Maintainers are allowed to work on Bounty Issues submitted by themselves. - -Bounty Program Participant is allowed to choose up to two Bounty Issues of any Complexity Level for simultaneous resolution. - -Two or more GitHub issues (each of which individually has a Complexity Level lower than `Medium` or those that are coupled tightly but not inextricably) can be aggregated to form one Bounty Issue with a Complexity Level `Medium`, which is then submitted for participation in the Bounty Program. Aggregated Bounty Issues have the prefix `[BOUNTY]`. - -The Bounty Program Participants that fall under the second and third categories should explain in meaningful words how they are going to approach the resolution process when expressing a desire to work on a Bounty Issue. - -All Bounty Program-related activities of the Bounty Program Participants that fall under the second and third categories (expression of a desire to work on a Bounty Issue, explanation of the presumed approach to the resolution of the Bounty Issue, etc.) are taken into consideration only if they occurred after the addition of the GitHub label `bounty` to the GitHub issue. - -GitHub label `bounty` has hex code `#0E8A16`. - - -## Claiming The Reward - -Claiming the reward for the completed Bounty Issue is done via the submission of an invoice at the dedicated [AsyncAPI Bounty Program page on Open Collective](https://opencollective.com/asyncapi/projects/asyncapi-bounty-program) (button '`ACTIONS`', dropdown option '`Submit expense`'). - -**Before the submission of the invoice, the Bounty Program Participant MUST ensure that the account they will use for the payout is VERIFIED by their financial institution, fully operational, and able to receive payments.** - -Requirements for the invoice: - -- Make sure that your `Full Name` on GitHub, as well as `Legal Name` and `Full name of the account holder` on the invoice, **are the same** and are YOUR REAL LEGAL NAME according to the passport/ID (on Open Collective, nicknames are allowed only in `Settings / Public profile / Display name`, and it is **this** name that will be displayed publicly throughout all https://opencollective.com if you have privacy concerns) - -- **Expense title**: '`Bounty [repo]#[issue]`' (e.g., '`Bounty cli#38`' or '`Bounty cli#38, cli#361`' in case of two rewards being joined into one sum) - -- **Tag**: '`bounty`' - -- **Set invoice details / Description**: mention the full URL of the GitHub issue which served as the Bounty Issue - -AsyncAPI does not perform financial transactions itself and relies on Open Collective's Fiscal Host 'Open Source Collective' to service payments and, thus, [comply with global sanctions](https://docs.oscollective.org/how-it-works/basics/expense-policies-and-limitations#permitted-countries-ofac-checks-and-payments-to-certain-countries). However, it has been empirically proven that even if the Bounty Program Participant is a citizen of a sanctioned jurisdiction, they can still receive the financial payment made to a payee in a non-sanctioned jurisdiction. Taking this into account, **potential Bounty Program Participants must [check themselves](https://wise.com/help/articles/2978049/which-countries-can-i-use-wise-in) to see whether they will be able to receive payment prior to starting participation in the Bounty Program**. AsyncAPI will not take any action if Open Source Collective refuses to relay the payment due to US or global sanctions imposed on a jurisdiction or an individual. - -Also, note that if a Bounty Program Participant submits invoice expenses for more than six hundred US dollars and 00 cents (USD 600.00) per calendar year to a Collective at Open Collective with a Fiscal Host in the US (AsyncAPI fits this description,) they will be asked to fill out an IRS tax information form, which will be either a `W-8BEN` or a `W-8BEN-E` depending on whether the Bounty Program Participant has the legal status of an individual or of a sole proprietor, **supplying a local Tax ID**, **regardless** of their US citizenship status. - -At the time of writing (2023-10-01), Open Collective supports `ACH`, `International SWIFT through Wise` (limitations of financial technology company 'Wise' are applied), and `PayPal` as automated payout methods. In rare cases (once per calendar year), Bounty Program Participant in personal communication with Open Collective can request them to perform a payout using a custom payment method to a non-sanctioned jurisdiction. - - -## Suspension - -Each new Bounty Program Participant starts participation in the Bounty Program with a quantity of Suspensions equal to zero. - -In case a Bounty Program Participant stops rendering services directed toward resolution of the (**one**) Bounty Issue without any communication on the subject ('silently drops') and/or fails to complete the (**one**) Bounty Issue within the assigned Timeline due to their own misperformance, for the **first time**, they receive a **First Suspension** and will be prohibited from participating in the Bounty Program **starting from the current moment and during two calendar months from the beginning of the next calendar month**. After this period, the First Suspension expires. - -In case a Bounty Program Participant stops rendering services directed toward resolution of the (**one**) Bounty Issue without any communication on the subject ('silently drops') and/or fails to complete the (**one**) Bounty Issue within the assigned Timeline due to their own misperformance, for the **second time** during six calendar months from the beginning of the next calendar month after the expiration of the First Suspension, they receive a **Second Suspension** and will be prohibited from participating in the Bounty Program **starting from the current moment and during eight calendar months from the beginning of the next calendar month**. After this period, the Second Suspension expires. - -In case a Bounty Program Participant stops rendering services directed toward resolution of **one of two** Bounty Issues, chosen for simultaneous resolution, without any communication on the subject ('silently drops') and/or fails to complete **one of two** Bounty Issues chosen for simultaneous resolution within the assigned Timeline due to their own misperformance, for the **first time**, they receive a **First Suspension** and will be prohibited from participating in the Bounty Program **during two calendar months from the beginning of the next calendar month**. After this period, the First Suspension expires. - -In case a Bounty Program Participant stops rendering services directed toward resolution of **one of two** Bounty Issues, chosen for simultaneous resolution, without any communication on the subject ('silently drops') and/or fails to complete **one of two** Bounty Issues chosen for simultaneous resolution within the assigned Timeline due to their own misperformance, for the **second time** during six calendar months from the beginning of the next calendar month after the expiration of the First Suspension, they receive a **Second Suspension** and will be prohibited from participating in the Bounty Program **during eight calendar months from the beginning of the next calendar month**. After this period, the Second Suspension expires. - -In case a Bounty Program Participant stops rendering services directed toward resolution of **two** Bounty Issues, **simultaneously** without any communication on the subject ('silently drops'), or fails to complete **two** Bounty Issues within the assigned Timeline due to their own misperformance **simultaneously**, or engages in any combination of the above actions, including scenarios such as misperforming one Bounty Issue and silently dropping another **simultaneously**, they receive a **Second Suspension** immediately and will be prohibited from participating in the Bounty Program **starting from the current moment and during eight calendar months from the beginning of the next calendar month**. After this period, the Second Suspension expires. - -The reward for the completed Bounty Issue (Bounty Issues) is not paid to the Bounty Program Participant who was assigned Suspension for this Bounty Issue (Bounty Issues) even in the case of its (their) voluntary completion. - -After the expiration of the Second Suspension or after six calendar months from the beginning of the next calendar month after the expiration of the First Suspension, if no Second Suspension was received during this time, their Suspension history is considered clean, and the quantity of Suspensions is reset to zero. - -A dedicated list is used for the purpose of tracking current Suspension history. - - -## Sources - -This document is the consolidated and formalized version of all information publicly available in free form at - -##### https://github.com/orgs/asyncapi/discussions/541#discussioncomment-5462792 -##### https://github.com/orgs/asyncapi/discussions/877#discussioncomment-6970799 -##### https://docs.opencollective.com/help/expenses-and-getting-paid/tax-information -##### https://asyncapi.slack.com/archives/C05UHTSEHE2/p1699433566459269 -##### https://github.com/asyncapi/community/pull/897#discussion_r1390778779 -##### https://github.com/asyncapi/community/issues/1072 -##### https://github.com/asyncapi/community/issues/2085#issuecomment-3407063246 -##### https://github.com/asyncapi/community/issues/2163 diff --git a/docs/010-contribution-guidelines/identifying-good-first-issues.md b/docs/010-contribution-guidelines/identifying-good-first-issues.md index 0ba9ca907b..c9cb0e43d6 100644 --- a/docs/010-contribution-guidelines/identifying-good-first-issues.md +++ b/docs/010-contribution-guidelines/identifying-good-first-issues.md @@ -54,7 +54,7 @@ When looking at issues, you might see different labels. Here's what they mean: | **bug** | Something isn't working correctly, so it's time to fix it!| | **area/javascript** | Issues specific to JavaScript projects. | | **area/typescript** | Issues specific to TypeScript projects. | -| **bounty** | AsyncAPI Bounty program-related issue. | +| **microgrant** | AsyncAPI Microgrant program-related issue. | | **gsoc** | Google Summer of Code-related ideas/issues. | | **Hacktoberfest** | Available for Hacktoberfest participants. | | **dependencies** | Pull requests that update dependencies. | diff --git a/docs/010-contribution-guidelines/index.md b/docs/010-contribution-guidelines/index.md index 1f331f9294..044dfd25d4 100644 --- a/docs/010-contribution-guidelines/index.md +++ b/docs/010-contribution-guidelines/index.md @@ -34,4 +34,4 @@ This section covers everything you need to know about contributing to AsyncAPI: - How to mentor other maintainers - Path to becoming a maintainer in existing projects -- Information about the AsyncAPI Bounty Program +- Information about the AsyncAPI Microgrant Program diff --git a/docs/010-contribution-guidelines/microgrant-program.md b/docs/010-contribution-guidelines/microgrant-program.md new file mode 100644 index 0000000000..73a531903f --- /dev/null +++ b/docs/010-contribution-guidelines/microgrant-program.md @@ -0,0 +1,271 @@ +--- +title: AsyncAPI Microgrant Program +weight: 160 +--- + +# AsyncAPI Microgrant Program + + +## Preface + +The main motivation behind the AsyncAPI Microgrant Program at its time was to create a sustainable model for [redistributing sponsor-contributed funds](https://github.com/orgs/asyncapi/discussions/541) directly to maintainers, ensuring they are financially rewarded for their work. The Program's approach helps provide at least a little compensation for the rendered selfless service and meaningful contributions. + + +## Overview + +The AsyncAPI Microgrant Program is a specification of the software development process customized to meet the needs of the AsyncAPI Initiative. + +The AsyncAPI Microgrant Program operates exclusively on donated funds, does not seek financial profit, uses publicly and freely available tools only, and has as its main purpose rewarding individual open source maintainers and contributors of **Middle** and **Senior** professional levels while creating an artificial set of time constraints to make the schedule for achieving assigned targets predictable. + +Anyone may implement this specification of the software development process with or without any modification in any way they find suitable. + + +## Budget + +Since 2026, the budget of the Microgrant Program is twenty-one thousand four hundred US dollars and 00 cents (USD 21,400.00) per calendar year, detailed as follows: + +- One thousand six hundred US dollars and 00 cents (USD 1,600.00) per one calendar-month round (USD 19,200.00 per twelve calendar-month rounds). + + - The reward for completion of a Microgrant Issue of Complexity Level `Medium` is two hundred US dollars and 00 cents (USD 200.00). + + - The reward for completion of a Microgrant Issue of Complexity Level `Advanced` is four hundred US dollars and 00 cents (USD 400.00). + + The approximate maximum number of Microgrant Issues per calendar-month round ranges from four to eight (from (4 * 400) to (8 * 200)). + +- Microgrant Program Coordination: + + - One hundred fifty US dollars and 00 cents (USD 150.00) per one calendar-month round (USD 1,800.00 per twelve calendar-month rounds). + +- Open Collective's Fiscal Host, 'Open Source Collective,' commission for fund transfers: USD 400.00 for all payouts per twelve calendar-month rounds (approximate; the exact commission per transfer depends on the method chosen and the beneficiary's location and cannot be precisely calculated in advance). + + +## Prioritization Of Participants + +Microgrant Program Participants are prioritized in the following order: + +1. AsyncAPI Maintainers (from the Microgrant Issue's repository or from other AsyncAPI repositories who have a prior agreement with the Microgrant Issue repository's Maintainers to work on the Microgrant Issue), checked at [MAINTAINERS.yaml](../../MAINTAINERS.yaml) + +2. Regular contributors (GitHub users who have three or more Pull Requests merged throughout the AsyncAPI GitHub Organization, checked with https://github.com/search?q=org%3Aasyncapi+is%3Apr+is%3Amerged+author%3Agh_username). + +3. Other (if a GitHub user doesn't fall under the above categories, the AsyncAPI Maintainer can determine the criteria, i.e., regular volunteers, etc.) + +Assignment of the Microgrant Issue on GitHub to users that fall under the first category can be performed immediately after the addition of the GitHub label `microgrant` according to GitHub's timestamp. + +Assignment of the Microgrant Issue on GitHub to users that fall under the second and third categories is performed not earlier than three calendar days after the addition of the GitHub label `microgrant` according to GitHub's timestamp. + + +## Microgrant Issues' Numbering + +To ensure ease of referencing, searching, and automation, a strictly defined format of Microgrant Issues' numbering is used: + +1. In submissions of GitHub issues for the Microgrant Program: `[repo]#[issue]` (`cli#38`) + +2. In invoices claiming reward: invoice's subject `Microgrant [repo]#[issue]` (e.g., `Microgrant cli#38`), tag `microgrant` (two rewards can be joined into one sum, in this case a comma and a space must be used in the invoice's subject as a separator for Microgrant Issues' numbers, e.g., `Microgrant cli#38, cli#361`) + + +## Clarification Of Time Periods + +Due to the asynchronous nature of the AsyncAPI Initiative itself and thus its Microgrant Program, UTC offset in Microgrant Program Issues' starting and ending dates is used. Starting dates should be considered to have started at `00:00:00 UTC+12:00`, and ending dates should be considered to have ended at `23:59:59 UTC-12:00` (inclusive.) + + +## Microgrant Issue's Submission + +GitHub issues for participation in the upcoming calendar-month round of the Microgrant Program that are candidates to become Microgrant Issues, and are agreed upon for participation in the Microgrant Program by all active Maintainers of the given repository, are submitted during the second full (seven-day) calendar week of the month after the call for such submission, in the comments of the dedicated [AsyncAPI GitHub Organization's Discussion](https://github.com/orgs/asyncapi/discussions), by an AsyncAPI Maintainer who will be responsible for the resolution of the given Microgrant Issue from the AsyncAPI's side, containing the following five fields: + +1. Number: `cli#361` + +2. Full GitHub link: https://github.com/asyncapi/cli/issues/361 + +3. Scope: `We need to extend the functionality of '--version' flag in AsyncAPI CLI to include info about versions of other AsyncAPI libraries used in the project` + +4. Complexity Level: `Medium` | `Advanced` + +5. Type: `Coding` | `DevOps` | `Docs` | `Design` + +Submitted GitHub issues undergo public pre-moderation by the AsyncAPI Community to ensure adherence to the values of the AsyncAPI Initiative. In case a GitHub issue does not pass pre-moderation, it is not accepted for participation in the upcoming calendar-month round of the Microgrant Program. + +In case documentation must be provided together with the solution requested in the Microgrant Issue, such requirement should be explicitly stated in the Scope. + +In case two Microgrant Issues are inextricably linked and cannot be completed separately from each other, such connection must be explicitly stated in the Scope. + +In case the total reward for all submitted Microgrant Issues exceeds the budget allocated for the upcoming calendar-month round of the Microgrant Program, a full list of submitted Microgrant Issues undergoes randomization using the randomization service provided by [random.org](https://random.org). Inextricably linked Microgrant Issues, in this case, get joined into one generic issue (e.g., `cli#361-cli#38`) for the sake of randomization. After randomization, the resulting randomized list is crawled from the beginning until the total reward for the Microgrant Issues reaches the amount of the budget allocated for the upcoming calendar-month round of the Microgrant Program. + +In case the reward for the last Microgrant Issue in the resulted randomized list generates an excess of the budget, this and all following issues until the end of the resulted randomized list are excluded from participation in the upcoming calendar-month round of the Microgrant Program. Such Microgrant Issues are allowed to be submitted during the submission of Microgrant Issues for the next calendar-month round of the Microgrant Program. + +All GitHub issues selected as Microgrant Issues get labels on GitHub: + +- GitHub label `microgrant` + +- text label indicating calendar-month round of the Microgrant Program in which Microgrant Issue participates (e.g., `microgrant/2026-06`) + +- text labels `microgrant/medium` | `microgrant/advanced` according to the Complexity Level of the Microgrant Issue + +- text labels `microgrant/coding` | `microgrant/devops` | `microgrant/docs` | `microgrant/design` according to the Type of the Microgrant Issue + +GitHub issues selected as Microgrant Issues can be viewed with GitHub's Project View tool at https://github.com/orgs/asyncapi/projects/36 +This project view is also visible to non-logged-in/non-GitHub users. + + +## Microgrant Issue's Timeline + +The start date in the Microgrant Program is counted from Monday of the next week when assignment of the Microgrant Issue on GitHub happened. + +In case the Microgrant Issue on GitHub was assigned during the third or fourth full (seven-day) calendar week of the month, the start date in the Microgrant Program is counted from the first Monday of the new calendar-month round. + +For Microgrant Issues of Complexity Level `Medium`: + +- Draft Pull Request, [linked to the Microgrant Issue using a keyword](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) if applicable, must be submitted no later than Sunday of the second week from the start date and updated every week no later than Sunday, until submission of Final Pull Request and the start of its merging process + +- Final Pull Request must be submitted, and its merging process must start no later than Sunday of the fourth week from the start date, with the merging process' successful ending no later than Sunday of the sixth week from the start date + +For Microgrant Issues of Complexity Level `Advanced`: + +- Draft Pull Request, [linked to the Microgrant Issue using a keyword](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) if applicable, must be submitted no later than Sunday of the third week from the start date and updated every week no later than Sunday, until submission of Final Pull Request and the start of its merging process + +- Final Pull Request must be submitted, and its merging process must start no later than Sunday of the sixth week from the start date, with the merging process' successful ending no later than Sunday of the eighth week from the start date + +Updates to the Draft Pull Request are determined by: + +- activity in the `Commits` section of the Draft Pull Request + +- activity of the automated code analysis service that runs on every commit (`SonarCloud`) + +If no Pull Request is involved, updates on the Microgrant Issue are determined by: + +- activity in the Microgrant Issue's comments + +In case the Microgrant Program Participant has not provided a weekly update to the Draft Pull Request and/or on the Microgrant Issue (on Monday, the last activity of any of the abovementioned types was four or more calendar days before, e.g., on `2024-05-20`, the last activity of any type was on `2024-05-16` or earlier,) they are pinged as a reminder to do so. + +In case the Microgrant Program Participant has not provided an update to the Draft Pull Request and/or on the Microgrant Issue after two pings over two consecutive Mondays, on the third consecutive Monday it is assumed that the task cannot be completed within the rest of the time, and that the Microgrant Program Participant has silently dropped the Microgrant Issue. Suspension rules are applied to such Microgrant Program Participants, and the End Of Life rules are applied to such Microgrant Issues. + +In case the Microgrant Program Participant has not provided the critical fixes required to make the Final Pull Request merging possible during the last week of the Timeline, they are pinged on Thursday, four days before the last day of the Timeline, to do so. + +In case the Microgrant Program Participant has not provided critical fixes during the next four days, on Monday, after the last day of the Microgrant Issues' Timeline, it is considered that the Microgrant Program Participant did not complete the Microgrant Issue within the assigned Timeline due to their own misperformance. Suspension rules are applied to such Microgrant Program Participants and the End Of Life rules to such Microgrant Issues. + + +### Microgrant Issue's Timeline Example + +|Complexity Level|Assignment Date (by GitHub)|Start Date (by BP Rules)|End Date (by BP Rules)|Draft PR Submission|Final PR Merge Start|Final PR Merge End| +|----------------|---------------------------|------------------------|----------------------|-------------------|--------------------|------------------| +|Medium |2024-06-21 |2024-07-01 |**2024-08-11** |2024-07-14 |2024-07-28 |**2024-08-11** | +|Advanced |2024-06-25 |2024-07-01 |**2024-08-25** |2024-07-21 |2024-08-11 |**2024-08-25** | + + +## Extension Of Microgrant Issue's Timeline + +In case a response critical for the technical resolution of the Microgrant Issue is delayed in [GitHub](https://github.com) and/or [Slack](https://asyncapi.slack.com) for a period of three or more consecutive working days, all remaining target dates of the Microgrant Issue's Timeline are shifted by one calendar week per each of the three consecutive working days the critically important response was delayed. 'Working days' are weekdays, from Monday through Friday, with any holidays regarded as standard weekdays. Friday and Monday are considered consecutive weekdays. + +In case of unpredicted [force majeure](https://iccwbo.org/wp-content/uploads/sites/3/2020/03/icc-forcemajeure-hardship-clauses-march2020.pdf) and/or circumstances that could not be foreseen and/or that are beyond the control of both the Microgrant Program Participant and the AsyncAPI Maintainer, the Microgrant Issue Timeline can be extended by a fixed or indefinite amount of time, with a fair explanation provided in the Microgrant Issue's or Pull Request's comments. + +Communication on the necessity of the Microgrant Issue Timeline extension should happen prior to any current milestone of the Microgrant Issue's Timeline approaching, with a reflection of the start of such communication in the Microgrant Issue's or Pull Request's comments, in case a communication platform other than GitHub is used. + + +## Microgrant Issue's Reclassification + +Upon request of the AsyncAPI Maintainer, who is responsible for the resolution of the given Microgrant Issue from the AsyncAPI's side in the Microgrant Issue's comments in the process of resolution, the Complexity Level of the Microgrant Issue can be reclassified in any direction (both lowered to `Medium` and heightened to `Advanced`), with corresponding changes to the Microgrant Issue's Timeline in case of a need. + +Reclassified Microgrant Issue gets one of the historical text labels `microgrant/downgraded` or `microgrant/upgraded` accordingly. + + +## Microgrant Issue's Completion + +To avoid half-merges, unmet dependencies on the completion of other (inextricably linked) issues, waiting for merges of other separate PRs that provide critically important functionality for the given task, etc., and to avoid situations where AsyncAPI has already acquired an obligation to pay but factually the conditions of the Microgrant Issue completion are not met yet, a system of double control with separation of concerns is exercised on the Microgrant Issues: + +- After the Microgrant Issue's closure on GitHub, the AsyncAPI Maintainer, who was responsible for the resolution of the given Microgrant Issue from the AsyncAPI's side, confirms the Microgrant Issue's technical resolution by posting a separate confirming comment in this Microgrant Issue's comments (followed by another confirming comment from the AsyncAPI Maintainer of this specific repository, if these were two different persons.) + +- The Microgrant Program Participant proceeds with the process of claiming the reward only after the second comment from the Microgrant Program Coordinator, confirming the Microgrant Issue completion and readiness to perform the payout. + + +## Microgrant Issue's End Of Life + +GitHub issue participates in the Microgrant Program and is considered a Microgrant Issue starting from the second of addition of the GitHub label `microgrant` according to GitHub's timestamp until the Microgrant Issue's End Of Life, which starts after the last second of the last day of the calendar-month round of the Microgrant Program it was introduced in, inclusive. + +In case a Microgrant Issue gets an assignee before the End Of Life and continues to have an assignee after the End Of Life, it continues to be a Microgrant Issue until completion. + +In case a Microgrant Issue does not get an assignee before the End Of Life, after reaching End Of Life, it gets the historical text label `microgrant/unpicked` and is considered the one that reached End Of Life. + +In case a Microgrant Issue gets an assignee before the End Of Life and is dropped after the End Of Life, it gets the historical text label `microgrant/dropped` and is considered the one that reached the End Of Life. + +In case a Microgrant Issue gets an assignee before the End Of Life and does not get completed within the assigned Timeline after the End Of Life due to the Microgrant Program Participant's misperformance, it gets the historical text label `microgrant/misperformed` and is considered the one that reached End Of Life. + +In case a Microgrant Issue gets an assignee before the End Of Life and, during its technical resolution, it becomes clear that this Microgrant Issue cannot be completed due to unpredicted [force majeure](https://iccwbo.org/wp-content/uploads/sites/3/2020/03/icc-forcemajeure-hardship-clauses-march2020.pdf) and/or circumstances that could not be foreseen and/or that are beyond the control of both the Microgrant Program Participant and the AsyncAPI Maintainer, it gets the historical text label `microgrant/canceled` and is considered the one that reached End Of Life. + +Microgrant Issue that reached End Of Life gets the historical text label `microgrant/eol`, the reward for this Microgrant Issue gets excluded from the budget allocated for the corresponding calendar-month round of the Microgrant Program, and this Microgrant Issue becomes a regular GitHub issue, which can be submitted again as a Microgrant Issue Candidate. + +A dropped Microgrant Issue cannot be assigned again to the same Microgrant Program Participant who dropped it in the next calendar-month rounds of the Microgrant Program. + + +## Additional Conditions + +The Microgrant Program operates on a mutual-exclusion basis: during the time of participation of a GitHub issue in the Microgrant Program, contributions (code, documentation, design, and other solutions) are accepted only from the assigned Microgrant Program Participants. + +AsyncAPI Maintainers are allowed to work on Microgrant Issues submitted by themselves. + +Microgrant Program Participant is allowed to choose up to two Microgrant Issues of any Complexity Level for simultaneous resolution. + +Two or more GitHub issues (each of which individually has a Complexity Level lower than `Medium` or those that are coupled tightly but not inextricably) can be aggregated to form one Microgrant Issue with a Complexity Level `Medium`, which is then submitted for participation in the Microgrant Program. Aggregated Microgrant Issues have the prefix `[MICROGRANT]`. + +The Microgrant Program Participants that fall under the second and third categories should explain in meaningful words how they are going to approach the resolution process when expressing a desire to work on a Microgrant Issue. + +All Microgrant Program-related activities of the Microgrant Program Participants that fall under the second and third categories (expression of a desire to work on a Microgrant Issue, explanation of the presumed approach to the resolution of the Microgrant Issue, etc.) are taken into consideration only if they occurred after the addition of the GitHub label `microgrant` to the GitHub issue. + +GitHub label `microgrant` has hex code `#708090`. + + +## Claiming The Reward + +Claiming the reward for the completed Microgrant Issue is done via the submission of an invoice at the dedicated [AsyncAPI Microgrant Program page on Open Collective](https://opencollective.com/asyncapi/projects/asyncapi-microgrant-program) (button '`ACTIONS`', dropdown option '`Submit expense`'). + +**Before the submission of the invoice, the Microgrant Program Participant MUST ensure that the account they will use for the payout is VERIFIED by their financial institution, fully operational, and able to receive payments.** + +Requirements for the invoice: + +- Make sure that your `Full Name` on GitHub, as well as `Legal Name` and `Full name of the account holder` on the invoice, **are the same** and are YOUR REAL LEGAL NAME according to the passport/ID (on Open Collective, nicknames are allowed only in `Settings / Public profile / Display name`, and it is **this** name that will be displayed publicly throughout all https://opencollective.com if you have privacy concerns) + +- **Expense title**: '`Microgrant [repo]#[issue]`' (e.g., '`Microgrant cli#38`' or '`Microgrant cli#38, cli#361`' in case of two rewards being joined into one sum) + +- **Tag**: '`microgrant`' + +- **Set invoice details / Description**: mention the full URL of the GitHub issue which served as the Microgrant Issue + +AsyncAPI does not perform financial transactions itself and relies on Open Collective's Fiscal Host 'Open Source Collective' to service payments and, thus, [comply with global sanctions](https://docs.oscollective.org/how-it-works/basics/expense-policies-and-limitations#permitted-countries-ofac-checks-and-payments-to-certain-countries). However, it has been empirically proven that even if the Microgrant Program Participant is a citizen of a sanctioned jurisdiction, they can still receive the financial payment made to a payee in a non-sanctioned jurisdiction. Taking this into account, **potential Microgrant Program Participants must [check themselves](https://wise.com/help/articles/2978049/which-countries-can-i-use-wise-in) to see whether they will be able to receive payment prior to starting participation in the Microgrant Program**. AsyncAPI will not take any action if Open Source Collective refuses to relay the payment due to US or global sanctions imposed on a jurisdiction or an individual. + +Also, note that if a Microgrant Program Participant submits invoice expenses for more than six hundred US dollars and 00 cents (USD 600.00) per calendar year to a Collective at Open Collective with a Fiscal Host in the US (AsyncAPI fits this description,) they will be asked to fill out an IRS tax information form, which will be either a `W-8BEN` or a `W-8BEN-E` depending on whether the Microgrant Program Participant has the legal status of an individual or of a sole proprietor, **supplying a local Tax ID**, **regardless** of their US citizenship status. + +At the time of writing (2023-10-01), Open Collective supports `ACH`, `International SWIFT through Wise` (limitations of financial technology company 'Wise' are applied), and `PayPal` as automated payout methods. In rare cases (once per calendar year), Microgrant Program Participant in personal communication with Open Collective can request them to perform a payout using a custom payment method to a non-sanctioned jurisdiction. + + +## Suspension + +Each new Microgrant Program Participant starts participation in the Microgrant Program with a quantity of Suspensions equal to zero. + +In case a Microgrant Program Participant stops rendering services directed toward resolution of the (**one**) Microgrant Issue without any communication on the subject ('silently drops') and/or fails to complete the (**one**) Microgrant Issue within the assigned Timeline due to their own misperformance, for the **first time**, they receive a **First Suspension** and will be prohibited from participating in the Microgrant Program **starting from the current moment and during two calendar months from the beginning of the next calendar month**. After this period, the First Suspension expires. + +In case a Microgrant Program Participant stops rendering services directed toward resolution of the (**one**) Microgrant Issue without any communication on the subject ('silently drops') and/or fails to complete the (**one**) Microgrant Issue within the assigned Timeline due to their own misperformance, for the **second time** during six calendar months from the beginning of the next calendar month after the expiration of the First Suspension, they receive a **Second Suspension** and will be prohibited from participating in the Microgrant Program **starting from the current moment and during eight calendar months from the beginning of the next calendar month**. After this period, the Second Suspension expires. + +In case a Microgrant Program Participant stops rendering services directed toward resolution of **one of two** Microgrant Issues, chosen for simultaneous resolution, without any communication on the subject ('silently drops') and/or fails to complete **one of two** Microgrant Issues chosen for simultaneous resolution within the assigned Timeline due to their own misperformance, for the **first time**, they receive a **First Suspension** and will be prohibited from participating in the Microgrant Program **during two calendar months from the beginning of the next calendar month**. After this period, the First Suspension expires. + +In case a Microgrant Program Participant stops rendering services directed toward resolution of **one of two** Microgrant Issues, chosen for simultaneous resolution, without any communication on the subject ('silently drops') and/or fails to complete **one of two** Microgrant Issues chosen for simultaneous resolution within the assigned Timeline due to their own misperformance, for the **second time** during six calendar months from the beginning of the next calendar month after the expiration of the First Suspension, they receive a **Second Suspension** and will be prohibited from participating in the Microgrant Program **during eight calendar months from the beginning of the next calendar month**. After this period, the Second Suspension expires. + +In case a Microgrant Program Participant stops rendering services directed toward resolution of **two** Microgrant Issues, **simultaneously** without any communication on the subject ('silently drops'), or fails to complete **two** Microgrant Issues within the assigned Timeline due to their own misperformance **simultaneously**, or engages in any combination of the above actions, including scenarios such as misperforming one Microgrant Issue and silently dropping another **simultaneously**, they receive a **Second Suspension** immediately and will be prohibited from participating in the Microgrant Program **starting from the current moment and during eight calendar months from the beginning of the next calendar month**. After this period, the Second Suspension expires. + +The reward for the completed Microgrant Issue (Microgrant Issues) is not paid to the Microgrant Program Participant who was assigned Suspension for this Microgrant Issue (Microgrant Issues) even in the case of its (their) voluntary completion. + +After the expiration of the Second Suspension or after six calendar months from the beginning of the next calendar month after the expiration of the First Suspension, if no Second Suspension was received during this time, their Suspension history is considered clean, and the quantity of Suspensions is reset to zero. + +A dedicated list is used for the purpose of tracking current Suspension history. + + +## Sources + +This document is the consolidated and formalized version of all information publicly available in free form at + +##### https://github.com/orgs/asyncapi/discussions/541#discussioncomment-5462792 +##### https://github.com/orgs/asyncapi/discussions/877#discussioncomment-6970799 +##### https://docs.opencollective.com/help/expenses-and-getting-paid/tax-information +##### https://asyncapi.slack.com/archives/C05UHTSEHE2/p1699433566459269 +##### https://github.com/asyncapi/community/pull/897#discussion_r1390778779 +##### https://github.com/asyncapi/community/issues/1072 +##### https://github.com/asyncapi/community/issues/2085#issuecomment-3407063246 +##### https://github.com/asyncapi/community/issues/2163 +##### https://github.com/asyncapi/community/issues/3498#issuecomment-4176693654 diff --git a/docs/020-governance-and-policies/PROJECT_FUNDING.md b/docs/020-governance-and-policies/PROJECT_FUNDING.md index 153e4043c6..48b741444e 100644 --- a/docs/020-governance-and-policies/PROJECT_FUNDING.md +++ b/docs/020-governance-and-policies/PROJECT_FUNDING.md @@ -74,9 +74,9 @@ To meet the demands of our growing community, we require full-time commitment. W We aim to establish our own swag store to efficiently distribute merchandise to contributors, mentees, ambassadors, and other community members. Part of the proceeds from the store can help cover the cost of complimentary swag. -#### Bounty Program +#### Microgrant Program -Our Bounty Program seeks to recognize and reward dedicated contributors and maintainers without relying solely on company-sponsored employees or volunteers. It also provides newcomers with the opportunity to build their contributor portfolios, making it easier for them to secure rewarding tech jobs. +Our Microgrant Program seeks to recognize and reward dedicated contributors and maintainers without relying solely on company-sponsored employees or volunteers. It also provides newcomers with the opportunity to build their contributor portfolios, making it easier for them to secure rewarding tech jobs. #### Services diff --git a/docs/020-governance-and-policies/TSC_MEMBERSHIP.md b/docs/020-governance-and-policies/TSC_MEMBERSHIP.md index 6a4bc1ce76..7874a8c72f 100644 --- a/docs/020-governance-and-policies/TSC_MEMBERSHIP.md +++ b/docs/020-governance-and-policies/TSC_MEMBERSHIP.md @@ -64,7 +64,7 @@ Possible topics: * Archive inactive projects without regular maintenance. * Programs organization that affect the whole organization, not a single repository: * Ambassador program - * Bounty program + * Microgrant program * Budget approval to allocate sponsorship funds for different initiatives. * Conflicts resolution - TSC resolves tech-related conflicts, while a dedicated committee handles personal conflicts related to the Code of Conduct. diff --git a/docs/020-governance-and-policies/initiative-inventory.md b/docs/020-governance-and-policies/initiative-inventory.md index 6394858963..8132b68756 100644 --- a/docs/020-governance-and-policies/initiative-inventory.md +++ b/docs/020-governance-and-policies/initiative-inventory.md @@ -74,7 +74,7 @@ For plugins: People we hire through Open Collective contracts or pay for a specific job to be done in one of our official programs. All costs below are always planned in the budget and approved by TSC. For clarity and better budget planning goal is to have dedicated subprojects in Open Collective platform to secure funding more easily. - [Thulie](https://github.com/thulieblack): hired through official contract with Open Source Collective (on our behalf) to do community management ($2.5k monthly). Managed through https://opencollective.com/asyncapi/projects/community-manager-budget -- [Ash](https://github.com/aeworxet): makes sure AsyncAPI Bounty program runs smoothly, organizes 4 rounds/year, one each quarter. We pay $400 for each round. We started to manage funding through https://opencollective.com/asyncapi/projects/asyncapi-bounty-program +- [Ash](https://github.com/aeworxet): makes sure AsyncAPI Microgrant program runs smoothly, organizes 12 rounds/year, one each month. We pay $150 for each round. We started to manage funding through https://opencollective.com/asyncapi/projects/asyncapi-microgrant-program - [Ace](https://github.com/AceTheCreator): ensures we participate in different mentorship programs and also host our own. We pay $2k for each program ($1k for all the work to kick off the program, get funding, and communications; and $1k at the end once completed and the summary is published). There is no single Open Collective subproject for securing funds. Until now, we have created dedicated projects per mentorship, but with the introduction of [cohorts](https://www.asyncapi.com/blog/2024-mentorship-program-summary#refocus-setting-our-future-intentions), it may make sense to maintain one project for all mentorships, with funds secured for Ace’s payment too. ## Social Media diff --git a/docs/030-project-vision-strategy-goals/2026_Community_Goals.md b/docs/030-project-vision-strategy-goals/2026_Community_Goals.md index 30e8d1c2a4..954c94cccc 100644 --- a/docs/030-project-vision-strategy-goals/2026_Community_Goals.md +++ b/docs/030-project-vision-strategy-goals/2026_Community_Goals.md @@ -23,7 +23,7 @@ Increase the number of active maintainers and support current maintainers in the - **S2: Improve the Maintainer Process** (Targets O1): Update the maintainer and TSC process, requirements and onboarding. Mandate that each critical repository has at least 2-3 active maintainers to prevent bus factor and burnout. Educate maintainers on the Maintainership Initiative. - **S3: Working Group Cleanup** (Targets O3): Clean up inactive working groups and channels. Improve guidelines for new groups, including a requirement for multiple active chairs, [completion of the Linux Foundation training course](https://training.linuxfoundation.org/training/leading-high-performance-working-group-meetings-lfc120), and quarterly reports on the AsyncAPI blog. - **S4: Enhance the Maintainership Program** (Targets O1): The [AsyncAPI Maintainership Program](https://www.asyncapi.com/docs/community/maintainership-guide) is our core brand and umbrella for all our mentorship programs. The only change is the funding approach through programs such as GSoC and LFX Mentorship. To further improve how the contributions of the Maintainership Program toward the community goal, we need to establish a dedicated Maintainership Working Group to improve all aspects of the program. -- **S5: The AsyncAPI Bounty Program** (Targets O1): Change the Bounty Program to operate on a monthly basis with a more effective financial schedule. +- **S5: The AsyncAPI Microgrant Program** (Targets O1): Change the Microgrant Program to operate on a monthly basis with a more effective financial schedule. - **S6: Organize the AsyncAPI Conference 2026** (Targets O1): Improve venue selection, establish a meet-ups section, and continue working on the API Standards Booth. Additionally, refine the conference prospectus for sponsors by reviewing what we offer, and start collecting our own attendee registrations for our contacts. We should also offer access to this information to conference sponsors. - **S7: Manage the Ambassador Program** (Targets O1): Continue monthly Ambassador meetings and identify additional Ambassadors to support the program. - **S8: Launch the Fellowship Program** (Targets O1): Lay the groundwork for the new program by creating documentation on its purpose and eligibility. Research and discuss criteria for selecting projects and create a communication plan. But to start work, it'll heavily rely on the execution of S1. @@ -37,7 +37,7 @@ Increase the number of active maintainers and support current maintainers in the - **M3**: Number of active working groups. - **M4**: Number of quarterly reports published on the blog. - **M5**: Number of participants in GSoC and LFX Mentorship. -- **M6**: Budget utilization for the Bounty Program. +- **M6**: Budget utilization for the Microgrant Program. - **M7**: Conference attendance and sponsor revenue. - **M8**: Number of active Ambassadors. - **M9**: Number of sponsors @@ -45,6 +45,6 @@ Increase the number of active maintainers and support current maintainers in the ### Summary 2026 is a year of focus, consolidation, and strengthening the foundation. We’re dedicated to ensuring AsyncAPI continues to scale sustainably while empowering the people behind it. -These efforts will coordinate under the Community Working Group umbrella, with execution led by Community Builders [Ace](https://github.com/AceTheCreator) (Maintainership Program), [Ash](https://github.com/aeworxet) (Bounty Program), [Łukasz](https://github.com/derberg) (Fellowship Program), [Hugo](https://github.com/hguerrero) (Sponsorships and Outreach), [Fran](https://github.com/fmvilas) (Repository Audit and Maintenance Processes), [Governance Board](https://github.com/orgs/asyncapi/teams/governance-board) (AsyncAPI Budget), and [Thulie](https://github.com/thulieblack) (AsyncAPI Conference and Ambassador Program), and supported by the wider AsyncAPI community. +These efforts will coordinate under the Community Working Group umbrella, with execution led by Community Builders [Ace](https://github.com/AceTheCreator) (Maintainership Program), [Ash](https://github.com/aeworxet) (Microgrant Program), [Łukasz](https://github.com/derberg) (Fellowship Program), [Hugo](https://github.com/hguerrero) (Sponsorships and Outreach), [Fran](https://github.com/fmvilas) (Repository Audit and Maintenance Processes), [Governance Board](https://github.com/orgs/asyncapi/teams/governance-board) (AsyncAPI Budget), and [Thulie](https://github.com/thulieblack) (AsyncAPI Conference and Ambassador Program), and supported by the wider AsyncAPI community. Additionally, this is an open call for new Community Builders to lead some initiatives and strategies listed above for those who want to take ownership, drive impact, and help shape the next chapter of the AsyncAPI community.