Re: [Python-Dev] PEP 595: Improving bugs.python.org
On Sat, Jun 1, 2019 at 11:50 AM Antoine Pitrou wrote: > > On Fri, 31 May 2019 11:58:22 -0700 > Nathaniel Smith wrote: > > On Fri, May 31, 2019 at 11:39 AM Barry Warsaw wrote: > > > > > > On May 31, 2019, at 01:22, Antoine Pitrou wrote: > > > > > > > I second this. > > > > > > > > There are currently ~7000 bugs open on bugs.python.org. The Web UI > > > > makes a good job of actually being able to navigate through these bugs, > > > > search through them, etc. > > > > > > > > Did the Steering Council conduct a usability study of Github Issues > > > > with those ~7000 bugs open? If not, then I think the acceptance of > > > > migrating to Github is a rushed job. Please reconsider. > > > > > > Thanks for your feedback Antoine. > > > > > > This is a tricky issue, with many factors and tradeoffs to consider. I > > > really appreciate Ezio and Berker working on PEP 595, so we can put all > > > these issues on the table. > > > > > > I think one of the most important tradeoffs is balancing the needs of > > > existing developers (those who actively triage bugs today), and future > > > contributors. These can be further divided in several groups: from core devs and release managers, to triagers, to regular and occasional contributors, to people that just want to report an issue and be done with it, to people that think the error they just got is a Python bug, each of them with different goals and needs. I think that rather than discussing whether GitHub Issues is better or worse than Roundup, we should first try to understand who is facing what issues now, and who will face what issues after the switch. This can be done both by gathering feedback from different types of people and by testing and comparing the solutions (see below). Once we know what the issues are, we should evaluate if and how we can address them, and also -- if we can't make everyone happy -- what groups of people we want to prioritize (e.g. do we want core devs to be more effective at dealing with the thousands of already existing issues, or we want to make it easier for users to report new bugs?). > > > But this and other UX issues are difficult to compare on our actual data > > > right now. I fully expect that just as with the switch to git, we’ll do > > > lots of sample imports and prototyping to ensure that GitHub issues will > > > actually work for us (given our unique requirements), and to help achieve > > > the proper balance. It does us no good to switch if we just anger all > > > the existing devs. > > > > > > IMHO, if the switch to GH doesn’t improve our workflow, then it > > > definitely warrants a reevaluation. I think things will be better, but > > > let’s prove it. > > > > Perhaps we should put an explicit step on the transition plan, after > > the prototyping, that's "gather feedback from prototypes, re-evaluate, > > make final go/no-go decision"? I assume we'll want to do that anyway, > > and having it formally written down might reassure people. It might > > also encourage more people to actually try out the prototypes if we > > make it very clear that they're going to be asked for feedback. > > Indeed, regardless of the exact implementation details, I think "try > first, decide after" is the right procedure here. > Testing a change of this magnitude is not trivial. I can see several possible options: * using the on-demand approach proposed by PEP 588, a full migration, or some other solution (e.g. parallel, synced trackers); * doing a throwaway test migration (import zero/some/all existing issues, then discard any new message/issue at the end of the test) or using real issues directly (import zero/some/all issues and keep adding real messages/issues); * if we do a test migration and it works, we might need to do a second, real migration, possibly involving the GH staff twice; if it doesn't work, we discard everything and that's it; * if we use real issues, we might need to migrate things back to Roundup if GH doesn't fit our needs and it might be confusing for users; * starting from scratch on GH with new issues (at least initially, for testing purposes) or porting some/all issues from bpo; * if we start from scratch we don't need to write the tools to migrate, but we won't have feedback about searching/navigating through lot of issues; * if we port some/all the issues, we need to write the tools to do it, even if it's just for testing purposes and we end going back to Roundup; * limiting the test to triagers/core-devs, or involve regular users; * if we involve regular users we might get better feedback, but there's risk of confusion (afaik the only way to inform users on GitHub Issues is writing another bot that adds messages) and backlash; * doing separate specific tests (e.g. having a read-only repo with all the issues to test search/navigation, and a separate read-write repo to test issue creation) or a "real-world" test; * some specific tests might be easier to setup (e.g. issue
Re: [Python-Dev] PEP 595: Improving bugs.python.org
On Fri, 31 May 2019 11:58:22 -0700 Nathaniel Smith wrote: > On Fri, May 31, 2019 at 11:39 AM Barry Warsaw wrote: > > > > On May 31, 2019, at 01:22, Antoine Pitrou wrote: > > > > > I second this. > > > > > > There are currently ~7000 bugs open on bugs.python.org. The Web UI > > > makes a good job of actually being able to navigate through these bugs, > > > search through them, etc. > > > > > > Did the Steering Council conduct a usability study of Github Issues > > > with those ~7000 bugs open? If not, then I think the acceptance of > > > migrating to Github is a rushed job. Please reconsider. > > > > Thanks for your feedback Antoine. > > > > This is a tricky issue, with many factors and tradeoffs to consider. I > > really appreciate Ezio and Berker working on PEP 595, so we can put all > > these issues on the table. > > > > I think one of the most important tradeoffs is balancing the needs of > > existing developers (those who actively triage bugs today), and future > > contributors. But this and other UX issues are difficult to compare on our > > actual data right now. I fully expect that just as with the switch to git, > > we’ll do lots of sample imports and prototyping to ensure that GitHub > > issues will actually work for us (given our unique requirements), and to > > help achieve the proper balance. It does us no good to switch if we just > > anger all the existing devs. > > > > IMHO, if the switch to GH doesn’t improve our workflow, then it definitely > > warrants a reevaluation. I think things will be better, but let’s prove > > it. > > Perhaps we should put an explicit step on the transition plan, after > the prototyping, that's "gather feedback from prototypes, re-evaluate, > make final go/no-go decision"? I assume we'll want to do that anyway, > and having it formally written down might reassure people. It might > also encourage more people to actually try out the prototypes if we > make it very clear that they're going to be asked for feedback. Indeed, regardless of the exact implementation details, I think "try first, decide after" is the right procedure here. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 595: Improving bugs.python.org
Nathaniel Smith wrote: On Fri, May 31, 2019 at 11:39 AM Barry Warsaw wrote: On May 31, 2019, at 01:22, Antoine Pitrou wrote: I second this. There are currently ~7000 bugs open on bugs.python.org. The Web UI makes a good job of actually being able to navigate through these bugs, search through them, etc. Did the Steering Council conduct a usability study of Github Issues with those ~7000 bugs open? If not, then I think the acceptance of migrating to Github is a rushed job. Please reconsider. Thanks for your feedback Antoine. This is a tricky issue, with many factors and tradeoffs to consider. I really appreciate Ezio and Berker working on PEP 595, so we can put all these issues on the table. I think one of the most important tradeoffs is balancing the needs of existing developers (those who actively triage bugs today), and future contributors. But this and other UX issues are difficult to compare on our actual data right now. I fully expect that just as with the switch to git, we’ll do lots of sample imports and prototyping to ensure that GitHub issues will actually work for us (given our unique requirements), and to help achieve the proper balance. It does us no good to switch if we just anger all the existing devs. IMHO, if the switch to GH doesn’t improve our workflow, then it definitely warrants a reevaluation. I think things will be better, but let’s prove it. Perhaps we should put an explicit step on the transition plan, after the prototyping, that's "gather feedback from prototypes, re-evaluate, make final go/no-go decision"? I assume we'll want to do that anyway, and having it formally written down might reassure people. It might also encourage more people to actually try out the prototypes if we make it very clear that they're going to be asked for feedback. -n As Barry mentioned, there are many considerations. - Will GitHub provide a similar experience as bpo? Can the features valued by existing developers be served in a suitable way by GitHub issues? - What opportunity costs exist for remaining on bpo? Planning, reporting, integration with services, and accessibility are some. - Chicken and egg question: Are there 7000 open issues because the existing workflow with bpo inhibits acting on open issues with patches? Antoine, as for large projects on GitHub with many issues, TypeScript is a reasonable proxy with close to 4000 open issues yet only 126 open PRs. There are some nice planning things that have been done in the repo https://github.com/microsoft/TypeScript/issues as well as good documentation around their process and workflow. Thanks to Ezio and Berker for raising points in PEP 595. - Carol ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 595: Improving bugs.python.org
On Fri, May 31, 2019 at 11:39 AM Barry Warsaw wrote: > > On May 31, 2019, at 01:22, Antoine Pitrou wrote: > > > I second this. > > > > There are currently ~7000 bugs open on bugs.python.org. The Web UI > > makes a good job of actually being able to navigate through these bugs, > > search through them, etc. > > > > Did the Steering Council conduct a usability study of Github Issues > > with those ~7000 bugs open? If not, then I think the acceptance of > > migrating to Github is a rushed job. Please reconsider. > > Thanks for your feedback Antoine. > > This is a tricky issue, with many factors and tradeoffs to consider. I > really appreciate Ezio and Berker working on PEP 595, so we can put all these > issues on the table. > > I think one of the most important tradeoffs is balancing the needs of > existing developers (those who actively triage bugs today), and future > contributors. But this and other UX issues are difficult to compare on our > actual data right now. I fully expect that just as with the switch to git, > we’ll do lots of sample imports and prototyping to ensure that GitHub issues > will actually work for us (given our unique requirements), and to help > achieve the proper balance. It does us no good to switch if we just anger > all the existing devs. > > IMHO, if the switch to GH doesn’t improve our workflow, then it definitely > warrants a reevaluation. I think things will be better, but let’s prove it. Perhaps we should put an explicit step on the transition plan, after the prototyping, that's "gather feedback from prototypes, re-evaluate, make final go/no-go decision"? I assume we'll want to do that anyway, and having it formally written down might reassure people. It might also encourage more people to actually try out the prototypes if we make it very clear that they're going to be asked for feedback. -n -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 595: Improving bugs.python.org
On May 31, 2019, at 01:22, Antoine Pitrou wrote: > I second this. > > There are currently ~7000 bugs open on bugs.python.org. The Web UI > makes a good job of actually being able to navigate through these bugs, > search through them, etc. > > Did the Steering Council conduct a usability study of Github Issues > with those ~7000 bugs open? If not, then I think the acceptance of > migrating to Github is a rushed job. Please reconsider. Thanks for your feedback Antoine. This is a tricky issue, with many factors and tradeoffs to consider. I really appreciate Ezio and Berker working on PEP 595, so we can put all these issues on the table. I think one of the most important tradeoffs is balancing the needs of existing developers (those who actively triage bugs today), and future contributors. But this and other UX issues are difficult to compare on our actual data right now. I fully expect that just as with the switch to git, we’ll do lots of sample imports and prototyping to ensure that GitHub issues will actually work for us (given our unique requirements), and to help achieve the proper balance. It does us no good to switch if we just anger all the existing devs. IMHO, if the switch to GH doesn’t improve our workflow, then it definitely warrants a reevaluation. I think things will be better, but let’s prove it. -Barry signature.asc Description: Message signed with OpenPGP ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 595: Improving bugs.python.org
On Fri, May 31, 2019 at 1:23 AM Antoine Pitrou wrote: > > I second this. > > There are currently ~7000 bugs open on bugs.python.org. The Web UI > makes a good job of actually being able to navigate through these bugs, > search through them, etc. > > Did the Steering Council conduct a usability study of Github Issues > with those ~7000 bugs open? What I can personally speak to is I work on https://github.com/microsoft/vscode-python for a living and we're at 928 issues. I also interact with and know the team behind https://github.com/microsoft/vscode at 5,439 issues. https://github.com/rust-lang/rust/ is as 4,806. https://github.com/golang/go is at 4,467. Whether it's 928 or 5,439, to me both numbers are well beyond being small enough to remember everything in the repo and having to rely on search, labels, etc. to find anything and it's worked out for me and my team at work. The VS Code team has also never told me that they were unhappy with GitHub for their issue tracker at their scale either (I've chatted to them about their automatic classification bot and they just gave an internal talk on how they manage the project). -Brett > If not, then I think the acceptance of > migrating to Github is a rushed job. Please reconsider. > > Regards > > Antoine. > > > > On Thu, 23 May 2019 22:17:24 +0200 > Ezio Melotti wrote: > > Hello, > > Berker and I have been working on a PEP that suggests we keep using > > and improving bugs.python.org and Roundup instead of switching to > > GitHub Issues as proposed by PEP 581. > > > > The PEP covers: > > * What are the advantages of Roundup over GitHub issues; > > * What features are missing in Roundup and how can we add them; > > * Issues with PEP 581; > > * Issues with the migration plan proposed by PEP 588; > > > > The rendered version of PEP 595 is available at > > https://www.python.org/dev/peps/pep-0595/ > > > > For reference, you can consult PEP 581 and 588 at > > https://www.python.org/dev/peps/pep-0581/ and > > https://www.python.org/dev/peps/pep-0588/ > > > > The full text of the PEP is include below. We are planning to update > > the PEP to include the feedback we receive and to update the status of > > features as we implement them (we also have a Google Summer of Code > > students working on it). > > > > Best Regards, > > Ezio Melotti > > > > > > > > PEP: 595 > > Title: Improving bugs.python.org > > Author: Ezio Melotti , Berker Peksag > > > > Status: Draft > > Type: Process > > Content-Type: text/x-rst > > Created: 12-May-2019 > > > > > > Abstract > > > > > > This PEP proposes a list of improvements to make bugs.python.org > > more usable for contributors and core developers. This PEP also > > discusses why remaining on Roundup should be preferred over > > switching to GitHub Issues, as proposed by :pep:`581`. > > > > > > Motivation > > == > > > > On May 14th, 2019 :pep:`581` has been accepted [#]_ without much > > public discussion and without a clear consensus [#]_. The PEP > > contains factual errors and doesn't address some of the > > issues that the migration to GitHub Issues might present. > > > > Given the scope of the migration, the amount of work required, > > and how it will negatively affect the workflow during the > > transition phase, this decision should be re-evaluated. > > > > > > Roundup advantages over GitHub Issues > > = > > > > This section discusses reasons why Roundup should be preferred > > over GitHub Issues and Roundup features that are not available > > on GitHub Issues. > > > > * **Roundup is the status quo.** Roundup has been an integral > > part of the CPython workflow for years. It is a stable product > > that has been tested and customized to adapt to our needs as the > > workflow evolved. > > > > It is possible to gradually improve it and avoid the disruption > > that a switch to a different system would inevitabily bring to > > the workflow. > > > > * **Open-source and Python powered.** Roundup is an open-source > > project and is written in Python. By using it and supporting > > it, we also support the Python ecosystem. Several features > > developed for bpo have also been ported to upstream Roundup > > over the years. > > > > * **Fully customizable.** Roundup can be (and has been) fully > > customized to fit our needs. > > > > * **Finer-grained access control.** Roundup allows the creation > > of different roles with different permissions (e.g. create, > > view, edit, etc.) for each individual property, and users can > > have multiple roles. > > > > * **Flexible UI.** While Roundup UI might look dated, it is > > convenient and flexible. > > > > For example, on the issue page, each field (e.g. title, type, > > versions, status, linked files and PRs, etc.) have appropriate > > UI elements (input boxes, dropdowns, tables, etc.) that are > > easy to set and also provide a convenient way to get info
Re: [Python-Dev] PEP 595: Improving bugs.python.org
I second this. There are currently ~7000 bugs open on bugs.python.org. The Web UI makes a good job of actually being able to navigate through these bugs, search through them, etc. Did the Steering Council conduct a usability study of Github Issues with those ~7000 bugs open? If not, then I think the acceptance of migrating to Github is a rushed job. Please reconsider. Regards Antoine. On Thu, 23 May 2019 22:17:24 +0200 Ezio Melotti wrote: > Hello, > Berker and I have been working on a PEP that suggests we keep using > and improving bugs.python.org and Roundup instead of switching to > GitHub Issues as proposed by PEP 581. > > The PEP covers: > * What are the advantages of Roundup over GitHub issues; > * What features are missing in Roundup and how can we add them; > * Issues with PEP 581; > * Issues with the migration plan proposed by PEP 588; > > The rendered version of PEP 595 is available at > https://www.python.org/dev/peps/pep-0595/ > > For reference, you can consult PEP 581 and 588 at > https://www.python.org/dev/peps/pep-0581/ and > https://www.python.org/dev/peps/pep-0588/ > > The full text of the PEP is include below. We are planning to update > the PEP to include the feedback we receive and to update the status of > features as we implement them (we also have a Google Summer of Code > students working on it). > > Best Regards, > Ezio Melotti > > > > PEP: 595 > Title: Improving bugs.python.org > Author: Ezio Melotti , Berker Peksag > > Status: Draft > Type: Process > Content-Type: text/x-rst > Created: 12-May-2019 > > > Abstract > > > This PEP proposes a list of improvements to make bugs.python.org > more usable for contributors and core developers. This PEP also > discusses why remaining on Roundup should be preferred over > switching to GitHub Issues, as proposed by :pep:`581`. > > > Motivation > == > > On May 14th, 2019 :pep:`581` has been accepted [#]_ without much > public discussion and without a clear consensus [#]_. The PEP > contains factual errors and doesn't address some of the > issues that the migration to GitHub Issues might present. > > Given the scope of the migration, the amount of work required, > and how it will negatively affect the workflow during the > transition phase, this decision should be re-evaluated. > > > Roundup advantages over GitHub Issues > = > > This section discusses reasons why Roundup should be preferred > over GitHub Issues and Roundup features that are not available > on GitHub Issues. > > * **Roundup is the status quo.** Roundup has been an integral > part of the CPython workflow for years. It is a stable product > that has been tested and customized to adapt to our needs as the > workflow evolved. > > It is possible to gradually improve it and avoid the disruption > that a switch to a different system would inevitabily bring to > the workflow. > > * **Open-source and Python powered.** Roundup is an open-source > project and is written in Python. By using it and supporting > it, we also support the Python ecosystem. Several features > developed for bpo have also been ported to upstream Roundup > over the years. > > * **Fully customizable.** Roundup can be (and has been) fully > customized to fit our needs. > > * **Finer-grained access control.** Roundup allows the creation > of different roles with different permissions (e.g. create, > view, edit, etc.) for each individual property, and users can > have multiple roles. > > * **Flexible UI.** While Roundup UI might look dated, it is > convenient and flexible. > > For example, on the issue page, each field (e.g. title, type, > versions, status, linked files and PRs, etc.) have appropriate > UI elements (input boxes, dropdowns, tables, etc.) that are > easy to set and also provide a convenient way to get info about > the issue at a glance. The number of fields, their values, and > the UI element they use is also fully customizable. > GitHub only provides labels. > > The issue list page presents the issues in a compact and easy > to read table with separate columns for different fields. For > comparison, Roundup lists 50 issues in a screen, whereas GitHub > takes two screens to shows 25 issues. > > * **Advanced search.** Roundup provides an accurate way to search > and filter by using any combination of issue fields. > It is also possible to customize the number of results and the > fields displayed in the table, and the sorting and grouping > (up to two levels). > > bpo also provides predefined summaries (e.g. "Created by you", > "Assigned to you", etc.) and allows the creation of custom > search queries that can be conveniently accessed from the sidebar. > > * **Nosy list autocomplete.** The nosy list has an autocomplete > feature that suggests maintainers and experts. The suggestions > are automatically updated
Re: [Python-Dev] PEP 595: Improving bugs.python.org
On Thu, May 23, 2019 at 10:17 PM Ezio Melotti wrote: > > Hello, > Berker and I have been working on a PEP that suggests we keep using > and improving bugs.python.org and Roundup instead of switching to > GitHub Issues as proposed by PEP 581. > > The PEP covers: > * What are the advantages of Roundup over GitHub issues; > * What features are missing in Roundup and how can we add them; > * Issues with PEP 581; > * Issues with the migration plan proposed by PEP 588; > > The rendered version of PEP 595 is available at > https://www.python.org/dev/peps/pep-0595/ > > For reference, you can consult PEP 581 and 588 at > https://www.python.org/dev/peps/pep-0581/ and > https://www.python.org/dev/peps/pep-0588/ > > The full text of the PEP is include below. We are planning to update > the PEP to include the feedback we receive and to update the status of > features as we implement them (we also have a Google Summer of Code > students working on it). > > Best Regards, > Ezio Melotti > > Hello, earlier today I expanded and reworded the "Migration considerations" section and added the feedback I got from the replies. You can find the rendered version of that section (and the rest of the PEP) at https://www.python.org/dev/peps/pep-0595/#migration-considerations The changeset can be found at https://github.com/python/peps/commit/b3f4c8eb09d1987d00785cad385adf7e0394776e The full text of the latest version of the PEP is included below. Best Regards, Ezio Melotti PEP: 595 Title: Improving bugs.python.org Author: Ezio Melotti , Berker Peksag Status: Draft Type: Process Content-Type: text/x-rst Created: 12-May-2019 Abstract This PEP proposes a list of improvements to make bugs.python.org more usable for contributors and core developers. This PEP also discusses why remaining on Roundup should be preferred over switching to GitHub Issues, as proposed by :pep:`581`. Motivation == On May 14th, 2019 :pep:`581` has been accepted [#]_ without much public discussion and without a clear consensus [#]_. The PEP contains factual errors and doesn't address some of the issues that the migration to GitHub Issues might present. Given the scope of the migration, the amount of work required, and how it will negatively affect the workflow during the transition phase, this decision should be re-evaluated. Roundup advantages over GitHub Issues = This section discusses reasons why Roundup should be preferred over GitHub Issues and Roundup features that are not available on GitHub Issues. * **Roundup is the status quo.** Roundup has been an integral part of the CPython workflow for years. It is a stable product that has been tested and customized to adapt to our needs as the workflow evolved. It is possible to gradually improve it and avoid the disruption that a switch to a different system would inevitabily bring to the workflow. * **Open-source and Python powered.** Roundup is an open-source project and is written in Python. By using it and supporting it, we also support the Python ecosystem. Several features developed for bpo have also been ported to upstream Roundup over the years. * **Fully customizable.** Roundup can be (and has been) fully customized to fit our needs. * **Finer-grained access control.** Roundup allows the creation of different roles with different permissions (e.g. create, view, edit, etc.) for each individual property, and users can have multiple roles. * **Flexible UI.** While Roundup UI might look dated, it is convenient and flexible. For example, on the issue page, each field (e.g. title, type, versions, status, linked files and PRs, etc.) have appropriate UI elements (input boxes, dropdowns, tables, etc.) that are easy to set and also provide a convenient way to get info about the issue at a glance. The number of fields, their values, and the UI element they use is also fully customizable. GitHub only provides labels. The issue list page presents the issues in a compact and easy to read table with separate columns for different fields. For comparison, Roundup lists 50 issues in a screen, whereas GitHub takes two screens to shows 25 issues. * **Advanced search.** Roundup provides an accurate way to search and filter by using any combination of issue fields. It is also possible to customize the number of results and the fields displayed in the table, and the sorting and grouping (up to two levels). bpo also provides predefined summaries (e.g. "Created by you", "Assigned to you", etc.) and allows the creation of custom search queries that can be conveniently accessed from the sidebar. * **Nosy list autocomplete.** The nosy list has an autocomplete feature that suggests maintainers and experts. The suggestions are automatically updated when the experts index [#]_ changes. * **Dependencies and Superseders.** Roundup allows to specify
[Python-Dev] PEP 595: Improving bugs.python.org
Hello, Berker and I have been working on a PEP that suggests we keep using and improving bugs.python.org and Roundup instead of switching to GitHub Issues as proposed by PEP 581. The PEP covers: * What are the advantages of Roundup over GitHub issues; * What features are missing in Roundup and how can we add them; * Issues with PEP 581; * Issues with the migration plan proposed by PEP 588; The rendered version of PEP 595 is available at https://www.python.org/dev/peps/pep-0595/ For reference, you can consult PEP 581 and 588 at https://www.python.org/dev/peps/pep-0581/ and https://www.python.org/dev/peps/pep-0588/ The full text of the PEP is include below. We are planning to update the PEP to include the feedback we receive and to update the status of features as we implement them (we also have a Google Summer of Code students working on it). Best Regards, Ezio Melotti PEP: 595 Title: Improving bugs.python.org Author: Ezio Melotti , Berker Peksag Status: Draft Type: Process Content-Type: text/x-rst Created: 12-May-2019 Abstract This PEP proposes a list of improvements to make bugs.python.org more usable for contributors and core developers. This PEP also discusses why remaining on Roundup should be preferred over switching to GitHub Issues, as proposed by :pep:`581`. Motivation == On May 14th, 2019 :pep:`581` has been accepted [#]_ without much public discussion and without a clear consensus [#]_. The PEP contains factual errors and doesn't address some of the issues that the migration to GitHub Issues might present. Given the scope of the migration, the amount of work required, and how it will negatively affect the workflow during the transition phase, this decision should be re-evaluated. Roundup advantages over GitHub Issues = This section discusses reasons why Roundup should be preferred over GitHub Issues and Roundup features that are not available on GitHub Issues. * **Roundup is the status quo.** Roundup has been an integral part of the CPython workflow for years. It is a stable product that has been tested and customized to adapt to our needs as the workflow evolved. It is possible to gradually improve it and avoid the disruption that a switch to a different system would inevitabily bring to the workflow. * **Open-source and Python powered.** Roundup is an open-source project and is written in Python. By using it and supporting it, we also support the Python ecosystem. Several features developed for bpo have also been ported to upstream Roundup over the years. * **Fully customizable.** Roundup can be (and has been) fully customized to fit our needs. * **Finer-grained access control.** Roundup allows the creation of different roles with different permissions (e.g. create, view, edit, etc.) for each individual property, and users can have multiple roles. * **Flexible UI.** While Roundup UI might look dated, it is convenient and flexible. For example, on the issue page, each field (e.g. title, type, versions, status, linked files and PRs, etc.) have appropriate UI elements (input boxes, dropdowns, tables, etc.) that are easy to set and also provide a convenient way to get info about the issue at a glance. The number of fields, their values, and the UI element they use is also fully customizable. GitHub only provides labels. The issue list page presents the issues in a compact and easy to read table with separate columns for different fields. For comparison, Roundup lists 50 issues in a screen, whereas GitHub takes two screens to shows 25 issues. * **Advanced search.** Roundup provides an accurate way to search and filter by using any combination of issue fields. It is also possible to customize the number of results and the fields displayed in the table, and the sorting and grouping (up to two levels). bpo also provides predefined summaries (e.g. "Created by you", "Assigned to you", etc.) and allows the creation of custom search queries that can be conveniently accessed from the sidebar. * **Nosy list autocomplete.** The nosy list has an autocomplete feature that suggests maintainers and experts. The suggestions are automatically updated when the experts index [#]_ changes. * **Dependencies and Superseders.** Roundup allows to specify dependencies that must be addressed before the current issues can be closed and a superseder issue to easily mark duplicates [#]_. The list of dependencies can also be used to create meta-issues that references several other sub-issues [#]_. Improving Roundup = This section lists some of the issues mentioned by :pep:`581` and other desired features and discusses how they can be implemented by improving Roundup and/or our instance. * **REST API support.** A REST API will make integration with other services and the development of new tools and applications
