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
> >
> >
>