Hi Peter,
There's nobody working on such Feature in Forgejo, even if someone
starts now it will take months to get in a state that could be merged.
Most projects have simply opted for a dedicated "Discussions" repository
where the issues are used as discussions. Threads are not a thing there,
but most have found peace with the "Quoted reply" feature where you can
quote parts of people's comments and have it nicely formatted.
Kind Regards
Gusted
Codeberg e.V.
--
https://codeberg.org
Codeberg e.V. – Arminiusstraße 2-4 – 10551 Berlin – Germany
Registered at registration court Amtsgericht Charlottenburg VR36929.
On 5/12/26 1:47 AM, Peter Taraba wrote:
> Any help with this?:
>
> >> "My main problem with Codeberg is the lack of a feature similar to GH
> >> Discussions. Those are not always enabled on repos, but I see them as
> >> essential for large-scope projects with many hidden users, old
> history and
> >> a way to reach out. They act essentially as a projec-hosted forum that
> >> allows signaling and preserving community debates around APIs, usages,
> >> complaints etc."
> Thank you!
> Best regards,
> Peter Taraba
>
>
https://randommathguy.blogspot.com/
> Ph.D. from Slovak University of Technology in Bratislava, Slovakia
> Microsoft Research, J.W.Goethe University and ST Microelectronics Alumnus
> *Sent:* Monday, May 11, 2026 at 1:08 AM
> *From:* "Arnaud Becheler via Boost" <boost@lists.boost.org>
> *To:* "Boost developers' mailing list" <boost@lists.boost.org>
> *Cc:* "Arnaud Becheler" <arnaud.becheler@gmail.com>
> *Subject:* [boost] Re: GitHub reliability
> I agree with Alex here.
>
> Although I would be happy to ditch Microsoft for an European solution, my
> main problem is that the Boost.Graph users we just connected with and
> promised less friction would be affected in how they participate in and
> engage with Boost.Graph.
>
> My main problem with Codeberg is the lack of a feature similar to GH
> Discussions. Those are not always enabled on repos, but I see them as
> essential for large-scope projects with many hidden users, old history and
> a way to reach out. They act essentially as a projec-hosted forum that
> allows signaling and preserving community debates around APIs, usages,
> complaints etc.
>
> They are functionally different from issues:
> - Issues are for bug reports, code defects, and actionable items, the
> quality-to-noise ratio for a good issue is high.
> - Discussions are a support/forum space for the project: questions,
> feature
> ideas, announcements, polls, "how do I configure this on XYZ" type help.
> Not necessarily actionable, although if relevant these can be converted to
> issues.
>
> Without a dedicated discussion space, issues become the recipient
> space for
> items that are not always actionable. The BGL issue tracker is somewhat
> encumbered by items that would rather belong in Discussions.
>
> What particularly worries me is that we heavily and successfully depended
> on GH Discussions to announce and organize the BGL Workshop last
> Wednesday,
> as I believe they are an essential part of revitalizing BGL and its
> community. We were positively surprised by the amount of participation and
> the quality of the feedback that the single announcement page collected:
>
https://github.com/boostorg/graph/discussions/466
>
> Leaving GH would mean dropping this feature, which has been discussed for
> years at Codeberg (
https://codeberg.org/forgejo/forgejo/issues/410 ). It
> would deprive BGL maintainers from their most efficient way to reach users
> at a critical time. It would also send a terrible message to BGL users who
> invested in those discussions and strongly asked for less friction, not
> more.
>
> I am aware that 1) what holds for Boost.Graph may not be true for other
> projects 2) vinnie said there was no urgency
>
> So as long as Github shittification makes maintainers lives harder but
> keep
> users happy, I would be tempted to absorb the cost at least for now.
>
> Best wishes,
> Arnaud Becheler
>
>
> On Mon, May 11, 2026 at 9:29 AM Alexander Grund via Boost <
> boost@lists.boost.org> wrote:
>
> > Am 11.05.26 um 04:18 schrieb Klemens Morgenstern via Boost:
> > > I think the first attempt should be to spin up a mirror of either
> Forgejo
> > > and/or Gitea
> > > and see how it works.
> > > And then we set a date, at which we disable issues and PRs on Github
> > > and use github as a pure (and automated) mirror.
> > >
> > >
> > >> If for example we want to transfer the open issues then we should
> start
> > >> collecting them now, because of rate limits (it could take weeks or
> > months
> > >> to collect all the data which is not stored in the repo).
> > >>
> > > Both have an "import from github" function, that allows you to
> import a
> > > full project.
> > > This is probably a good default, unless a maintainer wants to do it
> > another
> > > way (e.g. only transfer certains issues).
> >
> > TBH: Not really keen on that.
> > I'm aware of the sunken costs fallacy but there IS a lot of effort in
> > and around GitHub that we would/might loose.
> > That includes experience of us and users on how to do things there and
> > how to handle issues difficulties.
> > E.g. Boost.CI and the "reusable" workflow introduced by Jim last year
> > helps to have up to date configurations for lot's of Boost libraries,
> > especially those where CI is/was rooting away as maintainers were either
> > not that active anymore or simply didn't want to keep track of the
> > changes required for very new or old configurations.
> > Drone is only part way on that state where a new compiler can be tested
> > and added to dozens of libraries in a single commit to a central
> > repository.
> >
> > So far my work on GitHub wasn't affected to an extent I'd even
> notice much.
> > Especially with Boost we are not that highly active that even a day
> > outage would be catastrophic. I'd put it as "mildly annoying" instead.
> >
> > And the article shared by Vinnie [1] sounds like there is some hope:
> >
> > > GitHub. It is critical global infrastructure, and it is struggling
> > > under the weight of millions (if not billions) of AI agents spewing
> > > out code.
> >
> > > GitHub’s stated priorities are now availability first, capacity
> > > second, new features third. That’s the right order,
> >
> > So IMO this is a temporary struggle with the changing landscape of
> > software development and MS at least seems to be aware and dedicated to
> > handle that.
> >
> > So I would wait for this to calm down again but keep stuff like this in
> > mind.
> > If anyone has the time to test alternatives on what is viable if it
> > comes to that, it would certainly be good to know.
> > Especially how well issues and references to PRs, commits and other
> > issues are kept as that proved to be useful in multiple occasions to me.
> > But I wouldn't want to do the switch, at least not now.
> >
> > - Alex
> >
> > [1]
https://leaddev.com/software-quality/whats-gone-wrong-at-github
> >
> > _______________________________________________
> > Boost mailing list -- boost@lists.boost.org
> > To unsubscribe send an email to boost-leave@lists.boost.org
> >
https://lists.boost.org/mailman3/lists/boost.lists.boost.org/
> > Archived at:
> >
>
https://lists.boost.org/archives/list/boost@lists.boost.org/message/XLH3UJ65KVKARUAQFCSFAPOUTLXYN4JI/
> >
> _______________________________________________
> Boost mailing list -- boost@lists.boost.org
> To unsubscribe send an email to boost-leave@lists.boost.org
>
https://lists.boost.org/mailman3/lists/boost.lists.boost.org/
> Archived at:
>
https://lists.boost.org/archives/list/boost@lists.boost.org/message/4OKKCF5US4WZXXC4WFMNMSFAA5KIHISO/