Some links for the meeting:

Repositories from the Council Pagure project are now available in the Forgejo organization: Council.

Use the "Login by FAS" button to authenticate.

Council member accounts are not yet synced. I have added some of you manually from memory.

All current members have admin rights to the organization.

The council-docs repository failed to migrate in the production deployment, even though it works in staging.

Private issues are not yet migrated; I don't have access to them, nor do I want it. One of the council representatives will have to do that. Using the self-service migration tool.

Remaining steps:

• [DONE] figure out how to migrate council-docs
• figure out how to build https://docs.fedoraproject.org/en-US/council/ from that
• figure out how to migrate the private issues
• perform a final migration with recent changes
• "deactivate" pagure tickets/repos (or better yet, setup a redirect)

Summary of discussion with @ryanlerch today on the status of private issue functionality in fedora forge as this initiatives exec sponsor for council:

The forge team have proposed a workaround for repos who deal with private issues on discussion[link]. There are a few options open to the Fedora Council at this stage in the forge development. Please note - these are council specific options and other project teams may need to examine what would work best for them before migrating.

So, based on my sync with Ryan, below are what I think our options are:

1. Do not move the council ticket repo at all from pagure.io until parity with private issue filing is available in Fedora forge as we have in Pagure.
   Pros: No change in workflow and process at all.
   Cons: How long it will take to have feature parity is completely unknown and Council run the risk of losing out on finding and filing RFEs with the dev team when active development is happening. We are also the main leadership body of the project and lagging behind in this change is probably not a great impression to give :-/

2. Split the workflows by keeping private issues in Pagure.io until feature parity is reached and moving over to Fedora forge for everything else.
   Pros: Council joins early adopters of the new forge, and can file RFEs in real time with the dev team in real time. No change in workflow for reporters. It also unblocks us from migrating to the new forge.
   Cons: Council needs to maintain two repos.

3. Adopt the proposed workaround.
   Pros: Council joins early adopters of the new forge, and can file RFEs in real time with the dev team in real time. It also unblocks us from migrating to the new forge.
   Cons: Council needs to create a workflow to accomodate this change in how provate issues are filed and handled.

4. Council adopts using the council-private@lists.fedoraproject.org as the main way to report a private issue.
   Pros: Council joins early adopters of the new forge, and can file RFEs in real time with the dev team in real time. No change in workflow for reporters and this unblocks us from migrating fully. This list is also achievable in hyperkitty already and the reporter has the same way to send and receive information as council does. There's very little difference in using an email thread vs a ticket comments thread.
   Cons: Council needs a workflow or process to handle and respond to these emails appropriately.
   Side Questions: Why are private tickets necessary to report issues to council? What do we gain from having issues that we don't have from an email?

In reality, council should not block ourselves on migrating to the new forge because of private issue functionality when we have options to choose from that will fit our needs fine temporarily. A review of council repo activity for the last ~6 months has shown 0 private issues filed. I don't think this is as big a blocker for council as we think it is in reality. I even have some ideas on a workflow for options 3 and 4 if we migrate soon :)

That being said, this is a bigger issue for other repos in the project, so that's why I am explicitly stating that the options above are only intended to be considered by Council as ways to unblock ourselves from migrating.

@council, what are your thoughts on the above options? I am personally fine with either 2, 3 or 4. I am against delaying migration for much longer.

If I'm overlooking anything significant in how we currently handle liaising with reports for private issues that's not caught in one of the options, please let me know.

Also, updates on our remaining steps:

1. [DONE] figure out how to migrate council-docs
   • Migration tool has been developed and is in use to port repo data to Fedora Forge
2. [DONE] figure out how to build https://docs.fedoraproject.org/en-US/council/ from that
   • This functionality exists. Council docs can be built from fedora forge using the same git workflow as they are built in pagure currently.
3. [IN PROGRESS] figure out how to migrate the private issues
   • This can be addressed in the above comment.
4. [TODO] perform a final migration with recent changes
   • Currently blocked by decision on when to migrate
5. [TODO] "deactivate" pagure tickets/repos (or better yet, setup a redirect)
   • Currently blocked by decision on when to migrate

I have not yet dealt with any private council issues, so my opinion on the matter is not informed. I'd rather migrate everything at once. I worry that if we migrate before this functionality is done, the functionality will become less of a priority ("look, council already migrated, they did not need that after all"). I have a bad experience with shipping incomplete solutions that will be solved somehow later -- e.g. when we migrated away from pkgdb it took years to implement missing features.

My experience aligns with @churchyard: as soon as pressure is relieved to do the right thing, the right thing won't get done. So, I'd rather not allow any workarounds to unblock migration.

And that is completely valid for repositories within the project have a hard dependency on having a private issue feature. Those repositories cannot migrate until this is in place. So by that logic, that feature will eventually get implemented as it has to.

Based on my actual experience in council, and seeing how many private tickets we get, leads me to the conclusion that we don't face as hard a requirement for needing this feature in full before migrating, so it seems unnecessary to block on this.
We have more use and need for a functioning ticket tracker, and should be actively engaged with the new forge in as much capacity as possible.

Project teams should chose under what conditions they are comfortable with migrating under. I as a council member am comfortable migrating to the new forge once we agree what temporary solution seems best for us to use if and when a private issue needs to be filed. Personally, I really can't tell the difference between it being an email to the private council list or a private issue filed. The issue comes through as an email anyway :smile:

@ryanlerch Any known progress on the private issues in Forgejo? I don't think we are going to migrate before the end of 2025, but thinking of the Fedora Council Strategy Summit in February, it would be convenient if we could be settled into Forgejo by then.

Unfortunately, I concur with @churchyard and @ngompa too. I'd prefer to wait for the private issue functionality to be in place before we move. Of course, we could always start with a fresh repo, but I keenly remember when we moved from Trac to Pagure, it was incredibly useful for having Trac history inside of Pagure for referencing past decisions and context, especially in the first 6-12 months of migration.

Since there is a lot of important project policy and history represented in this issue tracker, I see value in waiting for a clean migration before we make the cut-over to Forgejo. We will get there in due time. :grinning:

@ryanlerch @t0xic0der Any updates on private issues in Forgejo? I'm curious how much longer we are held up.

Discussed at the Fedora Council 2026 Strategy Summit.

As part of our discussion and planned post-Summit action items, the topic of where we track our active work came up. Here are the main takeaways:

1. Private issues do not have a confirmed timeline because it requires fundamental reworking of how Forgejo upstream does issues. Fedora Infrastructure team members are actively working on upstream for this, but there is no ETA as of yet.
2. During the Summit, I commented on the appx. 30+ private issues in this repository, and asked anyone who receives the comment notification to help us evaluate whether the issue can be made public, if it needs to remain private but also remain for the historical record, or whether we can permanently archive/lose the ticket data without an impact on Fedora. I time-boxed this to a 30-day deadline for Friday, March 6th, at which point the Fedora Council can make our own decision on whether to open an issue, keep it private and migrate later, or permanently "delete" the ticket.
3. @humaton formally created forge.fedoraproject.org/council/tickets for us to start using in a new workflow. We agreed we need to lead by example here, and we cannot wait for the private issues functionality to be implemented fully to begin our migration.

Proposal

We will vote on this proposal in our Wednesday, 11 February 2026 meeting:

The Fedora Council agrees to the following course of action:

1. A final pass on all currently-open issues on the Fedora Council Pagure.io issue tracker will be conducted from today until Wednesday, 25 February 2026. Either issues will be closed, or identified as relevant for manual migration to Forgejo.
2. Effective Wednesday, 25 February 2026, all new work and tracking efforts will be done on Forgejo, in a brand-new repository.
3. Private issues on Pagure.io will be declassified as is appropriate and ethically-responsible throughout 2026.
4. Once private issue support is added to Forgejo, this repository will be migrated to Forgejo as a "tickets-archived" repo in the Council org, with a note that the repository exists for archival purposes only, and represents Council work from ~2013 to February 2026.

1. A final pass on all currently-open issues on the Fedora Council Pagure.io issue tracker will be conducted from today until Wednesday, 25 February 2026. Either issues will be closed, or identified as relevant for manual migration to Forgejo.

+1

1. Effective Wednesday, 25 February 2026, all new work and tracking efforts will be done on Forgejo, in a brand-new repository.

I would say "Effective Wednesday, 11 February 2026, all new public work and tracking efforts will be done on Forgejo, in the https://forge.fedoraproject.org/council/tickets/issues repository.

Private issues on Pagure.io will be declassified as is appropriate and ethically-responsible throughout 2026.

I do not honestly see the need for this. But do not want to object either.

Once private issue support is added to Forgejo, this repository will be migrated to Forgejo as a "tickets-archived" repo in the Council org, with a note that the repository exists for archival purposes only, and represents Council work from ~2013 to February 2026.

+1

I think we need to explicitly choose the recommended way for creating new private requests right now and until further notice:

• Do we suggest people to use mailing list. If yes, is it council-private@ ?

Or

• Do we suggest people to continue using Pagure repo for private issues only?

Here's my counterproposal:

We use pagure.io tracker until we migrate.

1. On 2026-02-18, we turn https://pagure.io/Fedora-Council/tickets/issues read only.
2. On 2026-02-18, we migrate all public issues to https://forge.fedoraproject.org/council/tickets -- they presevre their numbers.
3. On 2026-02-18, we migrate all private issues to a private repo on https://forge.fedoraproject.org/council/ -- they presevre their numbers.

That's it.

You can observe the results as done today in https://forge.fedoraproject.org/council/tickets-migrate-test/issues and https://forge.fedoraproject.org/council/private-tickets-from-pagure if you have concerns.

I have no feelings attached to the date proposed. It's in a week. Happy to pick any other date.

Here's my counterproposal:

We use pagure.io tracker until we migrate.

1. On 2026-02-18, we turn https://pagure.io/Fedora-Council/tickets/issues read only.
2. On 2026-02-18, we migrate all public issues to https://forge.fedoraproject.org/council/tickets -- they presevre their numbers.
3. On 2026-02-18, we migrate all private issues to a private repo on https://forge.fedoraproject.org/council/ -- they presevre their numbers.

That's it.

+1

+1 for @churchyard 's proposal.

IMPORTANT: This issue moved from Pagure to Forgejo

On Wednesday, 18 February 2026, the Fedora Council moved our issue tracker from Pagure.io to Fedora Forge, AKA Forgejo. Using the native Pagure importer tool in Forgejo, we imported git history and all public issues to a new Forgejo repository in the Council organization, forge.fedoraproject.org/council/tickets.

Please update any bookmarks or hyperlinks to the new location.

This specific ticket can be found on the new Forgejo issue tracker below:

https://forge.fedoraproject.org/council/tickets/issues/540