You are right that the name input doesn't communicate it's intention really well. Uncle Bob talks about "Boy Scout Rule" in his book Clean Code: "Leave the campground cleaner than you found it." The idea is that if you refactor code every time you touch, it is impossible for the code quality to degrade. So feel free to replace the parameter name to more descriptive one.

I wouldn't necessarily confront my coworker for a single instance like that. If that sort of bad naming conventions are typical in you project, then you should gather your team together and come up with common conventions about naming, style etc. Then after everybody knows the rules, they can be enforced with code reviews.

Still, everybody makes mistakes and nitpicking about one parameter name is not cool :) just fix it and get on with whatever you are doing

Confront the other person? Not so fast. I'd rather see you kick off a group discussion about coding standards, and add a paragraph to the coding standards document (you have one, right?) that specifies that in non-trivial cases, formal parameters should be self documenting.