Improve "Projects" (kanban) #694

Open
opened 2 months ago by zander · 4 comments

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.
Poster

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.
rwa added the
enhancement
contribution welcome
gitea-related
labels 1 month ago

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)?
Poster

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.

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.
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Codeberg/Community#694
Loading…
There is no content yet.