Determine where to send tickets

Tickets, issues, project management etc. are a concept distinct from repositories (repos are just versioned file storage, basically). But these 2 things meet, when you wish you open a ticket on a specific repo. And the question is, how does ForgeFed software decide where to send the ticket? Possible examples:

  • No ActivityPub way to send the ticket; maybe just email the repo’s maintainer
  • Send the ticket to the repo maintainer Person actor
  • Send the ticket to the repo team of collaborators
  • Send the ticket to the Repository actor, which perhaps manages tickets in addition to the actual VCS repo
  • Send the ticket to another Repository actor, which may be a repo containing the tickets, a-la distributed bug tracker such as git-bug or Bugs Everywhere
  • Send the ticket to a separate ticket tracker which manages tickets for the repo, and that tracker may be entirely separate software on a separate website

Question: When I have a bug or feature request to submit against a specific repo, how does my client software know where to deliver it? How can it choose among all those options above? We need to decide how it’s done because there’s no obvious way:

  • Gitolite, Gitosis, cgit, gitweb… manage only repos, not tickets
  • githu8, gitlab, Gogs, Gitea… manage tickets per-repo
  • Some projects have a dedicated fake empty repo used just for tickets
  • Some projects use an external bug tracker such as Bugzilla or Redmine or Trac or Taiga etc.
  • Some projects just say “email bugs to maintainer”
  • Some software supports a variety of project management features including ticket tracking and VCS repos, but neither is a primary feature/object and it’s not automatically obvious how a given repo and and a given ticket are related to each other

I have ideas, that I’ll write and discuss soon, leaving this open for feedback :slight_smile:

1 Like

I’d counter you want to open a specific ticket for the project not the repo.

So I’d introduce a structure like where there is a Project object that references a Repository and an ticket/issue Tracker.

Having the Project entity, you send the ticket to the Tracker the project references.

I’d say that the forgefed spec should contain definition for the most popular options.
But I think in the end the options boil down to: does the project have BITT?

If it has, then just use the BITT part of the ForgeFed spec to talk to the tracker.
If it has not, then you loose.

But because we’re nice we could specify a possibility to report bugs via mail; in the end that’s just SMTP, right? :smiley:

And finally I think the question of whether the tracker is internal (GitLab, GitHub) or not is irrelevant. As long as it speaks ForgeFed it can live on the groud of the ocean or the dark side of the moon.