search

django-rea / rea-app

Multi-platform UI application for OVN (Open Value Network) & REA (Resource / Event / Agent) backends- including Sensorica NRP, FreedomCoop OCP, GoPacifica DEEP & eventually django-rea project.
16 stars 6 forks source link

Kanban Mutations list #73

Open ivanminutillo opened 7 years ago

ivanminutillo commented 7 years ago

👋 Here an attempt to list all the mutations to perform on the kanban board for the first release.

REA Legend task === committment bin === process board === plan / work order

Mutations List

Is this list complete for the first release?

fosterlynn commented 7 years ago

I'd like to discuss prioritization, and part of that discussion I think is the general granularity of plan, process, task for FC, as the first users.

I think that for these first users (but not all users in the future) there will be many plans, mostly one process per plan, and mostly one task per process. Some will be more, but not a lot more, maybe up to 5 processes per plan, maybe 2 or 3 tasks per process. But mostly 1:1:1. (See the board put together by the testing group.)

So I think the card/bin interface for one plan is wonderful because it very well shows the value flow. But I don't think it will have a lot of value for these users for understanding the relationships between all their work in a project or group. This includes relative priorities.

So, I think that priority should go at the plan level. Within a process it is not that useful, and usually within a process, all tasks are needed to create the output goods or service. If there starts to be dependencies between tasks within a process, likely there should be more processes because that is the structure for those kinds of dependencies. At the plan level, there are not usually dependencies between plans based on resource flows, so at that level it can be useful for people to prioritize. (At least this is useful for people who won't get everything done that is planned. If you will do everything on the plan, the due dates are usually sufficient.)

Thoughts?

fosterlynn commented 7 years ago

Log event on a task

I think we also need to support update and delete of logged events on the first deliverable. That can be done by the person/user who created the event, or a superuser, if I recall correctly. (I need to write an authorization layer yet.)

fosterlynn commented 7 years ago

bin === process board === plan / work order

I don't think we can deliver just the plan board. There will also need to be something like the original page that shows all the plans for a project for them to get any kind of overview, given their data. (See discussion above on prioritization.)

So I'd like to use the language of "bin" and "board" and "card" to be generic UI elements that could represent any content.

The content could be "plan", "process", "task" to the extent that is actually shows up on a UI. Not sure about events.

fosterlynn commented 7 years ago

Edit task

  • Edit due
  • Edit description
  • Edit name

Also could edit type of work (resource classification), estimated/committed number of hours, planned start date. (Or are the last two part of "join a task"?)

Log event on a task

I think we want to also support logging an unplanned event, what do you think? Meaning a work event without a task, but within a process. It seems excessive to make them create a task if they already did something that wasn't planned. Possibly that could be a future deliverable, but I think it will be good to have the best user experience we can within the chosen scope.

Join a task

Just to clarify: It would possibly be nice if more than one person could explicitly join a task. But this is not possible in OCP data structure. So we will have something like one person committing to a task, and they might be considered the person responsible, even though others will work on it. After one person has committed to a task, in OCP, others can say they want to help, which notifies the person who has committed. And the person who has committed can ask for help, which notifies everyone with that skill (will need to change to notify just within the project). I'm not sure what we want to include in this deliverable....

ivanminutillo commented 7 years ago

Thoughts?

Agreed, I imagined prioritization also on the plan level, with this page: plans

Ok for me to avoid prioritization inside the plan 👍

I think we also need to support update and delete of logged events on the first deliverable. That can be done by the person/user who created the event, or a superuser, if I recall correctly. (I need to write an authorization layer yet.)

true

fosterlynn commented 7 years ago

Agreed, I imagined prioritization also on the plan level, with this page:

looks nice :smile:

fosterlynn commented 7 years ago

By the way, I agree with @ivanminutillo on not including planning in this first deliverable. That can be done in the work and admin apps for now.