Openbravo Design and Development Process/Contributions

Contributions

A Contribution is a development designed and developed by a team that is external to Openbravo's Engineering Team. This means it can be done by another Openbravo Team like Services, or by an external developer like an Openbravo Partner for which the corresponding partner agreement is in place.

If a feature is considered interesting to be included in the Product, then it goes through the Contribution Process.
A Feature is considered interesting when it is aligned with Openbravo's Product Roadmap or it is a feature that has been directly requested by an Openbravo's clients, and it is not implemented yet.

Product Managers are the ones to review this type of feature request and decide whether to include them in the product or not.

If it is decided to include them in the product, then the effort to review them and estimate the work to be done to include them in the product corresponds to an Engineering Team. The Engineering team will do this during the planning phase of a release, therefore it can be included in the most suitable release.

Following the Openbravo Development Process, the contribution starts in the Construction Process, Review Phase.

In this case, the review is a little bit different, as the design has to be validated also by the corresponding Engineering team.

In this case the review must focus on:

• Design
• Documentation
• Functional Review
• Code Review

In order to validate the design, both functional and technical design documents must be shared with the corresponding Engineering Team. Both are reviewed and if any of them is not accepted by the Enginnering Team, then it needs to be discussed with the developers who did the design.

At this point if the design needs to be changed and the development was already done, the impact, if any, must be measured:

• If it is acceptable then the design is changed and the external developer modifies the implementation of it.
• If it is not, the Contribution is stopped at this point.

This is why it is highly recommended to share the design documents as early as possible with the Engeneering Team, preferably before the development phase begins. This avoids additional overhead in the case of the design beign rejected.

After the design has been validated by Openbravo, the review process is executed as it is done for any other "internal" development.

Like before, there are some severe problems that are not tolerated. If a developer submits a development with any of this problems, it is immediately rejected until it is fixed:

• No automated tests
• Development makes the system unable to compile in any of the stacks supported by Openbravo
• Development does not fulfill functional specification
• Severe functional bugs
• Very poorly written code. Code must follow this coding style guide
• Very poorly written documentation
• Unacceptable performance with large volumes of data

Note: Large volumes of data are defined per development basis as it depends on the functionality that is going to be reviewed, and it is done based on volumes of existing clients. Acceptable performance is also defined as per development basis since also some functionalities tolerate more degradation than others.

When all the problems raised in the review are fixed, or discussed and discarded, the review phase is over and the development goes into the Launch Process of the Openbravo Development Life Cyle. At this point Openbravo is the responsible of support and maintenance of the development.

Collaborative Design

A Collaborative Design, as the name implies, is a Collaboration between an Engineering Team and a other internal team such as Services, or an external one like a Partner.

The Key difference between it and a Contribution is that the Engineering Team is involved earlier in the Construction Process.

Typically, if there is a feature request that is included in the Product Roadmap, but due to other commitments Openbravo is not going to develop it in the short to mid term, it is possible for an Openbravo partner to accelerate it by helping in the development process.

In this case, an agreement needs to be made between Openbravo and the Partner who collaborates.

In a Collaborative Design, only the Development phase is fully externalized. This means that the corresponding Team is also involved in both the design and the review.

A senior developer is assigned to analyze the functionality and then provides guidance to the external team on the design.

The external team creates the Design Documents (Functional and Technical) and shares them with the Engeneering Team to be validated. When the design is agreed, the development phase is started based on the created Design Documents.

After the development is done, the review is done again internally following the same standards as always and with the same restrictions. Like before, the development would not be accepted in the review phase if it has any of this problems:

• No automated tests
• Development makes the system unable to compile in any of the stacks supported by Openbravo
• Development does not fulfill functional specification
• Severe functional bugs
• Very poorly written code. Code must follow this coding style guide
• Very poorly written documentation
• Unacceptable performance with large volumes of data