Hi everyone, Unfortunately ASF Infra has already implemented the change and new Jira users can't sign up.
I think there is consensus that we shouldn't move from Jira now. My proposal would be to setup a separate mailing list to which users can send their request for an account, which gets sent to the PMC so they can create accounts for them. I don't see any other short term solution. If agreed, let's open up a vote thread on this. Thanks, Martijn Op do 3 nov. 2022 om 04:51 schreef Xintong Song <tonysong...@gmail.com> > Thanks all for the valuable feedback, opinions and suggestions. > > # Option 1. > I know this is the first choice for pretty much everyone. Many people from > the Flink community (including myself) have shared their opinion with > Infra. However, based on the feedback so far, TBH I don't think things > would turn out the way we want. I don't see what else we can do. Does > anyone have more suggestions on this option? Or we probably have to > scratch it out of the list. > > # Option 4. > Seems there are also quite some concerns on using solely GH issues: limited > features (thus the significant changes to the current issue/release > management processes), migration cost, source of truth, etc. I think I'm > also convinced that this may not be a good choice. > > # Option 2 & 3. > Between the two options, I'm leaning towards option 2. > - IMO, making it as easy as possible for users to report issues should be a > top priority. Having to wait for a human response for creating an account > does not meet that requirement. That makes a strong objection to option 3 > from my side. > - Using GH issues for consumer-facing issues and reflecting the valid ones > back to Jira (either manually by committers or by bot) sounds good to me. > The status (open/closed) and labels should make tracking the issues easier > compared to in mailing lists / slack, in terms of whether an issue has been > taken care of / reflected to Jira / closed as invalid. That does not mean > we should not reflect things from mailing lists / slack to Jira. Ideally, > we leverage every possible channel for collecting user issues / feedback, > while guiding / suggesting users to choose GH issues over the others. > - For new contributors, they still need to request an account from a PMC > member. They can even make that request on GH issues, if they do not mind > posting the email address publicly. > - I would not be worried very much about the privacy issue, if the Jira > account creation is restricted to contributors. Contributors are exposing > their email addresses publicly anyway, in dev@ mailing list and commit > history. I'm also not strongly against creating a dedicated mailing list > though. > > Best, > > Xintong > > > > On Wed, Nov 2, 2022 at 9:16 PM Chesnay Schepler <ches...@apache.org> > wrote: > > > Calcite just requested a separate mailing list for users to request a > > JIRA account. > > > > > > I think I'd try going a similar route. While I prefer the openness of > > github issues, they are really limited, and while some things can be > > replicated with labels (like fix versions / components), things like > > release notes can't. > > We'd also lose a central place for collecting issues, since we'd have to > > (?) scope issues per repo. > > > > I wouldn't want to import everything into GH issues (it's just a flawed > > approach in the long-term imo), but on the other hand I don't know if > > the auto linker even works if it has to link to either jira or a GH > issue. > > > > Given that we need to change workflows in any case, I think I'd prefer > > sticking to JIRA. > > For reported bugs I'd wager that in most cases we can file the tickets > > ourselves and communicate with users on slack/MLs to gather all the > > information. I'd argue that if we'd had been more pro-active with filing > > tickets for user issues (instead of relying on them to do it) we > > would've addressed several issues way sooner. > > > > Additionally, since either option would be a sort of experiment, then > > JIRA is a safer option. We have to change less and there aren't any > > long-term ramifications (like having to re-import GH tickets into JIRA). > > > > On 28/10/2022 16:49, Piotr Nowojski wrote: > > > Hi, > > > > > > I'm afraid of the migration cost to only github issues and lack of many > > > features that we are currently using. That would be very disruptive and > > > annoying. For me github issues are far worse compared to using the > Jira. > > > > > > I would strongly prefer Option 1. over the others. Option 4 I would > like > > > the least. I would be fine with Option 3, and Option 2 but assuming > that > > > Jira would stay the source of truth. > > > For option 2, maybe we could have a bot that would backport/copy user > > > created issues in github to Jira (and link them together)? Discussions > > > could still happen in the github, but we could track all of the issues > as > > > we are doing right now. Bot could also sync it the other way around > (like > > > marking tickets closed, affected/fixed versions etc). > > > > > > Best, > > > Piotrek > > > > > > czw., 27 paź 2022 o 07:48 Martijn Visser <martijnvis...@apache.org> > > > napisał(a): > > > > > >> 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 > > >> > > > > > -- Martijn https://twitter.com/MartijnVisser82 https://github.com/MartijnVisser
