Re: [DISCUSS] Issue tracking workflow

[Chesnay Schepler <ch...@apache.org>]

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 <ma...@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 <dannycranmer@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, <gy...@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 <rm...@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
>>>>> users@infra.apache.org, let's see ;)
>>>>>
>>>>> Best,
>>>>> Robert
>>>>>
>>>>>
>>>>> On Tue, Oct 25, 2022 at 2:08 PM Konstantin Knauf <kn...@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
>>>>>> <ma...@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 <
>>> tonysong820@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 <
>>>>>> martijnvisser@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 <
>>>>> tonysong820@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
>>

Re: [DISCUSS] Issue tracking workflow

[Piotr Nowojski <pn...@apache.org>]

Hey,

Infra team started a survey:
> to understand the heart of the problems that our projects and podlings
face.
> (...)
> https://infra.apache.org/surveys/survey-1.html

I'm just reposting it here, if it just happens that you have something to
share with them.

Best,
Piotrek



pon., 14 lis 2022 o 15:39 Martijn Visser <ma...@apache.org>
napisał(a):

> 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 <xb...@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 <
> > martijnvisser@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.marton@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 <
> > martijnvisser@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 <
> > tonysong820@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 <
> chesnay@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 <
> > >>> martijnvisser@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 <
> > >>>>>> dannycranmer@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, <gy...@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 <
> > >>>> rmetzger@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
> > >>>>>>>>>>> users@infra.apache.org, let's see ;)
> > >>>>>>>>>>>
> > >>>>>>>>>>> Best,
> > >>>>>>>>>>> Robert
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>> On Tue, Oct 25, 2022 at 2:08 PM Konstantin Knauf <
> > >>>>> knaufk@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
> > >>>>>>>>>>>> <ma...@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 <
> > >>>>>>>>> tonysong820@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 <
> > >>>>>>>>>>>> martijnvisser@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 <
> > >>>>>>>>>>> tonysong820@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
> >
> >
>

Re: [DISCUSS] Issue tracking workflow

[Martijn Visser <ma...@apache.org>]

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 <xb...@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 <
> martijnvisser@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.marton@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 <
> martijnvisser@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 <
> tonysong820@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 <ch...@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 <
> >>> martijnvisser@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 <
> >>>>>> dannycranmer@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, <gy...@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 <
> >>>> rmetzger@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
> >>>>>>>>>>> users@infra.apache.org, let's see ;)
> >>>>>>>>>>>
> >>>>>>>>>>> Best,
> >>>>>>>>>>> Robert
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On Tue, Oct 25, 2022 at 2:08 PM Konstantin Knauf <
> >>>>> knaufk@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
> >>>>>>>>>>>> <ma...@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 <
> >>>>>>>>> tonysong820@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 <
> >>>>>>>>>>>> martijnvisser@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 <
> >>>>>>>>>>> tonysong820@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
>
>

Re: [DISCUSS] Issue tracking workflow

[Leonard Xu <xb...@gmail.com>]

> 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 <martijnvisser@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 <ba...@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 <ma...@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 <to...@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 <ch...@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 <
>>> martijnvisser@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 <
>>>>>> dannycranmer@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, <gy...@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 <
>>>> rmetzger@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
>>>>>>>>>>> users@infra.apache.org, let's see ;)
>>>>>>>>>>> 
>>>>>>>>>>> Best,
>>>>>>>>>>> Robert
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On Tue, Oct 25, 2022 at 2:08 PM Konstantin Knauf <
>>>>> knaufk@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
>>>>>>>>>>>> <ma...@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 <
>>>>>>>>> tonysong820@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 <
>>>>>>>>>>>> martijnvisser@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 <
>>>>>>>>>>> tonysong820@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

Re: [DISCUSS] Issue tracking workflow

[Martijn Visser <ma...@apache.org>]

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 <martijnvisser@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 <ba...@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 <ma...@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 <to...@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 <ch...@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 <
>> martijnvisser@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 <
>> > > > dannycranmer@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, <gy...@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 <
>> > rmetzger@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
>> > > > >>>>> users@infra.apache.org, let's see ;)
>> > > > >>>>>
>> > > > >>>>> Best,
>> > > > >>>>> Robert
>> > > > >>>>>
>> > > > >>>>>
>> > > > >>>>> On Tue, Oct 25, 2022 at 2:08 PM Konstantin Knauf <
>> > > knaufk@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
>> > > > >>>>>> <ma...@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 <
>> > > > >>> tonysong820@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 <
>> > > > >>>>>> martijnvisser@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 <
>> > > > >>>>> tonysong820@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

Re: [DISCUSS] Issue tracking workflow

[Martijn Visser <ma...@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 <ba...@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 <ma...@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 <to...@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 <ch...@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 <martijnvisser@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 <
> > > > dannycranmer@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, <gy...@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 <
> > rmetzger@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
> > > > >>>>> users@infra.apache.org, let's see ;)
> > > > >>>>>
> > > > >>>>> Best,
> > > > >>>>> Robert
> > > > >>>>>
> > > > >>>>>
> > > > >>>>> On Tue, Oct 25, 2022 at 2:08 PM Konstantin Knauf <
> > > knaufk@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
> > > > >>>>>> <ma...@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 <
> > > > >>> tonysong820@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 <
> > > > >>>>>> martijnvisser@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 <
> > > > >>>>> tonysong820@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
> >
>

Re: [DISCUSS] Issue tracking workflow

[Márton Balassi <ba...@gmail.com>]

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 <ma...@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 <to...@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 <ch...@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 <ma...@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 <
> > > dannycranmer@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, <gy...@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 <
> rmetzger@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
> > > >>>>> users@infra.apache.org, let's see ;)
> > > >>>>>
> > > >>>>> Best,
> > > >>>>> Robert
> > > >>>>>
> > > >>>>>
> > > >>>>> On Tue, Oct 25, 2022 at 2:08 PM Konstantin Knauf <
> > knaufk@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
> > > >>>>>> <ma...@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 <
> > > >>> tonysong820@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 <
> > > >>>>>> martijnvisser@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 <
> > > >>>>> tonysong820@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
>

Re: [DISCUSS] Issue tracking workflow

[Martijn Visser <ma...@apache.org>]

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 <to...@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 <ch...@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 <ma...@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 <
> > dannycranmer@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, <gy...@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 <rmetzger@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
> > >>>>> users@infra.apache.org, let's see ;)
> > >>>>>
> > >>>>> Best,
> > >>>>> Robert
> > >>>>>
> > >>>>>
> > >>>>> On Tue, Oct 25, 2022 at 2:08 PM Konstantin Knauf <
> knaufk@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
> > >>>>>> <ma...@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 <
> > >>> tonysong820@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 <
> > >>>>>> martijnvisser@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 <
> > >>>>> tonysong820@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

Re: [DISCUSS] Issue tracking workflow

[Xintong Song <to...@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 <ch...@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 <ma...@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 <
> dannycranmer@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, <gy...@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 <rm...@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
> >>>>> users@infra.apache.org, let's see ;)
> >>>>>
> >>>>> Best,
> >>>>> Robert
> >>>>>
> >>>>>
> >>>>> On Tue, Oct 25, 2022 at 2:08 PM Konstantin Knauf <kn...@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
> >>>>>> <ma...@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 <
> >>> tonysong820@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 <
> >>>>>> martijnvisser@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 <
> >>>>> tonysong820@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
> >>
>
>