[New Feature] Sub Tasks #62

lmtr0 commented 2026年01月26日 13:36:16 +01:00

Warning

Please read this section of the README before interacting in the issue tracker.
We might remove comments that don't fit here. This is unfortunately necessary, because respect for design work is not yet common in Free/Libre Software projects.

Content

Basic

Hello there, everyone.

Over the past few weeks (I think it's been a month already), I've been trying to implement the sub-tasks feature into Forgejo. My overall goal is to make Forgejo compatible with the Agile Scrum Architecture. My company and I want to move our operations to Forgejo completely, and this will be an essential feature.

The community has discussed adding subtasks in 2 distinct ways: the GitHub route and the GitLab route. I favor the GitHub route (as it's less work and more intuitive in my opinion), but I would like to gather feedback on what other people want in this implementation. In summary, GitLab has a different structure altogether for tasks (tasks != issues), and GitHub creates issues and references them as subtasks.

Previous Discussions: forgejo/forgejo#5448 forgejo/forgejo#6267

Possible references: https://docs.gitlab.com/user/tasks/ https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/adding-sub-issues https://github.com/GraphiteEditor/Graphite/issues/2535

Deliverables:

• PR Backend: Just server changes
• PR Frontend: Just client-specific changes

Design decisions (Following the github style)

Issues can have subissues linked to them, UI will also show 5 subissues from the top subissues:
image

To prevent high server load, the server will only load a maximum of SUBISSUES_LOAD (configurable, defaults to 15) subissues per page will have pagination to navigate through the pages.

Handy new subissue button to create subissues
image

Help is wanted, please share your perspective for us to make a better product together

Demo video:

https://codeberg.org/attachments/5a9b5d2d-4dad-4b65-9285-5b9d1c301761

Credits

This was based on the initial work of @xtex in forgejo/forgejo#6267 and a suggestion of @yonas in forgejo/forgejo#5448

> **Warning** > Please read [this section of the README](https://codeberg.org/forgejo/design#what-you-can-do-here) before interacting in the issue tracker. > We might remove comments that don't fit here. This is unfortunately necessary, because respect for design work is not yet common in Free/Libre Software projects. ### Content ## Basic Hello there, everyone. Over the past few weeks (I think it's been a month already), I've been trying to implement the sub-tasks feature into Forgejo. My overall goal is to make Forgejo compatible with the Agile Scrum Architecture. My company and I want to move our operations to Forgejo completely, and this will be an essential feature. The community has discussed adding subtasks in 2 distinct ways: [the GitHub route](https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/adding-sub-issues) and [the GitLab route.](https://docs.gitlab.com/user/tasks/) I favor the GitHub route (as it's less work and more intuitive in my opinion), but I would like to gather feedback on what other people want in this implementation. In summary, GitLab has a different structure altogether for tasks (tasks != issues), and GitHub creates issues and references them as subtasks. Previous Discussions: https://codeberg.org/forgejo/forgejo/issues/5448 https://codeberg.org/forgejo/forgejo/pulls/6267 Possible references: https://docs.gitlab.com/user/tasks/ https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/adding-sub-issues https://github.com/GraphiteEditor/Graphite/issues/2535 Deliverables: - PR Backend: Just server changes - PR Frontend: Just client-specific changes ## Design decisions (Following the github style) Issues can have subissues linked to them, UI will also show 5 subissues from the top subissues:  To prevent high server load, the server will only load a maximum of SUBISSUES_LOAD (configurable, defaults to 15) subissues per page will have pagination to navigate through the pages. Handy new subissue button to create subissues  Help is wanted, please share your perspective for us to make a better product together ## Demo video: https://codeberg.org/attachments/5a9b5d2d-4dad-4b65-9285-5b9d1c301761 ## Credits This was based on the initial work of @xtex in https://codeberg.org/forgejo/forgejo/pulls/6267 and a suggestion of @yonas in https://codeberg.org/forgejo/forgejo/issues/5448

lmtr0 commented 2026年01月28日 01:38:48 +01:00

Feedback is needed here!

Feedback is needed here!

limiting-factor commented 2026年01月28日 15:08:22 +01:00

Can you explain how you plan to design the backend part?

Can you explain how you plan to design the backend part?

lenikadali commented 2026年01月28日 21:59:37 +01:00

I am a bit torn myself. I like GitLab's approach because of how holistic it is in terms of project management but I see your point about GitHub's approach being simpler.

So my feedback would be (from a design perspective), what problem are we trying to solve for here? If it is just defining sub-tasks of an issue, I would say in the current UI screen you have attached, I would change the colour to be more like GitHub's which is a green dot surrounded by a green circle so that it looks cleaner. Also is the GitHub based implementation going to allow tasks to become issues underneath i.e. they will share the same base but have some different fields that distinguish tasks from issues at model level?

After writing the above out, I would probably encourage moving towards the GitLab style because I've seen that there's a steady drip of people looking for Forgejo's project management features to fully built out (related issues here and pull requests here) Of course take the issues with a grain of salt because some of them may just have something to do with the word "project" in them. That being said, the PRs seem to indicate a desire for something in between basic and complex.

Also, I would link to this comment as having some overall good advice about how to go about this but more as an FYI :)

I am a bit torn myself. I like GitLab's approach because of how holistic it is in terms of project management but I see your point about GitHub's approach being simpler. So my feedback would be (from a design perspective), what problem are we trying to solve for here? If it is just defining sub-tasks of an issue, I would say in the current UI screen you have attached, I would change the colour to be more like GitHub's which is a green dot surrounded by a green circle so that it looks cleaner. Also is the GitHub based implementation going to allow tasks to become issues underneath i.e. they will share the same base but have some different fields that distinguish tasks from issues at model level? After writing the above out, I would probably encourage moving towards the GitLab style because I've seen that there's a steady drip of people looking for Forgejo's project management features to fully built out (related issues [here](https://codeberg.org/forgejo/forgejo/issues?state=open&type=all&labels=&milestone=0&project=0&assignee=0&poster=0&sort=relevance&q=project) and pull requests [here](https://codeberg.org/forgejo/forgejo/pulls?state=open&type=all&labels=&milestone=0&project=0&assignee=0&poster=0&sort=relevance&q=project)) Of course take the issues with a grain of salt because some of them may just have something to do with the word "project" in them. That being said, the PRs seem to indicate a desire for something in between basic and complex. Also, I would link to [this comment](https://codeberg.org/forgejo/forgejo/pulls/9995#issuecomment-8158685) as having some overall good advice about how to go about this but more as an FYI :)

mfenniak commented 2026年01月28日 22:41:14 +01:00

@lenikadali wrote in #62 (comment):

So my feedback would be (from a design perspective), what problem are we trying to solve for here?

I think this question is key to giving design feedback.

---

This is the project that I most recently worked upon which could have used something to assist project management: expanding reusable workflows. My workaround to a lack of tooling was to create a large comment with links to all the related work. Here's the problems that I discovered with that workaround:

• I would finish a pull request and merge it, and neglect to update the comment leaving it out-of-date. This probably confused myself more than anyone else.
• As I kept editing the comment, other people wouldn't get notifications since they don't get notifications for edits. This is
  probably a minor problem because they'd likely get notifications on other side-effects.
• Eventually I had to pin a browser tab to this comment because I kept losing it, and needed to find it by renavigating through a few issues where I knew I linked it.

My workflow in this workaround had these quirks that are interesting to know about:

• As I was completing this work, I kept adding and removing subtasks in sub-bullet points. For example, I would complete development on a PR and I would add three checkboxes under it -- "development", "code review", "merge". I would then be able to track those statuses on whether I needed to take action on that item today, and finally I removed them all when I was done.
  • This raises another problem: "code review" as a checkbox needed to be managed manually, the same as "merged".
• The pull requests being tracked were across multiple Forgejo instances (code.forgejo.org and codeberg.org).

---

Another project that is on my plate is adding foreign key constraints throughout Forgeo. My workaround to a lack of project management tooling here is to create a spreadsheet tracking all the outstanding and completed work. This workaround has these problems:

• It isn't visible and transparent to others (this is the first link to it. 😉)
• It requires manual maintenance or it becomes out-of-date.
• It is limited in scope to just the tables & fields that need technical work, and not supporting technical work that is needed to unblock development.

But it also has these strengths that I wouldn't want to lose with a different project management solution:

• I can reorganize work easily by dragging and dropping it.
• I can group work -- implement multiple foreign keys -- easily and arbitrarily, not limited by existing work granularity like it might be if I created sub-tasks for every item (eg. all for one table, or one by one).
• It is easy to add arbitrary notes that don't require navigation into some sub-task to see.

---

From my personal perspective when I look at the designs of GitHub and GitLab's subtasks, I'm not incredibly enthused to use those features. Compared to the workarounds I'm already using, I see the possibility to lose as much as I'm gaining:

• Navigating and interacting with forms, rather than documents (comment / spreadsheet) -- slower, more clicks, more refreshes and reloads
• Strict implementation of data structures -- no ability to quickly bring to the top-level overview arbitrary notes, flags, bold text, or change how I'm tracking work just by indenting it
• No ability to track work across multiple Forgejo instances

But I haven't hands-on used those other designs. Would it be possible to document how they would solve problems like the ones that I have?

My overall goal is to make Forgejo compatible with the Agile Scrum Architecture. My company and I want to move our operations to Forgejo completely, and this will be an essential feature.

The same here -- is it possible to expand on this a little bit and describe what you and your company do for scrum today, and how you'd solve those problems with sub-tasks in Forgejo? As I think we all know, scrum is either incredibly specific or incredibly vague depending on the organization. 😉 And it changes over time as you retrospect and work to adjust processes.

I ran into a mega-tracking issue today in another project. I wonder if anyone knows of communities that rely on this kind of approach where we could reach out and invite feedback here?

@lenikadali wrote in https://codeberg.org/forgejo/design/issues/62#issuecomment-10238662: > So my feedback would be (from a design perspective), what problem are we trying to solve for here? I think this question is key to giving design feedback. --- This is the project that I most recently worked upon which could have used something to assist project management: [expanding reusable workflows](https://codeberg.org/forgejo/forgejo/issues/9768#issuecomment-8828016). My workaround to a lack of tooling was to create a large comment with links to all the related work. Here's the problems that I discovered with that workaround: - I would finish a pull request and merge it, and neglect to update the comment leaving it out-of-date. This probably confused myself more than anyone else. - As I kept editing the comment, other people wouldn't get notifications since they don't get notifications for edits. This is probably a minor problem because they'd likely get notifications on other side-effects. - Eventually I had to pin a browser tab to this comment because I kept losing it, and needed to find it by renavigating through a few issues where I knew I linked it. My workflow in this workaround had these quirks that are interesting to know about: - As I was completing this work, I kept adding and removing subtasks in sub-bullet points. For example, I would complete development on a PR and I would add three checkboxes under it -- "development", "code review", "merge". I would then be able to track those statuses on whether I needed to take action on that item today, and finally I removed them all when I was done. - This raises another problem: "code review" as a checkbox needed to be managed manually, the same as "merged". - The pull requests being tracked were across multiple Forgejo instances (code.forgejo.org and codeberg.org). --- Another project that is on my plate is adding [foreign key constraints throughout Forgeo](https://codeberg.org/forgejo/discussions/issues/385). My workaround to a lack of project management tooling here is to create a [spreadsheet tracking all the outstanding and completed work](https://docs.google.com/spreadsheets/d/1Riv95dIpZjVpMsZ20YRlf3wemEeGz4mFTNe_AOGOVQE/edit?usp=sharing). This workaround has these problems: - It isn't visible and transparent to others (this is the first link to it. 😉) - It requires manual maintenance or it becomes out-of-date. - It is limited in scope to just the tables & fields that need technical work, and not [supporting technical work](https://codeberg.org/forgejo/discussions/issues/385#issuecomment-10218316) that is needed to unblock development. But it also has these strengths that I wouldn't want to lose with a different project management solution: - I can reorganize work easily by dragging and dropping it. - I can group work -- implement multiple foreign keys -- easily and arbitrarily, not limited by existing work granularity like it might be if I created sub-tasks for every item (eg. all for one table, or one by one). - It is easy to add arbitrary notes that don't require navigation into some sub-task to see. --- From my personal perspective when I look at the designs of GitHub and GitLab's subtasks, I'm not incredibly enthused to use those features. Compared to the workarounds I'm already using, I see the possibility to lose as much as I'm gaining: - Navigating and interacting with forms, rather than documents (comment / spreadsheet) -- slower, more clicks, more refreshes and reloads - Strict implementation of data structures -- no ability to quickly bring to the top-level overview arbitrary notes, flags, bold text, or change how I'm tracking work just by indenting it - No ability to track work across multiple Forgejo instances But I haven't hands-on used those other designs. Would it be possible to document how they would solve problems like the ones that I have? > My overall goal is to make Forgejo compatible with the Agile Scrum Architecture. My company and I want to move our operations to Forgejo completely, and this will be an essential feature. The same here -- is it possible to expand on this a little bit and describe what you and your company do for scrum today, and how you'd solve those problems with sub-tasks in Forgejo? As I think we all know, scrum is either incredibly specific or incredibly vague depending on the organization. 😉 And it changes over time as you retrospect and work to adjust processes. I ran into a [mega-tracking issue today](https://forgejo.ellis.link/continuwuation/continuwuity/issues/880) in another project. I wonder if anyone knows of communities that rely on this kind of approach where we could reach out and invite feedback here?

limiting-factor commented 2026年01月29日 10:02:03 +01:00

If I was to work on a set of related issues that need grouping in a way that is not easy to achieve with labels, I would probably use project boards. But that's just a thought as I've never actually done it (or felt a need to use it) with Forgejo.

If I was to work on a set of related issues that need grouping in a way that is not easy to achieve with labels, I would probably use [project boards](https://forgejo.org/docs/latest/user/project/). But that's just a thought as I've never actually done it (or felt a need to use it) with Forgejo.

fnetX commented 2026年02月03日 21:57:50 +01:00

@lmtr0 Would you be open to schedule a meeting with me? You can find a link on my profile. Things I'd like to talk about:

• Your roadmap and the effort you can commit into the feature
• feedback about the proposals you made
• finding related issues that could be integrated into the design

@lmtr0 Would you be open to schedule a meeting with me? You can find a link [on my profile](https://codeberg.org/fnetX/#talk-to-me). Things I'd like to talk about: * Your roadmap and the effort you can commit into the feature * feedback about the proposals you made * finding related issues that could be integrated into the design

lmtr0 commented 2026年03月18日 18:08:01 +01:00

Hi @fnetX! I hope you are doing well.

Thank you for the time availability.
Unfortunately, my time has become scarce with some health issues I am dealing with.

As soon as I get that sorted out, I'll come back to developing this.

Unfortunately, I cannot give a timeline yet. But I hope it will be sooner rather than later.

Best
Lorenzo

Hi @fnetX! I hope you are doing well. Thank you for the time availability. Unfortunately, my time has become scarce with some health issues I am dealing with. As soon as I get that sorted out, I'll come back to developing this. Unfortunately, I cannot give a timeline yet. But I hope it will be sooner rather than later. Best Lorenzo