:robot_face: Mariatta was mentioned, but she's out of open source from March 18th to May 9th, 2019 . Be aware she might not get to this until after PyCon US.
(I'm a bot)

Barry told me to post my email in python-committers here. I'll try to summarize it.

I'm strongly against using GitHub Issues because of the following reasons:

• Github doesn't listen to its users feedback. When you reach out to them, you usually get a "we can't say whether we are going to do this or not" response. Instead, they are busy with adding more important features.
• See issues Allow for the tweaking of the commit title template (or at least to use GH over #, Don't populate (or make it optional) intermediate commits automatically in commit message and can the preserve the author of the original commit in the squash merge? for more examples. Note that the last one is actually a bug.
• We are trying to workaround GitHub's lack of features by creating custom tools. https://github.com/berkerpeksag/cpython-emailer-webhook is a great example to this. I'd rather spend my free time to maintain our infrastructure than trying to workaround a company's product.
• Maintaining our tools that communicate with GitHub also take time. See Don't pass maintainer_can_modify when patching the PR. bedevere#163 for a recent example.

@berkerpeksag can I request you tweak the tone of your comment? It's coming off as unnecessarily hostile.

@brettcannon which part of my comment do you think is hostile?

@berkerpeksag primarily your first bullet point. While you might think GitHub doesn't listen, I don't think that's true but you state it like it's a universal truth. And your last sentence in that point very much comes off as a dig as well. And just because they don't announce features before they launch doesn't mean they don't listen (I say the same things to my users at my work because I know if I over-promise and under-deliver I'm the one they will yell at, so it's easier to just not say anything until something is already released).

@brettcannon I gave two examples from my own experience that they didn't listen (both issues can be classified as bug) in the second bullet point. I'd be happy to combine the first two bullet points if you think that would make my comment better.

And just because they don't announce features before they launch doesn't mean they don't listen

True, but none of my reports were actually feature requests and I definitely don't expect constant communication from them. I don't think it's unreasonable to expect a response like "we are going to fix this in X months" a year after I reported it in a place where they were created to gather feedback from the community.

Github doesn't listen to its users feedback. When you reach out to them, you usually get a "we can't say whether we are going to do this or not" response. Instead, they are busy with adding more important features.

Sorry you had terrible experience, but I think you're generalizing the situation. Personally I've had good experiences with GitHub. Whenever I had issues and questions, they answered within 24 hours. So I think saying "GitHub doesn't listen" doesn't sound fair, or maybe I'm really lucky.

See issues Allow for the tweaking of the commit title template (or at least to use GH over #, Don't populate (or make it optional) intermediate commits automatically in commit message and can the preserve the author of the original commit in the squash merge? for more examples. Note that the last one is actually a bug.

I feel these issues are not related to GitHub-as-issue-tracker, and not the problems that PEP 581 trying to solve, so it seems like a distraction to current topic. I also don't feel the last one as a bug. If miss-islington actually did the work to backport and create the PR, it can earn the credit IMO. The others problems you mentioned here, we've tried to help solve by miss-islington's automerge. If core devs still chose not to use the automerge feature, then I don't know what to say to that...

I'd rather spend my free time to maintain our infrastructure than trying to workaround a company's product.

You're definitely free to choose how you spend your free time. Roundup itself is not going away. It's not officially maintained by Python core developers, although several core developers like yourself maintain it. (thank you!!). I can understand if you're not interested in maintaining other workarounds like bedevere, miss-islington. However these projects are on GitHub and open source, and we already have quite a number of contributions to them from non core developers, so I don't feel there will be an issue.

We are trying to workaround GitHub's lack of features by creating custom tools.

Personally, I think that's the purpose of the APIs, and I actually think it is great that GitHub has a set of nice features, and we can still further customize the experience by building our own tools by utilizing their APIs.