For what it’s worth, I actually prefer JIRA’s workflow model. I strongly believe that people should log a JIRA case before starting work on a bug or feature. Then discussion can happen before coding starts.
And I like making holistic reviews - reviewing the whole change, its goals, its impact, and what’s missing - rather than reviewing line by line. GitHub makes it easy to review line by line, but you can then miss the important stuff. GitHub also makes it easy to write code, submit it as a PR, and that PR becomes the issue. Lastly, another quibble about GitHub: that it allows people to squash, rebase and amend commits. The line-by-line comments quickly go out of date. As to the backlog of PRs. There are multiple problems and solutions. The main one is that reviewing PRs quite simply takes work. We need more people to spend more time reviewing PRs. We have solved the problem for RMs - people volunteer, and put in the effort, and there is a rota so that no one person is doing all the work. Julian > On Dec 1, 2021, at 10:14 PM, Vladimir Sitnikov <sitnikov.vladi...@gmail.com> > wrote: > >> 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+ > > I am sure JIRA is slowing us down here. > > If we accept we do not need JIRA, PRs could become the way to go for the > reviews. > > Jacques, I see you've just created > https://github.com/apache/calcite/pull/2625 (generic visitor), and you > followed the exact pattern I suggest: you filed a PR without JIRA, and you > put all the clarifications into the description. > Congratulations. It confirms JIRA adds no value to our workflow. > > Your https://github.com/apache/calcite/pull/2624 (introduce > handlerbased...) is less fun. Why did you create JIRA? ;) > It could have been a JIRA-less PR as well. > > As you put description to the PR itself, it becomes easier to review. > > That is what I mean. > > ---- > > We rarely reject contribution or ideas, and, I believe, we could reduce > time-to-merge by lowering the barrier and allowing PR-first contributions. > > Let me put it as follows: in many cases committers and experienced > contributors know they are doing good. > For example, I see you are moving towards AOT. That is fine, and I do not > really need all those JIRA's. > It would be so much easier to review and follow if you created a single > Issue that references all your AOT PRs. > > It is not really fun to create tickets for moving to JUnit5. We could just > do it instead of spending time on JIRA comments. > > ---- > >> I'd estimate a median open time of 1 year+ > > I suggested moving "core test framework classes" from core/src/test/ into > its own test module long ago. My mistake was I sent an email instead of > just sending a PR. > > The response to my mail was strongly negative, however, recently I did the > split, and it works great. > >> This seems to solve a problem that doesn't exist > > It does exist. My current mail highlights it right away: you could submit > JIRA-less PRs, everybody would have a single page for reviews, and so on. > It is really sad to hear "does not exist". > > JIRA causes excessive mails: "jira created", "pr created". > > In case we skip JIRA completely, it would be less notifications for > everybody. > > Vladimir
