docs: add Bounty Program Rules

[aeworxet]

This PR adds the official Bounty Program Rules, which are the consolidated and formalized version of 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

[aeworxet]

@thulieblack @imabp @Mayaleeeee
Please review and enhance.

[derberg]

That is a very well and quickly written document 👏🏼

Some topics:

We need to have section on how issues are selected for bounty in case there are more candidates than budget

so yeah, we have budget $5k but total value of candidate issues is $6k. Afaik in discussion we talked about simple "draw approach" with some randomizer tool or something

also I'm missing mention of labels and where someone can see a list of bounty issues

[derberg]

also please do not forget to explain how payments are processed, that it is Open Collective, so people should double check if they can be actually paid in their location

[derberg]

Left some answers

[derberg]

up to two - I don't recall us having such limit in a trial. Why do you think it is needed. Maybe we should add it only if we see some problems in future?

[derberg]

or lets say we have limit for 2 but only if we have more than enough issues proposed by maintainers? os if limit is 20 issues, we get 30, then we have limit by 2 for each repo - although it makes stuff complex

[aeworxet]

There are 63 repositories in AsyncAPI GitHub Organization. If only half of them submits one Medium issue, it will already be 31 issue, which is more than 25 - the maximum of Medium issues allowed for the quarter round of the Bounty Program.
Let us hope only 25% of 63 will participate and submit one issue each. It is 16 issues of unknown complexity, which could easily eat up all quarter budget and even overflow it (16 x 400 = 6400.)
But I went further and capped at two issues per repository 'cause there might be many Medium ones, which are still highly needed.

[aeworxet]

In case budget is overflown, full list can be randomized through https://www.random.org, to ensure fairness.

Though it's not understandable how to randomize if there are two issues that strictly depend on each other, and one can't be done without the other, thus they should be excluded from randomization by default. And what to do with two last issues that are 400 but overflows by 200, and the next one is strictly 200 but choosing it would break randomization. ¯\_(ツ)_/¯

[aeworxet]

Covered these topics in Bounty Issue Submission.

[derberg]

Suggested change

	In case the doc documenting functionality, which is being covered in the Bounty Issue, should be created, edited, or altered simultaneously with the Bounty Issue's resolution, such requirement should be explicitly stated in the Scope during Bounty Issue submission.
	In case documentation must be provided together with a solution, which is being covered in the Bounty Issue, should be created, edited, or altered simultaneously with the Bounty Issue's resolution, such requirement should be explicitly stated in the Scope during Bounty Issue submission.

wdyt, just doc documenting functionality sounds strange

[thulieblack]

This looks good; just one thing, though we need to clarify how many Bounty Issues can be assigned to one person per round. For instance, we agreed that we can assign 2 issues to one person for the trial.

We can create a subsection Bounty Assignment in whichever way we need to clarify this.

[aeworxet]

we need to clarify how many Bounty Issues can be assigned to one person per round. For instance, we agreed that we can assign 2 issues to one person for the trial.

It is in Additional conditions, second paragraph.
This doc is currently being changed very lively so it's hard to keep up with changes, yeah.

[derberg]

"by the AsyncAPI Maintainer of the repository where the candidate for the Bounty Issue is residing"

sorry, not trying to be picky, I'm just not sure what you wanna say

[aeworxet]

I'm trying to say

"by the AsyncAPI Maintainer of the repository which contains The Issue. Exactly that Issue which is going to be the Bounty Issue candidate, not just any other minor issue."

How to rephrase it?

[derberg]

maybe instead of Up to two Bounty Issues per each calendar quarter round of the Bounty Program are submitted in comments of a dedicated AsyncAPI GitHub Organization's Discussion by the AsyncAPI Maintainer of the repository where the candidate for the Bounty Issue is residing, containing the following five fields: do something like

- Bounty issues must be submitted as a comment under a discussion related to given bounty calendar quarter. 
- Issue must be submitted my maintainer of a given repository
- There can be maximum two issues per repository per quarter
- Bounty discussions run under [AsyncAPI Organization's Discussions](https://github.com/orgs/asyncapi/discussions/)

although There can be maximum two issues per repository per quarter maybe should be There can be maximum two issues per repository per quarter. If there are not enough bounty candidates from other repositories, limit of two might be excited ?

[aeworxet]

I'd prefer to keep language of the document persistent, so rephrased original text but kept the language.

Bounty Issues are submitted from the eighth to the twenty-first day (inclusive) of March, June,
September and December, in a quantity of no more than two issues per repository, in comments of the
dedicated [AsyncAPI Organization's Discussion](https://github.com/orgs/asyncapi/discussions),
by the AsyncAPI Maintainer of the given repository, containing the following five fields:

If there are not enough bounty candidates from other repositories, limit of two might be excited ?

I wouldn't like to complicate the algorithm. In fact, in a year the Bounty Program might become so popular that there will be a need even to CUT the cap from two to one issue per repo. So I'd propose to leave the cap of two intact for now and reevaluate it at the end of 2024.

[derberg]

the more constraints - are submitted from the eighth to the twenty-first day - the worst for you. "Quarter" should be the only limit in this document. Then it gives you a flexibility of improving quarter by quarter - deadlines and other stuff

[derberg]

In fact, in a year the Bounty Program might become so popular that there will be a need even to CUT the cap from two to one issue per repo

yes, it is possible that it becomes more popular, but some could argue that solution is not to cut but rather prioritize which repost are more imported to invest it. Cause I personally prefer to have 4 bounty issues for generator that has huge audience, than 1 in a project with 2 stars and no regular maintenance. But yeah - not something we should worry about now

[aeworxet]

the more constraints - are submitted from the eighth to the twenty-first day - the worst for you.

Finance-related business activity should have the clearest defined timeline possible. 🤷‍♂️

[derberg]

maybe, not sure, as timeline is not money related, only quarter is. Anyway, such timeline can still be done per quarter and do not have to be written in stone in MD file

[Mayaleeeee]

Well done @aeworxet. You did a great job on this!

[AnimeshKumar923]

Suggested change

In case of the online absence of the AsyncAPI Maintainer in [Slack](https://asyncapi.slack.com) for a period of more than three working days in a raw, all target dates of the Bounty Issue Timeline are increased by one calendar week per each three working days in a raw of the online absence of the AsyncAPI Maintainer plus one calendar week. 'Plus one calendar week' period is required because after the AsyncAPI Maintainer has regained a confident online presence in [Slack](https://asyncapi.slack.com), the Bounty Program Participant would have to spend time getting back to the insides of the issue, and nearly unfamiliar at that time her or his own code.

In case of the online absence of the AsyncAPI Maintainer in [Slack](https://asyncapi.slack.com) for a period of more than three working days in a row, all target dates of the Bounty Issue Timeline are increased by one calendar week per each three working days in a row of the online absence of the AsyncAPI Maintainer plus one calendar week. 'Plus one calendar week' period is required because after the AsyncAPI Maintainer has regained a confident online presence in [Slack](https://asyncapi.slack.com), the Bounty Program Participant would have to spend time getting back to the insides of the issue, and nearly unfamiliar at that time of their own code.

[aeworxet]

@AnimeshKumar923, thank you for pointing out the questionable items.
This document, in its core, was intended to support women in AsyncAPI's Bounty Program by intentionally specifically mentioning their pronoun in text and putting it before the males' one as a sign of respect, while simultaneously drawing attention to the fact that women, in accordance with the principle of equal opportunities, receive both privileges of having the possibility to be recognized as qualified developers as well as receive bans for misperformance. And if everything's understandable with the row, concerning the second change, I think I ought to summon @Barbanio, so she helps to determine more precisely what pronoun or pronouns should be used in this document when referring to Bounty Program Participants and other people.
At the same time, I would also ask Barbaño for the expert conclusion about the text as a whole, whether it is gender-neutral enough in general, or should any more changes be introduced.

Pronounces are currently mentioned in the following places:

her or his own code
she or he will be asked
she or he receives a First Ban
she or he receives a Second Ban
her or his Ban history
they are pinged 
they will be able to
submitted by themselves
request them to perform
check ... themselves

[Barbanio]

Hi! Thank you for thinking about pronouns. They are very important for all people to feel included. The most common is to use they/them/theirs, even for the singular. This form allows us to include all people, even those who are non-binary 🙂

[AnimeshKumar923]

They are very important for all people to feel included. The most common is to use they/them/theirs, even for the singular. This form allows us to include all people, even those who are non-binary 🙂

Hmm...makes sense. That's why I suggested their 😁

[aeworxet]

Changed to

their own code
they will be asked
they receive a First Ban
they receive a Second Ban
their Ban history
they are pinged 
they will be able to
submitted by themselves
request them to perform
check ... themselves

[imabp]

@aeworxet i think, we missed an important thing in this doc. Kindly check the comment over the file.