Hi all, The new workflow is documented at https://flink.apache.org/community.html
Thanks, Martijn On Mon, Nov 14, 2022 at 3:37 AM Leonard Xu <xbjt...@gmail.com> wrote: > > > The mailing list has been created and I've opened a PR to update the > docs > > https://github.com/apache/flink-web/pull/583 > > Thanks @Martijn for the nice work. > I am willing to review this document PR, because the PR also provides > Chinese part, which is great, I should be able to offer some tips. > > Best, > Leonard > > > > > > > Op zo 13 nov. 2022 om 09:40 schreef Martijn Visser < > martijnvis...@apache.org > >> > > > >> Agreed. I've requested a new private mailing list [1] > >> > >> [1] https://issues.apache.org/jira/browse/INFRA-23898 > >> > >> On Sat, Nov 12, 2022 at 12:09 PM Márton Balassi < > balassi.mar...@gmail.com> > >> wrote: > >> > >>> Hi Martjin, > >>> > >>> Given the situation let us set up the Jira signup mailing list > following > >>> the Calcite model. This seems the most sensible to me as of now. > >>> > >>> On Fri, Nov 11, 2022 at 7:26 PM Martijn Visser < > martijnvis...@apache.org> > >>> wrote: > >>> > >>>> 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 > >>>> > >>> > >> -- > > Martijn > > https://twitter.com/MartijnVisser82 > > https://github.com/MartijnVisser > >
