PEP 581, 588: Split GitHub migration rationale and plan into two separate PEPs by warsaw · Pull Request #1013 · python/peps (original) (raw)

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.