I am wondering about ways to gather feedback from users of a package. Ideally, you as a developer will hear through questions, issues, and use cases, but for various reasons, this may not be the case.
What are some ways that others gather feedback on a package? I am considering super brief Google Form to Github page to request comments/feedback.
I thought I would take a shot here but I guess there are several things you might want to clarify to get better/more help... Are we talking about a package that is on CRAN/Bioconductor/Github? Or is this a package that you are planning on developing and want some indication that people view it as a good idea? What type of feedback are you interested in having? Concerning the packages functionality? The readability of the code? The utility of the package for a specific target audience?
I have never used Google Form so I can't be a lot of help there but maybe if you can fill in some of the blanks someone will chime in with some useful info.
Thanks for helping me clarify. It's a package on CRAN. I get an email about it about once every two weeks, usually when something has gone wrong. This suggests to me that there's a modest number of people (rough estimate: 2-3) people per week using it, but I have no sign of them using it. I'm interested in how they're using it and how it can be easier for them to use and why, if they stop using it, they do so. So, just general feedback - I think part of the issue is that my audience (educational researchers and a niche of social scientists) is not very familiar with using GitHub in particular and R / R packages in general, and so I'm trying to think through ways to hear from users.
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.
Maybe I should add... I am certainly no expert on feedback. I have one package that has been on Bioconductor for 2 years (?) and I have had 0 feedback. I am not even sure anyone is actually using it BUT some of the things I mentioned are what I have done to try to promote feedback...
These are super helpful tips, thanks.
URL is here: https://github.com/jrosen48/tidyLPA
I think re-directing people (gently) to GitHub issues is a great idea. This way, the feedback/questions are public and can be discovered by folks without directly asking a question. I also like the idea of a brief template for an email.
Completely forgot to add URL/BugReports tags to my DESCRIPTION, I'll do that in the next release.
Completely forgot to add URL/BugReports tags to my DESCRIPTION, I’ll do that in the next release.
usethis::use_github_links() will do this for you, I forget to do it pretty often myself 