>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
