configure, Makefile.in, config.guess & config.sub
Are static, included copies of code that should always be rebuild during build. If they are not rebuild at build time, it should be documented/automated the relevant helpers that are needed to rebuild the package. If they are failing to rebuild it’s RC since source code is provided that is effectively cannot be modified in the preferred form. They also should not be modified in patch form, as editing generated code is not preferred form of modification. Also it constantly hurts us when bringing up new kernels and architectures (recently kfreebsd, armhf, aarch64). dh_autoreconf is a great tool to achieve thiis s.

no native packages
Generally if software is useful in Debian Project it can be useful for other debian-like and unlike projects. In particular native packages do not offer the same patching flexibility as 3.0 (quilt), thus forcing downstream distributions to inline modify packages without DEP-3 headers. This hurts us, when  trying to merge useful stuff from derivatives back into Debian, as changes are not split into individual patches.

shared maintainership
I’d like to put all my packages under “Debian Developers ” maintainership. There is no need for NMU, QA, TEAM upload. If you have a patch, I don’t want a bug in BTS nor commits, I’d like you to simply upload it into the archive. Especially blanket changes must be welcomed across the whole archive: translations, unit tests, porting to new debhelper versions, FTBFS fixes against next versions of compilers and interpreters, multiarch & cross-building fixes, porting to latest best packaging practices.

ps. comments are turned off. All further discussion is redirected to your choice of: debian-devel or my personal email.