> 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

Reply via email to