You can try and reverse how pull requests happen.
- Go to your fork
Issue a Pull Request
By default this will be your fork on the right (head repo) requesting to push its commits and changes to the original repo (base repo) on the left.
Click the drop down for both base repo and head repo and select each other's repos.
You want yours listed on the left (accepting changes) while the original repository is on the right (the one with changes to push). As illustrated in this image:
![fork done over itself](https://i.stack.imgur.com/qy04n.png)
Send the pull request
If your fork has not had any changes, you should be able to automatically accept the merge.
If your code somehow conflicts or is not quite clean enough, then this will not work to update via the GitHub web interface and you will need grab the code and resolve any conflicts on your machine before pushing back to your fork.
You could define different groups of labels like issue types, issue priorities, issue statuses, version tags, and maybe more. In order to be able to see instantly to which group a label belongs to you could use a naming convention like :.
Using such a naming convention should make managing Github issues much easier and helps others to "understand" issues much faster. Note that you can also assign colors to labels which can add even more to readability (I would use a specific color for each label group). But because you still have to assign/unassign those labels to/from issues manually you might want to keep the overall list of groups/labels small.
According to the scheme suggested above you might define groups and corresponding labels as follows.
'issue type' group
type:bug
type:feature
type:idea
type:invalid
type:support
type:task
'issue priority' group
prio:low
prio:normal
prio:high
'issue status' group
(These labels describe an issue's state in a defined workflow.)
status:confirmed
status:deferred
status:fix-committed
status:in-progress
status:incomplete
status:rejected
status:resolved
'issue information' group
info:feedback-needed
info:help-needed
info:progress-25
info:progress-50
info:progress-75
'version tag' group
ver:1.x
ver:1.1
Best Answer
There is an Issues API. To get all issues from a repo, you can use cURL:
This returns a JSON encoded list of all issues. And …
… returns all open issues. Now you just have to convert the JSON to CSV and you are set.