Ok, that helps. Maybe you want to link or mention which package you are referring to so we can actually see your Github page and what information is obvious or not. I understand the issue with your target audience not being so acquainted with R/Github but I would guess that the best way to increase your feed back would be to try to re-direct them to Github. Potentially you could start re-directing email enquiries to Github issues. Personally, I am more likely to post new issues if I see that people have previously posted issues and they have been responded to. Maybe that could be a starting point. You could compose a email template that you could just copy and paste when receiving emails concerning the package that, kindly, asks that Github issues be used and, if you are worried that the target audience won’t know how they should use issues, a short 1), 2), 3) set of instructions.
In addition, does the URL tag in your description file point to your Github page? Does the BugReports tag point towards issues on your Github page? If not, these could also be obvious places to start. In addition, the README file can be very useful in this case I think. There you can make it clear what users should do if they are experiencing problems, where feedback can be directed, and what kind of feedback you would appreciate. Issues typically seem to be used for bugs and feature requests but, as far as I am concerned, you can also use them for other types of interaction unless you come up with a better platform.