Open Collective funds redistribution with contributors

[aeworxet]

Branching from topic with the same name in discussion AsyncAPI community building/maintenance goals for 2023.

The question that needs to be solved in this discussion is

HOW to define the amount of financial compensation to each particular contributor to AsyncAPI Initiative?

Preferably with a measurable metric.

I have come up with two approaches.
They are naïve, I know that. But their goal is not to provide a ready-to-use solution, but to trigger brainstorming process, for which goal they are good enough.

Approach #1

General hourly rate for all contributors is established. It will be voted by TSC (this way the rate will be an 'intermediary fair' for most areas of the world / programming languages / level of qualification), and in future all operations are performed using hours only.

GitHub issues are assigned levels of complexity:

• easy - 1 (one) hour (because after 15 minutes of coding the person still needs to shape up a pull request and respond / react in code to comments)
• medium - 2 (two) hours
• hard - 3 (three) hours

Approach #2

Auction rules are used (the USD amounts are given only as an example): each issue is automatically assigned a reward tag $10 on creation, and each Thursday (so people could estimate what they're going to be doing on weekend 🙂) the reward is automatically increased with step '$10' (but not more than $100), until someone takes the issue. This approach would give 9 (nine) increases, it's about 2 (two) months - quite enough so that nearly any issue gets resolved. If issue reaches reward tag $100 but is still unresolved - it either becomes stale, or someone from TSC members takes it (as unresolved issue definitely interferes with some maintenance activity).
The reward increasing freezes as soon as issue gets an assignee (kind of, sorry pal, you agreed to THAT amount, not to a bigger one, just because it took more than one week to resolve it), stays frozen on reassignment to another user, unfreezes on becoming 'Unassigned' again.

Merged PR automatically pulls the reward tags from the issues it fixes (the PR's description must include text 'Fixes #XXXX') and this link is included when the person is claiming the reward (by submitting expense) at AsyncAPI Initiative's OC profile.
Future bugfixes (SemVer's PATCH versions) to this functionality are performed by the author for free. Sorry, but take responsibility for your code.

Inspired by OpenCollective Foundation's bounty model:
https://docs.opencollective.com/help/contributing/development/bounties
https://github.com/opencollective/opencollective/issues?q=is%3Aissue+is%3Aclosed+label%3Abounty
https://opencollective.com/engineering/expenses?searchTerm=bounty

Please, criticize and submit your counter-proposals.

[Souvikns]

Not only money I think we should also incorporate swags, I see some open-source projects do this https://devswag.io/ . I think it would be suitable for easy tasks.

I also like the 2nd approach, one thing to add (not sure if it is even possible), it would be awesome if anyone could donate to an Issue, for example I am a company and I want to push a feature and I don't have time to work on it myself, I can donate an amount which would go towards helping anyone in the community solving that issue. It could be hard to track and manage money like this.

[aeworxet]

if anyone could donate to an Issue

Similar approach is used at https://issuehunt.io.
https://github.com/IssueHunt/readme#mission

IssueHunt acts like a 'safe box' operating through deposit model.
Sponsor finances specific issue resolution (places funds on IssueHunt's deposit) and whoever resolves that issue, gets paid this amount from IssueHunt (details in https://issuehunt.io/terms).

Of course, IssueHunt could be integrated to the AsyncAPI Initiative's payout model also, but the bigger the quantity of integrated payment systems is, the bigger is the need in a special dedicated person, who will be responsible strictly for accounting. Which should be considered a staff bloat, if no registered legal entity 'AsyncAPI Initiative', whose primary business activity is 'development and technical support of AsyncAPI Standard' and which uses accounting services already anyway, exists.

[derberg]

Sorry for coming that late in the discussion 🙏🏼

The only idea I'm not a fan of is Approach 1 with hour rate. This stuff is really hard to measure and depends on so many factors. I think hour rates work only in factories 😄

---

@aeworxet I like your approach with Bounties mainy as it is inspired on Open Collective (OC). My only question is, do we have to make this "minimum with weekly increase" flow and not fixed rate from the beginning as OC does? This "grow" approach seems like we are counting that we will pay less than needed, which doesn't feel fair (just my feeling though).

In our case the only difference between us and OC would be:

• Contributor Ladder for us would be needed to describe who has right to work on issues, if there are 2 or more candidates. I would say TSC member, then regular contributor (let's say 3PRs merged), and then the rest
• We are not yet super rich, so we would have to set some initial budget for this year. Let's say $10k as a pilot?
• I think it would make sense to set deadline, like "you are picked to work on it, you will get $200, you have 3 weeks, after that time, we will pick another candidate"
• As it is about money, we will first have to get Bounties candidates from maintainers with proposed reward, and then have TSC voting to select a number that fits the budget

anyway, above are just details we need to discuss, like "yeah we select person by assigning issue to that person".

I love that idea and think we should take it forward and discuss more

---

@Souvikns regarding:

• Swags - YES! why not making it a part of Bounties program? So again, we set a budget. Let's imagine initial for this year is $2k (probably 40 tshirts) so again, maintainers can properly mark issue that it is worth a tshirt, but it is not for TSC members? Basically not have it as separate thing but part of bigger Bounties program?
• Donations based - I think again it can be connected with Bounties program. First make it clear that we can open dedicated Project in Open Collective (like we did with Community Manager for @thulieblack) where we store money for this specific Project. So companies can request that for some topic, specify how much they pay, and we will make sure there are right people to work on that. We can also say and regularly communicate with sponsors like "yo, we had 40 issues in Bounties program, but budget covers only 30 of them, here is the way how you can sponsor remaining 10". We can even go further, make it clear in the related issues, have instructions also for individual folks, not just companies, on how to sponsor given issue through open collective.

---

@aeworxet thanks a bunch for starting this conversation 🙏🏼

[akshatnema]

I agree with approach 2 of @aeworxet and also the idea of @Souvikns to distribute swags among the contributors, rather than funds.

Also, regarding the issue @derberg raised do we have to make this "minimum with weekly increase" flow and not fixed rate from the beginning as OC does? , I think with the idea of having swags as the bounties, you are good to go with the fixed rate only and there is no issue of having a weekly increase of the reward a contributor will get.

Moreover, I like to have a query here. How the maintainers will get benefitted from this? Like they are not the current contributors in the repository in terms of code and also, the majority of the work lies as reviewing the PRs and discussing the issues with the contributors. Like how can we distribute the funds to maintainers too despite knowing the fact that they will not be directly involved in making issues and PRs?

[aeworxet]

I had the idea to extend approach 1 with a proposal to hire every maintainer for 20 (twenty) hours/month (one hour per working day or five per weekend, which is quite open-sourcy), but concerns emerged that products of some AsyncAPI subprojects are stable enough and no changes need to be made to them, so some hired maintainers would only end up with getting compensation for doing nothing. I agreed with this thought and excluded part of hiring maintainers from the approach. But the time was passing:

• I hardly understand how much issue Support referenceIntoComponents for other components than message bundler#97 should have cost. I had the main concept coded as a standalone function and ready to implement in main code, but in several months it turned out that nothing needs to be coded at all - quite contrary, even existing code needs to be excluded. If this was a paid issue then I would have spent three months of time on it, just to find out that programming work is not needed there. Spending of time, no financial income.

• In issue date-time formate display is not same as user used inside AsyncAPi file. asyncapi-react#651 I had done a research, found an inconsistency in the code, got no decision-maker feedback and at the end another guy claimed ownership of the issue at all. Spending of time, no financial income.

• Issue Group servers in sidebar navigation like Operation Objects asyncapi-react#649 of definitely medium level of hardness not higher. Due to holidays and high load of the coredev, delays happened. I was assigned this issue on 2022-12-06 and the PR got merged on 2023-01-31. Fifty six days - I counted. Was this time worth of even one hundred USD?

These cases reminded that knowledge work is not only plain coding, but has also intellectual and time-consuming nature. It is for a reason there is 'hourly rate', not 'lines of code quantity rate'. And I would like to hint that development of AsyncAPI Specification was not a programming work, but an intellectually challenging task which required lots of time.

So I think this discussion had logically led to the need to separate TSC members (each of them is a maintainer of some subproject, but using 'TSC members' instead of 'maintainers' eliminates the need to count quantity of maintained repositories, and admits that these folks might not necessarily write code, but only discuss issues, review PRs and steer the main course of AsyncAPI project's development) and regular third-party contributors whose contribution will be exactly programming code, and split this discussion into two streams:

• TSC members,
• regular third-party contributors.

[derberg]

I hardly understand how much issue asyncapi/bundler#97 should have cost

there is still work to do, removal of functionality, adding docs and making sure it is supported on optimizer and probably some stuff in CLI.

In issue asyncapi/asyncapi-react#651

yeah, this one is special case. It is not that there is no work, there is, but in different repo after all.

Issue asyncapi/asyncapi-react#649 of definitely medium level of hardness not higher

yes, open source is slow

☝🏼

These examples prove that if we go forward with bounty program, and give TSC folks power to assign proper bounty labels to issues, they will have to:

• make sure the issue doesn't require further dicussion and it is clear what needs to be implemented
• review will get a higher priority. We can even create some dashboards dedicated to bounty

---

Now if it comes to different work:

• discussions
• project knowledge and experience
• review

All of these are hard to estimate, measure and to set a price. And it is not a problem in open source only 😃 But the bigger problem we have in open source that something estimated as 10h of work with discussions can take in total 100h because of await time. There is a solution for it. If there is a repo where there are big delays, contribution guide needs limits, like "we wait for your opinion no longer than 3 days, then we assume you agree". But then of course we need enough maintainers in a project, otherwise "3 days" or any other rule will not make sense.

Tbh, in case of this kind of work, what I think is that the only solution is to hire them. But we need more money for that and we need some experience. We are in process of hiring Thulie through Open Collective and in few months we will see how it works technically. Until then we can collect more money and see if maybe we can hire more people

[thulieblack]

Here are my 2cents:
Instead of using hours (which is not feasible), why not award bounties according to technicality and priority? Issues that require high expertise and priority have a higher bounty and low priority and expertise lower bounty.

For instance:

Technical expertise	Priority	Timeframe	Bounty (estimate)
Beginner - Intermediate	low	merge 15-20 requests in 2-3 months (similar to hacktoberfest)	swag store coupon
Intermediate - Advanced	medium	2-4 weeks	$150 -$200
Advanced to Expert	med - high	4-6 weeks	$200 - $300
Highly technical	high	6 - 8 weeks	$300 - $600

We can separate a small budget for a test run and compile a list of issues. These issues will then be awarded a bounty according to a technicality, priority, and time frame i.e let's say we have to implement a new feature on the website repo which is required to be done in 4 weeks' time and the individual who'll take up the issue must have knowledge of UX. Whoever is assigned the issue will need to work within the timeframe period.

N.B these figures are just estimates from my head

[derberg]

I'm always afraid of Technical expertise as it is relative and people have different opinions. But in case of bounty maybe it is not a problem. If some maintainer will say issues is intermediate but nobody did it, obvious lesson is that it must be moved to Advanced 🤷🏼

We can separate a small budget for a test run and compile a list of issues.

yes, imho this is definitely a way to go, basically bounty trial

merge 15-20 requests in 2-3 months

what do you mean, what requests mean in this context?

why not award bounties according to technicality and priority

this is the only problem I see. Sometimes we have high technical task but we are not in rush. Not sure if priorities are needed for bounty as I assume that if something is urgent, then maintainer will work on that.

maybe priorities should be by repo, not by issue. Basically there are repositories that are more important than others, so we should assign bounty budget with higher priority to certain repos only?

[thulieblack]

This was my line of thinking:

If we have intermediate-advanced issues, we should offer a higher bounty especially if the issue needs to be resolved quickly.
For good first issues which typically require less expertise, we can offer a swag store voucher if the contributor merges 10-15 valid PRs similar to hacktoberfest.

If we are skeptical about technical expertise we can replace maybe with skills i.e knowledge of React etc. If that's not viable we can always come up with something else. But we can start with a few issues and see how it works out

[thulieblack]

Had a discussion with @derberg and we have come up with a proposal.

We suggest setting aside $2k for the AsyncAPI Bounty Program for approximately 7 issues as a trial. These issues will consist of 4 mid-level and 3 advanced-level tasks.

For mid-level tasks, we should assign a bounty of $200 with a completion deadline of 4-6 weeks. For advanced-level tasks, we assign a bounty of $400 with a completion deadline of 6-8 weeks.

In regards to mid-level issues, we should include 1 design task and 1 technical writing task out of 4.

In the case where maintainers suggest more than 7 issues, we will use a randomizer to pick out the first 7 tasks to be included in the trial.

Please share your thoughts on this!

[derberg]

And remember folks, this is a trial. Instead of rolling out a full blown bounty program, the plan is to do a small trial to see if how certain things work, get feedback and adjust.

@thulieblack we did not discuss what in case there are more than one candidate for one issue. I propose we say:

1. current AsyncAPI maintainer
2. not maintainer but regular contributor
3. others

[thulieblack]

Oooh yeah, I forgot about that. So if I understand correctly @derberg if we have more than one candidate interested in an issue, we will give priority according to this order:

1. AsyncAPI maintainer
2. Regular contributor (not a maintainer)
3. Other?

[derberg]

yup

AsyncAPI maintainer - from any asyncapi repo

and regular means for example - at least 3 PRs merged -> for trial, later we can increase

and we specify that if there is a case that cannot be soled with above rule (like only people from 3 volunteer, or 2 asyncapi maintainers volunteer) than it is up to maintainer to decide using their custom criteria

[aeworxet]

Drawing attention of @asyncapi/tsc_members to issue 'Open Collective funds redistribution with contributors'
https://github.com/orgs/asyncapi/discussions/541

[thulieblack]

AsyncAPI Bounty Program Trial

One of the initiatives this year is to find a way to support and appreciate contributors and maintainers for their work whenever possible. This gave birth to the bounty program, a method to effectively distribute funds and incentivize contributions. After discussing and juggling ideas, we would like to set the train in motion with a small trial to see how it will work.

How will this trial work?

We will start with a minimum of 7 projects which will include 4 medium-level tasks and 3 advanced-level tasks. Among the tasks, we would include a mix of design-related tasks and technical writing-related tasks. In the case, we receive more than 7 proposed projects, we will use a randomizer to select the projects that will participate in the trial.

To ensure fairness, we will prioritize interested individuals in the following order:

1. AsyncAPI maintainers (from any repository)
2. Regular contributors (individuals who have merged three or more pull requests)
3. Other (if an individual doesn’t fall under the above, the maintainer can determine the criteria i.e regular volunteers, etc)

Deadlines

The deadlines for task completion will be as follows:

• mid-level tasks will be set at 4-6 weeks from the date of assignment
• advanced-level tasks are expected to be completed within 6-8 weeks from the date of assignment

Issue Tracking and Updates

Here are some rules to implement after assigning tasks to contributors:

• Contributors must provide a weekly update on the task they're working on. This helps the maintainers keep informed about the progress of the issue.
• If the contributor hasn't provided an update on the issue, ping them as a reminder to do so.
• In the case that the contributor still doesn't provide an update after three pings over three weeks, we will assume that the task cannot be completed within the rest of the time and the contributor has silently dropped the issue. It will then be assigned to someone else.
• Should any contributor drop an issue assigned to them, they will not be eligible to participate in the bounty program for 6 months as a penalty.

Proposal

I would like to propose that we set aside a budget of $2,000 for the AsyncAPI Bounty Program trial. We will distribute the funds as follows:

• For every mid-level task, we assign a bounty of $200
• For every advanced-level task, we assign a bounty of $400

The AsyncAPI Bounty Program will be a great opportunity to incentivize contributions, attract more contributors to the project and eventually increase the growth and engagement of the community.

[Florence-Njeri]

Yes

[magicmatatjahu]

Yes :)

[pratik9315]

Yes

[Samridhi-98]

Yes

[Mayaleeeee]

Yes

[thulieblack]

Hi, my lovely maintainers and @asyncapi/tsc_members ,

Please kindly propose some projects that will participate in the AsyncAPI Bounty Trial. Make sure to include the following with your suggested project/s:

1. Clearly state the requirements of the task, including specific skillset, technology or tools to be used.
2. Specify whether the task falls under the mid-level or advanced-level category, this will help in assigning the bounty amount.

Here is an example (thank you @derberg) :

1. Link: https://github.com/asyncapi/cli/issues/361
2. 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
3. Category: Mid-level
4. Type: coding-related

Remember to also include design-related tasks and technical-writing related tasks.

If we receive more than the required projects for the trial, we will use a randomizer to select the first 7 tasks to participate in this round.

I'm giving y'all till the 17th of April.

[akshatnema]

Hey @thulieblack, I withdraw my submission here as we already get a PR asyncapi/website#1497 resolving the given issue. Kindly remove it from your list.

[magicmatatjahu]

From React component:

1. Link: Create script to generate the custom theme asyncapi-react#370
2. Scope: Add script to generate CSS Theme based on TailwindCSS classes used in component and custom TailwindCSS config. Script should be released together with package. Documentation how to use script should be also written.
3. Category: Advanced-level
4. Type: coding-related

[derberg]

1. Link: Consider enabling Next.js caching for Netlify builds website#843
2. Scope: Enable caching on website build on Netlify
3. Category: mid-level
4. Type: coding-related (or just config) - hard to specify

---

1. Link: Add Dockerfile and release pipeline cli#358
2. Scope:
3. Category: mid-level
4. Type: coding-related (but more like a configuration, for sure technical)

---

1. Link: readme is missing documentation for the new commands  cli#123
2. Scope: Configure CLI commands docs generation into existing flows
3. Category: mid-level
4. Type: coding-related (but more like a configuration, for sure technical)

---

1. Link: Make contexts shareable cli#38
2. Scope: enable CLI to read context from CWD
3. Category: advanced-level
4. Type: coding-related

---

1. Link: Add tutorial that explains step by step how to create a simple Generator Template generator#943
2. Scope: Create a first tutorial for AsyncAPI Generator
3. Category: advanced-level
4. Type: docs-related

---

1. Link: Poster/Graphic/Infograph that highlights what AsyncAPI does with sponsor's money #672
2. Scope: Create an infographic with information about AsyncAPI Initiative finance
3. Category: advanced-level (I'm not sure if this is mid or advanced, I think advanced as the AsyncAPI illustration we got recently costed 250Euro, and I think this infographic is more complex as there will probably be more smaller illustrations)
4. Type: design-related

---

[derberg]

ok, so we have at least 8 issues, with 1 design and 1 docs:

• so we are able to trial the randomizer approach to choose 5 possible coding tasks out from 6 proposed
• we already see I had issue with type of issues that are technical but not really coding
• there were many issues I saw that would be great candidates but the scope was not clarified. So long term, if we introduce bounty as something official, we will need to educate maintainers that they should clarify the scope on regular basis, assign issues to bounty without thinking when "the next bounty takes place" because if their issue didn't get into Bounty A, it may get in Bounty B

of course would be nice if we have more, maybe some more will come by the end of the day, but maybe others wait to see how it will work, if it will actually be effective or cause only noise and distraction

[thulieblack]

We have 4 mid-level tasks which meet the requirements and 4 advanced-level tasks (of which one coding task has to go -- randomizer😉). But yeah we still have a few hours left till the day is over in case we have more entries.

[thulieblack]

Update!

Below are the first 7 projects to participate in the AsyncAPI Bounty Trial :

Bounty Issue Link	Scope	Category	Type
asyncapi/website#843	Enable caching on a website built on Netlify	Medium Level	Coding
asyncapi/cli#358	Add a Dockerfile and release pipeline necessary to publish it	Medium Level	Coding
asyncapi/cli#123	Configure CLI commands docs generation into existing flows	Medium Level	Coding
asyncapi/cli#38	Enable CLI to read the context from CWD	Advanced Level	Coding
asyncapi/generator#943	Create a first tutorial for AsyncAPI Generator	Advanced Level	Doc's
#672	Create an infographic with information about AsyncAPI Initiative finance	Advanced Level	Design
asyncapi/cli#361	Extend the functionality of --version flag in AsyncAPI CLI to include info about versions of other AsyncAPI libraries used in the project	Medium Level	Coding

Next Steps

• Add bounty labels to the issues.
• Add bounty rules, details, and descriptions for interested contributors.
• Roll the trial full force 🫡

[aeworxet]

I would propose to formalize the process of extending timeline of a Bounty task, in case unpredicted force majeure circumstances which are beyond control of both contributor and maintainer appear out of thin air, like
asyncapi/cli#567 (review)
asyncapi/cli#567 (comment)

[aeworxet]

On clarification of time periods used in Bounty tasks.
I had changed PR's asyncapi/cli#567 state to 'Ready for review' at Fri 7PM CEST.
At this moment it was Sat 5AM in Auckland but Fri 10AM in Los Angeles.
I would propose to clarify UTC offset used in time periods of Bounty tasks' timeline and state deadlines as Friday, 2023-07-14, 23:59:59 UTC-12:00.

[aeworxet]

When PR asyncapi/cli#567 was already in 'Ready for review' state, it appeared that I need to add a doc describing functionality I was working with during execution of the task.
When I added the doc, it appeared that according to logic some functionality is missing, so I had to add two functionalities with rewrite of several underlying functions, while updating the doc at the same time.
This led to force-majeured prolongation of the Bounty task asyncapi/cli#38 for an indefinite amount of time.
Such situation could have been avoided if I had been tasked with creation of the doc from the start and it would had been reviewed during development as part of usual process.
So I would propose to introduce a mandatory requirement of simultaneous creation/editing/alteration of the doc documenting functionality which is being worked with, for all Bounty tasks, in every situation when it's applicable.

[aeworxet]

Please note that if bounty hunter submits invoice expenses for more than $600 USD per year to a Collective with a Fiscal Host in the US (AsyncAPI fits this description), she/he will be asked to fill out a tax information form, which will be either a W-8BEN or a W-8BEN-E depending on whether the bounty hunter is an individual or a company.

The form is fairly easy to fill but still, keep in mind there might be a legal document where you specify your local Tax ID.

[aeworxet]

I would propose to introduce strictly defined format for submitting requests for Bounty payouts

Bounty [repo]#[issue]
tag: bounty

It will make invoices related to Bounties easier visually greppable, add possibility to choose ones by tag, will immediately tell Bounty for what issue in what repo was it, and will help in case some automation is implemented in future.

[thulieblack]

Final Status

The AsyncAPI Bounty Trial is officially completed and was a success. We learned many things during the trial that we should implement in the official program. A special shout-out to @aeworxet for starting and leading the discussion 🎉🎉

Below are the completed projects and the wonderful assignees:

Bounty Issue Link	Scope	Category	Type	Assignee	Status
asyncapi/website#843	Enable caching on a website built on Netlify	Medium Level	Coding	Sambhav Gupta	Complete
asyncapi/cli#358	Add a Dockerfile and release pipeline necessary to publish it	Medium Level	Coding	Savio Dias	Complete
asyncapi/cli#123	Configure CLI commands docs generation into existing flows	Medium Level	Coding	Mahfuza Humayra Mohona	Complete
asyncapi/cli#38	Enable CLI to read the context from CWD	Advanced Level	Coding	Viacheslav Turovskyi	Complete
asyncapi/generator#943	Create a first tutorial for AsyncAPI Generator	Advanced Level	Doc's	Florence Njeri	Complete
#672	Create an infographic with information about AsyncAPI Initiative finance	Advanced Level	Design	AISHAT MUIBUDEEN	Complete
asyncapi/cli#361	Extend the functionality of --version flag in AsyncAPI CLI to include info about versions of other AsyncAPI libraries used in the project	Medium Level	Coding	Viacheslav Turovskyi	Complete

Next Steps

1. Write the documentation and rules for the official Bounty Program.
2. Add to the former rules and take all the suggestions and lessons from the trial, such as the task timeline.

[aeworxet]

A special shout-out to @aeworxet for starting and leading the discussion

If @derberg hadn't agreed to kick off Bounty program, this would never have happened, so all credit goes to him.