Introducing the pre-Approved Grant

[Reqrefusion]

It is a documented version of the suggestion given by me at #257 so that it is not lost.
@chennes @prokoudine @yorikvanhavre

I thought this was appropriate as a name. I think "post-facto grant" does not fully correspond to it.

[sliptonic]

This looks like a mechanism to pre-attach a certain amount of money to the resolution of a known bug/issue. In that sense, it is basically a bounty. I don't have a problem with bounties as a funding concept but I'm skeptical that they really work.

Even in this case, the developer could invest a significant amount of time implementing a feature or fixing a bug and the resulting PR could be rejected by the maintainers (code quality, incompatibility with other features, etc). In that case, the developer would be out of luck. The payout a bounty HAS to be tied to successful acceptance of a PR that closes an issue. This puts all the burden of research to understand the requirements, planning, and development on the developer. He or she runs the risk of doing a lot of work for a small amount of money.

Again, I'm not opposed to the program. I'm just skeptical about its effectiveness outside a very narrow set of issues like those we tackled at the end of the 1.0 development cycle.

[Reqrefusion]

This looks like a mechanism to pre-attach a certain amount of money to the resolution of a known bug/issue. In that sense, it is basically a bounty. I don't have a problem with bounties as a funding concept but I'm skeptical that they really work.

When it comes down to basics, grant is actually a bounty. The purpose of both is to compensate for alternative costs. Is there any need to go so basic? For example, it is wrong to lock a person in a place. But if the monopoly of force does this by operating various processes, this will be justice. The important thing here is the processes.

Even in this case, the developer could invest a significant amount of time implementing a feature or fixing a bug and the resulting PR could be rejected by the maintainers (code quality, incompatibility with other features, etc). In that case, the developer would be out of luck. The payout a bounty HAS to be tied to successful acceptance of a PR that closes an issue. This puts all the burden of research to understand the requirements, planning, and development on the developer. He or she runs the risk of doing a lot of work for a small amount of money.

All work goes through the technical committee. The technical committee informs about this. In addition, it is envisaged that the entire process will be carried out before the work is completed. For example, a person cannot apply for an accepted PR. Also, maybe you missed it, but as it is said that no money is put into issues, this is Grant, not Bounty. The person makes a prediction about the compensation in the grant proposal and can express his opinion about it in the technical committee. And there may even be a vote at the general assembly to determine this compensation. These processes are foreseen.

Again, I'm not opposed to the program. I'm just skeptical about its effectiveness outside a very narrow set of issues like those we tackled at the end of the 1.0 development cycle.

Unlike you, I'm completely skeptical. I even want it to be avoided in any way.

The system here is actually a method implemented by states. For underdeveloped regions within the country, such a thing is generally announced at the beginning of each year and investors benefit from it. Of course, investors follow the required processes. There is no bounty situation here.