Moving the reply to DISCUSS thread. Ruben>My vote might be biased because I have used Jira for many years (and I have Ruben>never used Github for issue tracking).
It is really sad to hear. You authored 87 PRs for Calcite! You did use GitHub for tracking already. https://github.com/apache/calcite/pulls?q=is%3Apr+author%3Arubenada+is%3Aclosed Here's a good example: https://github.com/apache/calcite/pull/2329 PR description says the intention of the feature. There are overall and line-targeted comments. Creating GitHub Issue is not that different from creating a PR. Ruben>I have the impression that some of the problems described discussion are Ruben>not per se Jira-related, but they appear because we misuse the current Ruben>tools (and it would remain more or less the same if we switched from Jira Ruben>to GitHub Issues). Ruben, I claim that we split information for no reason. What is the real meaning behind having 50% of the review comments in JIRA, and 50% of the comments in PR? What is the real meaning behind putting "common description in JIRA, and putting NO description in the PR"? Does it help to have different markup languages for JIRA and GitHub? My main motivation is not "replace JIRA with Issues". That replacement alone has few benefits. The key improvement to the current process is creating PRs **with description**, and keeping the relevant discussion in the PR itself. I really see no point in PR comments like "let's continue in JIRA". If a comment targets a specific PR, then why don't we just use PR's comment fields for that? Ruben>high level discussion (e.g. feature design) should Ruben>happen in Jira The vast majority of the changes are small. Adding Jira barrier for every change is a productivity killer (for both contributors and for the reviewers). I don't mean just "switch between JIRA and PR". I mean that comments are duplicated at different sites. The description of the issue and the code changes are separated. The notifications are duplicated (gitbox duplicates GitHub notifications). The markup format is different. The search is not coherent (there's no way to find issues and PRs at the same time). GitHub blame does not show the full picture (it shows PRs, however, opening the JIRA is a separate step). PR (and GitHub Issue) can be associated to a version, so it would be much easier to relate the PR with its release version. I think the list can go and go. Ruben>IMO every change must have a dedicated Jira ticket What are the benefits of "a dedicated Jira ticket"? How "a dedicated Jira ticket" is different from "a dedicated PR"? Ruben>high level discussion (e.g. feature design) should Ruben>happen in Jira, low-level details (e.g. line by line code review) in the Ruben>PR; Both can be in PR, so what are the benefits from splitting "low-level" vs "high-level"? There is a lot of cases when people discuss low-level details in JIRA. It would be so much better, if we aligned the review approach. Jira and GitHub are just tools, and if we don't agree to review high-level stuff first, then no tool helps. That implies, GitHub is just fine for high-level reviews. Ruben>like customized dashboards, or linked issues ("issue A is blocked by / Ruben>caused by / duplicated by / ... issue B"). GitHub allows links, and links have no properties like "caused by", "duplicated by". However, basic links are just enough for Calcite. If you have a "customized dashboard" that is useful for many contributors, please show it. The ASF is a set of volunteers, so it is not right to enforce usage of JIRA when only a single person needs "a customized dashboard". Vladimir
