Hi, We have to keep in mind that if a users asks for a new Jira account, that person will need to provide its email address which is the Flink PMC processing personal identifiable information. There needs to be a careful process for that and to be honest, I don't think the ASF should do this from a privacy perspective.
As an example, the Calcite community decided to create a dedicated, private list where users can ask for an account to avoid making the email address public. Best regards, Martijn Op wo 26 okt. 2022 om 22:31 schreef Danny Cranmer <dannycran...@apache.org> > Hello, > > I agree with Gyula. My preference is also option 1, and as a fallback > option 3. Handling new user account requests will be manageable, especially > via slack. We could setup a dedicated channel for people to ask for > Jira/wiki access. > > Thanks, > Danny > > On Wed, 26 Oct 2022, 12:16 Gyula Fóra, <gyf...@apache.org> wrote: > > > 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 > > > > > > > > > > -- Martijn https://twitter.com/MartijnVisser82 https://github.com/MartijnVisser
