Project CX is my personal project management/issue tracker. I was not fully satisfied with existing management and tracking tools and decided to create my own that would focus on efficiency and a clean, organized layout.

Project CX is a Django web application. As such, it requires Django 1.9 or higher and follows the standard Django app installation:

Project CX utilizes the built-in Django authentication models and the built-in /admin pages to manage the database objects. Project CX is a multi-user application, with users defined via the django.contrib.auth.models.User module. If you have users created via the built-in User model, Project CX will integrate seamlessly with those and the login credentials will be identical. If not, you must use the built-in /admin pages of the Django server to add users to Project CX.

Once you have a user created, you can enter the username and password on the login page. Once you have successfully logged in, you will be taken to the Projects page.

To log out, simply click the Logout button in the upper-right corner of the screen.

The navigation bar on the left side of the screen provides a few links:

Objectives are the main unit of work within Project CX. Each objective is a single task, feature, or bug to be addressed. This page displays every objective assigned to you across all projects. The table is sortable by any of the columns by clicking the header of a column. Clicking on an objective takes you to that objective's page.

This screen merely exists so that you can view the users who are available in Project CX.

As mentioned in the Installation & Setup, users are derived from the built-in Django django.contrib.auth.models.User module. If you have users created via the built-in User model, Project CX will integrate seamlessly with those and the login credentials will be identical. If not, you must use the built-in /admin pages of the Django server to add users to Project CX.

The Projects page provides a list of all the projects stored in Project CX. Each card contains some general information about the project. Following from right to left across the card header is the following information:

Clicking on the project name will take you to that project's Objectives page.

Project CX utilizes the LiveEdit framework, which provides quick, atomic transactions that save your data incrementally rather than waiting to process an entire form of data at once. As such, while Project CX has buttons marked as "Save", the data entered is saved as soon as you finish entring it.

To create a project, go to the Projects page and click the New Project button at the top of the screen. This will create a blank project and take you to the Project Info screen, where you can edit the prefix, project name, and description. The page also contains a full history of every action taken within the project. Upon creation, the only item in the history will be the creation of the project.

Once you have created or entered a project, the left navigation bar will have some extra links added to it. These links in order are:

There are three cards on this screen, each displaying the recent actiosn taken within the project.

Project CX has two ways that a project is identified as a completed unit: Builds and Releases. A release is a finalized version of the deliverable that will be delivered to a customer. Typically releases are identified by a version number of some sort (i.e. v1.2.6). A build should be created any time a set of objectives is ready for testing/QA. A build is not a final product, but a prototype or release candidate that must be verified by quality control.

Each release can have several builds associated with it, and they are listed below the release name. This list can be sorted by clicking the column headers. Builds that are not associated with a particular release are listed under the Other Builds section at the bottom of the Releases page.

Click the New Release button at the top of the screen to create a new release. Click on the name of a relases to edit it. This is will take you to the release page, where you can edit the name, date, and description of the release. The full history of changes made to the relase also appears on this screen.

Click the New Build button at the top of the screen to create a new build. Click on the row of a build to edit it. This will take you to the build page, where you can edit the name, date, decsription, and the release the build belongs to. The full history of changes made to the build also appears on this screen.

Objectives are the main unit of work within Project CX. Each objective is a single task, feature, or bug to be addressed. The Features, Issues & Bugs, and All Objectives pages all display objectives. This table of objectives can be sorted by clicking the column headers.

Assigning a Type to an objective identifies what the origin and expectation of the objective is.

Assigning a status to an objective identifies the current state and if needs further action to complete.

Once an objective has been discussed and there is an action plan, the Assigned To field should be changed to indicate who is responsible for the next action on the objective. This will also cause the objectibve to populate on that user's My Objectives screen.

It is good practice to use the Identified In and Resolved In fields to idicate which release the objective was created from, and which release the objective was completed in.

Notes are an important part of managing an objective. Any questions, concerns, or special actions that are needed for theobjective should be included as a Note on the objective. Notes are kept in chronological order, so any changes to the objective are recorded in some way. Example: A feature called "XML File Import" provides a rundown of the format the files being imported. However, it is discovered during development that the format provoided does not work. A user can add a Note to the objective about it. This way everyone viewing the objective knows when, why, and how the object has changed.