PEP 581: (First draft) Using GitHub Issues #681

Mariatta · 2018-06-21T04:11:03Z

No description provided.

vstinner

First review :-)

vstinner · 2018-06-22T10:07:11Z

pep-0581.rst

+  allows you to systematically filter emails.
+
+- Email address can remain hidden by choice.
+


Few more advantages:

Single namespace for issue numbers and pull request numbers: #xxx (instead of bpo-xxx vs GH-xxx). Many people omits bpo- or GH- prefix :-(

Ability to "quote" code using a permalink to lines of code in the Git repository. Example: https://github.com/python/cpython/blob/bcd3a1a18d841338f57c39f6a7de8cf14d0c3e03/Lib/asyncio/base_events.py#L375-L377 creates:

http://haypo.alwaysdata.net/tmp/quote.png

(The URL to the picture is a temporary link, please copy the picture somewhere!)

(the image linked to by @vstinner; attached via drag-drop on GitHub's web UI)

This image is a png image, not a permalink to the code itself. Clicking on the image gets you to the image on a screen by itself, not to the code.

That was just an example from elsewhere, here's one from this repo:

peps/pep0/pep.py

Lines 14 to 19 in 8ace3c5

class PEPError(Exception):

def __init__(self, error, pep_file, pep_number=None):

super(PEPError, self).__init__(error)

self.filename = pep_file

self.number = pep_number

(Markdown: https://github.com/python/peps/blob/8ace3c5e1fa67967824fcf2bcf24435ad3cfef2f/pep0/pep.py#L14-L19)

@terryjreedy The image is a representation of what you get from dropping a link like https://github.com/python/peps/blob/8ace3c5e1fa67967824fcf2bcf24435ad3cfef2f/genpepindex.py#L17-L27 in a message:

peps/genpepindex.py

Lines 17 to 27 in 8ace3c5

from __future__ import absolute_import, with_statement

from __future__ import print_function

import sys

import os

import codecs

from operator import attrgetter

from pep0.output import write_pep0

from pep0.pep import PEP, PEPError

On bpo, I copy-paste the link and then the quote, between "".

https://github.com/python/peps/blob/8ace3c5e1fa67967824fcf2bcf24435ad3cfef2f/genpepindex.py#L4-L5

"Generating the PEP index is a multi-step process. To begin, you must first
parse the PEP files themselves, which in and of itself takes a couple of steps:
"
Given that one wants the complete lines, it is definitely easier to only copy-paste the link to get the same effect.

peps/genpepindex.py

Lines 4 to 5 in 8ace3c5

Generating the PEP index is a multi-step process. To begin, you must first

parse the PEP files themselves, which in and of itself takes a couple of steps:

vstinner · 2018-06-22T10:13:42Z

pep-0581.rst

+
+- APIs we can use to build integrations and automations.
+
+- Ability to attach screenshots and files in pull requests and issues.


Hum, that's a basic feature of Roundup, whereas GitHub only accepts a small set of file formats, no? Last time I tried to attach a file, I got an error because the file format was denied.

Hm perhaps I should say "embed" screenshots, that I can see images directly in the issue, instead of having to click and open a new tab for the image.

vstinner · 2018-06-22T10:15:00Z

pep-0581.rst

+
+- Ability to attach screenshots and files in pull requests and issues.
+
+- Administrators and core developers can edit issues comments and pull requests.


I'm not sure that it's a big difference with bugs.python.org. The difference here is that the GitHub administrators can more easily give bug triage permission: single platform (GitHub) instead of two (GitHub + bugs.python.org). Single user directory.

I cannot edit or delete a message in bpo.
If I made a mistake in my message, I had to post a new message to explain my previous mistake.
In GitHub I can edit my own messages, and core devs can edit everyone's messages.

Github's all or nothing permission model is kind of a hindrance in this case. Right now there are triagers on bpo who aren't core devs, but can help categorize and resolve issues on bpo. Moving to Github means it would be harder to give them access.

vstinner · 2018-06-22T10:16:02Z

pep-0581.rst

+- Core developers don't have to maintain it, giving us more time to focus on
+  the development of Python.
+
+- We can automatically close issues when a PR has been merged [#close-github-issue]_.


We had that previously with Subversion, maybe also with Mercurial. It seems like we lost the feature when we migrated to Git and GitHub, likely because nobody "ported" the feature to Git.

vstinner · 2018-06-22T10:16:34Z

pep-0581.rst

+
+It has a lot of nice features readily available out of the box, that are not
+currently available in Roundup / bpo.
+


I would start by saying that the form is much simpler, so it's easier to report a bug, no?

vstinner · 2018-06-22T10:29:17Z

pep-0581.rst

+
+This should be the final step. Once we start using GitHub issues, make bpo
+readonly, not shut it down.
+Do not accept new registrations. Do not allow comments or issues to be created.


An alternative is to keep bpo: have bpo and GH.

No. Because then we need to support two different workflows and further complicate our life.

To minimize the burden of maintaining two issue reporting/commenting workflows, one for GitHub and one for bpo, the following constraints will be made to bpo when GitHub is used for issues:

Disable new user registration to bpo.

Disable new issue creation on bpo.

Lock comments on existing bpo issues. Additional comments would be done on GitHub with a link to the archival bpo issue.

vstinner · 2018-06-22T10:30:31Z

pep-0581.rst

+In bpo, we currently have the following fields for each issues:
+
+Type: behavior, crash, compile error, resource usage, security, performance, enhancement.
+Components: 2to3, Argument Clinic, asyncio, Build, Cross-build, ctypes, ...


IMHO components will be useful on pull requests are well. We already have "type-doc" label for example. It helps when someone wants to review all documentation PRs for example.

But the opportunity can potentially be taken to trim the component list

I'm for trimming it :) but perhaps we'll need more discussions with other core devs.

Another thread for committers list. I want to keep Idle, Tkinter, Windows, MacOS. We can ask whether anyone still want 2to3, Argument clinis, asyncio, ctypes, and some others.

By using custom labels on GitHub, priority, components, and other bpo fields can be set on issue creation/updating (i.e priority: high, components: asyncio, components: ctypes). For example, adopting a naming convention for labels is a common practice in other open source projects hosted on GitHub.

vstinner · 2018-06-22T10:31:19Z

pep-0581.rst

+
+Type: behavior, crash, compile error, resource usage, security, performance, enhancement.
+Components: 2to3, Argument Clinic, asyncio, Build, Cross-build, ctypes, ...
+Priority: release blocker, deferred blocker, critical, high, normal, low


Ditto: when a PR has no associated bug, priority might be useful on PRs as well. But when a PR has an associated bug, the priority would be redundant and may become inconsistent if only updated on one side :-/

Honestly, I think "release blocker" and "deferred blocker" are the only actually useful priority levels we currently have, and those will always be associated with issues rather than PRs.

vstinner · 2018-06-22T10:32:05Z

pep-0581.rst

+Type: behavior, crash, compile error, resource usage, security, performance, enhancement.
+Components: 2to3, Argument Clinic, asyncio, Build, Cross-build, ctypes, ...
+Priority: release blocker, deferred blocker, critical, high, normal, low
+


We need a field to specify the Python version that should be fixed, like the Python Versions field on bpo.

I think we can use the existing backport labels for that - just set them on the issue to indicate which labels the PR should get.

Yeah I plan to use the existing "needs backport to:" labels. These can be attached to the issue, and later automatically applied to the PR.

Those could be shorted to 'Backport to: x.y'

vstinner · 2018-06-22T10:32:36Z

pep-0581.rst

+
+   priority-release blocker, priority-deferred blocker, priority-critical, ...
+
+In addition, we'll create ``needs triage`` label.


Please elaborate. How do you qualify that a bug is triagged or not?

See "create issue template" below.

If the issue does not have at least one of type-, component, priority-, needs backport to- labels, then bot will apply needs triage label.

I think there is an other issue, currently, there are 2 lists, the contributors and the members. do you think you will add a new list for the 'triage' ? on bpo, my bpo account can change the associated component of an issue, could I do the same here?

ammaraskar · 2018-06-24T09:29:45Z

pep-0581.rst

+Why not other issue tracker
+---------------------------
+
+Using another issue tracker will require yet another learning curve, of having


Using Github to track issues has its own learning curve, do you mean its less steep than other bug trackers?

I meant that since we (existing Python core devs, The PSF, and contributors to Python) have been using GitHub for everything else, there is less learning to do, than if we're to use a different issue tracker.

ammaraskar · 2018-06-24T09:31:38Z

pep-0581.rst

+build out additional integrations and update our bots, but this is something
+we already know how to do.
+
+In order to really improve Roundup / bpo, it needs to first migrate to GitHub,


I think this is really only a concern with the roundup fork, which might not even be necessary anymore. The python-dev repo which hosts our custom plugins for roundup should be able to migrate to git without issue.

ammaraskar · 2018-06-24T09:33:54Z

pep-0581.rst

+account. A bpo account should not be required for those projects.
+
+Currently the CLA process involves real human to manually check the records.
+Question: Will it be possible to completely automate the CLA process, so


This would be a great time to start a thread with PSF legal on this. On the technical side, there are already great projects to handle this like http://clabot.github.io/

I was thinking that this itself might require a separate PEP 😅

ammaraskar · 2018-06-24T09:35:18Z

pep-0581.rst

+Components: 2to3, Argument Clinic, asyncio, Build, Cross-build, ctypes, ...
+Priority: release blocker, deferred blocker, critical, high, normal, low
+
+We will create the corresponding labels::


Hmm, this is a lot of labels. Have you given thought or experimented to see how well the Github interface handles this many labels?

I haven't seen any mention of limit of labels on GitHub anywhere. These are labels created but in really not all of them will be applied to the issue/PR.
In coala we've been working with 65 labels, and we also use bots to automatically categorize PRs.

Aah perfect, you already have a project that has a lot of labels 👍

ammaraskar · 2018-06-24T09:45:46Z

As far as downsides of Github, I think one thing to note is that its pretty much impossible to get them to do anything. This should be a major indicator of that: https://github.com/dear-github/dear-github

This means that we shouldn't really expect anything beyond the current feature set they provide.

ammaraskar · 2018-06-24T09:48:21Z

pep-0581.rst

+
+- We can automatically close issues when a PR has been merged [#close-github-issue]_.
+
+- With more than 28 million users, an open source contributor is more likely


This is a great point and worth highlighting, bpo right now is quite intimidating to people trying to report issues. Unless you've used it for a while the interface is really prehistoric and un-intuitive.

ncoghlan

Really solid proposal that does an excellent job of evaluating the available alternatives (and yeah, there really is an intimidating amount of work involved in getting Roundup up to speed with a modern web experience)

ncoghlan · 2018-07-10T14:09:02Z

pep-0581.rst

+In bpo, we currently have the following fields for each issues:
+
+Type: behavior, crash, compile error, resource usage, security, performance, enhancement.
+Components: 2to3, Argument Clinic, asyncio, Build, Cross-build, ctypes, ...


But the opportunity can potentially be taken to trim the component list

ncoghlan · 2018-07-10T14:10:27Z

pep-0581.rst

+
+Type: behavior, crash, compile error, resource usage, security, performance, enhancement.
+Components: 2to3, Argument Clinic, asyncio, Build, Cross-build, ctypes, ...
+Priority: release blocker, deferred blocker, critical, high, normal, low


Honestly, I think "release blocker" and "deferred blocker" are the only actually useful priority levels we currently have, and those will always be associated with issues rather than PRs.

ncoghlan · 2018-07-10T14:11:35Z

pep-0581.rst

+Type: behavior, crash, compile error, resource usage, security, performance, enhancement.
+Components: 2to3, Argument Clinic, asyncio, Build, Cross-build, ctypes, ...
+Priority: release blocker, deferred blocker, critical, high, normal, low
+


I think we can use the existing backport labels for that - just set them on the issue to indicate which labels the PR should get.

- Add acknowledgement section - Add TBD and additional concerns

- Fix wrong link

Mariatta · 2018-07-10T22:13:51Z

Thanks for all the reviews!

This means that we shouldn't really expect anything beyond the current feature set they provide.

I'm not too concerned. I believe we can work with GitHub as is. This PEP did not mention anything about needing GitHub to provide us additional features.

ammaraskar · 2018-07-11T01:41:34Z

This PEP did not mention anything about needing GitHub to provide us additional features.

Right, I just mean it might be a problem in the future if a new feature is required. Though with how hard it is to build new features into bpo it might be a moot point.

emilyemorehouse · 2018-07-11T20:58:56Z

pep-0581.rst

+
+   priority-release blocker, priority-deferred blocker, priority-critical, ...
+
+In addition, we'll create ``needs triage`` label.


I think it could be helpful to utilize GitHub's multiple issue templates (more info here). I found this to be really helpful on other OSS projects to keep general usage bugs out of the issue tracker by redirecting them elsewhere.

IMO, Babel does this really well (and has great emoji usage too).

terryjreedy

Fix claims about bpo and remove independent issues.

terryjreedy · 2018-07-11T19:52:24Z

pep-0581.rst

+  integrations and applications available from GitHub Marketplace to help with
+  our workflow. New applications are easily installed and enabled.
+
+- Ability to embed screenshots and files in pull requests and issues.


This is misleading at best. Attaching files to bpo issues is a core function, not absent. Listing them together at the top is a major advantage in favor of bpo.

This was discussed above: #681 (comment)

While bpo might support uploading images, you have to click away to view them as opposed to allowing them to be embedded in the issue page.

Images are rare, and at least some I have seen are well or better viewed on a separate tab. And I still prefer them listed with other files. Multi-screen text is definitely better on a new tab.

You can still click them to open them in a new tab on Github, there's not really a concept of a list of attached files to an issue on here though. That goes for images, test scripts etc. You'll have to find the particular comment where it was attached to download it.

This may be better phrased as the ability to drag and drop screenshots and debug log files into GitHub issues and pull requests.

terryjreedy · 2018-07-11T19:54:56Z

pep-0581.rst

+
+- Administrators and core developers can edit issues comments and pull requests.
+
+- Ability to reply to issues and pull request conversations via email.


People can and do reply to bpo messages by email. The main problem is that they often forget to delete the quoted email they are replying to.

This is often caused by not realizing it was an email from a tracker (at least in my case). Having whatever tracker we use make it visually clear that it's an automated tracker notification usually gets me to click through, and not trust the email return path.

terryjreedy · 2018-07-11T19:56:17Z

pep-0581.rst

+
+- Ability to embed screenshots and files in pull requests and issues.
+
+- Administrators and core developers can edit issues comments and pull requests.


A plus for gh issues. I often want to correct mistakes or delete email quotations (see next).

terryjreedy · 2018-07-11T19:57:29Z

pep-0581.rst

+- It supports voting (reactions).
+
+- It supports permalink [2]_, allowing us to quote and copy paste
+  source code easily.


One can embed links in bpo messages, and they are clickable.

The specific type of quoting being talked about here is this one #681 (comment) which bpo does not support. Again, you have to click away to get to the code.

After seeing yours and Zach's proper examples, and trying it for myself, I agree that link + quote of complete lines (typical for code) is easier. But it is pretty easy on bpo. So I would agree with "copy paste source code lines more easily."

Copying partial or complete sentences from docs, with extraneous material before and after the desired quote removed, as it typical for doc issues, requires a separate copy paste on either tracker.

terryjreedy · 2018-07-11T20:23:52Z

pep-0581.rst

+- Email address can remain hidden by choice.
+
+
+Issues with bpo / Roundup


You gave supposed ghi pluses and bpo minuses. For a fair evaluation, we need the opposite.

bpo has a header form with multiple fields, and options for each field listed with the field. This UI design is FAR, FAR superior to the anti-design of just jumbling all options together under Labels.

bpo has a search form, with search fields corresponding to issue header fields. Filling this out is easier than constructing a search command. The results are presented compactly, by default with one line per hit.

bpo log messages are listed separately from user messages so they can easily be reviewed. They are listed compactly, usually just one line per log item.

This UI design is FAR, FAR superior to the anti-design of just jumbling all options together under Labels.

I would agree with this, putting the dropdowns etc in the issue text and having a bot pick them is a little bit lackluster compared to a purpose built form. (There's been an open issue about this as far back as 2014 isaacs/github#148)

terryjreedy · 2018-07-11T20:34:53Z

pep-0581.rst

+
+In bpo, we currently have the following fields for each issues:
+
+Type: behavior, crash, compile error, resource usage, security, performance, enhancement.


This list was once much smaller. We could discuss on committers list whether the added options are really useful.

terryjreedy · 2018-07-11T20:39:10Z

pep-0581.rst

+In bpo, we currently have the following fields for each issues:
+
+Type: behavior, crash, compile error, resource usage, security, performance, enhancement.
+Components: 2to3, Argument Clinic, asyncio, Build, Cross-build, ctypes, ...


Another thread for committers list. I want to keep Idle, Tkinter, Windows, MacOS. We can ask whether anyone still want 2to3, Argument clinis, asyncio, ctypes, and some others.

terryjreedy · 2018-07-11T20:40:45Z

pep-0581.rst

+Type: behavior, crash, compile error, resource usage, security, performance, enhancement.
+Components: 2to3, Argument Clinic, asyncio, Build, Cross-build, ctypes, ...
+Priority: release blocker, deferred blocker, critical, high, normal, low
+


Those could be shorted to 'Backport to: x.y'

terryjreedy · 2018-07-11T22:02:07Z

pep-0581.rst

+
+We should not be moving all open issues to GitHub. Issues with little or no
+activity should just be closed. Issues with no decision made for years should
+just be closed.


No, No, No.

Closing bpo issues is a separate topic from and irrelevant to creating a usable GH cpython issue tracker. It can and has been done without this PEP. More could be done, but not so blindly as you propose. Doing so is a separate discussion, which I won't continue here.

Implementing this PEP is unaffected by bpo issue closures. The main affect of closure is limiting bpo search results. Bpo issue closures do not belong on this PEP and should be removed. Please don't repeat Chris Angelico's mistake of piggybacking a separate proposal onto his main proposal of assignment expressions.

I'm assuming your good intention, but I think your last sentence is unnecessary.

terryjreedy · 2018-07-11T22:02:10Z

pep-0581.rst

+-----------------
+
+This should be the final step. Once we start using GitHub issues, make bpo
+readonly, not shut it down.


It was not practical to use hg and git simultaneously. In my view, and some others, apparently, github was not fully ready to use when the switch was made. I would say not until Miss Islington started doing backports. (They still take more time than on hg, but the difference is tolerable.) The result was that many people stopped patching python for various periods.

It would be practical to have both issue trackers in use for a short time. So I think disabling bpo should wait until the new system has been used and approved by people other than the creators. Unlike with the repository, testing can be done with real issues for cpython PRs.

So I think approval of this PEP should be provisional, subject to final acceptance review, which would then signal 'stop using bpo'. At that point, shut off new registrations and issues, (which could be discourage earlier), and new comments. 'Readonly' should mean that search still works, and that issues can still be closed instead of transferred.

terryjreedy · 2018-07-11T23:41:36Z

pep-0581.rst

+is much less than a complete overhaul.
+
+We will create a button in bpo, that will copy over the issue description
+and associated comments into a GitHub issue.


What about the existing files, which are typically patch files? Create a comment to embed them in? Or put a link to the original in?

willingc

Thanks @Mariatta. You've done a great job of capturing the issues, benefits, and open items in this PEP. I've made some suggestions that may be helpful for the next draft.

willingc · 2018-07-12T15:19:28Z

pep-0581.rst

+GitHub has a lot of nice features readily available out of the box, that are not
+currently available in Roundup / bpo.
+
+- APIs we can use to build integrations and automations. There are various existing


Perhaps add something more specific about creating and deploying bots similar to miss-islington that can provide automation related to CPython-specific workflow.

willingc · 2018-07-12T15:21:35Z

pep-0581.rst

+  integrations and applications available from GitHub Marketplace to help with
+  our workflow. New applications are easily installed and enabled.
+
+- Ability to embed screenshots and files in pull requests and issues.


This may be better phrased as the ability to drag and drop screenshots and debug log files into GitHub issues and pull requests.

willingc · 2018-07-12T15:23:07Z

pep-0581.rst

+
+- It supports two factor authentication.
+
+- It supports markdown and emoji. It has a preview tab, so we can see how our


Perhaps split this into 2 bullets. 1) markdown and emoji and 2) preview before posting

willingc · 2018-07-12T15:25:26Z

pep-0581.rst

+- It supports permalink [2]_, allowing us to quote and copy paste
+  source code easily.
+
+- Core developers don't have to maintain it, giving us more time to focus on


it -> the issue infrastructure/site

willingc · 2018-07-12T15:27:28Z

pep-0581.rst

+
+- We can automatically close issues when a PR has been merged [3]_.
+
+- With more than 28 million users, an open source contributor is more likely


Lowers the barriers to contribution. With more than ...

willingc · 2018-07-12T15:39:38Z

pep-0581.rst

+
+In order to really improve Roundup / bpo, it needs to first migrate to GitHub,
+add CI and bots. As I understand it, there is hesitation because upstream Roundup
+is still im Mercurial. Someone more familiar with Roundup / bpo needs


willingc · 2018-07-12T15:40:33Z

pep-0581.rst

+to download GitHub data for CPython on daily basis. The archives will be
+dropped in an S3 bucket.
+
+Thanks to Ernest W. Durbin III for working on this.


willingc · 2018-07-12T15:48:11Z

pep-0581.rst

+In bpo, we currently have the following fields for each issues:
+
+Type: behavior, crash, compile error, resource usage, security, performance, enhancement.
+Components: 2to3, Argument Clinic, asyncio, Build, Cross-build, ctypes, ...


By using custom labels on GitHub, priority, components, and other bpo fields can be set on issue creation/updating (i.e priority: high, components: asyncio, components: ctypes). For example, adopting a naming convention for labels is a common practice in other open source projects hosted on GitHub.

willingc · 2018-07-12T15:55:59Z

pep-0581.rst

+If a core developer is still interested in the issue, they can indicate so in
+the bpo issue, and later use the button to migrate it over to GitHub.
+
+Make bpo readonly


Move bpo to be an archival, read only project

willingc · 2018-07-12T16:03:03Z

pep-0581.rst

+
+This should be the final step. Once we start using GitHub issues, make bpo
+readonly, not shut it down.
+Do not accept new registrations. Do not allow comments or issues to be created.


To minimize the burden of maintaining two issue reporting/commenting workflows, one for GitHub and one for bpo, the following constraints will be made to bpo when GitHub is used for issues:

Disable new user registration to bpo.

Disable new issue creation on bpo.

Lock comments on existing bpo issues. Additional comments would be done on GitHub with a link to the archival bpo issue.

matrixise · 2018-07-17T14:37:51Z

pep-0581.rst

+
+   priority-release blocker, priority-deferred blocker, priority-critical, ...
+
+In addition, we'll create ``needs triage`` label.


I think there is an other issue, currently, there are 2 lists, the contributors and the members. do you think you will add a new list for the 'triage' ? on bpo, my bpo account can change the associated component of an issue, could I do the same here?

matrixise · 2018-07-17T14:39:50Z

pep-0581.rst

+
+Based on the above headers, bedevere-bot can apply the necessary labels to the
+issue. If issue creator did not supply the above headers, the bot will apply
+``needs triage`` label. At that point it will require a core developer to


a core developer to properly label the issue, and what happens for the bpo accounts with the 'triage' flag? as mine.

the-knights-who-say-ni added the CLA signed label Jun 21, 2018

Mariatta changed the title ~~First draft of Using GitHub Issues~~ PEP 581: (First draft) Using GitHub Issues Jun 21, 2018

vstinner reviewed Jun 22, 2018

View reviewed changes

ammaraskar reviewed Jun 24, 2018

View reviewed changes

Mariatta force-pushed the use-github-issues branch from ae39902 to 078c647 Compare July 10, 2018 03:24

ncoghlan reviewed Jul 10, 2018

View reviewed changes

Mariatta and others added 8 commits July 10, 2018 14:31

First draft of Using GitHub Issues

7f49130

finish the sentence...

3ad7d3b

- Renumbered to PEP 581

ac93b3f

- Add acknowledgement section - Add TBD and additional concerns

Add missing references

b4a3687

fix markup, add further discussions as TBD

c3bbdb3

- Fix several markups

200bda9

- Fix wrong link

Next iteration.

53c13c8

Capitalize Mercurial

699c71e

Capitalize Roundup

4e29974

Mariatta force-pushed the use-github-issues branch from 2b13611 to 4e29974 Compare July 10, 2018 22:19

Mariatta added 4 commits July 11, 2018 10:20

Add Discussions-To header.

41c9021

Add link to #pep581 zulip stream.

2f853f7

Not yet ready for python-dev

425553c

Fix the url to zulip.

478ffc2

emilyemorehouse reviewed Jul 11, 2018

View reviewed changes

terryjreedy requested changes Jul 11, 2018

View reviewed changes

terryjreedy reviewed Jul 11, 2018

View reviewed changes

willingc reviewed Jul 12, 2018

View reviewed changes

matrixise reviewed Jul 17, 2018

View reviewed changes

More updates.

d8631e4

Mariatta merged commit 4a33866 into python:master Aug 14, 2018

Mariatta deleted the use-github-issues branch August 14, 2018 12:15

		allows you to systematically filter emails.

		- Email address can remain hidden by choice.

	class PEPError(Exception):

	def __init__(self, error, pep_file, pep_number=None):
	super(PEPError, self).__init__(error)
	self.filename = pep_file
	self.number = pep_number

	from __future__ import absolute_import, with_statement
	from __future__ import print_function

	import sys
	import os
	import codecs

	from operator import attrgetter

	from pep0.output import write_pep0
	from pep0.pep import PEP, PEPError

	Generating the PEP index is a multi-step process. To begin, you must first
	parse the PEP files themselves, which in and of itself takes a couple of steps:


		- APIs we can use to build integrations and automations.

		- Ability to attach screenshots and files in pull requests and issues.


		- Ability to attach screenshots and files in pull requests and issues.

		- Administrators and core developers can edit issues comments and pull requests.


		It has a lot of nice features readily available out of the box, that are not
		currently available in Roundup / bpo.


		priority-release blocker, priority-deferred blocker, priority-critical, ...

		In addition, we'll create ``needs triage`` label.


		- We can automatically close issues when a PR has been merged [#close-github-issue]_.

		- With more than 28 million users, an open source contributor is more likely


		- Administrators and core developers can edit issues comments and pull requests.

		- Ability to reply to issues and pull request conversations via email.


		- Ability to embed screenshots and files in pull requests and issues.

		- Administrators and core developers can edit issues comments and pull requests.

		- Email address can remain hidden by choice.


		Issues with bpo / Roundup


		In bpo, we currently have the following fields for each issues:

		Type: behavior, crash, compile error, resource usage, security, performance, enhancement.


		- It supports two factor authentication.

		- It supports markdown and emoji. It has a preview tab, so we can see how our

PEP 581: (First draft) Using GitHub Issues #681

PEP 581: (First draft) Using GitHub Issues #681

Conversation

Mariatta commented Jun 21, 2018

vstinner left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ammaraskar Jul 11, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Mariatta Jul 10, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ammaraskar commented Jun 24, 2018

Choose a reason for hiding this comment

ncoghlan left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Mariatta commented Jul 10, 2018

ammaraskar commented Jul 11, 2018

Choose a reason for hiding this comment

terryjreedy left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

willingc left a comment

Choose a reason for hiding this comment

ammaraskar Jul 11, 2018 •

edited

Loading

Mariatta Jul 10, 2018 •

edited

Loading