Register as a Contributor

Before you move on please make sure you already joined the In-Portal Community and selected to be a "Contributor" under Community Preferences.

Also, please make sure to join the In-Portal Development Team that is responsible for R&D (Research & Development). Please note that if you want to participate in any type of development (PHP programming, Themes design, Translating, etc), but not sure where to start - feel free to ask in the In-Portal Community Group and we'll be glad to help you pick the area of interest and guide you through the process.

Introduction to In-Portal’s Research & Development

We have prepared the following guide to help you get yourself familiarized with the In-Portal’s development process:

1. Code Repository
2. Developers Guide
3. Discussions & Communications
4. Issue Tracker
5. Releases Life-Cycle
6. Development Process
7. Patching
8. Environment Setup

Code Repository

In-Portal uses Subversion (SVN) as its version control system. If you are not familiar with SVN or would like to learn more about In-Portal’s code repository and how it is structured, along with the process of checking out and committing the code, please refer to the Code Repository page.

It is recommended to learn about In-Portal’s Code Repository before attempting to work with the code.

Developers Guide

Before starting any work on In-Portal (or throughout the process of your project) you can use the Developers Guide as your reference.

Developers Guide is documentation for programmers or developers who are interested in working with In-Portal’s code. Developers Guide is located at http://guide.in-portal.org and is powered by Wiki, making it easy for all members of the Community to keep it updated. If you are interested in contributing to this process, please check out our guide into Writing Documentation.

Discussions & Communications

All development-related discussions and communications should take place in the Development Team’s Google Group (or corresponding groups for other teams). Please try to keep all discussions public for everyone to participate and express their opinions. As an open source project, In-Portal relies on participation from its Community members and open public discussions allow all members to participate.

Currently there are eight In-Portal Teams, each having its area of functional expertise and contributing to certain aspects of In-Portal’s system or Community.

You may want to consider joining the team of most interest to you, but In-Portal Development and In-Portal Bugs are the two teams that you should definitely join if you wish to participate in the development process or simply want to follow some of the development-related discussions.

Remember, it is also perfectly okay to ask for help or ask questions in any groups if you are lost or need some assistance.

Issue Tracker

In-Portal Issue Tracker is the central task/issue management tool for all types of tasks/bugs or issues across the In-Portal Project. Issue Tracker is located at http://jira.in-portal.org/. In-Portal uses Mantis as the issue tracking engine.

Please refer to our Issue Tracker page for more information about In-Portal’s Issue Tracker and how to use it properly to report bugs, store patches, etc.

Releases Life-Cycle

Before engaging in any kind of code development, it is crucial to understand the In-Portal Development Cycle (or Releases Life-Cycle). We have summarized all life-cycle phases in the "In-Portal Development Wheel" below:

Please make sure to familiarize yourself with the entire process and all Phases:

Alpha Phase

The goal of the Alpha Phase is to set Goals and achieve them by performing Development work. The work flows in the following order:

1. Work begins with planning and setting of goals which require the Community’s Input. This is when we decide what to do and how to do it;
2. Once we decide on a plan of action, all tasks (features and bug-fixes) are tracked and documented using Issue Tracker;
3. The actual development work (coding) starts once the Development Team agrees with and confirms the goals. This continues until the work is completed;
4. Once completed, all code is prepared for the Beta Phase release.

What takes place during Alpha Phase?

• Features Planning & Review
• Coding / Programming Work
• Usability & User Interfaces Development
• Themes Design
• Performance Review
• Localization (i.e. translating interfaces, etc.)
• Documentation (documenting new features)
• Bug-fixes (ongoing)

Alpha Phase Timing

Usually Alpha phase is the longest of the phases with no specific timelines until final goals are set. For that reason, planning can start long before the actual development and may take months (depending on the scale and complexity of planned work).

Beta Phase

The goal of the Beta Phase is to Test, Document and Fix Issues after the Community Input. It usually flows in the following order:

1. Beta release is prepared and released to the Community to be tested and scrutinized;
2. Community members test all aspects, including thorough internal and external testing of all of the affected components;
3. Documentation Teams document new features and code changes (in the Developers Guide and User Manual);
4. Feedback and suggestions is collected from the Community.

What takes place during Beta Phase?

• Bug-fixes
• Performance Optimization (addressing performance issues)
• Usability & Accessibility Review (addressing usability issues)
• User Interfaces Review (addressing interface issues)
• Themes & Design Review (addressing design issues)
• Localization Review (addressing translation issues)
• Documentation (addressing missing/incorrect documentation issues)

Beta Phase Timing

Multiple Beta releases (Beta1, Beta2, etc.) can be released before all major known issues are resolved. This process generally can take up to several weeks before the process moves into the Stable phase.

Stable Phase

The goal of the Stable Phase is to prepare a general release for the public (free from any known issues or errors). It generally flows in the following order:

1. Generate the Release Candidate;
2. Thoroughly test all aspects of the software, including testing open to all Community members
3. Documentation Teams document new features and code changes (in the Developers Guide and User Manual);
4. Feedback and suggestions is collected from the Community.

What takes place during Stable Phase?

Critical Bug-fixes
Critical Performance Issues

Stable Phase Timing

Multiple Release Candidates (RC1, RC2...) are released until it is assumed that the version released is stable and is free of known issues or errors. At that point the last Release Candidate becomes the official In-Portal Release.

Versioning & Phases Flow Process

The diagram below explains the In-Portal’s versioning scheme with respect to the abovementioned phrases.

It is important to note that the In-Portal Development Tree and the Code Repository were setup to support two (2) simultaneous development lines (branches).

How is this helpful to developers?

Developers can choose whether they want to participate in development of latest cutting-edge features or working on the latest release candidate ensuring it is 100% bug free.

How is this helpful to the Community?

Community members can choose whether they want to deploy a more stable (more tested) version or to take part in testing and improving upon the latest version with more/latest features.

Development Process

All Development Work (coding/programming/design), no matter whether it is a new feature or a bug-fix, ALWAYS goes through the following steps:

DISCUSS => REPORT => PATCH => TEST => COMMIT

DISCUSS

All work starts with a discussion process in Teams (Google Groups) depending on the area of interest: Features should be discussed with members of the Development Team; Bugs should be reported and discussed with members of In-Portal Bugs Team, etc.

REPORT

The next step is to properly report the bug / post feature, once there is a clear understanding of the task at hand. It is a tradition that the same individual who started the discussion also submits the bug report (if it's a bug). Please read more about how to properly submit bugs.

PATCH

This step consists of the actual development work resulting in a Patch (that should be attached to the issue in the Issue Tracker). Once the patch is uploaded, the developer should change the issue’s status to "Needs Testing" and assign it to the “!COMMUNITY” user in the Issue Tracker.

TEST

Once the patch is available; it can now be tested by other members of the Community. The following are the things to keep in mind when testing:

1. Always test patch against the correct version (keep in mind the software version in the task);
2. If testing is successful – change the task’ status to "Reviewed and Tested" and assign it back to the “!COMMUNITY!” user;
3. If testing fails – change the status to "Needs Work" and assign it back to the user who's patch was tested;
4. If there are questions that prevent you from testing – change the task’s status to "Needs Feedback" and assign to the user you want the feedback from.

COMMIT
Once the patch has been successfully tested and has a "Reviewed and Tested" status, it can be committed into the Target version (or planned for a future release). The commit will be performed by developers with Commit privileges. These users are appointed by the Community.

Patching

Patches should be applied using the Linux "patch" command or using an "Apply/Create Patch" capable SVN client. We strongly recommend using "Tortoise SVN". Make sure your .patch or .diff files are compatible or please include specific instructions on how to apply your changes. Please always specify the release version you are patching.

Unified diffs are preferred. Please follow the following naming convention for naming your patches:

${Issue#}-${IssueShortName}-${patchAuthor}-${YYYY_MM_DD}-v${patchVersion}.patch
 

For example: 211-default_null_for_date_fields-Alex-2009_10_04-v1.patch

Patches should always be attached to corresponding tasks in the In-Portal Issue Tracker.

Please refer to this “Create and Apply patches using Tortoise SVN” for additional information on how to properly use Tortoise SVN for patching.

Environment Setup

In order to program with In-Portal you may want to set up the following native environment:

Install and setup Apache + PHP + MySQL

• Zend Server CE (Community Edition) - http://www.zend.com/en/products/server-ce/
• OR LAMP - http://en.wikipedia.org/wiki/LAMP

(software_bundle)

• OR WAMP Server (for Windows) - http://www.wampserver.com
• OR
  - Apache
  - PHP
  - MySQL

Step-by-step installation and setup process for PHP (if done by hand): PHP.net http://php.net/manual/en/install.php

Install phpMyAdmin

You will need phpMyAdmin in order to manage your database structure. You can download it from here: http://www.phpmyadmin.net

Note that phpMyAdmin is already supplied with Zend Server by default.