> 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
