CINXE.COM

<!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <meta name="color-scheme" content="light dark"> <title>PEP 588 – GitHub Issues Migration Plan | peps.python.org</title> <link rel="shortcut icon" href="../_static/py.png"> <link rel="canonical" href="https://peps.python.org/pep-0588/"> <link rel="stylesheet" href="../_static/style.css" type="text/css"> <link rel="stylesheet" href="../_static/mq.css" type="text/css"> <link rel="stylesheet" href="../_static/pygments.css" type="text/css" media="(prefers-color-scheme: light)" id="pyg-light"> <link rel="stylesheet" href="../_static/pygments_dark.css" type="text/css" media="(prefers-color-scheme: dark)" id="pyg-dark"> <link rel="alternate" type="application/rss+xml" title="Latest PEPs" href="https://peps.python.org/peps.rss"> <meta property="og:title" content='PEP 588 – GitHub Issues Migration Plan | peps.python.org'> <meta property="og:description" content="This PEP describes the detailed plan for migrating from Python’s issue tracker on Roundup to GitHub issues. See PEP 581 for rationale and background. PEP 588 also describes the detailed timeline for the migration."> <meta property="og:type" content="website"> <meta property="og:url" content="https://peps.python.org/pep-0588/"> <meta property="og:site_name" content="Python Enhancement Proposals (PEPs)"> <meta property="og:image" content="https://peps.python.org/_static/og-image.png"> <meta property="og:image:alt" content="Python PEPs"> <meta property="og:image:width" content="200"> <meta property="og:image:height" content="200"> <meta name="description" content="This PEP describes the detailed plan for migrating from Python’s issue tracker on Roundup to GitHub issues. See PEP 581 for rationale and background. PEP 588 also describes the detailed timeline for the migration."> <meta name="theme-color" content="#3776ab"> </head> <body> <svg xmlns="http://www.w3.org/2000/svg" style="display: none;"> <symbol id="svg-sun-half" viewBox="0 0 24 24" pointer-events="all"> <title>Following system colour scheme</title> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"> <circle cx="12" cy="12" r="9"></circle> <path d="M12 3v18m0-12l4.65-4.65M12 14.3l7.37-7.37M12 19.6l8.85-8.85"></path> </svg> </symbol> <symbol id="svg-moon" viewBox="0 0 24 24" pointer-events="all"> <title>Selected dark colour scheme</title> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"> <path stroke="none" d="M0 0h24v24H0z" fill="none"></path> <path d="M12 3c.132 0 .263 0 .393 0a7.5 7.5 0 0 0 7.92 12.446a9 9 0 1 1 -8.313 -12.454z"></path> </svg> </symbol> <symbol id="svg-sun" viewBox="0 0 24 24" pointer-events="all"> <title>Selected light colour scheme</title> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"> <circle cx="12" cy="12" r="5"></circle> <line x1="12" y1="1" x2="12" y2="3"></line> <line x1="12" y1="21" x2="12" y2="23"></line> <line x1="4.22" y1="4.22" x2="5.64" y2="5.64"></line> <line x1="18.36" y1="18.36" x2="19.78" y2="19.78"></line> <line x1="1" y1="12" x2="3" y2="12"></line> <line x1="21" y1="12" x2="23" y2="12"></line> <line x1="4.22" y1="19.78" x2="5.64" y2="18.36"></line> <line x1="18.36" y1="5.64" x2="19.78" y2="4.22"></line> </svg> </symbol> </svg> <script> document.documentElement.dataset.colour_scheme = localStorage.getItem("colour_scheme") || "auto" </script> <section id="pep-page-section"> <header> <h1>Python Enhancement Proposals</h1> <ul class="breadcrumbs"> <li><a href="https://www.python.org/" title="The Python Programming Language">Python</a> » </li> <li><a href="../pep-0000/">PEP Index</a> » </li> <li>PEP 588</li> </ul> <button id="colour-scheme-cycler" onClick="setColourScheme(nextColourScheme())"> <svg aria-hidden="true" class="colour-scheme-icon-when-auto"><use href="#svg-sun-half"></use></svg> <svg aria-hidden="true" class="colour-scheme-icon-when-dark"><use href="#svg-moon"></use></svg> <svg aria-hidden="true" class="colour-scheme-icon-when-light"><use href="#svg-sun"></use></svg> <span class="visually-hidden">Toggle light / dark / auto colour theme</span> </button> </header> <article> <section id="pep-content"> <h1 class="page-title">PEP 588 – GitHub Issues Migration Plan</h1> <dl class="rfc2822 field-list simple"> <dt class="field-odd">Author<span class="colon">:</span></dt> <dd class="field-odd">Mariatta <mariatta at python.org></dd> <dt class="field-even">BDFL-Delegate<span class="colon">:</span></dt> <dd class="field-even">Barry Warsaw <barry at python.org></dd> <dt class="field-odd">Discussions-To<span class="colon">:</span></dt> <dd class="field-odd"><a class="reference external" href="https://discuss.python.org/t/13791">Discourse thread</a></dd> <dt class="field-even">Status<span class="colon">:</span></dt> <dd class="field-even"><abbr title="Accepted and implementation complete, or no longer active">Final</abbr></dd> <dt class="field-odd">Type<span class="colon">:</span></dt> <dd class="field-odd"><abbr title="Non-normative PEP containing background, guidelines or other information relevant to the Python ecosystem">Informational</abbr></dd> <dt class="field-even">Created<span class="colon">:</span></dt> <dd class="field-even">27-Mar-2019</dd> </dl> <hr class="docutils" /> <section id="contents"> <details><summary>Table of Contents</summary><ul class="simple"> <li><a class="reference internal" href="#abstract">Abstract</a></li> <li><a class="reference internal" href="#migration-plan">Migration Plan</a><ul> <li><a class="reference internal" href="#hire-a-professional-project-manager">Hire a professional project manager</a></li> <li><a class="reference internal" href="#create-a-playground-cpython-issue-tracker-on-github">Create a playground CPython issue tracker on GitHub</a></li> <li><a class="reference internal" href="#backup-of-github-data">Backup of GitHub data</a></li> <li><a class="reference internal" href="#update-the-cla-host">Update the CLA host</a></li> <li><a class="reference internal" href="#create-python-triage-team-on-github">Create “Python Triage” team on GitHub</a></li> <li><a class="reference internal" href="#create-labels-for-issue-triage">Create labels for issue triage</a></li> <li><a class="reference internal" href="#create-issue-templates">Create issue templates</a></li> <li><a class="reference internal" href="#updates-to-bedevere">Updates to bedevere</a></li> <li><a class="reference internal" href="#update-the-devguide">Update the devguide</a></li> <li><a class="reference internal" href="#add-a-button-in-bpo-to-migrate-the-issue-to-github">Add a button in bpo to migrate the issue to GitHub</a></li> <li><a class="reference internal" href="#migrated-issues">Migrated issues</a></li> <li><a class="reference internal" href="#make-bpo-read-only">Make bpo read-only</a></li> <li><a class="reference internal" href="#mapping-between-issues-from-bpo-and-github">Mapping between issues from bpo and GitHub</a></li> <li><a class="reference internal" href="#nosy-ing-the-expert">Nosy-ing the expert</a></li> </ul> </li> <li><a class="reference internal" href="#open-issues">Open issues</a><ul> <li><a class="reference internal" href="#a-github-account-should-not-be-a-requirement">A GitHub account should not be a requirement</a></li> <li><a class="reference internal" href="#trim-off-the-components-list">Trim off the “Components” list</a></li> <li><a class="reference internal" href="#priority-list">Priority list</a></li> </ul> </li> <li><a class="reference internal" href="#further-questions-and-discussions">Further questions and discussions</a></li> <li><a class="reference internal" href="#acknowledgements">Acknowledgements</a></li> <li><a class="reference internal" href="#references">References</a></li> <li><a class="reference internal" href="#copyright">Copyright</a></li> </ul> </details></section> <div class="pep-banner canonical-doc sticky-banner admonition important"> <p class="admonition-title">Important</p> <p>This PEP is a historical document. The up-to-date, canonical documentation can now be found at <a class="reference external" href="https://github.com/psf/gh-migration/issues/13">psf/gh-migration#13</a>.</p> <p class="close-button">×</p> <p>The migration was carried out in April 2022.</p> <p>See <a class="pep reference internal" href="../pep-0001/" title="PEP 1 – PEP Purpose and Guidelines">PEP 1</a> for how to propose changes.</p> </div> <section id="abstract"> <h2><a class="toc-backref" href="#abstract" role="doc-backlink">Abstract</a></h2> <p>This PEP describes the detailed plan for migrating from Python’s issue tracker on Roundup to GitHub issues. See <a class="pep reference internal" href="../pep-0581/" title="PEP 581 – Using GitHub Issues for CPython">PEP 581</a> for rationale and background. <a class="pep reference internal" href="../pep-0588/" title="PEP 588 – GitHub Issues Migration Plan">PEP 588</a> also describes the detailed timeline for the migration.</p> </section> <section id="migration-plan"> <h2><a class="toc-backref" href="#migration-plan" role="doc-backlink">Migration Plan</a></h2> <p>Here we outline the tasks, steps, and core decisions we need to make in order to migrate bug tracking to GitHub, with the least impact on CPython developer productivity.</p> <section id="hire-a-professional-project-manager"> <h3><a class="toc-backref" href="#hire-a-professional-project-manager" role="doc-backlink">Hire a professional project manager</a></h3> <p>Having a professional project manager to handle the migration, similar to how the Warehouse project was managed, would help ensure the success of this project.</p> </section> <section id="create-a-playground-cpython-issue-tracker-on-github"> <h3><a class="toc-backref" href="#create-a-playground-cpython-issue-tracker-on-github" role="doc-backlink">Create a playground CPython issue tracker on GitHub</a></h3> <p>We should create a playground issue tracker on GitHub where we can experiment and test out the new workflow.</p> </section> <section id="backup-of-github-data"> <h3><a class="toc-backref" href="#backup-of-github-data" role="doc-backlink">Backup of GitHub data</a></h3> <p>This effort has been started and is being tracked as an issue in core-workflow <a class="footnote-reference brackets" href="#id7" id="id1">[1]</a>. We’re using GitHub’s Migrations API <a class="footnote-reference brackets" href="#id8" id="id2">[2]</a> to download GitHub data for CPython on a daily basis. The archives will be dropped in a S3 bucket.</p> <p>Thanks to Ee Durbin for working on this.</p> </section> <section id="update-the-cla-host"> <h3><a class="toc-backref" href="#update-the-cla-host" role="doc-backlink">Update the CLA host</a></h3> <p>At the moment, the CLA is hosted within bpo. It needs to be updated such that signing the CLA does not require a bpo account, and it should be hosted outside of the bpo.</p> <p>The current CLA process itself is not ideal. Currently, contributors to devguide, peps, and core-workflow need to sign a CLA, and it requires a bpo account. A bpo account should not be required for those projects.</p> <p>There is an ongoing effort to start using our own instance of CLA assistant instead of the current CLA process in place. Discussion about this has been started in <a class="reference external" href="https://mail.python.org/archives/list/core-workflow@python.org/thread/JBV3XJVD2DLDX5DY7TZEA6CO5YPNHJ2C/">core-workflow mailing list</a> as well as on <a class="reference external" href="https://discuss.python.org/t/using-cla-assistant-for-python/990">Discourse</a>.</p> <p>This effort <a class="reference external" href="https://discuss.python.org/t/cla-assistant-is-no-go/2066/">is currently stalled</a> because cla-assistant does not yet support CLA signed on behalf of organization.</p> </section> <section id="create-python-triage-team-on-github"> <h3><a class="toc-backref" href="#create-python-triage-team-on-github" role="doc-backlink">Create “Python Triage” team on GitHub</a></h3> <p>The bug triagers on bpo are valuable to the core Python workflow, and we definitely would need even more help with triaging issues on GitHub.</p> <p>It has been <a class="reference external" href="https://discuss.python.org/t/proposal-create-bug-triage-team-on-github/992/5">proposed on Discourse</a> for us to create a “bug triage” team on GitHub to help with closing issues, notifying the appropriate parties, as well as applying labels to issues and pull requests.</p> <p>The new Triage role on GitHub is currently in beta, and the Python organization has been granted access to this role, and we can begin taking advantage of it.</p> <p>The “Python Triage” team has been created. A description and expectations of the triage role <a class="reference external" href="https://devguide.python.org/triaging/#python-triage-team">have been added to Devguide</a>.</p> <p>Progress of this project can be tracked in <a class="reference external" href="https://github.com/python/core-workflow/projects/3">“Adding Triagers” project board</a>.</p> </section> <section id="create-labels-for-issue-triage"> <h3><a class="toc-backref" href="#create-labels-for-issue-triage" role="doc-backlink">Create labels for issue triage</a></h3> <p>In bpo, we currently have the following fields for each issue:</p> <p>Types: <code class="docutils literal notranslate"><span class="pre">behavior</span></code>, <code class="docutils literal notranslate"><span class="pre">crash</span></code>, <code class="docutils literal notranslate"><span class="pre">compile</span> <span class="pre">error</span></code>, <code class="docutils literal notranslate"><span class="pre">resource</span> <span class="pre">usage</span></code>, <code class="docutils literal notranslate"><span class="pre">security</span></code>, <code class="docutils literal notranslate"><span class="pre">performance</span></code>, <code class="docutils literal notranslate"><span class="pre">enhancement</span></code>.</p> <p>Components: <code class="docutils literal notranslate"><span class="pre">2to3</span></code>, <code class="docutils literal notranslate"><span class="pre">Argument</span> <span class="pre">Clinic</span></code>, <code class="docutils literal notranslate"><span class="pre">asyncio</span></code>, <code class="docutils literal notranslate"><span class="pre">Build</span></code>, <code class="docutils literal notranslate"><span class="pre">Cross-build</span></code>, <code class="docutils literal notranslate"><span class="pre">ctypes</span></code>, …</p> <p>Priority: <code class="docutils literal notranslate"><span class="pre">release</span> <span class="pre">blocker</span></code>, <code class="docutils literal notranslate"><span class="pre">deferred</span> <span class="pre">blocker</span></code>, <code class="docutils literal notranslate"><span class="pre">critical</span></code>, <code class="docutils literal notranslate"><span class="pre">high</span></code>, <code class="docutils literal notranslate"><span class="pre">normal</span></code>, <code class="docutils literal notranslate"><span class="pre">low</span></code></p> <p>We will create the corresponding labels:</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="nb">type</span><span class="o">-</span><span class="n">behavior</span><span class="p">,</span> <span class="nb">type</span><span class="o">-</span><span class="n">crash</span><span class="p">,</span> <span class="nb">type</span><span class="o">-</span><span class="nb">compile</span> <span class="n">error</span><span class="p">,</span> <span class="nb">type</span><span class="o">-</span><span class="n">resource</span> <span class="n">usage</span><span class="p">,</span> <span class="o">...</span> <span class="n">components</span><span class="o">-</span><span class="mi">2</span><span class="n">to3</span><span class="p">,</span> <span class="n">components</span><span class="o">-</span><span class="n">argument</span> <span class="n">clinic</span><span class="p">,</span> <span class="n">components</span><span class="o">-</span><span class="n">asyncio</span><span class="p">,</span> <span class="o">...</span> <span class="n">priority</span><span class="o">-</span><span class="n">release</span> <span class="n">blocker</span><span class="p">,</span> <span class="n">priority</span><span class="o">-</span><span class="n">deferred</span> <span class="n">blocker</span><span class="p">,</span> <span class="n">priority</span><span class="o">-</span><span class="n">critical</span><span class="p">,</span> <span class="o">...</span> </pre></div> </div> <p>In addition, we’ll create a <code class="docutils literal notranslate"><span class="pre">needs</span> <span class="pre">triage</span></code> label.</p> <p>The final “labels” to be created can be decided at a later time when it is time to start switching to GitHub issues.</p> <p>A test repository containing all possible labels and color schema has been created by Carol Willing and can be reviewed at <a class="reference external" href="https://github.com/willingc/test-581/labels">https://github.com/willingc/test-581/labels</a>.</p> </section> <section id="create-issue-templates"> <h3><a class="toc-backref" href="#create-issue-templates" role="doc-backlink">Create issue templates</a></h3> <p>We will create an issue template and add the following headers:</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="o">---</span> <span class="n">Type</span><span class="p">:</span> <span class="n">behavior</span> <span class="o">|</span> <span class="n">crash</span> <span class="o">|</span> <span class="nb">compile</span> <span class="n">error</span> <span class="o">|</span> <span class="n">resource</span> <span class="n">usage</span> <span class="p">(</span><span class="n">choose</span> <span class="n">one</span><span class="p">)</span> <span class="n">Components</span><span class="p">:</span> <span class="mi">2</span><span class="n">to3</span> <span class="o">|</span> <span class="n">Argument</span> <span class="n">Clinic</span> <span class="o">|</span> <span class="n">asyncio</span> <span class="o">|</span> <span class="n">Build</span> <span class="o">|</span> <span class="o">...</span> <span class="p">(</span><span class="n">can</span> <span class="n">select</span> <span class="n">more</span> <span class="n">than</span> <span class="n">one</span><span class="p">)</span> <span class="n">Priority</span><span class="p">:</span> <span class="n">release</span> <span class="n">blocker</span> <span class="o">|</span> <span class="n">deferred</span> <span class="n">blocker</span> <span class="o">|</span> <span class="n">critical</span> <span class="o">|</span> <span class="o">...</span> <span class="n">Needs</span> <span class="n">backport</span> <span class="n">to</span><span class="p">:</span> <span class="mf">2.7</span> <span class="o">|</span> <span class="mf">3.6</span> <span class="o">|</span> <span class="mf">3.7</span> <span class="o">---</span> </pre></div> </div> <p>The idea is to allow the issue creator to help us triage the issue. The above values are pre-filled in the template. The issue creator will remove texts that do not apply to their issue.</p> <p>Based on the above headers, bedevere-bot can apply the necessary labels to the issue. If the issue creator did not supply the above headers, the bot will apply the <code class="docutils literal notranslate"><span class="pre">needs</span> <span class="pre">triage</span></code> label. At that point, it will require a core developer to properly label the issue.</p> <p>We can also take advantage of GitHub’s multiple issue template feature, and the ability to automatically set issue assignee and labels by using issue templates.</p> </section> <section id="updates-to-bedevere"> <h3><a class="toc-backref" href="#updates-to-bedevere" role="doc-backlink">Updates to bedevere</a></h3> <p>Bedevere-bot will need to be updated to recognize the issue headers described above and apply the proper labels.</p> <p>Bedevere-bot can also copy over the labels to pull requests that correspond to the issue.</p> </section> <section id="update-the-devguide"> <h3><a class="toc-backref" href="#update-the-devguide" role="doc-backlink">Update the devguide</a></h3> <p>Devguide should be updated with information about the new workflow of using GitHub issues. It can be done as a separate branch, and it should be done ahead of the migration, not after.</p> </section> <section id="add-a-button-in-bpo-to-migrate-the-issue-to-github"> <h3><a class="toc-backref" href="#add-a-button-in-bpo-to-migrate-the-issue-to-github" role="doc-backlink">Add a button in bpo to migrate the issue to GitHub</a></h3> <p>This will require the bpo to be updated. But I believe the effort needed for this is much less than a complete overhaul.</p> <p>We will create a button in bpo, that will copy over the issue description and associated comments into a GitHub issue.</p> <p>We need to add a new status: “moved” with the url of the GitHub issue.</p> <p>We should not be moving all open issues to GitHub. Only when someone is interested in continuing work or discussion about the issue, that the issue should be “moved” to GitHub.</p> </section> <section id="migrated-issues"> <h3><a class="toc-backref" href="#migrated-issues" role="doc-backlink">Migrated issues</a></h3> <p>When an issue is marked as “moved”, this issue should be in read-only mode. bpo should forbid the edition of the issue.</p> </section> <section id="make-bpo-read-only"> <h3><a class="toc-backref" href="#make-bpo-read-only" role="doc-backlink">Make bpo read-only</a></h3> <p>This should be the final step. Once we start using GitHub issues, make bpo read-only, instead of shutting it down. Do not accept new registrations. Do not allow comments or issues to be created.</p> </section> <section id="mapping-between-issues-from-bpo-and-github"> <h3><a class="toc-backref" href="#mapping-between-issues-from-bpo-and-github" role="doc-backlink">Mapping between issues from bpo and GitHub</a></h3> <p>Usually when we reference an issue from bpo, we use bpo-XYZ but with GitHub, we will have a new reference with this format <code class="docutils literal notranslate"><span class="pre">https://github.com/python/cpython/issue/XYZ</span></code>.</p> <p>Because we will migrate the issues from bpo to GitHub, we need to have a new field on bpo for the reference to the issues on GitHub, and the same thing on GitHub for the ‘eventual’ reference from bpo.</p> <p>For GitHub, we need to add <code class="docutils literal notranslate"><span class="pre">origin:</span> <span class="pre">https://bugs.python.org/issueXYZ</span></code>. For bpo, add a new field <code class="docutils literal notranslate"><span class="pre">moved</span> <span class="pre">to:</span> <span class="pre">https://github.com/python/cpython/issue/XYZ</span></code>.</p> </section> <section id="nosy-ing-the-expert"> <h3><a class="toc-backref" href="#nosy-ing-the-expert" role="doc-backlink">Nosy-ing the expert</a></h3> <p>A current functionality in bpo is to automatically nosy people who are listed as an expert of certain area. Several Python core developers have expressed that they prefer not having to subscribe to everything on GitHub, but only getting notified for issues related to their area of interest and expertise.</p> <p>To help with this situation, we can develop a bot that can notify people whenever an issue has been categorized using labels. For example, when an issue was labeled with <code class="docutils literal notranslate"><span class="pre">area-windows</span></code>, the windows experts can be notified. The notification can be in the form of email notification, or @-mention on GitHub.</p> </section> </section> <section id="open-issues"> <h2><a class="toc-backref" href="#open-issues" role="doc-backlink">Open issues</a></h2> <section id="a-github-account-should-not-be-a-requirement"> <h3><a class="toc-backref" href="#a-github-account-should-not-be-a-requirement" role="doc-backlink">A GitHub account should not be a requirement</a></h3> <p>Back when moving the CPython codebase from Mercurial to GitHub was being discussed <a class="footnote-reference brackets" href="#id9" id="id3">[3]</a> <a class="footnote-reference brackets" href="#id10" id="id4">[4]</a>, it was brought up that we still needed to allow uploading of patches on bpo, and that a GitHub account should not be a requirement in order to contribute to Python.</p> <p>If bpo is made read-only, we’ll need to come up with a different solution to allow people to contribute when they don’t have a GitHub account.</p> <p>One solution is to create a new “python-issues” mailing list, similar to the <a class="reference external" href="mailto:docs%40python.org">docs<span>@</span>python<span>.</span>org</a> <a class="footnote-reference brackets" href="#id11" id="id5">[5]</a> mailing list, to allow people to submit their issues there.</p> <p>Related to this, since the migration to GitHub in 2017, I recall one case <a class="footnote-reference brackets" href="#id12" id="id6">[6]</a> where there was a contributor, who submitted a patch to Mercurial and refused to create a GitHub account. Because of this, our bot was unable to detect whether they had signed the CLA. Another person had volunteered to upload their patch to GitHub. But it was still required that both people sign the CLA.</p> <p>That particular situation was complicated. It took up five core developers’ time to investigate and manually check the CLA, causing confusion.</p> </section> <section id="trim-off-the-components-list"> <h3><a class="toc-backref" href="#trim-off-the-components-list" role="doc-backlink">Trim off the “Components” list</a></h3> <p>Is the current “components” list still making sense and relevant? Can the list be shortened?</p> </section> <section id="priority-list"> <h3><a class="toc-backref" href="#priority-list" role="doc-backlink">Priority list</a></h3> <p>Is the current “priority” list useful? Alyssa Coghlan noted that perhaps only <code class="docutils literal notranslate"><span class="pre">release</span> <span class="pre">blocker</span></code> and <code class="docutils literal notranslate"><span class="pre">deferred</span> <span class="pre">blocker</span></code> are useful.</p> </section> </section> <section id="further-questions-and-discussions"> <h2><a class="toc-backref" href="#further-questions-and-discussions" role="doc-backlink">Further questions and discussions</a></h2> <p>You can post questions on Discourse under the <a class="reference external" href="https://discuss.python.org/c/core-workflow">Core-Workflow</a> category.</p> </section> <section id="acknowledgements"> <h2><a class="toc-backref" href="#acknowledgements" role="doc-backlink">Acknowledgements</a></h2> <p>Thanks to Guido van Rossum, Brett Cannon, and Alyssa Coghlan, who were consulted in the early stage and research of this PEP. Their feedback, concerns, input, and ideas have been valuable.</p> </section> <section id="references"> <h2><a class="toc-backref" href="#references" role="doc-backlink">References</a></h2> <aside class="footnote-list brackets"> <aside class="footnote brackets" id="id7" role="doc-footnote"> <dt class="label" id="id7">[<a href="#id1">1</a>]</dt> <dd>Backup GitHub information (<a class="reference external" href="https://github.com/python/core-workflow/issues/20">https://github.com/python/core-workflow/issues/20</a>)</aside> <aside class="footnote brackets" id="id8" role="doc-footnote"> <dt class="label" id="id8">[<a href="#id2">2</a>]</dt> <dd>GitHub’s Migrations API (<a class="reference external" href="https://developer.github.com/v3/migrations/orgs/">https://developer.github.com/v3/migrations/orgs/</a>)</aside> <aside class="footnote brackets" id="id9" role="doc-footnote"> <dt class="label" id="id9">[<a href="#id3">3</a>]</dt> <dd>Python-committers email (<a class="reference external" href="https://mail.python.org/pipermail/python-committers/2015-December/003642.html">https://mail.python.org/pipermail/python-committers/2015-December/003642.html</a>)</aside> <aside class="footnote brackets" id="id10" role="doc-footnote"> <dt class="label" id="id10">[<a href="#id4">4</a>]</dt> <dd>Python-committers email (<a class="reference external" href="https://mail.python.org/pipermail/python-committers/2015-December/003645.html">https://mail.python.org/pipermail/python-committers/2015-December/003645.html</a>)</aside> <aside class="footnote brackets" id="id11" role="doc-footnote"> <dt class="label" id="id11">[<a href="#id5">5</a>]</dt> <dd>docs mailing list (<a class="reference external" href="https://mail.python.org/mailman/listinfo/docs">https://mail.python.org/mailman/listinfo/docs</a>)</aside> <aside class="footnote brackets" id="id12" role="doc-footnote"> <dt class="label" id="id12">[<a href="#id6">6</a>]</dt> <dd>CPython GitHub pull request 1505 (<a class="reference external" href="https://github.com/python/cpython/pull/1505">https://github.com/python/cpython/pull/1505</a>)</aside> </aside> </section> <section id="copyright"> <h2><a class="toc-backref" href="#copyright" role="doc-backlink">Copyright</a></h2> <p>This document has been placed in the public domain.</p> </section> </section> <hr class="docutils" /> <p>Source: <a class="reference external" href="https://github.com/python/peps/blob/main/peps/pep-0588.rst">https://github.com/python/peps/blob/main/peps/pep-0588.rst</a></p> <p>Last modified: <a class="reference external" href="https://github.com/python/peps/commits/main/peps/pep-0588.rst">2024-10-28 18:53:21 GMT</a></p> </article> <nav id="pep-sidebar"> <h2>Contents</h2> <ul> <li><a class="reference internal" href="#abstract">Abstract</a></li> <li><a class="reference internal" href="#migration-plan">Migration Plan</a><ul> <li><a class="reference internal" href="#hire-a-professional-project-manager">Hire a professional project manager</a></li> <li><a class="reference internal" href="#create-a-playground-cpython-issue-tracker-on-github">Create a playground CPython issue tracker on GitHub</a></li> <li><a class="reference internal" href="#backup-of-github-data">Backup of GitHub data</a></li> <li><a class="reference internal" href="#update-the-cla-host">Update the CLA host</a></li> <li><a class="reference internal" href="#create-python-triage-team-on-github">Create “Python Triage” team on GitHub</a></li> <li><a class="reference internal" href="#create-labels-for-issue-triage">Create labels for issue triage</a></li> <li><a class="reference internal" href="#create-issue-templates">Create issue templates</a></li> <li><a class="reference internal" href="#updates-to-bedevere">Updates to bedevere</a></li> <li><a class="reference internal" href="#update-the-devguide">Update the devguide</a></li> <li><a class="reference internal" href="#add-a-button-in-bpo-to-migrate-the-issue-to-github">Add a button in bpo to migrate the issue to GitHub</a></li> <li><a class="reference internal" href="#migrated-issues">Migrated issues</a></li> <li><a class="reference internal" href="#make-bpo-read-only">Make bpo read-only</a></li> <li><a class="reference internal" href="#mapping-between-issues-from-bpo-and-github">Mapping between issues from bpo and GitHub</a></li> <li><a class="reference internal" href="#nosy-ing-the-expert">Nosy-ing the expert</a></li> </ul> </li> <li><a class="reference internal" href="#open-issues">Open issues</a><ul> <li><a class="reference internal" href="#a-github-account-should-not-be-a-requirement">A GitHub account should not be a requirement</a></li> <li><a class="reference internal" href="#trim-off-the-components-list">Trim off the “Components” list</a></li> <li><a class="reference internal" href="#priority-list">Priority list</a></li> </ul> </li> <li><a class="reference internal" href="#further-questions-and-discussions">Further questions and discussions</a></li> <li><a class="reference internal" href="#acknowledgements">Acknowledgements</a></li> <li><a class="reference internal" href="#references">References</a></li> <li><a class="reference internal" href="#copyright">Copyright</a></li> </ul> <br> <a id="source" href="https://github.com/python/peps/blob/main/peps/pep-0588.rst">Page Source (GitHub)</a> </nav> </section> <script src="../_static/colour_scheme.js"></script> <script src="../_static/wrap_tables.js"></script> <script src="../_static/sticky_banner.js"></script> </body> </html>