Proposal: Transfer repositories to portfolio-performance Github organization

[buchen]

The plan is to

• transfer the repositories to the portfolio-performance organization
• prune old (and very old) issues and pull requests by automatically closing them

After 11 years, the project has outgrown my personal GitHub account. Transferring it to an organization allows better management of collaborators, projects, issues, help pages, etc. Moreover, it offers a fresh start for the list of open issues, resolving past mismanagement.

Which repositories will be transferred?

• portfolio (the Java code of Portfolio Performance)
• buchen.github.io (the website at https://www.portfolio-performance.info)
• portfolio-updatesite (the repository hosting the update site used for online updates)
• portfolio-help (the help pages at https://help.portfolio-performance.info)
• portfolio-releng (release engineering tools, in particular the sync of translations with POEditor)

What is the impact for users of PP?

None. As the program never contacts github directly, there should be no impact if the domain names point somewhere else (for example for the update site)

What is the impact for developers contributing to PP?

The document reads:

All links to the previous repository location are automatically redirected to the new location. When you use git clone, git fetch, or git push on a transferred repository, these commands will redirect to the new repository location or URL. However, to avoid confusion, we strongly recommend updating any existing local clones to point to the new repository URL.

My understanding is: the process stays the same. The change is pushed to a local repository, a pull request is created. The commands should use the URL, but do not have to immediately.

How will the issues be pruned?

The current idea is

• close all tickets that have not seen any comments/activity this year
• add a notice to the issuer to reopen the ticket if needed

Update 23 July: we have to re-think because tickets cannot be reopened (which then could lead to duplicates). As the transfer of the repository is anyway independent of the pruning, put that discussion to the side until there are better ways

When?

Unless there significant objections or better proposals, the plan is to do the move until end of July.

[flywire]

add a notice to the issuer to reopen the ticket if needed

?? Someone posting an issue cannot reopen it if they do not have sufficient privileges, eg: #2496

[buchen]

Someone posting an issue cannot reopen it if they do not have sufficient privileges

Thanks @flywire for pointing this out - I wasn't aware of it. Apparently, only if the ticket is closed by the reporter, the reporter can re-open the ticket. A mass closing of tickets would mean they can only be commented on and rely on the maintainers to reopen.

Anybody know of an approach that works better? Just keep them open?

[pfalcon]

Just keep them open?

Well, that definitely doesn't scale across decades ;-). Maybe instead of "close all tickets that have not seen any comments/activity this year" have "for a year" (365 days). And otherwise yes, just for maintainers to watch comments posted and reopen as needed.

[lenucksi]

For the case of "close after period x" there's the Stale-Bot, now Stale-Action: https://github.com/actions/stale
It probably should be used very careful if at all. But it's not something that would need manual action.

[buchen]

Thanks @lenucksi for pointing out the stale bot. I definitely do not want to run this continuously. There are old issues which are legitimately open. I was more thinking of a "cleaner restart" of looking into the technical issues (there is also the forum).

@pfalcon writes:

And otherwise yes, just for maintainers to watch comments posted and reopen as needed.

Sounds like that is the only option on Github...

[Morpheus1w3]

@buchen

Thanks @lenucksi for pointing out the stale bot. I definitely do not want to run this continuously. There are old issues which are legitimately open.

It's might be suitable to label the issue/PR accordingly and exclude this label as mentioned at https://github.com/orgs/community/discussions/26712#discussioncomment-5057589 from the stale action.

if: "!(contains(github.event.pull_request.labels.*.name, 'label1') || contains(github.event.pull_request.labels.*.name, 'label2'))"

In this circumstances, this could be applied to issues as well.

https://docs.github.com/en/github-ae@latest/actions/managing-issues-and-pull-requests/closing-inactive-issues

[Morpheus1w3]

Someone posting an issue cannot reopen it if they do not have sufficient privileges

Thanks @flywire for pointing this out - I wasn't aware of it. isaacs/github#583, only if the ticket is closed by the reporter, the reporter can re-open the ticket. A mass closing of tickets would mean they can only be commented on and rely on the maintainers to reopen.

Anybody know of an approach that works better? Just keep them open?

As proposed at https://github.com/orgs/community/discussions/5766 a suitable approach could be to clone dedicated issues w/ Kamino 🤔

Another approach, before transferring the repo to the new organization repo, transfer the outdated issues to a temporary repo as described at https://docs.github.com/en/issues/tracking-your-work-with-issues/transferring-an-issue-to-another-repository . In this case, old issues remains in your old repository, only the intended one will might be transferred to the new account.

A mass transfer is might be available by using https://github.com/arunnalla/bulk-transfer-github-issues or https://jloh.co/posts/bulk-migrate-issues-github-cli/

If I understood the GitHub CLI and the above posted guide, the following two code lines should transfer all closed issued and where the last update was before a specific date.

gh issue list -s updated:<=YYYY-MM-DD -L 500 --json number | \
    jq -r '.[] | .number' | \
    xargs -I% gh issue transfer % https://github.com/<destination repo>

gh issue list -s closed:<=YYYY-MM-DD -L 500 --json number | \
    jq -r '.[] | .number' | \
    xargs -I% gh issue transfer % https://github.com/<destination repo>

[buchen]

Thanks @Morpheus1w3 - the links are very helpful indeed

My thinking is: with the transfer of the repository, all issues are transferred as well (which is fine). The issues can remain in the repository. My intention is to close old and very old issues to get to a manageable list. I just checked: the oldest open issues is more than 10 years old. It looks like the command line could help to have a one-time cleanup. If the reporter thinks the issue should be reopened, the reporter would have to make a comment - ideally with an explicit mention.

[buchen]

BTW, the repository has been transferred now.

[buchen]

I played around using the gh cli as mentioned above.

gh issue list --search "is:issue state:open created:<2020-01-01 updated:<2020-01-01"

This is how many issues would be closed if matching issues created and last updated before:

• Before 2020 matches 237 issues
• Before 2021 matches 389 issues
• Before 2022 matches 558 issues
• Before 2023 matches 660 issues

Most issues are created recently (which I do not want to close anyway). I am also not sure if it worth the trouble if the list is reduced f rom 747 open issues (at the time of writing) to 510 (when closing all before 2020).