Accessing the Issue Tracker
In-Portal’s Issue Tracker can be accessed through your browser by going to http://tracker.in-portal.org
Note to Developers: Please make sure to record and manage all Bugs, new Features or miscellaneous Tasks using the Issue Tracker.
Before reporting bugs, please read the introduction on How to Report Bugs. All bug reports should include a clear “Reproduction Recipe” and other related information.
Recording Features & Miscellaneous Tasks
Features and Miscellaneous Tasks posted to the Issue Tracker should include final specifications and links to the corresponding discussion(s) in Google Groups.
In-Portal’s Issue Tracker is also used for storing Patches, as well as the history of Development and Commits (also known as “Changesets”) which are crucial to development phases and versioning.
Structure of Issue Tracker
Issue Tracker has a project-based structure where "In-Portal CMS" is the main project and all Open Source modules such as In-Link, In-News, In-Bulletin and Custom (Development Kit) are sub-projects. It is setup this way in order to maintain an organized structure and dependencies between In-Portal CMS and other modules.
Currently, the following is the structure of projects:
- In-Portal CMS
- Custom (Dev. Kit)
- In-Portal Infrastructure
“In-Portal Infrastructure” project is used by the Community to manage various administrative and community infrastructure-related tasks (websites, community projects, etc.)
Please make sure to submit all issues to the corresponding projects so that your fellow developers can spend more time on developing the code instead of cleaning up the Issue Tracker.
Statuses in Issue Tracker
While working with the Issue Tracker you will notice that some tasks are assigned to a user “!COMMUNITY!”. “!COMMUNITY!” is not an individual user but rather the In-Portal Community as a whole. Tasks assigned to this user can be “grabbed” by any member of the community
The following is the description of statuses used in the Issue Tracker:
Active – issue reported and can be assigned to a Developer;
Needs feedback – issue requires feedback/assistance and can be assigned to the !COMMUNTY! (where anyone is invited to reply or assist), the Reporter (member who reported the issue) or the Developer (member who wrote the patch);
Needs Work – the task requires work and can be assigned to the !COMMUNITY! (where anyone is invited to do the work) or the specific Developer (If, for example, they’ve worked on it before but it requires more work);
Needs Testing – the task requires testing and can be assigned to the !COMMUNITY! or any specific user, for example the patch Developer
Reviewed and Tested – the issue has been successfully tested and is waiting to be Committed into the Code Repository, or for consideration for the next release;
Resolved – the issue has been Committed into the Code Repository and has been "Fixed In Version #" (see below). If necessary, the issue can be Re-opened with a status "Needs work";
Closed – the issue has been archived and cannot be reopened. New issue should be opened instead;
Versions in Issue Tracker
Product Version – indicates the release version in which the issue was found (if a bug), or the last release version before it was added (if it's a feature).
Fixed In Version – indicates the release version in which it has been fixed (committed into the Code Repository). This can be any release: Beta or a Release Candidate.
Target Version – indicates the public release version in which this work (bug fix or feature) will be available to all community members.