We are all about GitHub on the docs.microsoft.com team. We host documentation there and just recently we launched content feedback that’s storing comments in GitHub issues as well. Today, we moved all site feedback to GitHub as well.
Prior to the move, all our site suggestions and feedback were on UserVoice, and as we kept consolidating the feedback triage locations, site feedback was next in line. But how do we accomplish this?
Manually moving things over was not exactly my style, so I thought I would script it. There were two key things in place that helped me - the UserVoice Python SDK and PyGitHub. You can get the same script that I used by looking at my tools repo.
Following the script, first thing we need to define all the required automation credentials. That is - the API keys.
For UserVoice, you can get that by going to
If you are not using SSO-based authentication, you can safely skip
Once you have the API keys, you can specify them in the string variables I showed above -
For GitHub, you can get a standard Personal Access Token (PAT) via the developer console -
https://github.com/settings/tokens. Make sure that it has repo-level access to be able to create new issues.
Last but not least,
GITHUB_TARGET_REPO should be set to the GitHub repo ID where the issues will be created.
Now, we need to jump to some extra cleanup pre-processing - it so happens that some suggestions contain profanities, and I wanted to make sure that we avoid posting those on GitHub once we move the issues over. After a bit of research, I’ve stumbled across this answer on Stack Overflow that showed how to implement a rudimentary filtering mechanism that works well enough for my scenario.
purifier.py came to life - we can import a new
Now we can initialize both the UserVoice and GitHub clients, and start getting the list of suggestions that were posted:
When getting the list of suggestions, I thought I would get a mirror array that contains only ideas that are still open - that means nothing that’s marked as completed or declined:
Last but not least, once the ideas are ready - moving them over to GitHub is relatively easy with the help of
create_issue - depending on the existing labels you have in your GitHub repo, you can map UserVoice statuses to new GitHub issue labels.
In addition, I’ve also added an attribution string that will be representative of who originally opened the idea - that will be appended to the issue text:
And there we have it!
30 minutes of coding saving hours of manual work - just like automation was supposed to work!
Have any thoughts? Let me know on Twitter!