Hi Xintong, I'm also not in favour of option 2, I think that two systems will result in an administrative burden and less-efficient workflow. I'm also not in favour of option 3, I think that this will result in first time users/contributors in not-filling their first bug report, user question or feature request.
I'm still hoping for option 1 while the discussion is not finished with Infra. If we assume that option 1 won't be possible, then I think option 4 will be the best-option-left. I'm not necessarily in favour, because of a number of problems it will introduce: 1. I don't think importing current Jira tickets into Github Issues is a realistic option. So we would have two administrations. Before you create a new ticket, you should check if it exists both as a Jira ticket and as a Github Issue. 2. How would we deal with completing a PR? There must be one administration leading for the changelog generation (to avoid that you're missing an item), which could then only be Github Issues. So would we require all PRs that are merged to exist as a Github Issue? 3. There's no longer one central administration, which is especially valuable to track all issues across projects like the different connectors, Flink ML, Table Store etc. 4. Our current CI labeling works on the Jira issues, not on the Github Issues labels. Best regards, Martijn On Mon, Oct 24, 2022 at 7:29 AM Xintong Song <tonysong...@gmail.com> wrote: > Hi devs and users, > > As many of you may have already noticed, Infra announced that they will > soon disable public Jira account signups [1]. That means, in order for > someone who is not yet a Jira user to open or comment on an issue, he/she > has to first reach out to a PMC member to create an account for him/her. > This raises the bar for new contributors and users to participate in > community interactions, making it necessary for us to consider whether (and > how) we should change our issue tracking workflows. > > I can see a few possible options. > > 1. Reaching out to Infra and trying to change their mind on this decision. > I’ve already been trying this [2], and so far the feedback seems > unoptimistic. > 2. Using both Jira (for development issues) & Github Issues (for > customer-facing issues), as Infra suggested. > 3. Stay with using Jira only, so that new Jira users need to ask on the > mailing lists / Slack for creating accounts. > 4. Migrating to Github Issues completely. > > Personally, I’m leaning toward option 4). > > TBH, I don’t see any good reason for option 2). I’d expect using two > different issue tracking tools at the same time would be complex and > chaotic. Option 3) is probably more friendly to existing developers and > users, while being less friendly to newcomers. Option 4) on the contrary, > is more friendly to newcomers, at some migration cost which might be > non-trivial but once for all. > > Github issues have been widely used by many open source projects, > including Kubernetes, Flink CDC, and Apache projects Iceberg and Airflow. > With a set of well-designed labels, we should be able to achieve most of > the Jira functions / features that we currently rely on. Moreover, it > better integrates the issue tracking and code contributing systems, and > would be easier to access (I believe there’s more GH users than Jira / > mailing lists). > > All in all, I’d suggest to keep monitoring Infra’s feedback on option 1), > while taking steps (investigation, workflow & label design) preparing for > option 4). > > Looking forward to hearing what you think about this. > > Best, > > Xintong > > > [1] https://lists.apache.org/thread/jx9d7sp690ro660pjpttwtg209w3m39w > > [2] https://lists.apache.org/thread/fjjtk30dxf6fyoo4q3rmkhh028or40fw > >
