@@ -137,6 +137,17 @@ by improving Roundup and/or our instance.

A mobile-friendly theme that is more modern but still familiar

will be added.

* **Move reply box close to the last message.** The reply box is

located at the top of the page, whereas the last message is at the

bottom.

The reply box can be moved or duplicated after the last message.

* **Real-time updates.** When another users submits changes to an

issue, they should show up in real time.

This can be accomplished by using the REST API.

* **Add PR link to BPO emails.** Currently bpo emails don't include

links to the corresponding PRs.

@@ -277,78 +288,135 @@ have been addressed by :pep:`581` and :pep:`588`.

:pep:`588` suggests to add a button to migrate issues to GitHub

only when someone wants to keep working on them. This approach

has several issues:

* bpo will need to be updated in order to add a button that,

once pressed, creates a new issue on GitHub, copies over all

the messages, attachments, and creates/adds label for the

existing fields. Permissions will also need to be tweaked

to make individual issues read-only once they are migrated,

and to prevent users to create new accounts.

* The issues will be split between two trackers; searching issues

will take significant more effort.

* The conversion from Roundup to GitHub is lossy, unless all

the bpo fields are converted into labels or preserved somewhere

else.

* bpo converts a number of references into links, including

issue, message, and PR IDs, changeset numbers, legacy SVN

revision numbers, paths to files in the repo, files in

tracebacks (detecting the correct branch), links to devguide

pages and sections [#]_. This happens when messages are

requested so it is possible to create the correct link (e.g.

all the file links used to point to hg.python.org and now

point to GitHub).

If the links are hardcoded during the migration, it will be

difficult (if not impossible) to change them later. If they

aren't, they will either be lost, or a tool to generate the

links and updating them will need to be written.

* GitHub doesn't provide a way to set and preserve issue IDs

if they are migrated automatically with the use of a button.

(Some projects managed to preserve the IDs by contaacting

the GitHub staff and migrating the issues *en masse*.)

* On top of the work and changes required to migrate to GitHub

issues, we will still need to keep running and maintaining

Roundup, for both our instance (read-only) and for the Jython

has several issues, but there are also other issues that will

need to be addressed regardless of the approach used:

* **Vendor lock-in.** GitHub is properietary and there is risk

of vendor lock-in. Their business model might change and they

could shut down altogether. For example, several projects

decided to move away from GitHub after Microsoft acquisition.

If/when the repository is no longer available on GitHub, we will

be forced to migrate again and all the links to the issues won't

work anymore.

* **Required bpo updates.** bpo will need to be updated in order

to add a button that, once pressed, creates a new issue on

GitHub, copies over all the messages, attachments, and

creates/adds labels for the existing fields. Permissions will

also need to be tweaked to make individual issues read-only

once they are migrated, and to prevent users to create new

accounts. It might be necessary to set up redirects (see below).

* **Two trackers.** If issues are migrated on demand, the issues

will be split between two trackers. Referencing and searching

issues will take significant more effort.

* **Lossy conversion.** GitHub only mechanism to add custom metadata

is through labels. bpo uses a number of fields to specify several

different metadata. Preserving all fields and values will result

in too many labels. If only some fields and values are preserved

the others will be lost (unless there is a way to preserve them

elsewhere).

* **Issue IDs preservation.** GitHub doesn't provide a way to

set and preserve the ID of migrated issues. Some projects managed

to preserve the IDs by contacting the GitHub staff and migrating

the issues *en masse*. However, this is no longer possible, since

PRs and issues share the same namespace and PRs already use

existing bpo issue IDs.

* **Internal issue links preservation.** Existing issues might

contain references to other issues in messages and fields (e.g.

dependencies or superseder). Since the issue ID will change

during the migration, these will need to be updated. If the

issues are migrated on demand, all the existing internal

references to the migrated issues (on both bpo and GitHub issues)

will have to be updated.

Setting up a redirect for each migrated issue on bpo might

mitigate the issue, however -- if references in migrated messages

are not updated -- it will cause confusion (e.g. if bpo issue

`#1234` becomes GitHub issue `#4321`, a reference to `#1234`

in a migrated message could link to bpo `#1234` and bpo can

redirect to GitHub issue `#4321`, but new references to `#1234`

will link to GitHub PR `#1234` rather than GitHub issue `#4321`).

Manually having to specify a `bpo-` or `gh-` prefix is error prone.

* **External issue links preservation.** A number of websites,

mails, etc. link to bpo issues. If bpo is shut down, these links

will break. If we don't want to break the links, we will have to

keep bpo alive and set up a redirect system that links to the

corresponding GitHub issue.

In addition, if GitHub shuts down, we won't have any way to setup

redirects and preserve external links to GitHub issues.

* **References preservation and updating.** In addition to issue

references, bpo converts a number of other references into links,

including message and PR IDs, changeset numbers, legacy SVN

revision numbers, paths to files in the repo, files in tracebacks

(detecting the correct branch), and links to devguide pages and

sections [#]_.

Since Roundup converts references to links when messages are

requested, it is possible to update the target and generate the

correct link. This need already arised several times, for

example: files and HG changesets moved from `hg.python.org` to

GitHub and the devguide moved from `docs.python.org/devguide` to

`devguide.python.org`.

Since messages on GitHub are static, the links will need to be

generated and hardcoded during the migration or they will be lost.

In order to update them, a tool to find all references and

regenerate the links will need to be written.

* **Roundup and bpo maintenance.** On top of the aforementioned

changes to bpo and development of tools required to migrate to

GitHub issues, we will still need to keep running and maintaining

Roundup, both for our bpo instance (read-only) and for the Jython

and Roundup trackers (read-write).

Even if eventually we migrate all bpo issues to GitHub and we stop

maintaining Jython and Roundup, bpo will need to be maintained

and redirect to the corresponding GitHub issues.

In addition to the issues listed in the "Open issues" section of

:pep:`588`, this issues will need to be addressed:

* **Bots maintenance.** Since it's not possible to customize GitHub

directly, it's also necessary to write, maintain, and host bots.

Even if eventually we stop maintaining Roundup, the maintenance

burden simply shifted from Roundup to the bots. Hosting each

different bot also has a monetary cost.

* GitHub is properietary and there is risk of vendor lock-in.

Their business model might change and they could shut down

altogether.

* **Using issue templates.** Manually editing issue templates to

"remove texts that don't apply to [the] issue" is cumbersome and

error-prone.

* Switching to GitHub Issues will likely increase the number of

invalid reports and increase the triaging effort. This concern

has been raised in the past in a Zulip topic [#]_.

* **Signal to noise ratio.** Switching to GitHub Issues will

likely increase the number of invalid reports and increase

the triaging effort. This concern has been raised in the past

in a Zulip topic [#]_.

There have been already cases where people posted comments on

PRs that required moderators to mark them as off-topic or

disruptive, delete them altogether, and even lock the

conversation [#]_.

* Roundup sends weekly reports to python-dev with a summary that

includes new issues, recent issues with no replies, recent

issues waiting for review, most discussed issues, closed issues,

and deltas for open/closed/total issue counts [#]_. The report

provides an easy way to keep track of the tracker activity and

to make sure that issues that require attention are noticed.

* **Weekly tracker reports and stats.** Roundup sends weekly reports

to python-dev with a summary that includes new issues, recent

issues with no replies, recent issues waiting for review, most

discussed issues, closed issues, and deltas for open/closed/total

issue counts [#]_. The report provides an easy way to keep track

of the tracker activity and to make sure that issues that require

attention are noticed.

The data collect by the weekly report is also use to generate

statistics and graphs that can be used to gain new insights [#]_.

* There are currently two mailing lists where Roundup posts new

tracker issues and all messages respectively: new-bugs-announce

[#]_ and python-bugs-list [#]_. A new system will need to be

developed to preserve this functionality. These MLs offer

additional ways to keep track of the tracker activity.

* **bpo-related MLs.** There are currently two mailing lists where

bpo posts new tracker issues and all messages respectively:

`new-bugs-announce` [#]_ and `python-bugs-list` [#]_. A new system

will need to be developed to preserve this functionality. These MLs

offer additional ways to keep track of the tracker activity.

References