Thanks for starting this discussion Vladimir and all those sharing your experience. Quite interesting information so far.
As usual, there are advantages and disadvantages between GitHub issues and JIRA issues. In order to avoid writing an overly long email I will try to focus on those aspects that I consider more important. As a user I want to be able to easily find a problem/feature, see if it is fixed, and if yes on which version(s). When Google fails me, I turn to JIRA or GitHub and it turns out that I am able to find the information easier with JIRA. I find JIRA search superior to GitHub both when it comes to approximate text search and exact filters. Moreover, many Apache projects are using JIRA already which makes it easy to perform cross project search. I admit, I have more experience with JIRA compared to GitHub issues so maybe I am just lacking knowledge. Clearly, the interaction between JIRA and GitHub is not perfect but doesn't bother me much. 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. Last but not least, 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. It could be trivial to adapt but still it is work that needs to be done. This is to say that the migration may have a bigger impact than expected. Small reminder: Since someone brought up how to determine if a release is ready; in JIRA we currently have the following dashboards: https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950 https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333951 I am using the first for monitoring the state of the release mostly when I am RM and the second for staying up to date in discussions, important issues, todos, etc. Best, Stamatis On Tue, Nov 30, 2021 at 7:49 PM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > >I think the easiest thing is to focus on the > >"workflow" for each "persona" we have > > While I agree the questions you raise are valid, I would say, that moving > to GitHub Issues > does not really change the workflow except in certain small cases. > > I doubt there's an exhaustive list of answers for JIRA. > No way I want to bomb you with answers, however, I truly believe replacing > JIRA with GitHub is not really disrupting for Calcite. > > On the other hand, moving to GitHub issues would likely bring new > contributors and reviewers. > > >Writing down what you believe to be "allowed" and making sure everyone > >else is on the same page is perfect. > > https://calcite.apache.org/develop/#contributing is more or less relevant > if you replace JIRA with GitHub Issue. > > >what would a contributor > >do on Github to provide a patch for a bug they found? > > Like with the current workflow: they file a PR. > They don't have to file a JIRA first. They just file a PR that explains the > problem and suggests the fix. > > >What about a contributor reporting an issue? > > a) If they are not sure, they can file an issue at GitHub > b) They can ask on a dev@calcite mailing list > c) If they can't understand how to use Calcite APIs, they could file GitHub > Discussion (if we enable it). > It might be useful to distinguish "bugs in Calcite" vs "user > questions regarding the way to use Calcite". > d) If they have a reproducer, they could just file a PR that reproduces the > issue. It would immediately > show up as a build failure, and everybody would be able to see how it > breaks. > > >How should a developer structure a "big" > >change to Calcite which might contain multiple commits? > > a) They can file PR that contains several commits (like we currently do > sometimes) > b) They can create an issue and reference the relevant PRs/issues in the > description > > "tasks lists" is useful here: > > https://docs.github.com/en/issues/tracking-your-work-with-issues/about-task-lists > > ^^ the above answers are pretty much the same as our current workflow > except JIRA is replaced with GitHub issues. > > >Where does a > >release manager look to determine if a release is ready (all necessary > >issues are fixed)? > > Typically, when planning a release, we ask everybody to figure out which > issues are "blockers" for the release. > With GitHub, we can associate the relevant issues/PRs with the milestone. > > Here's how "open items" look in Airflow: > https://github.com/apache/airflow/milestones/Airflow%202.2.3 > The release manager opens the milestone, and they see if it is all ready. > > Vladimir >
