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)

[valeriocos]

The discussions around this proposal seem enough to let everybody evaluate the proposal and vote for it.

@GeorgLink can you update the proposal with the outcome of these discussions (e.g., which repo will be used, document the decision in the single repos)? Then, anyone interested in this proposal can vote for it, and democratically we will take a final decision. WDYT?

[GeorgLink]

I agree that we seem to have discussed all relevant points and additional discussion would be fruitless. This is my last comment unless someone asks me a direct question.

I would prefer the maintainers make a decision because they have to enforce it. Lazy consensus for the maintainers' decision would work better than voting for several reasons.

Right now, with the four participants in this thread, we might have a tie between keeping the status quo with issues spread over many places that are difficult to understand as casual community members and consolidating issues in one place with proper tagging for simpler community engagement. Either way, there probably is no perfect solution and the maintainers have to decide based on their vision and goal for the GrimoireLab community.

[sduenas]

To summarize, the proposals are:

• One single repository
  • Use grimoirelab as the hub where issues will be reported
  • Use tags to categorize which component/ is/are related to which issue/s.
  • When working with pull requests, use references to issues as described here.
• Multiple repositories
  • Issues can be reported in all grimoirelab related repositories.
  • Maintainers will move issues to the corresponding repository en case of the issue was reported in a wrong repository.

[sduenas]

I'll go with the first one. In somehow, we have been working with the second option since we started the project. I cannot say it didn't work but I think is not the best option. I'd like to try with the first proposal and see how it goes.

[jgbarah]

I'll go with the first one. In somehow, we have been working with the second option since we started the project. I cannot say it didn't work but I think is not the best option. I'd like to try with the first proposal and see how it goes.

If that's finally what we do, we need to figure out how to avoid people filing issues in the tool repositories instead of in the grimoirelab "hub". Likely, we need also to figure out how to let submitters tag issues, so that developers don't have that extra overhead.

[sduenas]

I'll go with the first one. In somehow, we have been working with the second option since we started the project. I cannot say it didn't work but I think is not the best option. I'd like to try with the first proposal and see how it goes.

If that's finally what we do, we need to figure out how to avoid people filing issues in the tool repositories instead of in the grimoirelab "hub".

Issues can be disabled in GitHub.

Likely, we need also to figure out how to let submitters tag issues, so that developers don't have that extra overhead.

We can create tags for each component but I'm afraid tags cannot be assigned by people who are not contributors or owners. Apparently, the only way is to define issue templates:

https://stackoverflow.com/questions/13829466/how-to-put-a-label-on-an-issue-in-github-if-you-are-not-a-contributor-owner/31366954#31366954

[valeriocos]

I'm fine with any proposal @sduenas . Can we draft a plan to implement the first proposal (if this one is finally selected)? For instance, do we want to do a hard switch to apply the first proposal or we go for a transition/testing period? How do we want to notify the community? Since we will start using labels, do we want use them also to mark issues as bugs, features, release they will be included, etc.?

[GeorgLink]

For the tags, we can maybe use the name of the repository that it an issue belongs to:

• component:chaoss/grimoirelab-elk
• component:chaoss/grimoirelab-sigils
• ...

[sduenas]

I've been checking how to do this process. Issues can only moved one by one and manually. There's no API calls to move issues. We can automate some parts using selenium or similar, though.

Another collateral problem is related to Grimoirelab tool itself and how it will analyze this data. If we move issues to this repository our platform will consider all the issues belong to grimoirelab project, and not to the subprojects. Would that be a problem? This will mean we won't be able to drill down to get specific numbers in terms of issues for each one of the sub-projects or components. In other words, we won't be able to analyze our tool with our tool. :D

(Maybe we should move to GitLab)

[GeorgLink]

we won't be able to drill down to get specific numbers in terms of issues for each one of the sub-projects or components

Does GrimoireLab support issue labels that can be used for analyzing the issues belonging to a sub-project or component?

Issues can only be moved one by one and manually.

Not sure if GitMover Python script could help?

Maybe we should move to GitLab?

I'm open to the idea. Maybe something to discuss in the CHAOSS GrimoireLab call, CHAOSS weekly call, and CHAOSS mailing list maybe?

[sduenas]

we won't be able to drill down to get specific numbers in terms of issues for each one of the sub-projects or components

Does GrimoireLab support issue labels that can be used for analyzing the issues belonging to a sub-project or component?

No, it doesn't. The main problem is it will be an ad-hoc analysis because I don't know other projects that use labels to categorize their components. I'm sure there are but I don't think that's the common case.

Issues can only be moved one by one and manually.

Not sure if GitMover Python script could help?

If it works, that might be very helpful.

Maybe we should move to GitLab?

I'm open to the idea. Maybe something to discuss in the CHAOSS GrimoireLab call, CHAOSS weekly call, and CHAOSS mailing list maybe?

Sure. I think we should talk about it and I'm not talking about GrimoireLab only. Other projects in CHAOSS should probably do the same. You know we like to use open source projects and GitHub it's not one. We start using GitHub because at that time there wasn't any other option.
Before we started in CHAOSS we were talking to move to GitLab but that never happens because CHAOSS started using GitHub (I don't know the reasons). So yeah, we should talk about it.

If it's not clear, my main reason about why move to GitLab is because it's open source or at least, the main components.

[GeorgLink]

because CHAOSS started using GitHub (I don't know the reasons)

There was no deliberation. We needed a platform that worked better than a wiki.

[davidam]

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

Reading the subject I only want to say that I am using todo.org files to manage tasks is so portable if you plan migrate from github to gitlab or similar.

[GeorgLink]

Now that we are not moving to GitLab, we can find a different way to manage tickets in GitHub. For example, move all issues to chaoss/grimoirelab, tag them for the component they are about, and disable issue tracking on all other repositories.

[almereyda]

The six months deadline from #296 (comment) has passed and GitLab proves to be a suitable and productive working environment for many groups. The import of GitHub projects with all detail is flawless, and can be batched. The combined group-level and sub-group-level issue trackers an Kanban boards are useful helpers in tackling the daily information flux of modular projects.

Further on, after Microsoft buying GitHub, many projects have migrated to plenty of GitLab and Gitea instances, since U.S. governmental restrictions may apply on the platform. Additionally U.S. platforms become a less likely target for European projects since establishment of the GDPR, and cancellation of the Privacy Shield agreement.

Later we will be able to use https://fedeproxy.eu/ to link multiple git forges together.

[canasdiaz]

Hey @almereyda , I'm pretty sure @sduenas should be involved in this conversation but he will be offline for a month due to personal reasons.

[almereyda]

It's okay. My comment was primarily about highlighting that plenty of FLOSS development is now happening outside of GitHub esp. due to the poor legal status it has as seen from EU. That it also grows a fruitful ecosystem of independent, decentralised labs all across the space then makes solutions like Fedeproxy neccessary. Just wanted GrimoireLab to be aware of the developments and allow the group to have new arguments for considering to make use of these network effects with switching to the GitLab platform also for themselves.

[GeorgLink]

Feel free to bring the conversation to the broader CHAOSS community because we decided last time GrimoireLab would stay with GitHub because CHAOSS stayed with it.