Hi everyone, while I see some benefits in moving to Github Issues completely, we need to be aware that Github Issues lacks many features that Jira has. From the top of my head: * there are no issue types * no priorities * issues can only be assigned to one milestone So, you need to work a lot with labels and conventions and basically need bots or actions to manage those. Agreeing on those processes, setting them up and getting used to them will be a lot of work for the community.
So, I am also in favor of 1) for now, because I don't really see a good alternative option. Cheers, Konstantin Am Mo., 24. Okt. 2022 um 22:27 Uhr schrieb Matthias Pohl <matthias.p...@aiven.io.invalid>: > I agree that leaving everything as is would be the best option. I also tend > to lean towards option 4 as a fallback for the reasons already mentioned. > I'm still not a big fan of the Github issues. But that's probably only > because I'm used to the look-and-feel and the workflows of Jira. I see > certain benefits of moving to Github, though. We're still having the idea > of migrating from AzureCI to GitHub Actions. Moving the issues to GitHub as > well might improve the user experience even more. Reducing the number of > services a new contributor should be aware of to reach the community is a > good way to reduce the confusion for newcomers, I could imagine. > Additionally, I also like the fact that I wouldn't have to bother about the > Apache Jira markdown anymore. 8) > > I agree with Martijn's concern about not being able to track all > Flink-related issues in a single system. I'm just wondering whether > something is holding us back from collecting all Flink-related issues in > the Flink's Github repository and disabling the issue feature in any other > Flink-related repository? > > About migrating the Jira issues: I would be hopeful that migrating is > doable in the end. There is a blog post from the spring data guys about > their journey on migrating from Jira to GitHub issues [1]. Unfortunately, > they didn't provide any scripts. > > For the case that infra moves forward with disabling the signup without us > having come up with a decision and its actual execution (i.e. migrating the > Jira issues to GH), I would prefer having users send a request to the > mailing list. I would rather have a temporary phase where there's a bit of > overhead of registering the users in the Apache Jira than having two > locations for bug tracking. I suspect that there are no statistics on how > many new users register with Jira in a given timeframe to contribute to > Flink? > > Matthias > > [1] > > https://spring.io/blog/2021/01/07/spring-data-s-migration-from-jira-to-github-issues > [2] https://lists.apache.org/thread/pjb5jzvw41xjtzgf4w0gggpqrt2fq6ov > > > On Mon, Oct 24, 2022 at 10:28 AM Xintong Song <tonysong...@gmail.com> > wrote: > > > I agree with you that option 1) would be the best for us. Let's keep > hoping > > for the best. > > > > Option 4), as you said, comes with prices. At the moment, I don't have > > thorough answers to your questions. > > > > Just one quick response, I think there's a good chance that we can import > > current Jira tickets into GH. Jira supports exporting issues with fields > > that you specified as CSV/XML/... files. With a brief google search, I > > found some tools that help bulk creating issues in GH. E.g., > > github-csv-tools [1] is described to support importing issues with title, > > body, labels, status and milestones from a CSV file. That's probably good > > enough for us to search/filter the issues in GH, and a link to the Jira > > ticket can be posted in the GH issue for complete conversation history > and > > other details. > > > > Best, > > > > Xintong > > > > > > [1] https://github.com/gavinr/github-csv-tools > > > > > > > > On Mon, Oct 24, 2022 at 3:58 PM Martijn Visser <martijnvis...@apache.org > > > > wrote: > > > > > 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 > > >> > > >> > > > -- https://twitter.com/snntrable https://github.com/knaufk
