Steve Kemp holds the opinion that "Debian package maintainers should be able to program/debug handle the language a package is developed in" to be a package maintainer for that software.
Naturally, as a non-C programmer, maintaining multiple packages in Debian of software written in C, I disagree.
Any bug in the software packaged is inherently an upstream bug, and the problem of the upstream author. As a Debian package maintainer, I'm responsible for how the software is packaged and integrates with the rest of the Debian operating system, but I think to make it a requirement to be overly familiar with the code base itself is too onerous.
My view is more that if the Debian package maintainer doesn't have a good relationship with the upstream author, then they should reconsider packaging it (depending on the complexity of the package).
For most of the packages that I maintain, I have a reasonably good relationship with the authors. For dhcp3, I've met with the guys from the ISC a few times, and follow their mailing lists. For dstat, the upstream author is subscribed to the package via the PTS, and pretty much always chimes in on bugs filed by Debian users.
I don't know C, but I can (generally) read it, I can (usually) refit a patch if necessary, and I know how to drive strace (but sadly not GDB terribly well). Having that skill set has served me well enough to date.
That's not to say I don't want to learn C, I've just always been served well enough by a higher level language like Perl, PHP or Python, that I've not felt the need to go cutting my teeth on C (I have always felt less of a man, not being a C hacker, though).
I have a hankering to try and write an application for Asterisk, so that'd require me to do it in C, so maybe I'll get a chance sometime soon.