Proposed Private Issues Process for Fedora Forge

amoloney commented

2026-08-03 17:48:43 +00:00

Owner

Summary

Please review and provide feedback on the attached video and/or howit-works guide for filing private issues in fedora forge

Background

The Forge developer team (within CLE - RH) have developed a feature that will handle filing and processing private issues in Fedora Forge. This was a feature that the Fedora Council requires. It is not a feature that is heavily used by Council. This video and how-it-works guide gives an overview of the feature and process for this function.

Details

Council members are to review and provide feedback (if any) in this ticket on whether this proposed method of filing and handling private issues in Fedora Forge meets our needs.

We (council) require the following:

An issue can be filed privately
The issue can be used to interact with the requestor to get more information
The issue can remain private or be turned public if/when required.

Link to documentation https://forge.fedoraproject.org/forge/ForgeFiler/#how-it-works

Summary

Council should decide if this feature and process satisfies the requirement of having private issues.

### Summary Please review and provide feedback on the attached video and/or howit-works guide for filing private issues in fedora forge ### Background The Forge developer team (within CLE - RH) have developed a feature that will handle filing and processing private issues in Fedora Forge. This was a feature that the Fedora Council requires. It is not a feature that is heavily used by Council. This video and how-it-works guide gives an overview of the feature and process for this function. ### Details Council members are to review and provide feedback (if any) in this ticket on whether this proposed method of filing and handling private issues in Fedora Forge meets our needs. We (council) require the following: - [x] An issue can be filed privately - [x] The issue can be used to interact with the requestor to get more information - [x] The issue can remain private or be turned public if/when required. Link to documentation https://forge.fedoraproject.org/forge/ForgeFiler/#how-it-works ### Summary Council should decide if this feature and process satisfies the requirement of having private issues.

Screencast_29_07_26_22_27_53.webm

16 MiB

jflory7 commented

2026-08-03 22:57:57 +00:00

Owner

When @ryanlerch introduced the topic, it seemed like he was thinking of both the Fedora Council (significantly lower traffic for private issues) and the Code of Conduct Committee (all issues are private issues).

I genuinely wonder whether it is a better investment of effort for the Fedora Council to bide time until private issues are natively implemented for bringing private ticket workflows back to the Council. We do have an established "closed" list where anyone can email and contact the Council to report sensitive matters.

The Code of Conduct Committee needs this tool to have an operational ticketing workflow outside of email. I recognize that the Council is not the CoC Committee, but by way of @jspaleta, @jonatoni, and myself, we can provide some of that coverage. @ankursinha and @chris could also weigh in on this ticket directly too with any feedback.

When @ryanlerch introduced the topic, it seemed like he was thinking of both the Fedora Council (significantly lower traffic for private issues) and the Code of Conduct Committee (all issues are private issues). I genuinely wonder whether it is a better investment of effort for the Fedora Council to bide time until private issues are natively implemented for bringing private ticket workflows back to the Council. We do have an established "closed" list where anyone can email and contact the Council to report sensitive matters. The Code of Conduct Committee needs this tool to have an operational ticketing workflow outside of email. I recognize that the Council is not the CoC Committee, but by way of @jspaleta, @jonatoni, and myself, we can provide some of that coverage. @ankursinha and @chris could also weigh in on this ticket directly too with any feedback.

jflory7 added the

labels

2026-08-03 22:58:16 +00:00

ryanlerch was assigned by jflory7

2026-08-03 22:58:45 +00:00

jflory7 added this to the Fedora Linux 45 milestone

2026-08-03 22:58:49 +00:00

jflory7 added this to the Council Meeting Planner project

2026-08-03 22:58:54 +00:00

ryanlerch commented

2026-08-04 00:21:07 +00:00

Owner

The two main stakeholder repos that were considered when developing ForgeFiler were:

fedora-pdr (Fedora Personal Data Requests) — currently on Pagure, primarily processed by @zlopez and @kevin. These are essentially all private tickets.
CoC (Code of Conduct) — all issues are private by nature.

Both of these repos rely heavily on private issue handling, and ForgeFiler was designed with their workflows in mind.

The two main stakeholder repos that were considered when developing ForgeFiler were: - **[fedora-pdr](https://pagure.io/fedora-pdr)** (Fedora Personal Data Requests) — currently on Pagure, primarily processed by @zlopez and @kevin. These are essentially all private tickets. - **[CoC](https://pagure.io/CoC)** (Code of Conduct) — all issues are private by nature. Both of these repos rely heavily on private issue handling, and ForgeFiler was designed with their workflows in mind.

gotmax23 commented

2026-08-04 01:25:22 +00:00

Thanks for working on this. Is this intended as a permanent solution or is the ultimate goal still to upstream private issue support into Forgejo? This workaround will probably not scale well¹ if we end up deciding in fesco/tickets#3664 to use Forgejo for distgit package bug tracking, but it sounds like it would work alright for the other usecases you mentioned.

(due to needing two trackers per component, not being able to make tickets un-private after the fact, not having an API for prodsec and others to auto-file private issues) ↩︎

Thanks for working on this. Is this intended as a permanent solution or is the ultimate goal still to upstream private issue support into Forgejo? This workaround will probably not scale well[^1] if we end up deciding in https://forge.fedoraproject.org/fesco/tickets/issues/3664 to use Forgejo for distgit package bug tracking, but it sounds like it would work alright for the other usecases you mentioned. [^1]: (due to needing two trackers per component, not being able to make tickets un-private after the fact, not having an API for prodsec and others to auto-file private issues)

t0xic0der commented

2026-08-04 03:06:27 +00:00

Owner

I genuinely wonder whether it is a better investment of effort for the Fedora Council to bide time until private issues are natively implemented for bringing private ticket workflows back to the Council. We do have an established "closed" list where anyone can email and contact the Council to report sensitive matters.

It might just be. From the perspective of someone working with @nphilipp to actively develop the requested private issues feature, it may take a little while longer for the upstream acceptance. As this is a big change, that cannot introduced piece by piece, it makes sense to have a limited workaround for the time being.

Thanks for working on this. Is this intended as a permanent solution or is the ultimate goal still to upstream private issue support into Forgejo? This workaround will probably not scale well1 if we end up deciding in fesco/tickets#3664 to use Forgejo for distgit package bug tracking, but it sounds like it would work alright for the other usecases you mentioned.

Not permanent at all. It is a temporary workaround starting from the aforementioned two repositories. Please see the private-issues branch of the Fedora Project's Forgejo fork. We are in continuous communication with the upstream project and actively developing this suggested feature for a while now.

> I genuinely wonder whether it is a better investment of effort for the Fedora Council to bide time until private issues are natively implemented for bringing private ticket workflows back to the Council. We do have an established "closed" list where anyone can email and contact the Council to report sensitive matters. It might just be. From the perspective of someone working with @nphilipp to actively develop the requested private issues feature, it may take a little while longer for the upstream acceptance. As this is a big change, that cannot introduced piece by piece, it makes sense to have a limited workaround for the time being. > Thanks for working on this. Is this intended as a permanent solution or is the ultimate goal still to upstream private issue support into Forgejo? This workaround will probably not scale well1 if we end up deciding in fesco/tickets#3664 to use Forgejo for distgit package bug tracking, but it sounds like it would work alright for the other usecases you mentioned. Not permanent at all. It is a temporary workaround starting from the aforementioned two repositories. Please see the [`private-issues`](https://codeberg.org/fedora/forgejo/src/branch/private-issues) branch of the [Fedora Project's Forgejo fork](https://codeberg.org/fedora/forgejo). We are in continuous communication with the [upstream project](https://codeberg.org/forgejo/design/issues/2) and actively developing this suggested feature for a while now.

❤️ 1

amoloney commented

2026-08-06 12:20:57 +00:00

Author

Owner

FWIW I think this is fine for Council to use as a mechanism for private ticket handling, in the rare event we do require one. But, I would equally be fine with adding a note in the readme of our repo saying something like:

'If you have a private matter you wish to discuss with the Fedora Council, please email council-private@lists.fedoraproject.org. Our repo currently does not support private issues'.

FWIW I think this is fine for Council to use as a mechanism for private ticket handling, in the rare event we do require one. But, I would equally be fine with adding a note in the readme of our repo saying something like: 'If you have a private matter you wish to discuss with the Fedora Council, please email council-private@lists.fedoraproject.org. Our repo currently does not support private issues'.

pbrobinson commented

2026-08-06 12:38:12 +00:00

I think there's another option needed:

Public read only but restricted comments.

I actually fed that into requirements for the forge replacement (it might have got lost). There are situations where you want the community to be able to see what's going on but the ability to comment is restricted.

That sort of functionality is useful for things like council discussions, security advisories etc where you may need to start them public but later want to open them up but don't necessarily need/want/or can even allow a whole lot of drive by comments.

I think there's another option needed: * Public read only but restricted comments. I actually fed that into requirements for the forge replacement (it might have got lost). There are situations where you want the community to be able to see what's going on but the ability to comment is restricted. That sort of functionality is useful for things like council discussions, security advisories etc where you may need to start them public but later want to open them up but don't necessarily need/want/or can even allow a whole lot of drive by comments.

ryanlerch commented

2026-08-10 09:46:17 +00:00

Owner

@pbrobinson wrote in #577 (comment):

I think there's another option needed:

Public read only but restricted comments.

I actually fed that into requirements for the forge replacement (it might have got lost). There are situations where you want the community to be able to see what's going on but the ability to comment is restricted.

That sort of functionality is useful for things like council discussions, security advisories etc where you may need to start them public but later want to open them up but don't necessarily need/want/or can even allow a whole lot of drive by comments.

This is actually already available in Forgejo via issue locking. When an issue is locked:

The issue remains publicly visible — anyone can read it
Only users with write access to the issues unit of the repository (or site admins) can add comments
The issue can be locked/unlocked at any time by repo maintainers

This maps well to the use cases you're describing — council discussions where you want transparency (public read) but need to control who can participate in the conversation. A repo maintainer can lock an issue at creation or at any point during the discussion, and unlock it later when broader input is appropriate.

@pbrobinson wrote in https://forge.fedoraproject.org/council/tickets/issues/577#issuecomment-1261852: > I think there's another option needed: > > * Public read only but restricted comments. > > I actually fed that into requirements for the forge replacement (it might have got lost). There are situations where you want the community to be able to see what's going on but the ability to comment is restricted. > > That sort of functionality is useful for things like council discussions, security advisories etc where you may need to start them public but later want to open them up but don't necessarily need/want/or can even allow a whole lot of drive by comments. This is actually already available in Forgejo via **issue locking**. When an issue is locked: - The issue remains **publicly visible** — anyone can read it - Only users with **write access to the issues unit** of the repository (or site admins) can add comments - The issue can be locked/unlocked at any time by repo maintainers This maps well to the use cases you're describing — council discussions where you want transparency (public read) but need to control who can participate in the conversation. A repo maintainer can lock an issue at creation or at any point during the discussion, and unlock it later when broader input is appropriate.

👍 1

ryanlerch referenced this issue from forge/forge

2026-08-10 11:12:36 +00:00

Deploy ForgeFiler to production and configure coc/fedora-pdr to use it #722

ryanlerch referenced this issue from a commit

2026-08-14 11:38:31 +00:00

Sanitize attachment filenames with secure_filename before forwarding to Forgejo API

jflory7 commented

2026-09-03 17:20:28 +00:00

Owner

@ryanlerch The Code of Conduct Committee discussed this today. Is it possible for us to add a custom note and link to the Clarifying Notes & Statements page? This would help us encourage reporters to submit their reports to the first path of escalation before opening a CoC report.

@ryanlerch The Code of Conduct Committee discussed this today. Is it possible for us to add a custom note and link to the [Clarifying Notes & Statements](https://docs.fedoraproject.org/en-US/project/code-of-conduct/clarifying-statements/) page? This would help us encourage reporters to submit their reports to the first path of escalation before opening a CoC report.

amoloney commented

2026-09-07 13:41:01 +00:00

Author

Owner

Wrt to this ticket, can we close this as done from a council pov? I think the mechanism will work if we do require a private ticket to be filed, which is actually very seldom. There is also the ability to lock issues as Ryan describes, so we have a way to have restricted but public ticket discussion. I would consider this done and would like to close out the issue.

If Code of Conduct committee have more feedback to share, I suggest in the interest of good housekeeping to have an issue open on the Fedora Forge repo or the committee repo.

Wrt to this ticket, can we close this as done from a council pov? I think the mechanism will work if we do require a private ticket to be filed, which is actually very seldom. There is also the ability to lock issues as Ryan describes, so we have a way to have restricted but public ticket discussion. I would consider this done and would like to close out the issue. If Code of Conduct committee have more feedback to share, I suggest in the interest of good housekeeping to have an issue open on the Fedora Forge repo or the committee repo.

👍 1

amoloney commented

2026-09-09 17:26:31 +00:00

Author

Owner

@jspaleta @shaunm @bookwar @jonatoni @decathorpe @pbokoc @t0xic0der @nimbinatus @pboy @churchyard Id like to close this ticket as done from a council perspective. Is there any objections to that?

👍 2

nimbinatus commented

2026-09-09 17:59:32 +00:00

Member

@amoloney wrote in #577 (comment):

@jspaleta @shaunm @bookwar @jonatoni @decathorpe @pbokoc @t0xic0der @nimbinatus @pboy @churchyard Id like to close this ticket as done from a council perspective. Is there any objections to that?

No objection from me

@amoloney wrote in https://forge.fedoraproject.org/council/tickets/issues/577#issuecomment-1355299: > @jspaleta @shaunm @bookwar @jonatoni @decathorpe @pbokoc @t0xic0der @nimbinatus @pboy @churchyard Id like to close this ticket as done from a council perspective. Is there any objections to that? No objection from me

jflory7 closed this issue

2026-09-15 02:44:14 +00:00

Rows
Columns

Proposed Private Issues Process for Fedora Forge #577

Summary

Background

Details

Summary