Good point writing this down! I guess you got the idea because I closed a few issues today. In general, if I close something and you are not happy about my decision, feel free to comment and discuss! I do not want to be the “bad guy” closing all feature requests. Nevertheless, I think that one sometimes needs to be a bit more strict and close requests that totally have a use case – but maybe are a bit too much for an app that is targeted at average podcast listeners.
I am not totally against adding more settings. The thing is, most of the settings that are suggested only help a very limited number of users (for example, synchronizing with a service users need to host themselves). If there is something that I think will help a big number of users (the automatic skip feature would be a recent example), I am more or less okay with adding more settings. I have posted this blog post a few times because it illustrates why adding more options is usually worse for users. From a developer’s perspective, I can recommend reading this article by a GitHub manager. Thanks to the K-9 maintainer cketti for bringing those to my attention.
I do not like this kind of changes, that is right. If the same problem is caused by many providers (web server caching, for example), this can be discussed. If publishers mess up the content of the feeds (invalid xml, invalid URLs, etc), I do not want to encourage them to continue with it by working around the problem.
I would say this is not a “maybe” but a “yes”. What is confusing might be different for each person, though. So in general, before starting to work on something, it is good to create an issue and outline what you plan to do. It can then be discussed with other developers.
This is a big maybe. Now and then, we get a pull request that updates all dependencies or fixes some highlighted issues throughout the project. “Blind” dependency updates usually cause unexpected behavior that manifests long after the PR is merged. Therefore, the work to fix that usually falls back to me. Changes that touch 10+ files to just make something more consistent often cause merge conflicts and confusion later, too. If you already touch a section of the code (some dialog, for example), I am totally happy with cleaning up the related code, even if it is not directly necessary to get the feature or fix working. Just those “spring clean everything” PRs usually cause a lot of additional work.
Again as a reminder: If you do not agree with something I say, you are invited to argue 
My messages are often pretty short and might sound a bit rude. I am that kind of person who is always in a hurry even if nothing needs to be done quickly. I should really try to spend more time to write nice and friendly texts like @keunes. I mean, just compare those two texts that, in the end, say the exactly same thing:
