Ok so I did a test migration, although I had to solve some issues before: https://stg.pagure.io/famsco_test [[br]]
And while solving them with the developers I asked also about permissions and plans of pagure itself.

So the Trac has migrated to the staging instance of pagure, and I did the following settings:
* All tickets, open and closed, are set as private now;
* Default issues are set to private;
* All FAmSCo members are admins, we can create user groups if needed, but I don't see any pro doing that
* New issues will send out a notification mail to every single FAmSCo member (not to the list)

There is already a [https://pagure.io/fedora-infrastructure/issue/5740 ticket open in Infra to try to sync out FAS with pagure]. I don't know when this will be available in production, but we can set tickets in the future to FAS, even to FAS groups or anything we will decide.

Actually private tickets are accessible to reporters and admins. Assignees can access these tickets only if they are set also as admin. There is no option to set and grant access to watchers. Finally, if you don't have the permission to view the private tickets you won't see them neither in the list. So, for all other users, authenticated to pagure or not, the FAmSCo issue list will be empty until we can set permissions to FAS.

Just have a look, I think this could be a good compromise if we want to keep the old tickets in some way. Consider, most of them are closed and not of interest anymore.

I still think we shouldn't keep old tickets. I see no reason for that. As you say, they are of no interest anymore.
Can we leave them as read only and focus on migrating the active tickets? Just an idea.

Hi! I know I was asked to add some of my feedback to this, but just now getting a chance to get around to it. I have some ideas and suggestions to share.

= Migrating old data: Public v. private =

For me, I believe having old discussions to remain easily accessible and public is important. As an Ambassador, I have frequently been linked back to older tickets in FAmSCo history for context but also to look back on past discussions to better understand the Ambassador program, as an Ambassador. I place a high value in migrating this data, but also keeping it accessible for current and future Ambassadors to reflect back on.

=== How? ===

It is possible to migrate Trac tickets to private Pagure issues. However, there's no granularity – that is, it's either ALL public or ALL private. Even though it is tedious, I would suggest that the work be done to manually migrate the data and adjust ticket sensitivity as needed. To save effort, current FAmSCo members should see if there are more private or more public tickets. If there are more private tickets, then the migration should be all private, and then public tickets are made public. If there are more public tickets, then private tickets should be marked private after the migration.

If the latter, one way to potentially do this is to use an obscure repository on the staging version of Pagure for the migration, and then the person migrating would quickly switch visibility of private tickets back to private. After doing that, it wouldn't be hard to change the git remote to a repository on the production version of Pagure and just push the tickets to the production repository.

= Default privacy for tickets =

I also believe that it would be preferential to have new tickets be public by default. I believe it is more beneficial to encourage Ambassadors, FAmSCo members, and other community members to keep discussion open and public to the wider community. While a subtle change, if someone is not paying close attention, I see it likely that someone files a ticket privately that could easily be public. If someone is trying to file a ticket that needs to be private, I imagine they will be motivated to make sure their request remains private.

= FAS syncing to Pagure group =

I also think it would be better to manually update the Pagure group membership for each release cycle. It's worth noting that whoever creates the group will permanently be a member, so it might be better for someone like the FPL or FCAIC to create the FAmSCo Pagure group and then manually update members each release, until an automatic syncing option is available.

(The same thing applies for whoever actually creates the repo itself in production Pagure too.)

Replying to [comment:3 jflory7]:

For me, I believe having old discussions to remain easily accessible and public is important. As an Ambassador, I have frequently been linked back to older tickets in FAmSCo history for context but also to look back on past discussions to better understand the Ambassador program, as an Ambassador. I place a high value in migrating this data, but also keeping it accessible for current and future Ambassadors to reflect back on.

We have some tickets with sensitive data we don't want to be public for non Fedora contributors. I know there is a plan to sync pagure out with FAS, but until that I would suggest to keep tickets private.

It is possible to migrate Trac tickets to private Pagure issues. However, there's no granularity – that is, it's either ALL public or ALL private. Even though it is tedious, I would suggest that the work be done to manually migrate the data and adjust ticket sensitivity as needed.

Wanna volunteer? :)

I also believe that it would be preferential to have new tickets be public by default. I believe it is more beneficial to encourage Ambassadors, FAmSCo members, and other community members to keep discussion open and public to the wider community. While a subtle change, if someone is not paying close attention, I see it likely that someone files a ticket privately that could easily be public. If someone is trying to file a ticket that needs to be private, I imagine they will be motivated to make sure their request remains private.

That makes sense.

I also think it would be better to manually update the Pagure group membership for each release cycle. It's worth noting that whoever creates the group will permanently be a member, so it might be better for someone like the FPL or FCAIC to create the FAmSCo Pagure group and then manually update members each release, until an automatic syncing option is available.

One of the actual Trac admins can do that and should do that, rather than people who probably are less involved in the FAmSCo/ambassador group. It's clear the admins will update the FAmSCo pagure owners at every release cycle. This is already a work we do for other places after every election.

Replying to [comment:4 robyduck]:

Wanna volunteer? :)

If FAmSCo wouldn't have an issue with me having access to past, private data, I wouldn't mind doing this work. My eagerness to help here is motivated by the high value I am placing into keeping past discussions accessible and open (that is, for discussions that were accessible and open in the past). I just know that as an Ambassador, I have very frequently referred back on older tickets in this Trac. I think it would be smart to keep them all together in their new / future home for the benefit of future Ambassadors who one day may not know about this Trac.

No, there is no issue with that, you can access all tickets already in the fedorahosted trac. What we mean with private, is opening them to 'non-Fedora' people.

I reported a bug which has been fixed and the fix will be shipped in the next release, so once this is out I will recreate the repo and can make you admin too in the stg instance, just to have look which way you think would be the best (migrate as private or public tickets). My feeling is we have more public tickets, and could set some of them as private afterwards with your help.

What I really would like to do, is creating some FAmSCo docs on pagure where people can get all the informations about FAmSCo, mentoring etc. without having to search on the wiki...but that's another pagure chapter....

Ok, the bugfix has been released in staging and also in production. I did a new merge and set all tickets to private. All FAmSCo members can access them, same as jflory7. Please go to this new testing repo: https://stg.pagure.io/famsco-test

@jflory7: if you have time and still want to help, can you have a look which merge we should do when going to production? Private or public? Depends on how many tickets we/you have to change afterwards.

Anything else on that? I'll move on then and migrate the trac privately, as in staging. If you have anything to add, please do.

I found the famsco-test pretty good so I think we can migrate.

Migration went fine. I added also a README and wrote a comment on the old Trac to use pagure from now on.
Still need to go through the old and closed tickets, but there is no hurry anymore.

Looks good to me, thanks @robyduck for closing this out! :smile: