Consider a different issue tracker solution for GrimoireLab

[GeorgLink]

Proposal: Adopt a single issue tracker for GrimoireLab and use "labels" or something similar to indicate which component an issue is for. This can be a GitHub native issue tracker or a third-party solution.

Rationale: GrimoireLab is using GitHub native issue tracker. However, the issues are spread across different repositories for the different modules. This makes it difficult to search and find issues, producing duplicates and frustration on both user and maintainer side.

/cc @sduenas @valeriocos @jsmanrique

[sduenas]

I think that's a good idea. The problem is how to implement it. My main concern is related to how to manage PRs and close issues. If we open issues in this repository only, we need to find the way to close those issues automatically when merging the PRs opened in the other repositories.

Apparently it's possible to close issues doing this: https://github.blog/2013-03-18-closing-issues-across-repositories/. Never tried, though.

Another option would be to have only one repository of code but I don't really like this idea because we usually try to produce tools that don't require the rest of the platform to work with.

[valeriocos]

It would be easier to define a process, where issues are first opened to the grimoirelab repository. The maintainers review them and add labels based on the component(s) involved. Issues on specific repositories can be opened, linking these issues with the main issue in the grimoirelab repository. Also in this case we could use labels to quickly identify which issues have no relations with the grimoirelab repository.

In this scenario, we could close issues in multiple repositories and have independent tools.

[sduenas]

@valeriocos the problem that I see with that workflow is that requires a lot of interaction and it's prone to errors. You might either forget to open a new issue in the component repository, forget to assign the proper tags, or forget to close the issues in both repositories.

Moreover, we will need to define where to write comments. People reporting will have problems to follow the progress of the issues.

[GeorgLink]

Another option would be to have only one repository of code but I don't really like this idea because we usually try to produce tools that don't require the rest of the platform to work with.

I agree that the tools best live in different repositories

[valeriocos]

@valeriocos the problem that I see with that workflow is that requires a lot of interaction and it's prone to errors. You might either forget to open a new issue in the component repository, forget ...

The issues can be opened in the grimoirelab repository, tagged and then moved to the specific repository (github provides a features to transfer issues) by maintainers.

With this workflow the comments are centralized, the interactions minimized and we can have tools in different repos.

[GeorgLink]

The issues can be opened in the grimoirelab repository, tagged and then moved to the specific repository (github provides a features to transfer issues) by maintainers.

I guess I am not familiar with GitHub features for discovering issues across repositories? How can a user or contributor find an issue after issues were moved out of chaoss/girmoirelab issue tracker?

[valeriocos]

the contributor should receive a notification about the issue that has been transfered: https://help.github.com/en/github/managing-your-work-on-github/transferring-an-issue-to-another-repository

People or teams who are mentioned in the issue will receive a notification letting them know that the issue has been transferred to a new repository. The original URL redirects to the new issue's URL. People who don't have read permissions in the new repository will see a banner letting them know that the issue has been transferred to a new repository that they can't access.

[GeorgLink]

Okay, so the author of an issue gets notified. When they come back to our issue tracker, do we expect them to remember that an issue had been moved? What about someone who comes for the first time and wants to see if someone else has asked the same question before; how will they go about finding issues?

I keep coming back to the conclusion that a single issue tracker is more user friendly for the community. Separating issues across repositories may be the best solution for the maintainers who know what is going on, but the community as a whole is not equipped to understand how to navigate multiple issue trackers and find the issues most relevant to them.

[sduenas]

What about someone who comes for the first time and wants to see if someone else has asked the same question before; how will they go about finding issues?

I was just writing about it. This is a problem because people would have to look for the issues in each repository (as now), and they probably end up opening an issue in grimoirelab (as now) because they don't know which components/repositories GrimoireLab has. Also, a normal user won't know whether the problem is in perceval or in ELK. In fact, they shouldn't care, so to have everything centralized should be better for the standard user.

[valeriocos]

@GeorgLink @sduenas , this is the reason why I suggested at #284 (comment) to open the issues in the grimoirelab repository (this one), and then the maintainers take care of creating issues in other repositories (if needed) and linking them with proper labels to the original one.

I was just writing about it. This is a problem because people would have to look for the issues in each repository (as now), and they probably end up opening an issue in grimoirelab (as now) because they don't know which components/repositories GrimoireLab has. Also, a normal user won't know whether the problem is in perceval or in ELK. In fact, they shouldn't care, so to have everything centralized should be better for the standard user.

@sduenas you can't prevent people to open duplicated issues and it's pretty difficult to avoid the errors you mentioned at: #284 (comment). The best thing to do is to define a CONTRIBUTING or CodeOfConduct file explaining the rules of the game (probably this file should be defined also in each grimoirelab repo), so the user knows where to open an issue, and how the issue will be handled. If an issue is opened in a wrong place, we can transfer it to the right place.

[GeorgLink]

Hi @valeriocos, I went back to read your original suggestion. Is the reason you want to keep different issue trackers so that you can easily see which issues relate to a specific tool? How does filtering by tag not already provide you the overview you want? Or am I missing the reason and benefit of your process suggestion?

[valeriocos]

From an end-user perspective (someone that wants just to use grimoirelab) it makes sense to open an issue in the grimoirelab repo (e.g., #233). For users interested in single tools (e.g., perceval and graal), it makes probably much sense if they open issues in the repository hosting the tool.

Example of issues that may not fit with having just a single issue tracker are:

• It is impossible to install ELK right now due to redis version conflict grimoirelab-elk#726 -> specific only for a component (ELK in this case)
• [feature] Include comments from /reviews in pull_request fetched by Perceval grimoirelab-perceval#516 -> issues that may involve more components. The fix is in Perceval, however this work may imply changes in ELK, Sigils and Mordred (in case the new data must be visualized in the dashboards), which could start weeks/months/years later the patch on Perceval. A possible scenario with a single issue tracker could be the following: Comments authors in GH issues, PRs #207, which may be hard to follow when the number of comments grows.

Said that, I'm fine with any solution (since each one has benefits and drawbacks). I would just stress the fact that the way of contributing to grimoirelab should be clear and stated somewhere. Once the rules are set, we have a baseline to improve on.

[jgbarah]

Let me summarize, and have some reality contrast. Please take all of this with a grain of salt.

• It would be convenient to have a clear way of reporting and tracking issues for GrimoireLab
• Having separate repos for each of the tools makes sense. Having a specific repo for dealing with all the toolset also seems reasonable (this one is the grimoirelab repo).
• Issues can be transferred from repo to repo by maintainers, if for example somebody submitted an issue to the grimoirelab repo, it can be transferred to the repo of an specific tool, if developers feel it fits there better.
• Issue transfers can be tracked via email by everyone involved.
• We should have a document stating how issues should be filed, and the process afterwards.
• We cannot avoid that people submit issues without reading the document, or don't caring about what is specified in the document (I mean, many people are used to submit issues in GH, and maybe they won't notice there is an specific document saying that issues should be submitted to such and such repo). But we could have issue templates stating that the document should be read, or even including excerpts from it (issue templates are shown to users when they intend to submit issues, by prefilling the description field).

With all of this in mind, i suggest that:

• We add to the CONTRIBUTING.md file in grimoirelab some text about which issues to submit to that repo, and which issues to submit to tools repos. Also, which mentions about issue transfer, so people understand what may happen.
• We add issue templates to all repos poiniting to that text in CONTRIBUTING.md in the grimoirelab repo, and maybe summaries of the above.

[sduenas]

I don't like the idea of moving issues from one tracker to another. It makes so complex the whole process and managers will need to spend more time managing the issues. It also makes hard to track issues in other trackers ;-). It also makes the process complex to the users which need to figure out if the issues go to the main repository or to a specific one.

[GeorgLink]

@valeriocos :

From an end-user perspective (someone that wants just to use grimoirelab) it makes sense to open an issue in the grimoirelab repo (e.g., #233). For users interested in single tools (e.g., perceval and graal), it makes probably much sense if they open issues in the repository hosting the tool.

Example of issues that may not fit with having just a single issue tracker are:

• It is impossible to install ELK right now due to redis version conflict grimoirelab-elk#726 -> specific only for a component (ELK in this case)
• [feature] Include comments from /reviews in pull_request fetched by Perceval grimoirelab-perceval#516 -> issues that may involve more components. The fix is in Perceval, however this work may imply changes in ELK, Sigils and Mordred (in case the new data must be visualized in the dashboards), which could start weeks/months/years later the patch on Perceval. A possible scenario with a single issue tracker could be the following: Comments authors in GH issues, PRs #207, which may be hard to follow when the number of comments grows.

From the perspective of someone who knows all the tools, this makes sense. I prefer to have all issues in one place and using tags for those who want to filter issues and see only the ones relevant to the module they care about.

@jgbarah :

• It would be convenient to have a clear way of reporting and tracking issues for GrimoireLab

+1

• Having separate repos for each of the tools makes sense. Having a specific repo for dealing with all the toolset also seems reasonable (this one is the grimoirelab repo).

+1 (but only for the repository and code base, not for the issues)

• Issues can be transferred from repo to repo by maintainers, if for example somebody submitted an issue to the grimoirelab repo, it can be transferred to the repo of an specific tool, if developers feel it fits there better.

-1 (Technically possible, but that is the current state and not solving the issue stated initially of having all issues in one place, regardless of which component they relate to)

• We should have a document stating how issues should be filed, and the process afterwards.

+1

• We cannot avoid that people submit issues without reading the document, or don't caring about what is specified in the document (I mean, many people are used to submit issues in GH, and maybe they won't notice there is an specific document saying that issues should be submitted to such and such repo). But we could have issue templates stating that the document should be read, or even including excerpts from it (issue templates are shown to users when they intend to submit issues, by prefilling the description field).

+1 (great idea)

@sduenas :

I don't like the idea of moving issues from one tracker to another. It makes so complex the whole process and managers will need to spend more time managing the issues. It also makes hard to track issues in other trackers ;-). It also makes the process complex to the users which need to figure out if the issues go to the main repository or to a specific one.

+1 (I agree with that analysis)