Thank you for starting this discussion Xintong! I would also prefer option 1.
The ASF Jira is probably one of the largest, public Jira instances on the internet. Most other Jiras are internal within companies, so Atlassian is probably not putting a lot of effort into automatically detecting and preventing spam and malicious account creation. If we want to convince Infra to keep the current sign up process, we probably need to help them find a solution for the problem. Maybe we can configure the ASF Jira to rely on GitHub as an identity provider? I've just proposed that in the discussion on us...@infra.apache.org, let's see ;) Best, Robert On Tue, Oct 25, 2022 at 2:08 PM Konstantin Knauf <kna...@apache.org> wrote: > 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 >
