The mailing list has been created and I've opened a PR  to update the docs
https://github.com/apache/flink-web/pull/583

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