Improve "Projects" (kanban) #694

zander commented 2022年08月16日 12:03:51 +02:00

Yesterday I sat down and tried the 'project' concept which basically is a gateway to the kanban feature. (well hidden).

From a discoverability point of view, projects doesn't make much sense. I don't understand what the gitea people were thinking. It probably speaks much clearer to people if this 'projects' undergoes some renames and we provide some sane defaults.

• Rename 'projects' to 'boards'. Or "Kanban boards" if space permits.
• When there is exactly one project (or board) make the tab show the singular title. I suspect that for most people exactly one is good enough. Lets optimize for the majority.
• When this is enabled, create a default project and when clicking on the 'projects' tab, auto select this to hide that there is a hierarchy.
• Rename button "New Project Board" to "Add Column" (on a specific project page).
• Remove "Uncategorized" column.
• By default create a series of columns for a project. Initially I'd suggest "Backlog", "In Progress", "Done", "Cancelled" (backlog as the default column)
• Remove 'color' feature for a column, it doesn't work with website color-themes (and no kanban software does that, its a silly feature).
• Make moving an issue between columns actually alter the state of the issue.

Yesterday I sat down and tried the 'project' concept which basically is a gateway to the kanban feature. (well hidden). From a discoverability point of view, projects doesn't make much sense. I don't understand what the gitea people were thinking. It probably speaks much clearer to people if this 'projects' undergoes some renames and we provide some sane defaults. - [ ] Rename 'projects' to 'boards'. Or "Kanban boards" if space permits. - [ ] When there is exactly one project (or board) make the tab show the singular title. I suspect that for most people exactly one is good enough. Lets optimize for the majority. - [ ] When this is enabled, create a default project and when clicking on the 'projects' tab, auto select this to hide that there is a hierarchy. - [ ] Rename button "New Project Board" to "Add Column" (on a specific project page). - [ ] Remove "Uncategorized" column. - [ ] By default create a series of columns for a project. Initially I'd suggest "Backlog", "In Progress", "Done", "Cancelled" (backlog as the default column) - [ ] Remove 'color' feature for a column, it doesn't work with website color-themes (and no kanban software does that, its a silly feature). - [ ] Make moving an issue between columns actually alter the state of the issue.

zander commented 2022年08月16日 12:10:30 +02:00

As a background, I wrote my own kanban app (in Qt/QML) which me and various family members use with hundreds of issues each and lots of features.

So my point of view is from my way of working with kanban as a more rich version of issue-management (well, task-management is a better name).

Things like having default columns makes sense since you can then associate issue-states to them. "Open", "In Progress", "Done" and dragging issues between those columns is just a visual way to change the underlying issue data.
Extra columns are always possible, dragging them into that just doesn't change the status.

As a background, I wrote my own kanban app (in Qt/QML) which me and various family members use with hundreds of issues each and lots of features. So my point of view is from my way of working with kanban as a more rich version of issue-management (well, task-management is a better name). Things like having default columns makes sense since you can then associate issue-states to them. "Open", "In Progress", "Done" and dragging issues between those columns is just a visual way to change the underlying issue data. Extra columns are always possible, dragging them into that just doesn't change the status.

bmorel commented 2022年09月10日 22:18:40 +02:00

Extra columns are always possible, dragging them into that just doesn't change the status.

Would not a "rejected" column affect status, though (won't merge, etc)?

> Extra columns are always possible, dragging them into that just doesn't change the status. Would not a "rejected" column affect status, though (won't merge, etc)?

zander commented 2022年09月11日 11:42:34 +02:00

Would not a "rejected" column affect status, though (won't merge, etc)?

That makes sense.

The default columns "Backlog", "In Progress", "Done" & "Cancelled" do change status. Any extra columns not in this default list would have no change in status.

This is about issues, the status of issues can be maintained quickly and visually in this way, which is great. I am not aware of any way that the status of an issue can affect the status of a pull request. Only the other way around. So a cancelled column or status should be reasonably self-contained.

> Would not a "rejected" column affect status, though (won't merge, etc)? That makes sense. The default columns "Backlog", "In Progress", "Done" & "Cancelled" do change status. Any extra columns not in this default list would have no change in status. This is about issues, the status of issues can be maintained quickly and visually in this way, which is great. I am not aware of any way that the status of an issue can affect the status of a pull request. Only the other way around. So a cancelled column or status should be reasonably self-contained.

bmorel commented 2022年09月12日 01:29:23 +02:00

am not aware of any way that the status of an issue can affect the status of a pull request.

The same I'd say.
A PR might be just opened, means that nobody reviewed it. It can be rejected, for various reasons. It can be merged. It can be worked on.

> am not aware of any way that the status of an issue can affect the status of a pull request. The same I'd say. A PR might be just opened, means that nobody reviewed it. It can be rejected, for various reasons. It can be merged. It can be worked on.

fsologureng commented 2023年01月12日 21:00:17 +01:00

Despite the discussions opened in the references above, I think this proposition should be opened in an own issue in the User research repo, taking this one as their downstream issue.

Despite the discussions opened in the references above, I think this proposition should be opened in an own issue in the User research repo, taking this one as their downstream issue.

circlebuilder commented 2023年01月16日 09:03:03 +01:00

@fsologureng I created an issue at forgejo/user-research#13

@fsologureng I created an issue at https://codeberg.org/forgejo/user-research/issues/13

adrinux commented 2023年03月28日 15:39:43 +02:00

I'd add:

• Don't limit the height of the board columns

Having to scroll inside each column is annoying, can't see much more than 5 tasks at once even on a large monitor.

I'd add: - [ ] Don't limit the height of the board columns Having to scroll inside each column is annoying, can't see much more than 5 tasks at once even on a large monitor.