Contributions are always welcome and many articles have been written on how contribution can happen. Following a brief selection:
Let's assume that you have found a bug in your ]project-open[ installation that you have fixed yourself. Or maybe you have added a new feature to ]project-open[ that your would like to share for future releases of ]project-open[. Now you would like to contribute this patch, so that it will be included in future releases.
Please create the patch using the following commands:
Then please go to our Source Forge Bug Tracker page and create a new [Bug Report] with all the necessary context of the problem ("bug") that your patch solves. Please add a description of the intended new behavior after the patch has been applied. Then please include your patch in the bug description, either in plain text (short patches) or via upload (longer patches).
By contributing the patch you agree that your code will become part of the ]project-open[ source code and will be issued under the same license as the original source code file.
Due to the long release cycle of ]project-open[ it may take several weeks or months before the ]project-open[ core team will decide on whether or not to include the patch in the next release. At that moment, the team will mark the patch as "closed" (if it has been included) or as "rejected" (if it hasn't been included in the product).
Please follow the formatting and code style of the original source code file for your patch. We (]project-open[ core team) use the Emacs "TCL-mode" formatting, plus tabs for SQL and HTML statements.
The ]project-open[ source code has been designed to be very "configurable" in order to serve diverse companies involved in many distinct industries. Our primary targets and most successful implementations so far have been consulting companies, translation agencies, advertising companies and internal IT departments. For this reason, the ]project-open[ code needs to honor and allow the specific configurations of each possibly diverse system. For example, there can be no English plain text in the code, instead you must conform the internal localization system so that ]project-open[ can be localized easily to all global languages. When deciding whether or not to accept a particular patch the ]project-open[ core team has several areas of concern, such as if the patch is suitable for different business sectors or solely targeted towards the interests of one industry and if all of these sectors will benefit from the inclusion of this patch into ]project-open[.
So please don't be disappointed if the ]project-open[ replies negatively because they have decided that your patch is too specific.
When fixing a bug, more then 50% of the time spent on correcting the error is spent attempting to "reproduce" the bug. "Reproducing" a bug means being able to see the exact issue on one of our development servers in order to understand the bug completely. The original bug reporter is indispensable and can help us save considerable time by including detailed instructions on where and how the bug was encountered allowing us to quickly "reproduce" the bug ourselves. Please follow these guidelines when posting a bug report .
We usually make sure that all critical bugs are fixed before we release a new version. Depending on the seriousness of your bug, it may take awhile to receive attention if it is minor and not critical.
Write a success story so that ]po[ gains more attraction.
If you use our software to satisfaction you can express that by giving us a donation