TaskAlot 3.0 - Functional specification

This is for the proof-of-concept. See also the examples above - Not everything is repeated here:

Tasks

Tasks are the basic elements of a project management system:

A task can be anything

Within Extreme Programming, a task seems to be something that takes up to a couple of days. S. said that tasks typically take less than a day. For me, it seems that a task can basically be anything: From a vague idea for a new project to something as small as put out the garbage tonight:

• I think it's important that I can create tasks without having to be specific or having to think whether the thing I want to create is a task or maybe something else. Often, tasks become more specific when they get a due date, but it doesn't have to
• Sometimes tasks can be specific and still take multiple days. Or are really simple and still take multiple days
• In Notion tasks can include checklists, textfields, etc. This makes it attractive to make tasks relatively large, and I like that flexibility.

A downside of this: It might not always be possible to link tasks to an agenda item. And that's fine.

Other aspects

• Tasks are usually associated with Projects. In that case, they should automatically also be associated with the corresponding Category
• It is possible that a task is associated with a Category, but not with a project - For example when I know already to what Category a task belongs, but not yet to what Project
• It is possible that a task isn't associated with a Category or Project at all - Again: When I just want to not forget something, but I didn't yet figure out where it belongs
• Tasks can belong to multiple Projects (and therefore to multiple Category-Project combinations) - That's quite important: When I'm not sure to which project a task should belong, I associate it with both, so it doesn't fall in between the cracks
• Multiple persons can be associated with a Task - This is important

Clustering tasks

• It seems natural to group or cluster tasks into collections, based on shared characteristics. That sounds academic, but it means e.g. all tasks for this week. Or all tasks for customer x, or all tasks for all customers, or all tasks delegated to person Y
• It seems that soon after clustering tasks, I have a need for having a hierarchy between such collections. Again, in order to have a view on a collection of items in a certain context
• Some ways of clustering are more-or-less static. Others seem to change with the weather
• It's important that tasks don't have to belong to any collection, or to multiple collections (like when I don't really know if it belongs to x or y, I tend to associate it with both, rather than risking that I loose the task)
• There is such a thing as a default clustering. That's what I call categories and projects below, eventhough they probably don't fit anyone's definition of category or project - I haven't found a better name of now.

Categories

It seems I have two or three levels (depending on how you look at it) of grouping or clustering tasks:

• Tasks usually live in projects
• Projects live in categories.

The reason for this clustering: To have tasks (or projects) grouped together with likewise things. These groupings are actually quite

• I currently have 7 categories, the first 5 of which are business-related and the other two are private: Revenue-X, Revenue, Overhead, BizDev, R&D, Private-X & Private
• Revenue-X is a specific customer for which I made a specific category
• These 7 categories are rather static. Maybe once per two years there is a change

Projects

• At any one moment, there are about 20 different projects
• I believe that Projects are always associated with Categories
• Projects get frequently split, merged and renamed

Project aliases

• Occasionally, I use what I dub project aliases. They are like alternative selections of tasks. I do this occasionally for subcontractors
• E.g.: If subcontractor Maciej is working on various projects, and I feel I lack overview, I might create an additional Project + Board Maciej. All his taks now belong to two Projects: His original Project + Maciej. I probably would copy this structure in my file system: There is now a folder Maciej under Projects and it probably contains a lot of links (rather than actual files)
• While writing this, I realise that in Notion, this might be easily achieved by only creating an additional View.

Boards

• Usually, there is a 1-to-1 correspondence between Projects and Boards, with multiple views per board
• For the proof-of-concept, have at least two boards (e.g. Board1 and Board2), each for a different project, similar to the screenshot of Trello above
• Have the ability to easily add boards myself
• Boards should have a view with a grouping according to Kanban state (I'm not sure that's formulated correctly). They should also have a view with a grouping according to Local state, etc.

Task Fields

An impresion of some fields. This is not complete and even their names can be changed:

===Kanban state=== (universal, optional, default is Backlog):

• I currently use Backlog, Next, Recurrent, Current, Done and Static
• Static is for static (non-task) information that I somehow want to incorporate on a board like a task
• I am not sure what the state would be of an unfinished task, when a project gets closed. Cancelled, Closed?

===Local state=== (non-universal, optional, no default, a better name might be welcome):

• A state that is only used on this very board
• You can see an example in the Trello board displayed earlier: Amongst other, it has lists for the various weeks in which tasks were delivered, like OK - Wk 12 and OK - Wk 36. At the end of a year, I usually go back to add the year (so the first would become OK - Wk 2022.12. This grouping is ad-hoc. There is for example no heading for a week in which there were no deliveries.

===Priority=== (universal, optional, default is Normal):

Priority means different things to different people. To me, it means stuff that I should do before doing non-stuff priority. Funnely enough, something that has priority at any one moment, doesn't automatically still has priority later on. Simple example: On Monday morning Putting garbage outside has priority. On Tuesday, this doesn't have priority anymore, even when I didn't do this task. But next Monday morning, it will again have priority.

• I currently use Normal, High & Low
• To be more precise: I currently use Normal priority, High priority & Low priority, so that in Board view, I understand what this field is about. Just High might not be enough information.

===Week entered=== (optional, default is current week number):

• For planning purposes, I usually think in weeks
• The number of the week in which the task was entered. I use that information to monitor how long a task has been open
• It probably also needs an associated year in which the task was entered.

===Week of delivery=== (universal, optional, no default):

• The number of the week in which I plan to finish the task. This is not the same as the deadline for the task
• The associated year should probably also be saved.

===Project=== (universal, optional, no default)

• A task can belong to multiple projects - Discussed before at Tasks
• All projects have unique names. So, knowing the name of a project, would be enough information to know to which Category it is associated

===Category=== (universal, optional, no default)

• A task can belong to multiple Categories - See above at Tasks for details.

Collaboration

• Sharing Board1 with person X and sharing Board2 with person Y
• Person X can't see person Y===s board and vice versa
• Person X and Y can edit content, but not change the setup of the board that they're on.

Overviews

There should be some overviews: Boards where tasks from various projects are brought together, like:

• All tasks from all Projects or all Categories
• All tasks with high priority
• All tasks that don't belong to me.

In order to be able to group tasks in overviews (where data from multiple boards come together), they need what I dubbed common, or universal fields. This is indicated with Universal in the list above at Task Fields. In practice, I suspect all fields will be universal, unless they clearly aren't (like Local state fields).

Contingency - Closing a project

• When a project is closed, the status of the corresponding tasks, should be automatically updated accordingly
• Example: Project Jamboree22 (a family gathering last July): When the party was over, the project could be closed. There were still a lot of open tasks (e.g., Check inflatable matrasses), but they all became irrelevant
• When a task is part of mutiple projects, their state should not be affected (e.g., Hang up shelves yellow room was part of project Jamboree22 but also of project Renovation22 and should therefore stay open)

See also

• TaskAlot 3.0 (Notion)
• TaskAlot 3.1 - Functional specification
• TaskAlot 3.1 - Technical specification