Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kanban Mutations list #73

Open
ivanminutillo opened this issue Sep 23, 2017 · 7 comments
Open

Kanban Mutations list #73

ivanminutillo opened this issue Sep 23, 2017 · 7 comments

Comments

@ivanminutillo
Copy link

👋 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

  • Create a new task inside a bin
  • Prioritize a task inside a bin
  • Edit bin
    • Edit name
    • Edit description
    • Edit due date
  • Edit task
    • Edit due
    • Edit description
    • Edit name
  • Join a task
  • Delete a task
  • Mark a task as finished
  • Log event on a task
  • Mark a process as complete

Is this list complete for the first release?

@fosterlynn
Copy link
Contributor

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
Copy link
Contributor

fosterlynn commented Sep 23, 2017

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Author

ivanminutillo commented Sep 23, 2017

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
Copy link
Contributor

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

looks nice 😄

@fosterlynn
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants