Contributions

Contributions are always welcome and many articles have been written on how contribution can happen. Following a brief selection:

Contributing Patches

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.

The Mechanics

Please create the patch using the following commands:

 

cd /packages/your_package/www/


cvs -z3 diff -u source_file.tcl > patch.diff


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).

 

Intellectual Property Rights

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.

 

The Decision Process

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 Original Formatting

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.

 

Generic vs. Specific Patches

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.


Bug Reports

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 .  

  1. Provide a descriptive name for the bug.  "Expense menu tab links to wrong page" is preferred over "Menu tab is broken".
  2. Provide the URL of the page where the error occurs.  "http://www.myposerver/intranet-core/expenses?view=all"
  3. What are the steps to reproduce the bug? Does the bug only appear under specific circumstances?  How did you originally encounter the bug?
  4. Please try to reproduce the bug on our demo server. This helps us to determine if the bug is specific to your installation or global, or possibly already solved by an upgrade.
  5. If the bug can be reproduced on the demo server, please open a ticket at sourceforge.net . If possible, please provide screen shots and -if applicable- sample files.  It is a great idea to create the screen shots using MS-PowerPoint or OpenOffice "Impress", because you can add comments.
  6. Please tell us the version of ]project-open[ you are currently running on. Usually we are interested in the version number of the "intranet-core" package in the Package Manager (http://[YOUR_SERVER]/acs-admin/apm/). If the issue is related to an installer, please tell us the version number of your operating system and the installer you used.
  7. If you want us to fix this issue for you we would need SSH access to your server if the bug is related to your specific installation.  This information includes your IP address, username (root) and the password.

 

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.

Users with a ]project-open[ service contact please log on www.project-open.org  and go to http://www.project-open.org/intranet-helpdesk/  to create a new "Bug Request" ticket.

Success Story

Write a success story so that ]po[ gains more attraction.  

Donations

If you use our software to satisfaction you can express that by giving us a donation


  Contact Us
  Project Open Business Solutions S.L.

Calle Aprestadora 19, 12o-2a

08902 Hospitalet de Llobregat (Barcelona)

Spain

 Tel Europe: +34 609 953 751
 Tel US: +1 415 200 2465
 Mail: info@project-open.com