Project Planning & Tracking Software

[rootkovska]

Intro

NOTE This is not about replacing GitHub ticketing (issues) system!

We, and myself especially, need a powerful project planning and tracking software to be able to plan and track all sorts of projects going on at Qubes and at ITL in general. I'm talking beyond ticket-level project management.

The primary project I wish to track is called: "Invisible Things Lab", and this project has only two goals:

• be able to produce meaningful things,
• to continue to exist.

Now, within this top-level project ("ITL"), there is a number of high-level projects, such as:

• Qubes OS development (open source, community edition),
• Customer-sponsored features development, some/most of which might later go into the community Qubes OS (i.e. become deps for some future Qubes releases),
• Customer-specific training and support activities (Qubes pilot programs, on-site consulting, fixing bugs),
• Some non-Qubes-specifics projects, mostly commercial security research projects. Some of these might later benefit Qubes, i.e. become deps for future Qubes releases (e.g. once we gain know how with technology XYZ, we might want to introduce some XYZ-based feature to some Qubes release).

Of course, any of these high-level projects, might be further broken down to more specific ones, e.g. Qubes 4.0 release.

Because ITL needs to hire people in order to achieve its stated goals given above, and most people in order to survive in the present world need regular income, this, in turn, implies that, at least some of the activities (projects) must provide income to ITL. This implies the software needs to be able to track both income and expenses and perform some balancing.

Additionally, because most people needs income on a regular, periodic basis, this implies the software should keep track of calendar time and be able to put tasks into this context. Also, because people (often called "resources" by management software) have limited capacity of multi-tasking, it should be smart enough to understand who works on what at a given point in time and take this into account when coming up with (calendar-based) roadmaps.

I'd like to make it clear that we don't intend to turn ITL into a "factory" with per-hour work accounting, strict work-plans, time-sheets and other BS. This will never work out for the type of work we do at ITL. And even if it did work, I would be against it, because I don't believe that people should be treated like machines. This implies somehow less flexible approach to work-accounting and planning, which should be reflected in the software.

Some might wonder why introduce "ITL" as a meta-project? This is mostly to allow aggregated income/expense balancing. Also because of the shared resources, i.e. people who work for ITL.

Below I try to summarize what I wrote above, plus add a few more obvious requirements:

Requirements

1. Decompose projects into sub-projects, and further down
2. Balance incomes and expenses
3. Dependencies which can span multiple projects
4. Take declarative description of projects, tasks, deps, people's availability, various constrains, etc
5. Calendar-time and resource limitations aware
6. Ability to generate graphical reports (Gantt, etc)
7. Enough flexibility to be able to plan and manage beyond the silly hour-level timesheets.

Good to have

1. A native Linux application
2. Open source software
3. Text-based input files, batch processing
4. Easily integrated with git repos for easy cooperation (note how I didn't write: with GitHub.com!)
5. Integration with graphviz for visualizing of dependencies
6. Semi-automated ability to simulate various scenario of deviation from the plan (unexpected delays, people unavailability, etc)

No-requirements

1. Exact tracking of work hours, detailed per-hour, or per-day accounting
2. Being also a ticketing system (many ppl conflate ticketing system for a project planning and tracking)
3. Ability to send notifications

No-go's

1. Cloud-based
2. Proprietary data format-based (note: it might be ok to be a proprietary application)
3. Only OSX, iOS, or Android based (note: it might be ok to be Windows-based)

Expected outputs

Given some declarative description of N projects (their deps, estimated efforts, available resources, etc), I expect the software to produce at least the following:

• Calendar-based plan (schedule) of work (Gantt-like chart), taking deps and other constrains into account
• Balance expected incomes and expenses
• Create more high-level roadmaps like e.g. this one
• Generation of "who should do what next" report, e.g. a separate file for each person.
• Visualize progress vs. plan.

/CC @marmarek

Edited 2017-05-21 13:53 UTC: introduced numbers instead of bullets for reqs, etc, for easier referencing, also added calendar-aware req.

[rootkovska]

One software that seems to meet most (all?) of the requirements and "good to haves" seems to be the TaskJuggler.

Here's a short tutorial: http://taskjuggler.org/tj3/manual/index.html
And some examples: http://taskjuggler.org/tj3/examples/Tutorial/Overview.html

What I like

1. Text-based, batch processing mode
2. Apparently there is vim integration plugin! ;)
3. Seems v. powerful
4. Seems well suited to use via a shared git repo (which can be securely hosted Somewhere™)

Potential problems

1. Doesn't seem to allow for project aggregation? (see below)
2. The tree-like structure of the definition language might be too limiting?
3. Might encourage (and thus be optimized for) to use too-rigid management approaches?
4. Uses MediaWiki syntax (not that anything's work with this by itself, expect that we heavily happen to be using Markdown in lots of other places...)

Regarding problem #1: E.g. I'd like to be able for the "GUI domain" project to become a sub-project of "Qubes 4.1", which itself become a sub-project of "Qubes OS" project, itself a sub-project of "ITL". Instead, AFAIU, the project can only have tasks and this means that once something was declared as a "project", it would not be easy to convert it into a "task" of a higher-level project. At the same time, I don't think it'd be good to keep everything as "tasks", because the top-level "ITL" project?

Edited: added MediaWiki as a potential problem.

[rootkovska]

One software that seems to meet most (all?) of the requirements and "good to haves" seems to be the TaskJuggler.

Here's a short tutorial: http://taskjuggler.org/tj3/manual/index.html
And some examples: http://taskjuggler.org/tj3/examples/Tutorial/Overview.html

What I like

1. Text-based, batch processing mode
2. Apparently there is vim integration plugin! ;)
3. Seems v. powerful
4. Seems well suited to use via a shared git repo (which can be securely hosted Somewhere™)

Potential problems

1. Doesn't seem to allow for project aggregation? (see below)
2. The tree-like structure of the definition language might be too limiting?
3. Might encourage (and thus be optimized for) to use too-rigid management approaches?
4. Uses MediaWiki syntax (not that anything's work with this by itself, expect that we heavily happen to be using Markdown in lots of other places...)

Regarding problem #1: E.g. I'd like to be able for the "GUI domain" project to become a sub-project of "Qubes 4.1", which itself become a sub-project of "Qubes OS" project, itself a sub-project of "ITL". Instead, AFAIU, the project can only have tasks and this means that once something was declared as a "project", it would not be easy to convert it into a "task" of a higher-level project. At the same time, I don't think it'd be good to keep everything as "tasks", because the top-level "ITL" project?

Edited: added MediaWiki as a potential problem.

[andrewdavidwong]

Haven't looked into it deeply, but Planner might be another good option.

One great thing about both TaskJuggler and Planner is that they're already in the Fedora repos.

[andrewdavidwong]

Haven't looked into it deeply, but Planner might be another good option.

One great thing about both TaskJuggler and Planner is that they're already in the Fedora repos.

[rootkovska]

FWIW, I've started playing with TaskJuggler this week and I've been liking it so far. I will write more about its pros and cons later, but for now it seems like the way to go for us.

[rootkovska]

FWIW, I've started playing with TaskJuggler this week and I've been liking it so far. I will write more about its pros and cons later, but for now it seems like the way to go for us.

[Yethal]

I believe Odoo (formerly known as OpenERP) might be a good tool to look at.

• Open source
• Runs under any operating system
• Supports most of the features listed under Requirements
• Written in Python (in which most of ITL staff is already proficient in so customization will be easier)
• Modular architecture
• Good community support

[Yethal]

I believe Odoo (formerly known as OpenERP) might be a good tool to look at.

• Open source
• Runs under any operating system
• Supports most of the features listed under Requirements
• Written in Python (in which most of ITL staff is already proficient in so customization will be easier)
• Modular architecture
• Good community support

[marmarek]

@rootkovska do you consider this task resolved?

[marmarek]

@rootkovska do you consider this task resolved?