Papercuts fund

[terminills]

I'm merely starting a thread to discuss how to properly design a fund to handle paying for fixing small bugs in AROS.


Obviously we've used power2people for many years to handle bounties. 

I would like to point out that the fund cannot have a single point of contact due to the fact that people lose interest, get old or whatever may happen.

So suggestions.

[Amiwell]

I should accept multiple contacts

[terminills]

I should accept multiple contacts

Well I'll start

I would suggest setting up 2 dates as to which the funds will be used maybe say in January and July.
Point of contact should be voted on at least once a year.
Point of contact IMHO should be one developer and one user.

Rules for papercut I would suggest at least 2 verification's that the bug is fixed.

[G-linx]

The free stuff..
Clear large wanted/reward banners at the top of aros exec and aros.org

Create an official aros youtube channel?

Contact Dan and Stephen for there youtube assistance/promotion (I can do this in the next few days, though my letters will need clearing first by the aros heads)

[Amiwell]

Well I'll start

I would suggest setting up 2 dates as to which the funds will be used maybe say in January and July.
Point of contact should be voted on at least once a year.
Point of contact IMHO should be one developer and one user.

Rules for papercut I would suggest at least 2 verification's that the bug is fixed.

It could go well

[G-linx]

If the complexities of the money handling are to many perhaps a paper cut when defined are sponsored by an individual and covered by a second?

Now, thinking about the possibility of offending our developers, perhaps when a developer issues a paper cut to be fixed a small amount should also go to them when fixed?

[terminills]

If the complexities of the money handling are to many perhaps a paper cut when defined are sponsored by an individual and covered by a second?

Now, thinking about the possibility of offending our developers, perhaps when a developer issues a paper cut to be fixed a small amount should also go to them when fixed?

It's not the complexity of handling the money that's the issue.  The issue is simply defining the fund in a way that the fund can be used for such a project.

[OlafS3]

Generally I would say first the task should be identified, which bugs should be fixed by it. Then someone with enough experience should estimate how much work is needed to fix it (hours) and how much money would be needed for it. Then someone should raise the hand who would do it. And then money should be collected. Collecting money without developer willing to do it will not work.

First we should look which bugs (papercuts) are really important to users.

[terminills]

Generally I would say first the task should be identified, which bugs should be fixed by it. Then someone with enough experience should estimate how much work is needed to fix it (hours) and how much money would be needed for it. Then someone should raise the hand who would do it. And then money should be collected. Collecting money without developer willing to do it will not work.

First we should look which bugs (papercuts) are really important to users.

We've had that approach for many years and it has never brought new developers.   The whole idea behind the papercuts is its a bunch of small bugs that anyone can pick and choose what interests them and get some appreciation for. Last time we did the papercuts 100 bugs were fixed in a few months.   So the biggest difference is now we're designing a yearly gameplan and developers can decide if it interests them.   power2people has always refunded peoples money if it didn't work out as expected.

[terminills]

Generally I would say first the task should be identified, which bugs should be fixed by it. Then someone with enough experience should estimate how much work is needed to fix it (hours) and how much money would be needed for it. Then someone should raise the hand who would do it. And then money should be collected. Collecting money without developer willing to do it will not work.

First we should look which bugs (papercuts) are really important to users.

We've had that approach for many years and it has never brought new developers.   The whole idea behind the papercuts is its a bunch of small bugs that anyone can pick and choose what interests them and get some appreciation for. Last time we did the papercuts 100 bugs were fixed in a few months.   So the biggest difference is now we're designing a yearly gameplan and developers can decide if it interests them.   power2people has always refunded peoples money if it didn't work out as expected.

I guess I should point out that papercuts are small trivial bugs and nothing complex. 

[OlafS3]

Generally this is not different than any other software project so we need someone skilled who estimate the time needed for it and based on that the amount of money needed. In best case the developer estimating it and doing the papercuts is the same. Realistic it should be someone experienced with Aros, at the moment I could only guess Deadwood, Kalamatee or Michal for it.

But before we should identify which papercuts are important. You in many situations have the 80:20 rule... 20 percent of a project require 80% of the time. Perhaps there are papercuts that are not problematic for normal users but would require lots of time to solve. I have personally no overview there. If papercuts are really only trivial then of course this would be not a big problem. Then we just need someone who looks at it, estimates the time and does it

[terminills]

Generally this is not different than any other software project so we need someone skilled who estimate the time needed for it and based on that the amount of money needed. In best case the developer estimating it and doing the papercuts is the same. Realistic it should be someone experienced with Aros, at the moment I could only guess Deadwood, Kalamatee or Michal for it.

But before we should identify which papercuts are important. You in many situations have the 80:20 rule... 20 percent of a project require 80% of the time. Perhaps there are papercuts that are not problematic for normal users but would require lots of time to solve. I have personally no overview there. If papercuts are really only trivial then of course this would be not a big problem. Then we just need someone who looks at it, estimates the time and does it

The estimation is normally done when they decide to pick up the bug to work on.   If it's too complex they don't do them.  Also if you don't like the idea don't donate.   This isn't about who has the better idea because it comes down to if a developer decides it's worth their time.   I for one will never donate to a singular bounty again I would rather donate to a fund that could be used for trivial bugs.

[deadwood]

My opinion is that standard project management approach, where you estimate time needed and translate to money works for bigger projects which are done via bounties - like porting Poseidon. The cost was estimated by developer, money was collected, work was done.

For paper cuts I think we should follow a simpler approach similar to @terminills is proposing:

1) Have a relatively large pool of "rather small" issues (> 100) so developers of different experience level can choose from
2) Have a fixed price per issue - yes, some issues will be harder, some easier, but keep the rules simple
3) A (theoretical) developer looks at issues, looks at price and decides if he is interested to make quick buck or not

[deadwood]

Well I'll start

I would suggest setting up 2 dates as to which the funds will be used maybe say in January and July.
Point of contact should be voted on at least once a year.
Point of contact IMHO should be one developer and one user.

Rules for papercut I would suggest at least 2 verification's that the bug is fixed.

Looks good, what I'd add is:
1) Contact people should decide on two topics: if issue is matching papercut criteria (is not too simple, not too hard, not designed to abuse the system)
2) Payout would be twice a year OR after reaching some threshold. If a developer fixes 10 issues in second week of January, he should not need to wait until 1st July to be paid out

[terminills]

Well I'll start

I would suggest setting up 2 dates as to which the funds will be used maybe say in January and July.
Point of contact should be voted on at least once a year.
Point of contact IMHO should be one developer and one user.

Rules for papercut I would suggest at least 2 verification's that the bug is fixed.

Looks good, what I'd add is:
1) Contact people should decide on two topics: if issue is matching papercut criteria (is not too simple, not too hard, not designed to abuse the system)
2) Payout would be twice a year OR after reaching some threshold. If a developer fixes 10 issues in second week of January, he should not need to wait until 1st July to be paid out

I would agree with that.