search

go-gitea / gitea

Git with a cup of tea! Painless self-hosted all-in-one software development service, including Git hosting, code review, team collaboration, package registry and CI/CD
https://gitea.com
MIT License
45.03k stars 5.49k forks source link

Hierarchical issue tracking #13642

Open h0lg opened 3 years ago

h0lg commented 3 years ago

Are there any plans (or existing forks you know of) for supporting hierarchical issue tracking?

If not, is there a way to store information about issue hierarchy? I want to migrate from redmine, which provides that feature (via a parent_id field on the issue model).

I've looked at the dependencies/"blocking issues" model, but

  1. it seems to have a different purpose in that it is opinionated about allowing status changes on an issue with open dependencies. In my experience, it is better to keep hierarchical information independent from that. Otherwise moving an open issue into a closed one invalidates the status of the parent or even forces you to reopen it. That introduces perpetually-open issues into your system, because top-level components/modules will always have open ancestors some levels deeper. Redmine for example started out un-opinionated about that and then introduced a rule enforcing that a closed issue could only have closed ancestors, which made the entire hierarchy system harder to manage.

  2. Also, there doesn't seem to be a swagger API or migration model support for the dependencies/"blocking issues" model.

Acknowledging that hierarchical issue tracking may be somewhat of a personal preference/subjective topic and you may be reluctant to add official support for it:

Background

I came to Gitea for the easy setup of a self-hosted git server on Windows. (Great job there btw - love the simple setup approach!) Then I looked into the Issue tracking and immediately recognized it from Github - which is a big plus, because most devs know how to use that. What got me excited (and seriously thinking about switching issue trackers as well as git servers) though, are the new Kanban task boards.

The only thing that keeps me from making the switch at this point is the question of how to preserve the hierarchical information when migrating my issues to Gitea.

Having used hierarchical issue trackers has probably spoiled me and taught me to expect more from my issue tracking these days :| Either way, I don't like the "solve & forget" approach of unstructured issue trackers much any more. I feel like I'm losing to much information and have to repeat myself too often when I use them; the communication overhead increases and the pitfalls become more numerous.

The case for hierarchical issue tracking

(from my personal experience)

h0lg commented 1 year ago

A few years later and with some more experience working with hierarchical issue trackers I still like the option to organize part of my issues in a structured way (i.e. in trees instead of a flat list) that mimics the navigational and UI structure of my app. It works well for big apps with many distinct components/pages.

But there's an issue with it that is hidden in the little word or in this section of the original proposal:

depending on the type of project, enables you to structure your issues either

  • user-friendly by UI views/components/widgets

  • or developer-friendly by module/class/functionality

What if I want that or to be an and? What if I want my issue to be associated with a UI component as well as with a module relevant only to devs? Or associated with multiple UI components because it relates to their interaction? That basically means I want different tree structures or have the issue in different parts of the same tree. Yet my issue can't have more than one parent. As an OO programmer, I realize that I've signed up for a single-inheritance scheme lacking the flexibility that I need.

I don't want one tree to rule them all.

And on the heels of that it came to me that I don't need a pre-defined structure either: The existing issue Labels (tags) do what I need to categorize issues. Giving the labels the correct structure (e.g. a tree by navigational structure down to UI component or a list by internal module) can really only be taken care of by the consumer of the issue data - because any pre-defined structure would hardly ever be right for everyone all the time.

Once I have the label structure right, I can use the API to list issues by label.

The only thing I can currently think of required to make categorizing new issues easier is the ability to pre-fill the Labels from the URL #27341. A host app could use this to enable creating issues for a specific page or UI component, improving issue tracker integration and reducing manual categorization efforts.

So unless anyone sees benefits in defining and rendering issue label structures in gitea itself (e.g. in a JSON "trees" with title: label pairs for nodes), I'd say this may be better implemented as optional functionality in a plugin or custom in the host app.

Feel free to close this proposal.

lunny commented 1 year ago

I think Gitea Issues will not have a complicated features like Jira or Redmine int a short-term.

h0lg commented 1 year ago

I think Gitea Issues will not have a complicated features like Jira or Redmine int a short-term.

And that's not a problem - because if you want it, you can build it on top of gitea as a plugin or use its REST API to query and structure your issues according to your needs. That's the gist of what I wanted to get across above.