AROS World Exec
Development => Development (General) => Topic started by: terminills on July 01, 2022, 08:46:20 AM
-
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. :)
-
I should accept multiple contacts
-
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.
-
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)
-
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
-
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?
-
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.
-
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.
-
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.
-
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.
-
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 ;)
-
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.
-
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
-
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
-
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.
-
I second that
-
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. :)
It's also worth noting that fees will be deducted due to paypal's policy of charging merchant fees even for donations.
https://www.paypal.com/us/webapps/mpp/merchant-fees#ReceivingDonations
USD a $5 donation has a .49 + 2.89% so that's about $0.64 eaten from a $5 donation.
-
... I think we'd have to cover that, or half the fee at least, can't short change anyone
-
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. :)
Spoke to André and he suggested having the fund allow one time payments due to the fact that you have the ability to make a larger one time payment and less gets eaten by fees.
Example in USD based off of paypal's website
$60 single Donation after fees would be around 57.776
but 6, $10 donations after fees would be 52.21.
-
Hmm, arent' there two fees?
I fee that gets extracted when donor pays to power2people. The second few when power2people pays out to developer?
-
Hmm, arent' there two fees?
I fee that gets extracted when donor pays to power2people. The second few when power2people pays out to developer?
Yes plus Paypal has a split fee schedule. Percentage plus transaction. In the US it's 2.89% +.49 per transaction. the .49 doesn't seem like much until you add it across 100's of transactions.
-
Okay so here's where we sit.
- 2 Community members control the verification and payout system(mainly because we've had issues in the past of users not verifying bounties).
Payout is twice a year or 10 fixes whichever comes first(Developer has the option of waiting). - Donations can be either one time or subscription with preference to single larger donations due to fees but all are appreciated.
- Yearly nominations of the 2 community members(Assume nominate in December vote in January?). Initial vote should be within the next month.
- Papercut/trivial tag needs to be in the issue/bug tracker.
- Outreach, we need to reach outside of the Amiga/AROS community(maybe create a informational page?).
-
Looks good. But obviously needs approval from those higher than me.
I would like to see permanent banners at the top of all aros related website's/forums advertising the paper cut initiative.
-
Looks good. But obviously needs approval from those higher than me.
I would like to see permanent banners at the top of all aros related website's/forums advertising the paper cut initiative.
There isn't really a higher up. It's supposed to be community driven.
-
There'll be a few more responses when everyone's back from the Sunday visits no doubt.
-
There'll be a few more responses when everyone's back from the Sunday visits no doubt.
I know I'm just trying to keep it on the front page.
-
Any further comments ideas or suggestions from anyone?
-
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
This approach sounds very interesting and it would benefit AROS. That is very positive.
-
Okay so here's where we sit.
- 2 Community members control the verification and payout system(mainly because we've had issues in the past of users not verifying bounties).
Payout is twice a year or 10 fixes whichever comes first(Developer has the option of waiting). - Donations can be either one time or subscription with preference to single larger donations due to fees but all are appreciated.
- Yearly nominations of the 2 community members(Assume nominate in December vote in January?). Initial vote should be within the next month.
- Papercut/trivial tag needs to be in the issue/bug tracker.
- Outreach, we need to reach outside of the Amiga/AROS community(maybe create a informational page?).
Thank you for the efforts on this! I appreciate it.
-
Okay so here's where we sit.
- 2 Community members control the verification and payout system(mainly because we've had issues in the past of users not verifying bounties).
Payout is twice a year or 10 fixes whichever comes first(Developer has the option of waiting). - Donations can be either one time or subscription with preference to single larger donations due to fees but all are appreciated.
- Yearly nominations of the 2 community members(Assume nominate in December vote in January?). Initial vote should be within the next month.
- Papercut/trivial tag needs to be in the issue/bug tracker.
- Outreach, we need to reach outside of the Amiga/AROS community(maybe create a informational page?).
[/quote
I agree thank you :)
-
Okay so here's where we sit.
- 2 Community members control the verification and payout system(mainly because we've had issues in the past of users not verifying bounties).
Payout is twice a year or 10 fixes whichever comes first(Developer has the option of waiting). - Donations can be either one time or subscription with preference to single larger donations due to fees but all are appreciated.
- Yearly nominations of the 2 community members(Assume nominate in December vote in January?). Initial vote should be within the next month.
- Papercut/trivial tag needs to be in the issue/bug tracker.
- Outreach, we need to reach outside of the Amiga/AROS community(maybe create a informational page?).
Thank you for the efforts on this! I appreciate it.
When FinalWriter is officially launched I will be donating part of the proceeds to the papercuts fund, Maybe we can get it large enough to gain some attention. :)
-
Thanks a great initiative :D
-
We cannot start a campaign for Odyssey :-\
-
I would like a odyssey fund as well. Updating odyssey is my primary goal, but I'm also keen to support paper cuts as well :)
-
I would like a odyssey fund as well. Updating odyssey is my primary goal, but I'm also keen to support paper cuts as well :)
the problem with webbrowser updating... it is a never ending story
whereas fixing small problems/bugs is hopefully finished sometime
-
The thing is not so drastic, we are using a version of Odyssey in 2016 and you can still access many sites, I discussed this thing with Asigel Webkit maintains a certain compatibility even after years
-
The thing is not so drastic, we are using a version of Odyssey in 2016 and you can still access many sites, I discussed this thing with Asigel Webkit maintains a certain compatibility even after years
Updating a browser is a large task. It could quickly become a full time job. >:(
-
I repeat myself as I wrote above then surely after years some service will stop working but will pass the years
-
I have been using Odyssey and Aros with profit as the main station for years and I don't use anything about the mainstream and I have still found many useful and accessible services
-
We cannot start a campaign for Odyssey :-\
You can but typically what I did in the past was I found a developer and had them help me write up the bounty. Also it wouldn't be a papercut as it's a large endeavor.
-
ok I understand ;)
-
The thing is not so drastic, we are using a version of Odyssey in 2016
Mid-2015.
Javascript works pretty well. On the other hand, some of the page rendering is inexplicably worse than with Odyssey on MorphOS despite the newer engine.
and you can still access many sites, I discussed this thing with Asigel Webkit maintains a certain compatibility even after years
Back in 2020, I said this: "In my opinion, the Webkit currently used by Odyssey on AROS is not that bad."
At that time, the browser engine was 5 years old. Now we are at 7 years.
I still would not refer to the browser engine as "bad" but, unlike wine, it also does not get better with age. After roughly 5 years, it is usually a good idea to think about upgrading your browser engine in order to maintain compatibility with mainstream online services if that is your goal.
Of course, if AXRuntime continues to evolve into Linux-based "AROS" distributions, then porting browsers might become a moot point depending on what you see as the future direction of AROS (native vs hosted, etc).
Anyway, I do not mean to derail the Papercuts discussion.
-
I thought the current version of Odyssey could be correct by adding any corrections to the list
regards
-
I thought the current version of Odyssey could be correct by adding any corrections to the list
regards
You seem not to have any clue how fast webbrowsers change. There is not much left propably that not has to be changed now.
-
I thought the current version of Odyssey could be correct by adding any corrections to the list
regards
You seem not to have any clue how fast webbrowsers change. There is not much left propably that not has to be changed now.
My personal opinion is the engine should be decoupled from the GUI and built as a library to allow for easier upgrades. But don't quote me on that I'm not a developer. :D
-
I thought the current version of Odyssey could be correct by adding any corrections to the list
regards
You seem not to have any clue how fast webbrowsers change. There is not much left propably that not has to be changed now.
As far as I understand you don't know what it means to use to use aros every day
-
My personal opinion is the engine should be decoupled from the GUI and built as a library to allow for easier upgrades. But don't quote me on that I'm not a developer. :D
If you take a look at the Odyssey code base, the actual GUI part is really quite tiny compared to everything else.
Anybody who manages to get to the point of running Webkit in "minibrowser" mode with a dumb window output on AROS should find it relatively trivial to add a basic native user interface.
Besides, it does not necessarily make the updates easier because regularly rewriting your "abstraction layer", which would sit between your GUI and Webkit, would not always take less time compared to just adapting your GUI code that might directly call certain Webkit functions otherwise.
The real problem is that Webkit is a giant project that is constantly changing and its developers do break things quite frequently. There is no easy solution. It simply takes effort to deal with that. There are no shortcuts - except for using the work that somebody else is already doing maybe...
-
Okay so here's where we sit.
- 2 Community members control the verification and payout system(mainly because we've had issues in the past of users not verifying bounties).
Payout is twice a year or 10 fixes whichever comes first(Developer has the option of waiting). - Donations can be either one time or subscription with preference to single larger donations due to fees but all are appreciated.
- Yearly nominations of the 2 community members(Assume nominate in December vote in January?). Initial vote should be within the next month.
- Papercut/trivial tag needs to be in the issue/bug tracker.
- Outreach, we need to reach outside of the Amiga/AROS community(maybe create a informational page?).
Thank you for the efforts on this! I appreciate it.
When FinalWriter is officially launched I will be donating part of the proceeds to the papercuts fund, Maybe we can get it large enough to gain some attention. :)
So how do we setup a vote?
-
Should we start nominations on this thread?
Clearly it needs someone with knowledge and understanding of AROS so I'm out. I'm just a donator.
So, for someone who appears to have good motivation to getting this going - terminills, would you accept my nomination for you?
As for a second, I would think magorium would keep everyone grounded, if he's willing?
-
Should we start nominations on this thread?
Clearly it needs someone with knowledge and understanding of AROS so I'm out. I'm just a donator.
So, for someone who appears to have good motivation to getting this going - terminills, would you accept my nomination for you?
As for a second, I would think magorium would keep everyone grounded, if he's willing?
Probably not I feel my time is better spent elsewhere. But we'll see.