Hi! I would also personally prefer staying with JIRA given the feature set and the past positive experience with it. I think the structured nature of JIRA with flexible components, issue types, epics, release handling etc have been a great benefit to the project, it would be a shame to give some of these up.
If for some reason Option 1 is not possible, I would still prefer Option 3 (requiring new contributors to ask for JIRA access) compared to the alternatives. Cheers, Gyula On Tue, Oct 25, 2022 at 3:48 PM Robert Metzger <rmetz...@apache.org> wrote: > 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 > > >
