Transfer all the GitHub issues to the main CKEditor 5 repository

[mlewand]

Is this a bug report or feature request?

👷‍ Task

📋 Steps to reproduce

During the course of CKE5 development we've seen that multiple issue trackers in multirepo project become less efficient with time.

It's important that all existing issues are moved to the main repository in tact.

With this we'll do some labels cleanup.

Action list

• Update all the READMEs in dependent packages (don't forget about new packages like horizontal-page). (KP)
• Update links in the documentation. (KP)
• Add missing package: labels (e.g. package:autosave, package:indent). (KP)
  • Process old wildcard package labels (move open and closed issues to proper new labels, and remove wildcard labels). (KP)
• Transfer all the issues (so far ckeditor5-build-balloon-block and build-inline were ported)
  • Make sure that both open and closed issues are transferred. (ML)
  • Make sure that metadata is preserved (author, assignee, labels, milestone). (ML)
  • Check if it's possible that there are redirects in the old repo, even if issue tracker will be disabled there. - yes the redirects are working after closing the tracker (ML)
  • Add a proper package: label to the migrated issue. (ML)
• Prepare old references converter (see Transfer all the GitHub issues to the main CKEditor 5 repository #2002 (comment)). (KP)
• Refresh template labels, utilize feature for issue auto labeling (Use github issues templates (like in CKEditor 4) #1191). (MG)
• Cleanup Codetree. (CT settings not changed, as it's still the only convenient way to see PRs) (ML)

Challenges

I'll list a few challenges that come to my mind at this point.

• labels and milestone metadata are lost during issue transferring. See example.
  • Reactions and assignee are moved correctly though.
• Issue's Closes #xyz references in the GH pull request description are not updated. See
  • Though the issue keeps information "May be fixed by repo/address#issueNumber".
• I believe we should reach out to GH and ask whether the redirections are permanent or temporary. It would be bad if it stopped working at some point as we have some references in docs and, most importantly, in the code.

Few more complex cases That I have found:

Open pull requests will not close the transferred issue properly.

Without explicit actions PRs will not close associated issues.

Sample case:

1. There's a PR ckeditor/ckeditor5-image#317 that closes ckeditor/ckeditor5-image#315 issue.
2. #315 issue is being moved to main ckeditor/ckeditor5 repo.
3. #317 PR is being merged.

Actual

Dramma happens, (now migrated) #315 is not being closed. An example experiment was done in mlewand/soon-to-be-deleted-sub#6 (might get removed soon).

Best would be to simply update all open PRs.

[oskarwrobel]

I'm wondering what about branch names? Now when an issue is in the same repo as a branch then we named it t/xxx when it's cross-repo then t/repo-name/xxx. Since all tickets will be in one repo we could call all branches t/xxx. 🤔

[jodator]

It makes sense for simplified t/xxx as we will not have tickets in other repositories. So probably the rule is that it is not a cross-repo but cross-issue-tracker. So we still can create a branch t/other-repo/xxx for that. But inside CKEditor 5 scope the t/xxx will be used probably :)

[mlewand]

@oskarwrobel @jodator regarding branching, well I believe we could go with a simple t/<number> convention after migration.

• We're currently sitting on id above 2000, which was never exceeded in any of our subrepos, so there will be no collisions.
• It's subjective, but I feel having fewer rules/exceptions and more consistency is always better. (finally you could safely use mg co t/<number> in order to switch to a given PR)
• It's just easier to type if you happen to do it by hand.

So my proposal would be to simplify it. Sure we'll have to discuss this on a TM though.

[mlewand]

Interestingly, even though we changed bugs property in the package.json last release, npm didn't propagate this change. See https://www.npmjs.com/package/@ckeditor/ckeditor5-widget and click the number below "open issues" label. 😕

[pomek]

Update all the READMEs in dependent packages (don't forget about new packages like horizontal-page). (KP)

We don't have any links in README to I'm marking this point as done.

[pomek]

Update links in the documentation. (KP)

Done. See the logs above.

[mlewand]

I have also verified that even if issue GH feature is disabled on an origin repository, the redirects still going to work. 👍

[mlewand]

Another problem after issue migration will be Codetree. The thing is that transferred issues doesn't seem to play nice. E.g. in it25th we closed #1490 (which was moved from https://github.com/ckeditor/ckeditor5-autoformat/issues/62) and codetree still shows issue status based on autoformat issue.

[mlewand]

There's still this issue that I spoiled here:

• Issue's Closes #xyz references in the GH pull request description are not updated. See

  • Though the issue keeps information "May be fixed by repo/address#issueNumber".

The thing is that issue references in the comments (PRs, issues) are not updated accordingly after transferring an issue.

For example, after moving a #1 from ckeditor5-build-balloon-block repo, there are couple of broken references:

• In PRs of the same repo: t/1: Implemented the balloon block build ckeditor5-build-balloon-block#2 "Closes #1."
• In PRs of other repo: t/ckeditor5-build-balloon-block: Added the balloon block editor build to the project documentation. #1437 "(see ckeditor/ckeditor5-build-balloon-block#1)."

We should update these references to work with new issue numbers assigned in the main ckeditor5 issue tracker.

[pomek]

What about all the references that were inside issues? After moving issues from X to Y, also those stopped work. Now I am feeling that we want to fix only the small part of the problem. Those issues are still open. PRs are closed.

I am not saying that the reference converter is unworkable. But what could we gain after writing the tool? Links in changelogs work because GitHub cares about redirecting. I am not sure that anybody looks at closed PRs.

OTOH, the entire issue converter seems to be a task that GitHub could do. They know that those issues existed (because of redirects work) and it could be linked. Couldn't we just ask them?

[mlewand]

OTOH, the entire issue converter seems to be a task that GitHub could do.

Agree, GitHub should do better job in this regard but it doesn't.

Couldn't we just ask them?

Please ask them using support channel if GH is working on anything like that. However I don't expect GH improving it anytime soon.

What about all the references that were inside issues?

We could also update that in case it's easy to apply the same logic as for PR with just minor tweaks.

I am not sure that anybody looks at closed PRs.

Some of us are doing this extensively, checking issues that were closed couple of days ago, checking issues that were closed in past iterations when looking for some rationale. There are really many cases, and the references are extremely useful.