Transfer issues between repos to simplify collaboration

[patcon]

Re-ticketing from https://github.com/pol-is/polis-deploy/issues/8#issuecomment-616612100

@crkrenn suggested moving one specific issue, but perhaps we could start moving all issues to one place? Since we're about to contract repos when we move to monorepo, this feels aligned.

EDIT: skip the preamble comments; here are the asks: https://github.com/pol-is/polis-issues/issues/134#issuecomment-625540171

To Dos

• decide on One True Place™️ (polisServer or polis-issues) -- @metasoarous
• test transferring issues between demo repos for some common edge-cases -- @patcon
• transfer open issues to polisServer -- @patcon
  • polisMath
  • polisReport
  • polis-documentation
  • polisClientAdmin
  • polisClientParticipation
  • polis-deploy
  • polis-issues
• cross-reference stray PRs
  • Add scripts for local servers pol-is/polisMath#3
  • Add caveat of voting threshold to best practices pol-is/polis-documentation#1
  • Add section of readme for related resources/code/projects pol-is/polis-deploy#6
  • Added Death of the Gods press mention pol-is/polisClientAdmin#31
  • merge local polis changes from PDIS fork pol-is/polisClientParticipation#44
• mark previous repos as archived? (prevent new issues and read-only for remaining closed issues) -- @metasoarous
  • polisClientParticipation
  • polisClientAdmin
  • polisReport
  • polisMath
  • polis-deploy
  • polis-issues
  • polis-documentation
• unpin repos in org

(^^^ look ok?)

[patcon]

My specific proposal would be:

• transfer all existing issues from soon-to-be-merged repos into polis-issues (math, report, docs, client-admin, client-participation, server, deploy)
• turn off issues queues on all the now-empty repos (only PRs now)
  • use polis-issues going foward

Considerations: Transferring even closed issues might help preserve history, if possible, since disabled issue queues makes contained issues inaccessible. Alternatively, could disable issue queues for now on those repos (which hides closed tickets), and then enable them again before we archive the repos. That way, they'll be available as read-only going forward, and we won't have disappeared historic issue content)

Perks: Issues in one place. Decouples issue queue perms from ability to push code, since repos are separate.

Thoughts? Would others find this a step in the right direction?

(only someone with write perms on all repos can do these issue transfers)

cc: @metasoarous

EDIT: added considerations.

[metasoarous]

Seems like if we're moving everything to one polis monorepo it makes way more sense just to move all of the issues to that repo. I think the polis-issues only really made sense because we did have so many repos, and it was always unclear where to file them. Keeping issues in the same repo as code makes it easier for commit messages to reference issues and vice versa.

since disabled issue queues makes contained issues inaccessible.

Not actually sure what "issue queues" are. Can you please clarify?

Thanks!

[crkrenn]

Migrating everything to the new mono-repo (polisServer -> polis) sounds best to me.

[crkrenn]

And, should new issues be placed in https://github.com/pol-is/polisServer/issues?

[patcon]

I'm good with any one place for now, whether pol-is/polis for code+issues, or separate.

My understanding is that you're still hoping to be judicious with write access on the code repo. I'll share my understanding of that, so we're on same page with trade-offs.

The following are helpful for supporting community management: (they're not directly accessible without write perms, which could be more liberally shared if code lives in separate repo)

• creating/modifying labels: colors and names can't be edited
• retitling issues/PRs: helps when consolidating issues or clarifying scope
• editing non-authored body text of original issue comment: helpful for keeping a "shared section" in issue body for updating todos, summaries of decisions/threads, etc.

Alternatively, the above can also be facilitated in the issues+code repo way, using "protected branches", which make it less scary to share "write" perms with contributors who sign on for gardening the issue queue.

We can also decide: this isn't important right now :)

This decision is relatively low-stakes, because we're not locked in. (links redirect after any transfer)

@metasoarous Given the above, do you still have pref for polisServer to be the one issues+code repo? I'm down with whatever feels right to you 😄(And def curious about others' thoughts!)

Keeping issues in the same repo as code makes it easier for commit messages to reference issues and vice versa.

Yes, [Closes pol-is/polisServer#107] would instead be written as [Closes polis-code#13] for the folks who wish to work that way.

[patcon]

Regardless, I'm +1 on asap transferring all issues from their old repos to the One True Place™️ as decided, so pls feel free to make it happen @metasoarous :)

[patcon]

A "plus" for using same repo for both code and issues:

This type of permanent link will render as a code snippet only in the repository it originated in. In other repositories, the permalink code snippet will render as a URL.
-- GitHub Help: Creating a permanent link to a code snippet

[patcon]

Agreement on 2020-05-01 community call pol-is/polis-issues#147 to use pol-is/polisServer

[patcon]

Tested how issue transfers work (see below).

I'd recommend this for the 163 issues in question:

• close all PRs in non-polisServer repos
• for any incoming references from external repos, write a comment with a back-link (to preserve the cross-reference from other side)
• one-at-a-time, transfer all open and closed issues into polisServer
• create single open issue in old repos to explain migration
• set old repos to "archived" mode (read-only) -- stars/watchers/etc preserved; issues locked.

(closed issues would be migrated only for consistency -- all issue history now in pol-is/polisServer :)

@metasoarous @colinmegill is the above doable? If you're comfortable giving me temporary push access to the required repos, then I'm happy to get his tedium outta the way asap. Would be great to get this done. Pls skip steps as needed.

Testing Results

(Info that informs above recommendation.)

Mostly moving from repo 1 to 2:
https://github.com/patcon/test-issue-transfer-1/issues/
https://github.com/patcon/test-issue-transfer-2/issues/

Findings:

• there's no bulk or API option for issue transfer
• write access on both repos is required to do transfer.
• PRs cannot be transferred
• all issues (open/closed) can be transferred
• everything seems to "fix" when transferred, with one exception that requires manual fix:
  • when a referenced issue is transferred, the references to that issue get "unlinked" (including loss of cross-references on both sides), but the shorthand plaintext remains, e.g., pol-is/polis-issues#123. example: https://github.com/patcon/test-issue-transfer-2/issues/
  • Lost links can be converted back into full links and re-referenced by user, e.g., https://github.com/pol-is/test/issues/123

[metasoarous]

Hey @patcon.

That all sounds pretty reasonable.

My only real feedback is that I don't think it's necessary to transfer closed issues over. If they're closed we can just leave them on the old repos, and refer to them as needed.

Thanks again!

[patcon]

@metasoarous Kthx! To confirm, you're saying you'll handle the actions to close this out?

(Heh sorry for being dense, but your response sounded like you were giving me permission to, but I can't without push on all the repos)

[patcon]

migrated all the tickets to polisServer repo 🎈

Left a single remaining open issue in each repo, like so:
https://github.com/search?q=org%3Apol-is+%22status+of+this+repo%22&type=Issues

@metasoarous no rush on this, but seems your privileges are still needed to adjust "Settings" for each old repo into read-only archived mode.

[patcon]

Ok, @metasoarous got everything archived and renamed, so we're good to close this out 🎉

[patcon]

@metasoarous To confirm, polisMath isn't being archived, right?