31 lines
3.3 KiB
Markdown
Executable file
31 lines
3.3 KiB
Markdown
Executable file
Bugs and Issues
|
|
===============
|
|
|
|
* [Home](help)
|
|
|
|
|
|
If your server has a support page, you should report any bugs/issues you encounter there first. Reporting to your support page before reporting to the developers makes their job easier, as they don't have to deal with bug reports that might not have anything to do with them, and that helps us get new features faster.
|
|
|
|
If you're a technical user, or your site doesn't have a support page, you'll need to use the <a href = "http://bugs.friendica.com/">Bug Tracker</a>. Please perform a search to see if there's already an open bug that matches yours before submitting anything.
|
|
|
|
Try to provide as much information as you can about the bug, including the **full** text of any error messages or notices, and any steps required to replicate the problem in as much detail as possible. It's generally better to provide too much information than not enough.
|
|
|
|
<a href = "http://www.chiark.greenend.org.uk/~sgtatham/bugs.html">See this article</a> to learn more about submitting **good** bug reports.
|
|
|
|
|
|
**Bug Sponsorship**
|
|
|
|
If you find a bug, and it is caused by a problem in main branch (ie, is not specific to our site), you may sponsor it.
|
|
|
|
The bug/issue database allows you to sponsor issues. This provides an incentive for developers to work on your issue. This isn't necessary - we don't like bugs and will try to fix them. This has more importance for future development projects and feature requests.
|
|
|
|
Bug sponsorship works on the honour system. If you agree to pay $10 to fix a bug, when the fix has been checked in and verified you should send a paypal payment to the developer assigned to the bug. Don't ever think you can get away with not paying a developer for work performed. Some of these guys could hack into your credit card account if you make them mad.
|
|
|
|
At the present time, one has to be approved as a "developer" to be able to assign themselves to a sponsored bug. This requires the developer to have some history fixing Friendica bugs. This is for everybody's assurance that the bug fix will work well with Friendica. If you wish to become approved as a developer, work on and check in some non-sponsored issues or your own projects and we will move you up the ladder.
|
|
|
|
If you truly feel you have the solution to a sponsored bug but aren't an approved developer, you risk a sponsored developer assigning the bug to themselves before you check it in, but if they haven't done so - include a short note with your pull request. Assuming that it meets our code standards, we'll see that you get credit.
|
|
|
|
If you sponsor a project at greater than a $50 level, you may be requested by the developer for payment up front before work has begun (typically half). Again this is on the honour system - and is mostly to avoid payment issues and disagreements later. You should also expect to see some progress updates or demonstrations if the work takes more than a week or two. If the work is not completed within a reasonable time (as decided by those involved), you are entitled to get your money back.
|
|
|
|
Friendica is not involved in these transactions. It is purely a personal agreement between sponsors and developers. If there are any issues, the parties will need to work it out between themselves. We're just providing some guidelines to help avoid potential problems.
|
|
|