I'm generally -0.47 on this. This seems to solve a problem that doesn't exist (or at least isn't pressing). Calcite contribution speed is very helpful. Don't get me wrong, I hate jira as much as anyone. Nonetheless, process change takes time in both the direct costs (migration/workflow disruption/etc) and the indirect costs (learning/refining a new system).
A bigger problem around our process that I see is not enough reviews/triage for the contributions we do receive. We have 224 open prs and I'd estimate a median open time of 1 year+. Many of those may now be abandoned but it'd be great to actually mark them as such (if we think that). I'm much more excited about creative ways to solve that problem and if someone feels like putting time against process improvement, I think that would be a good place for it. To be clear, I prefer GitHub issues for new things and do agree that it reduces the bar towards contribution. On Tue, Nov 30, 2021 at 11:39 PM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > >I know people/companies who have built tools/plugins > >around JIRA for getting useful information such as which internal forks > >have this particular fix, etc > > That is true. However, I do not know what should we do about it. > Of course, any change brings hidden costs, so if the benefits are unclear, > there's not much point in making changes. > > On the other hand, the more I discover, the more I am sure GitHub Issues > would be great for Calcite. > I started the discussion like "it looks we are fine, but we can try > GitHub", and now I am quite > enthusiastic that moving to GitHub would bring multiple improvements in > various aspects. > > >I turn to JIRA > >or GitHub and it turns out that I am able to find the information easier > >with JIRA. > > GitHub issues are searchable, including comments. > We currently "enforce" JIRA tickets, so PRs lack descriptions and > explanations, so it is expected you can't find them. > > Try using JIRA to figure out when we bumped Guava to 31. There's no JIRA > for that. > > On the other hand, GitHub search returns PRs, code files, and commits that > match the search. > https://github.com/apache/calcite/search?q=guava+31 > > Then, if you know Git SHA (e.g. from "git blame"), you can find PRs related > to that SHA. > For example > > https://github.com/apache/calcite/search?q=890eb61efcccc486e2192110cefe4cac5aa6f150&type=issues > Frankly speaking, I never thought of trying to search via commit SHA, but > it is a definitely cool trick I learned > when reading > > https://docs.github.com/en/search-github/searching-on-github/searching-issues-and-pull-requests > > When it comes to versions, GitHub PRs and issues would have "milestones" (~ > "fix version"), > and when you browse commits, GitHub shows the list of tags that include > this commit. > For instance, if you open > > https://github.com/apache/calcite/commit/2326cf8dc97f473d0efa2b0e4883fef87a40746b > , > you know Guava was updated to 31 since Calcite 1.28.0 > > >One unpleasant situation which comes up from time to time is when > >discussions develop in both places. However, migrating to GitHub issues > >will not completely solve this since we will still need to navigate back > >and forth between issue and PR > > If we allow PR-first (no issue, no JIRA, just PR with the proper > description) contributions, then: > 1) It will be in a single place, no need to switch > 2) Navigation between issues and comments would still be easier in GitHub > than commenting like "please continue in JIRA" > > GitHub allows responding to issues/PRs via mail, and I find it a nice > feature. > I don't use it often, however, I use it from time to time, and I see others > using it. > > >Moreover, many Apache projects are using > >JIRA already which makes it easy to perform cross project search > > GitHub has an out-of-the-box way to scope search for organizations. > > Here's a search for Calcite in the Apache organization: > https://github.com/search?q=org%3Aapache+calcite > > At any point in time, you can remove org:apache, and you get GitHub-wide > search. > GitHub hosts more projects than ASF JIRA, so being able to search and link > across them (all, not just ASF projects) would be useful. > > >I find JIRA search superior to GitHub both when it comes to approximate > >text search and exact filters > > I might be wrong here, however, I think we do not really use JIRA metadata. > In most cases, we use only the ticket title, description, and the fix > version. > > There's "affects version" in JIRA, and I do not know if GitHub has a > one-to-one replacement for that. > However, I would be fine if the affected version was in the issue/PR > description. > > "component" (~core, linq4j, cassandra, ...) could become a label in GitHub. > AFAIK the limitation is that labels can only be changed by committers or > collaborators. > We can mitigate that by: > a) Adding collaborators (via asf.yaml) > b) Adding committers > c) Adding GitHub Actions that label Issues based on descriptions or even > PRs based on the set of touched files. > > GitHub's search features are more than enough for us. We have no fancy > metadata for complicated searches :) > > Vladimir >
