Feedback on the Microgrant Program

[aeworxet]

While the Microgrant Program has been running smoothly since late 2023, over the past two months, after the number of submitted GitHub issues for participation in the Microgrant Program spiked and randomization started to be used, concerns from different AsyncAPI maintainers began piling up in DMs.

Most concerns raised have been that clearly non-critical repositories are randomly given priority over obviously critical ones.

When I was choosing randomization, my logic was that the level of technical debt in AsyncAPI is so high that all submitted GitHub issues are equally important. However, practice has shown that the common equality should be atomized and distributed over levels, and the number of opinions on approaches to achieving that has become too many to be resolved individually through DMs.

Hence, this discussion where everyone can share their concerns, frustrations, criticisms, and - most importantly - proposals.

[AceTheCreator]

Yes, I share the same concern about the randomization of issues. It can result in some critical issues never getting selected, while others receive multiple opportunities, with a single maintainer ending up with two or three slots.

I think a fairer approach would be to limit each repository to one selected issue (at most) during the initial selection. That would give other repositories an equal opportunity to participate, since their proposed issues are just as important.

My other suggestion is around the review process for advanced issues. In my opinion, any issue tagged as advanced should go through an additional review, perhaps by the Governance Board, the Code of Conduct lead, or another group designated by the program organizers. That way, advanced projects receive consistent scrutiny, and maintainers can confidently classify their issues appropriately. It would also encourage us to downgrade issues that don't truly meet the bar, knowing that advanced proposals will be reviewed before being accepted.

[TenzDelek]

Agreed that the initial selection should be limited to one issue per maintainer. As it stands, some maintainers end up with two or three slots while others have nothing to work on.

[aeworxet]

The proposal https://github.com/orgs/asyncapi/discussions/3612#discussioncomment-17877635 is incorporated in test mode for the calendar-month round 2026-09.

The mechanism for scrutinizing the Microgrant Issues of both Medium and Advanced Complexity Levels through community pre-moderation already exists:

Submitted GitHub issues undergo public pre-moderation by the AsyncAPI Community to ensure adherence to the values of the AsyncAPI Initiative.
https://github.com/asyncapi/community/blob/master/docs/010-contribution-guidelines/microgrant-program.md?plain=1#L85

The effort to reinforce the existing capabilities is undertaken in asyncapi/optimizer#306 (comment).

[aeworxet]

The test limit of one GitHub issue - both per repository and per maintainer - allowed the submission to finish with the budget state of 1400/1600.

At the same time, it showed that there should be a list of reserve GitHub issues that can be used to fill empty spaces in the budget, if any remain.

If such a list exists, there could be the submission of two GitHub issues, but the first one (by the GitHub timestamp) would be accepted unconditionally, and the second one would be accepted only if free space remains in the budget (i.e., the current round's budget is under-utilized).

For this to work well, there also needs to be a list of repositories sorted in descending order by criticality to determine which reserve GitHub issue should go first.

The list of repositories sorted by criticality could also be used instead of a randomizer if the budget is overflowed already by the first queue of GitHub issues.

So, I propose developing the list of repositories, sorted in descending order by criticality (which appears to align with S1).

The starting point for such a list could be https://github.com/asyncapi/parser-js because the rest of the ecosystem revolves around it, and it could also draw on https://npmtrends.com, https://github.blog/news-insights/octoverse/octoverse-a-new-developer-joins-github-every-second-as-ai-leads-typescript-to-1/#the-top-programming-languages-of-2025-typescript-jumps-to-1-while-python-takes-2, and others as references.

[AysajanE]

Hi @aeworxet, I saw that the one-issue limit was incorporated in test mode for 2026-09. Could one future, unstarted Medium coding Microgrant Issue test one additional mechanism?

• AsyncAPI keeps its normal issue selection, assignee, technical review, merge decision, double-control closeout, and Open Collective reward.
• Before work starts, maintainers freeze one narrow automated check.
• Northset funds a separate $200 objective-check bonus, without using AsyncAPI’s budget. The bonus is earned only when the agreed check passes. AsyncAPI can still decline merge, and its normal reward remains governed by the current process.

This would not claim code quality, maintainability, or that the PR should merge. Northset would handle the setup and funding.

Would this be useful to the program, or is any reward independent of the full human closeout intentionally out of scope?

A yes or no is enough. If useful, I will post a one-page proposal for one task.

Disclosure: I am the founder of Northset. This would be a founder-operated, one-task experiment, not a self-serve product or integration.

[derberg]

Hey, thanks but this is not really related to this discussion. You listed 3 bullet points, and this discussion is related to the first one.

[AysajanE]

Thanks—understood. I read this discussion too broadly and won't continue the proposal here. Would the Ideas category be the appropriate public place for a separately funded one-task experiment, or should I treat it as out of scope for AsyncAPI?

Thanks.

[aeworxet]

@AysajanE

Integrating blockchain smart contracts and the USDC cryptocurrency into the Microgrant Program is currently out of scope, and no target completion date has been set.

Should demand for Northset's services materialize, the company will be contacted using the information provided at https://northset.ai/company.

[AysajanE]

Understood. Thank you for the clear answer. I will close this here.

[derberg]

Most concerns raised have been that clearly non-critical repositories are randomly given priority over obviously critical ones.

I'd love to get some actual examples related to this. It would be great if folks DMing you could explain that in more detail. Cause when I look at the list of issues, sometimes I feel that not-so-important topics are pushed, and that we are not spending sponsor money well.

Imho, the biggest problem is at the repository level and the lack of cooperation between the maintainers. Looking just at Microgrant Program (view) there is only one issue related to official community set goals (goals set by TSC) and the rest are issues where you see no interaction between given repo maintainers - no evaluation of importance, alignment, level discussion. If there is no discussion, there is only individual opinion that later will always be questioned by others, and there will be ideas for committees and other groups to perform such evaluations (that should be done by maintainers and selected stakeholders)

[princerajpoot20]

Yes, non-critical work is being pushed into the Microgrant Program.

Agree with Lukasz:

no evaluation of importance, alignment, level discussion. If there is no discussion, there is only individual opinion that later will always be questioned by others

Yes, agreed. For this we can have the submission cycle in 2 parts: 1st is submission, and then 2nd part is assessment / reviewing and discussion. Other maintainers can discuss and should say whether they see it as aligned and worth a slot. That will help us eventually select the right set of issues out of the given list.

Here are my personal views and proposal:

1. Remove the “per maintainer” rule, keep only the 1-issue-per-repo rule

Firstly, removing the “issue per maintainer” rule, as it limits people who are maintaining more repositories and gives the same weight to a person maintaining 4 to 8 repositories vs a person maintaining a single repository.

It creates an impact on all those repos. Limiting it to 1 or 2 gives equal priority to 1 repo and to 5 repos, which is not correct IMHO.

We need to understand that we do not need to think purely as individuals, where everyone should have equal opportunity. We should think about the organization first and at the organization level. Keeping organization priorities first, and not putting a rule which is only towards the individual. We are the ones responsible for organization growth and sustainability.

If a limit should be there, it should strictly be based on the number of repos you maintain - with an option to ignore the per-person limit if it is related to a community goal. Community goals are the top-most priority of our organization, and these rules should not hamper the community goals we have already decided, because those are the things we decided as an organization.

I see we have a lot of pending community-goal work left for this year. Hence those should be first priority. After that, the limit should be based on the repo, and not based on per person. If a person is maintaining 10 repos, giving them only 1 issue per round vs the one maintaining a single repo who also has a 1-issue limit is simply not fair from an organization POV. That person has more work in their bucket, because they simply maintain 10x more repos. Hence the limit should be 1 issue per repo.

Solution:

• a. Should remove the one-issue-per-person rule, as mentioned above. It limits the person maintaining more repos vs the person maintaining only 1 repo.
• b. Prioritize community goals as the first, top-most priority. That is what Lukasz also mentioned above: "that is the money well spent." A community-goal issue is not bound by the per-person cap. It is still bound by 1 issue per repo. If that repo already has a community-goal issue, that is the one slot - there is no second slot left for a non-goal / maintenance ticket on the same repo that round. It still has to respect the monthly budget.

2. “Set of microgrant issues” as a submission type

Coming to the next point: I was analyzing all the submissions done in the Microgrant Program and pulling out some data.

I see mostly issues are “Set of microgrant issues” submissions, where you put a few minor bugs into one issue.

I see repo that only really rely on the Microgrant Program for this kind of maintenance.

Like for example, parser-js. If I look at human PRs merged there in the last around 2 months:

Reference: https://github.com/asyncapi/parser-js/pulls?q=is%3Apr+state%3Amerged+-author%3Aasyncapi-bot+-author%3Adependabot%5Bbot%5D+created%3A2026-07-05..2026-09-05 [Total 8 PRs are there]

The work done in those 2 months is all labeled microgrant, and the majority of that is this maintenance work done under “Set of microgrant issues” submissions. I am not saying the repo had zero unpaid work, and I am not saying it is totally wrong. My point is: we need to understand that not all maintenance work can simply be pushed under the Microgrant Program.

If we keep on pushing every maintenance work under the Microgrant Program, that will not work out anyway, as we have huge backlogs in every repo. If you keep pushing every maintenance work under the program, then it will hamper other important work like community-goal work, which is actually happening right now. We are left with 3 months for this year, and we have a lot of pending community-goal work left to be done for 2026.

We need to understand that regular maintenance work should be done by the maintainer of their own will as well, without tying everything to the Microgrant Program. I have never seen a repo to date whose maintenance bucket is empty, as it is never-ending work.

Hence, I would suggest we remove “Set of microgrant issues” as a solution, that format should not be how we fund maintenance. Those tickets, and other routine maintenance, should get less priority or at least priority after community goals.

IMHO, we need to understand: as an open source maintainer, it is our responsibility to do the maintenance work with our own will. The community fund should go to community priorities, that is community goals first in any way. You are a maintainer of a repo; you have some responsibility towards that repo.

IMHO, any repo that is solely relying on the Microgrant Program should simply do something on its own as well, without relying on the Microgrant Program. Community-goal issues on those repos still come first - that override stays. Non-goal work and routine maintenance I would treat as the same bucket. They are the same kind of ticket.

Solution:

• Remove “Set of microgrant issues” as a submission type. That is just combining a few very small issues which should be part of the maintenance bucket.

The idea is simple. First, it is our duty/responsibility. Second, it will help reduce the burden on microgrant if we do some work on our own will. It will help clear the backlog at a very good speed, and improve repo health to a far better level.

IMHO, I would suggest that regular maintenance should be 2x or 3x more than the microgrant maintenance. Which means, for a month for a repo, if there are 2 issues/PRs submitted under microgrant, you should have at least 4 or 6 issues/PRs completed without microgrant for that month. You do not need to be the author - anyone can be the author. If a contributor is raising the PR, and it is merged, you did your job as a maintainer.

I would suggest this as a health check / expectation, not as a hard ban. If a repo is far below that, we can ask the maintainer to improve this metric in the coming months. The idea is not hard-banning anyone. The idea is to focus on improving the repo’s health and reducing the maintenance work that keeps landing on the program. Community-goal issues are still first.

If you check the last couple of months’ submissions, the majority are those maintenance work. This should be done by the maintainer, or by a contributor with review by the maintainer.

IMHO, it is our duty as open source maintainers. The community fund should go to community priorities - community goals first in any way.

These microgrant issues should not include day-to-day maintenance tasks. As maintainers we also have a responsibility to handle some of these tasks ourselves rather than pushing everything to the microgrant. We simply cannot afford to fund routine maintenance this way.

3. @aeworxet's repo priority list

Coming to @aeworxet's suggestion regarding having a repo priority list: that seems a nice idea to have. My only point is, this list should be able to be overridden by community goals. Those will remain 1st priority irrespective of that list.

We can have critical repos getting more priority than the ones which comparatively need less maintenance.

Solution:

• We should work on preparing the prioritization list.

How this fits together when we are over budget

Keep in mind we need to respect the budget by self-reviewing all the other issues. If things are getting over budget - let’s say if all are community goals and we are still over budget - see if you can retract some to the next cycle.

If that does not happen, we have the repo prioritization list that can serve as the deciding factor for leftover / overflow.

And the ones that are not selected in that round, or let’s say 2 consecutive rounds: in the 3rd round they should be picked first, so that we don’t have a stale situation.

A new community-goal ticket still outranks a stale non-goal ticket. Order:

Community-goal ticket > repeatedly skipped non-goal ticket > ordinary non-goal ticket

1. Stay inside the monthly budget.
2. Community-goal issues first. They are not bound by the per-person cap. They do not ignore the budget. They are bound by 1 issue per repo.
3. 1 issue per repo in total. If that repo already has a community-goal issue, the slot is used - there is no slot left for a non-goal / maintenance / “set of issues” ticket on the same repo that round. Ordinary non-goal and maintenance sit in the same bucket, and they only get in if that repo does not already have a goal ticket.
4. Repo criticality list is only a tie-break inside leftover, never above a goal tag.
5. Cut two rounds in a row → third round that non-goal ticket is picked before criticality and before a new ordinary non-goal. A new community-goal ticket still outranks it.
6. The 2x/3x unpaid-vs-microgrant ratio is a health check / expectation, not a hard ban. If a repo is below it, we ask the maintainer to improve that metric in the coming months. The idea is not to restrict the repo. The idea is to improve repo health and reduce how much maintenance we keep funding.
7. You can argue we will have a situation where the round is filled with community-goal issues only, we are still over budget, so all the other rules are not even valid, and we are stuck. If that is the case, simply then enforce the 1 issue per repo rule, and start picking issues based on the repo prioritization list. That will handle any amount of load we have. The ones that do not fit this month go to the next cycle.

cc: @aeworxet

[aeworxet]

this list should be able to be overridden by community goals. Those will remain 1st priority irrespective of that list.

Then the following order seems logical:

0. Community Goals
1. List of repositories sorted in descending order by criticality (beginning with Parser)

We should work on preparing the prioritization list.

I'm thinking about a file REPOSITORIES.yaml, placed in the root of the community repository, similar to MAINTAINERS.yaml, that would contain a sequence of repositories sorted by criticality in descending order.

I propose using a YAML sequence rather than a mapping because the order of properties in a JavaScript object may not be preserved consistently when parsing YAML, whereas the order of elements in a JavaScript array is guaranteed to be preserved.

[aeworxet]

The proposal https://github.com/orgs/asyncapi/discussions/3612#discussioncomment-18407241 is incorporated in test mode for the calendar-month round 2026-10.