Opening gh issues in miq repos

Developers
#1

As more and more repos are split out, and not in a vertical way (vertical = all code including server, ui, etc of to provider X belongs to a single repo), it is becoming much harder to file and find opened issues that are relevant for a several topic:

  1. Filing issues against the correct repo (especially by non devs who are less familiar with the relevant code locations, but not only) becomes somewhat mission impossible.

  2. Finding the relevant provider issues in ~5 repos in parallel,
    especially if they are not tagged (labeled) properly becomes also a big challenge.

any suggestions to solve this are welcome.

cc @chessbyte @fryguy @blomquisg

#2

example: https://github.com/ManageIQ/manageiq/issues/15764
reshuffling issues between repos is also tedious.

#3

For finding issues or PR mentioning ruby 2.4, you can just search the org like this:

https://github.com/issues?utf8=✓&q=org%3AManageIQ+ruby+2.4+

For PRs:
https://github.com/issues?utf8=✓&q=org%3AManageIQ+ruby+2.4+is%3Apr

etc.

To move issues:

@miq-bot move_issue manageiq-ui-classic

As an example:

See: New bot features: Moving and closing Github issues

#4

I should have also linked to the github searching issues/PRs doc:

https://help.github.com/articles/searching-issues-and-pull-requests/

#5

thanks @jrafanie.
I know how to move issues from one repo to another.
It is just there is a high possibility that it needs to be done too frequently with all those multiple issues filed against multiple repos.
in addition, if you know that you search for “ruby” - that task is easy.
But in a provider case, you might find yourself searching for: hawkular, middleware, datasource, deployment, eap - a very long list of terms. again - super time consuming.
The fact a lot of issues are not labeled, or labeled incorrectly does not help in the search task either.

#6

@abonas How are you hoping to solve missing labels other than having people properly label issues and PRs? Yes, splitting code into repos makes issue/PR management harder so we have to double our efforts to properly label things as they’re triaged.

#7
  1. I would separate the challenge of labeling issues and PRs. in PRs you can at least partially rely on changed files to label. In issues you can’t. Unless we do some bot based on keywords :slight_smile:
  2. I would suggest the core miq teams who are going over the issues would label more and more frequently. I’ve seen a lot of issues (and actually PRs) not labeled properly (including the merged ones) or not triaged/labeled at all for a very long time.
  3. more repos that are split not vertically contribute to this problem. have the repos been split vertically (including all/most layers of code for a topic/provider), this would be less of a problem because then most of the code belonging to topic/provider X would reside in this repo. Then it would be either self explanatory that issues in that repo are relevant to that topic, or easier to label them, and the maintainers of that repo will be notified on the issues anyway.