{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreicenkgmkcv2qxnxi3tspkbcsvaxnm2ycddgiki4qptwsre4cytpfu",
    "uri": "at://did:plc:yrn4rbgwenb6lfhhzjegbtnc/app.bsky.feed.post/3mngty6urvjl2"
  },
  "path": "/t/repository-hierarchy-in-forgejo/12300#post_1",
  "publishedAt": "2026-06-03T21:08:57.000Z",
  "site": "https://discourse.flathub.org",
  "tags": [
    "Bart Piotrowski: \"something may be happening\" - Treehouse Mastodon"
  ],
  "textContent": "I’ve been hinting over at Fediverse that I’m getting somewhere with deploying a Forgejo instance: Bart Piotrowski: \"something may be happening\" - Treehouse Mastodon\n\nIgnoring the technical part of it (i.e. where it will be hosted, what about CI, etc), the area I would like to have some alignment on with The Community™ is the future repository setup, should we ever migrate.\n\nIt’s worth keeping in mind that contrary to GitLab, Forgejo does not allow “unbound” root-level repositories. Each repo has to belong to some user or organization.\n\nIn the current GitHub world, I would differentiate these spaces:\n\n  * `flathub-infra` org which would map directly to something like `infrastructure/`\n  * `flathub/flathub` which is a kitchen sink of general issue tracker and target repo of the submission PRs. This would likely be `meta/`, with separate projects for issue tracking and new apps. Also where `flathub-infra/memberships` should go.\n  * Actual applications. Probably `apps/`? Doesn’t fit exactly because there are also extensions and BaseApps over there.\n\n\n\nAnyone with strong opinions is welcome to chime in!",
  "title": "Repository hierarchy in Forgejo"
}