In the Create Issue dialog allow the users to pick a set of labels wich which will be attached to the issue on creation.
@asaadmahmood Is there a component that can be reused? Maybe the Direct Message member picker?

Yup, we should be able to use react-select.
I also request to be able to pick assignee and milestone in the modal
I'll take this one.
@mickmister @hanzei I have a question about this though:
I also request to be able to pick assignee and milestone in the modal
How do we want to handle the cases where the given label, assignee, or milestone aren't defined in the target repository?
I just manually tested the GitHub API. While you can create new labels on the fly, the request fails if the assignee (contributor) and/or the milestone are not defined.
For instance, here's how the response looks like if the assignee (octocat) is invalid:
{
"message": "Validation Failed",
"errors": [
{
"value": "octocat",
"resource": "Issue",
"field": "assignees",
"code": "invalid"
}
],
"documentation_url": "https://developer.github.com/v3/issues/#create-an-issue"
}
@hanzei @mickmister I've examined the GitHub API reference a bit more and found out that milestones have to be specified by their IDs while creating an issue:
So, we can just type label & assignee names into the "create issue" dialog, but we cannot do the same for milestones.
For instance, we have a milestone called v5.26.0 in the mattermost-server repository:
https://github.com/mattermost/mattermost-server/milestone/62
If you look at the URL, you can see that its ID is 62. We should set that ID in the HTTP POST request if we want to associate the new issue with this milestone, whereas we can just pass label names & assignee names in the form of arrays of strings.
Therefore, if we want to allow users to select a milestone in the "create issue" dialog, we'll have to:
Note — I also checked if the API request we already make for fetching repositories contains the milestone information. It contains a URL but not the list of available milestones:
https://github.com/google/go-github/blob/259aa56b9e3f43b924520fb5b5bc0784a901f90d/github/repos.go#L109
Please let me know your thoughts on how we should scope this issue in the light of this new (at least for me 馃槃) piece of information.
@utkuufuk Having to type assignees and labels by hand is error-prone, and would not be a good experience for the user. I personally think fetching the values for each category is part of this task. It is probably a good idea to consolidate each type of entity being fetched into one React component, then having a wrapper component for each entity (labels, assignees etc).
I've done something similar in the Jira plugin. Here's an example of the consolidated BackendSelector component I've made there, as well as a usage of the component:
<BackendSelector
{...this.props}
search={this.searchAutoCompleteFields}
/>
I think it's appropriate to migrate the BackendSelector component over to the GitHub plugin. The code is intentionally generic so it should be able to be copy&pasted over here. We currently do not have a system set up to share components among the different plugins. If you need help with this, you can comment here, or DM me on https://community.mattermost.com at michael.kochell.
Please let me know your thoughts on this. Thanks for taking a look at this @utkuufuk!
@mickmister Thank you for the clarification, I've sent you a DM on the community server.