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 <martijnvis...@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 <xbjt...@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 < > > martijnvis...@apache.org > > >> > > > > > >> Agreed. I've requested a new private mailing list [1] > > >> > > >> [1] https://issues.apache.org/jira/browse/INFRA-23898 > > >> > > >> On Sat, Nov 12, 2022 at 12:09 PM Márton Balassi < > > balassi.mar...@gmail.com> > > >> wrote: > > >> > > >>> Hi Martjin, > > >>> > > >>> Given the situation let us set up the Jira signup mailing list > > following > > >>> the Calcite model. This seems the most sensible to me as of now. > > >>> > > >>> On Fri, Nov 11, 2022 at 7:26 PM Martijn Visser < > > martijnvis...@apache.org> > > >>> wrote: > > >>> > > >>>> Hi everyone, > > >>>> > > >>>> Unfortunately ASF Infra has already implemented the change and new > > Jira > > >>>> users can't sign up. > > >>>> > > >>>> I think there is consensus that we shouldn't move from Jira now. My > > >>>> proposal would be to setup a separate mailing list to which users > can > > >>> send > > >>>> their request for an account, which gets sent to the PMC so they can > > >>> create > > >>>> accounts for them. I don't see any other short term solution. > > >>>> > > >>>> If agreed, let's open up a vote thread on this. > > >>>> > > >>>> Thanks, Martijn > > >>>> > > >>>> > > >>>> Op do 3 nov. 2022 om 04:51 schreef Xintong Song < > > tonysong...@gmail.com> > > >>>> > > >>>>> Thanks all for the valuable feedback, opinions and suggestions. > > >>>>> > > >>>>> # Option 1. > > >>>>> I know this is the first choice for pretty much everyone. Many > people > > >>>> from > > >>>>> the Flink community (including myself) have shared their opinion > with > > >>>>> Infra. However, based on the feedback so far, TBH I don't think > > things > > >>>>> would turn out the way we want. I don't see what else we can do. > Does > > >>>>> anyone have more suggestions on this option? Or we probably have to > > >>>>> scratch it out of the list. > > >>>>> > > >>>>> # Option 4. > > >>>>> Seems there are also quite some concerns on using solely GH issues: > > >>>> limited > > >>>>> features (thus the significant changes to the current issue/release > > >>>>> management processes), migration cost, source of truth, etc. I > think > > >>> I'm > > >>>>> also convinced that this may not be a good choice. > > >>>>> > > >>>>> # Option 2 & 3. > > >>>>> Between the two options, I'm leaning towards option 2. > > >>>>> - IMO, making it as easy as possible for users to report issues > > should > > >>>> be a > > >>>>> top priority. Having to wait for a human response for creating an > > >>> account > > >>>>> does not meet that requirement. That makes a strong objection to > > >>> option 3 > > >>>>> from my side. > > >>>>> - Using GH issues for consumer-facing issues and reflecting the > valid > > >>>> ones > > >>>>> back to Jira (either manually by committers or by bot) sounds good > to > > >>> me. > > >>>>> The status (open/closed) and labels should make tracking the issues > > >>>> easier > > >>>>> compared to in mailing lists / slack, in terms of whether an issue > > has > > >>>> been > > >>>>> taken care of / reflected to Jira / closed as invalid. That does > not > > >>> mean > > >>>>> we should not reflect things from mailing lists / slack to Jira. > > >>> Ideally, > > >>>>> we leverage every possible channel for collecting user issues / > > >>> feedback, > > >>>>> while guiding / suggesting users to choose GH issues over the > others. > > >>>>> - For new contributors, they still need to request an account from > a > > >>> PMC > > >>>>> member. They can even make that request on GH issues, if they do > not > > >>> mind > > >>>>> posting the email address publicly. > > >>>>> - I would not be worried very much about the privacy issue, if the > > >>> Jira > > >>>>> account creation is restricted to contributors. Contributors are > > >>> exposing > > >>>>> their email addresses publicly anyway, in dev@ mailing list and > > >>> commit > > >>>>> history. I'm also not strongly against creating a dedicated mailing > > >>> list > > >>>>> though. > > >>>>> > > >>>>> Best, > > >>>>> > > >>>>> Xintong > > >>>>> > > >>>>> > > >>>>> > > >>>>> On Wed, Nov 2, 2022 at 9:16 PM Chesnay Schepler < > ches...@apache.org> > > >>>>> wrote: > > >>>>> > > >>>>>> Calcite just requested a separate mailing list for users to > request > > >>> a > > >>>>>> JIRA account. > > >>>>>> > > >>>>>> > > >>>>>> I think I'd try going a similar route. While I prefer the openness > > >>> of > > >>>>>> github issues, they are really limited, and while some things can > be > > >>>>>> replicated with labels (like fix versions / components), things > like > > >>>>>> release notes can't. > > >>>>>> We'd also lose a central place for collecting issues, since we'd > > >>> have > > >>>> to > > >>>>>> (?) scope issues per repo. > > >>>>>> > > >>>>>> I wouldn't want to import everything into GH issues (it's just a > > >>> flawed > > >>>>>> approach in the long-term imo), but on the other hand I don't know > > >>> if > > >>>>>> the auto linker even works if it has to link to either jira or a > GH > > >>>>> issue. > > >>>>>> > > >>>>>> Given that we need to change workflows in any case, I think I'd > > >>> prefer > > >>>>>> sticking to JIRA. > > >>>>>> For reported bugs I'd wager that in most cases we can file the > > >>> tickets > > >>>>>> ourselves and communicate with users on slack/MLs to gather all > the > > >>>>>> information. I'd argue that if we'd had been more pro-active with > > >>>> filing > > >>>>>> tickets for user issues (instead of relying on them to do it) we > > >>>>>> would've addressed several issues way sooner. > > >>>>>> > > >>>>>> Additionally, since either option would be a sort of experiment, > > >>> then > > >>>>>> JIRA is a safer option. We have to change less and there aren't > any > > >>>>>> long-term ramifications (like having to re-import GH tickets into > > >>>> JIRA). > > >>>>>> > > >>>>>> On 28/10/2022 16:49, Piotr Nowojski wrote: > > >>>>>>> Hi, > > >>>>>>> > > >>>>>>> I'm afraid of the migration cost to only github issues and lack > of > > >>>> many > > >>>>>>> features that we are currently using. That would be very > > >>> disruptive > > >>>> and > > >>>>>>> annoying. For me github issues are far worse compared to using > the > > >>>>> Jira. > > >>>>>>> > > >>>>>>> I would strongly prefer Option 1. over the others. Option 4 I > > >>> would > > >>>>> like > > >>>>>>> the least. I would be fine with Option 3, and Option 2 but > > >>> assuming > > >>>>> that > > >>>>>>> Jira would stay the source of truth. > > >>>>>>> For option 2, maybe we could have a bot that would backport/copy > > >>> user > > >>>>>>> created issues in github to Jira (and link them together)? > > >>>> Discussions > > >>>>>>> could still happen in the github, but we could track all of the > > >>>> issues > > >>>>> as > > >>>>>>> we are doing right now. Bot could also sync it the other way > > >>> around > > >>>>> (like > > >>>>>>> marking tickets closed, affected/fixed versions etc). > > >>>>>>> > > >>>>>>> Best, > > >>>>>>> Piotrek > > >>>>>>> > > >>>>>>> czw., 27 paź 2022 o 07:48 Martijn Visser < > > >>> martijnvis...@apache.org> > > >>>>>>> napisał(a): > > >>>>>>> > > >>>>>>>> Hi, > > >>>>>>>> > > >>>>>>>> We have to keep in mind that if a users asks for a new Jira > > >>> account, > > >>>>>> that > > >>>>>>>> person will need to provide its email address which is the Flink > > >>> PMC > > >>>>>>>> processing personal identifiable information. There needs to be > a > > >>>>>> careful > > >>>>>>>> process for that and to be honest, I don't think the ASF should > > >>> do > > >>>>> this > > >>>>>>>> from a privacy perspective. > > >>>>>>>> > > >>>>>>>> As an example, the Calcite community decided to create a > > >>> dedicated, > > >>>>>> private > > >>>>>>>> list where users can ask for an account to avoid making the > email > > >>>>>> address > > >>>>>>>> public. > > >>>>>>>> > > >>>>>>>> Best regards, > > >>>>>>>> > > >>>>>>>> Martijn > > >>>>>>>> > > >>>>>>>> Op wo 26 okt. 2022 om 22:31 schreef Danny Cranmer < > > >>>>>> dannycran...@apache.org > > >>>>>>>>> Hello, > > >>>>>>>>> > > >>>>>>>>> I agree with Gyula. My preference is also option 1, and as a > > >>>> fallback > > >>>>>>>>> option 3. Handling new user account requests will be > manageable, > > >>>>>>>> especially > > >>>>>>>>> via slack. We could setup a dedicated channel for people to ask > > >>> for > > >>>>>>>>> Jira/wiki access. > > >>>>>>>>> > > >>>>>>>>> Thanks, > > >>>>>>>>> Danny > > >>>>>>>>> > > >>>>>>>>> On Wed, 26 Oct 2022, 12:16 Gyula Fóra, <gyf...@apache.org> > > >>> wrote: > > >>>>>>>>> > > >>>>>>>>>> Hi! > > >>>>>>>>>> > > >>>>>>>>>> I would also personally prefer staying with JIRA given the > > >>> feature > > >>>>> set > > >>>>>>>>> and > > >>>>>>>>>> the past positive experience with it. > > >>>>>>>>>> I think the structured nature of JIRA with flexible > components, > > >>>>> issue > > >>>>>>>>>> types, epics, release handling etc have been a great benefit > to > > >>>> the > > >>>>>>>>>> project, it would be a shame to give some of these up. > > >>>>>>>>>> > > >>>>>>>>>> If for some reason Option 1 is not possible, I would still > > >>> prefer > > >>>>>>>> Option > > >>>>>>>>> 3 > > >>>>>>>>>> (requiring new contributors to ask for JIRA access) compared > to > > >>>> the > > >>>>>>>>>> alternatives. > > >>>>>>>>>> > > >>>>>>>>>> Cheers, > > >>>>>>>>>> Gyula > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> On Tue, Oct 25, 2022 at 3:48 PM Robert Metzger < > > >>>> rmetz...@apache.org > > >>>>>> > > >>>>>>>>>> wrote: > > >>>>>>>>>> > > >>>>>>>>>>> Thank you for starting this discussion Xintong! > > >>>>>>>>>>> > > >>>>>>>>>>> I would also prefer option 1. > > >>>>>>>>>>> > > >>>>>>>>>>> The ASF Jira is probably one of the largest, public Jira > > >>>> instances > > >>>>> on > > >>>>>>>>> the > > >>>>>>>>>>> internet. Most other Jiras are internal within companies, so > > >>>>>>>> Atlassian > > >>>>>>>>> is > > >>>>>>>>>>> probably not putting a lot of effort into automatically > > >>> detecting > > >>>>> and > > >>>>>>>>>>> preventing spam and malicious account creation. > > >>>>>>>>>>> If we want to convince Infra to keep the current sign up > > >>> process, > > >>>>> we > > >>>>>>>>>>> probably need to help them find a solution for the problem. > > >>>>>>>>>>> Maybe we can configure the ASF Jira to rely on GitHub as an > > >>>>> identity > > >>>>>>>>>>> provider? I've just proposed that in the discussion on > > >>>>>>>>>>> us...@infra.apache.org, let's see ;) > > >>>>>>>>>>> > > >>>>>>>>>>> Best, > > >>>>>>>>>>> Robert > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> On Tue, Oct 25, 2022 at 2:08 PM Konstantin Knauf < > > >>>>> kna...@apache.org> > > >>>>>>>>>>> wrote: > > >>>>>>>>>>> > > >>>>>>>>>>>> Hi everyone, > > >>>>>>>>>>>> > > >>>>>>>>>>>> while I see some benefits in moving to Github Issues > > >>> completely, > > >>>>> we > > >>>>>>>>>> need > > >>>>>>>>>>> to > > >>>>>>>>>>>> be aware that Github Issues lacks many features that Jira > > >>> has. > > >>>>> From > > >>>>>>>>> the > > >>>>>>>>>>> top > > >>>>>>>>>>>> of my head: > > >>>>>>>>>>>> * there are no issue types > > >>>>>>>>>>>> * no priorities > > >>>>>>>>>>>> * issues can only be assigned to one milestone > > >>>>>>>>>>>> So, you need to work a lot with labels and conventions and > > >>>>>>>> basically > > >>>>>>>>>> need > > >>>>>>>>>>>> bots or actions to manage those. Agreeing on those > processes, > > >>>>>>>> setting > > >>>>>>>>>>> them > > >>>>>>>>>>>> up and getting used to them will be a lot of work for the > > >>>>>>>> community. > > >>>>>>>>>>>> So, I am also in favor of 1) for now, because I don't really > > >>>> see a > > >>>>>>>>> good > > >>>>>>>>>>>> alternative option. > > >>>>>>>>>>>> > > >>>>>>>>>>>> Cheers, > > >>>>>>>>>>>> > > >>>>>>>>>>>> Konstantin > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> Am Mo., 24. Okt. 2022 um 22:27 Uhr schrieb Matthias Pohl > > >>>>>>>>>>>> <matthias.p...@aiven.io.invalid>: > > >>>>>>>>>>>> > > >>>>>>>>>>>>> I agree that leaving everything as is would be the best > > >>>> option. I > > >>>>>>>>>> also > > >>>>>>>>>>>> tend > > >>>>>>>>>>>>> to lean towards option 4 as a fallback for the reasons > > >>> already > > >>>>>>>>>>> mentioned. > > >>>>>>>>>>>>> I'm still not a big fan of the Github issues. But that's > > >>>> probably > > >>>>>>>>>> only > > >>>>>>>>>>>>> because I'm used to the look-and-feel and the workflows of > > >>>> Jira. > > >>>>>>>> I > > >>>>>>>>>> see > > >>>>>>>>>>>>> certain benefits of moving to Github, though. We're still > > >>>> having > > >>>>>>>>> the > > >>>>>>>>>>> idea > > >>>>>>>>>>>>> of migrating from AzureCI to GitHub Actions. Moving the > > >>> issues > > >>>> to > > >>>>>>>>>>> GitHub > > >>>>>>>>>>>> as > > >>>>>>>>>>>>> well might improve the user experience even more. Reducing > > >>> the > > >>>>>>>>> number > > >>>>>>>>>>> of > > >>>>>>>>>>>>> services a new contributor should be aware of to reach the > > >>>>>>>>> community > > >>>>>>>>>>> is a > > >>>>>>>>>>>>> good way to reduce the confusion for newcomers, I could > > >>>> imagine. > > >>>>>>>>>>>>> Additionally, I also like the fact that I wouldn't have to > > >>>> bother > > >>>>>>>>>> about > > >>>>>>>>>>>> the > > >>>>>>>>>>>>> Apache Jira markdown anymore. 8) > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> I agree with Martijn's concern about not being able to > track > > >>>> all > > >>>>>>>>>>>>> Flink-related issues in a single system. I'm just wondering > > >>>>>>>> whether > > >>>>>>>>>>>>> something is holding us back from collecting all > > >>> Flink-related > > >>>>>>>>> issues > > >>>>>>>>>>> in > > >>>>>>>>>>>>> the Flink's Github repository and disabling the issue > > >>> feature > > >>>> in > > >>>>>>>>> any > > >>>>>>>>>>>> other > > >>>>>>>>>>>>> Flink-related repository? > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> About migrating the Jira issues: I would be hopeful that > > >>>>>>>> migrating > > >>>>>>>>> is > > >>>>>>>>>>>>> doable in the end. There is a blog post from the spring > data > > >>>> guys > > >>>>>>>>>> about > > >>>>>>>>>>>>> their journey on migrating from Jira to GitHub issues [1]. > > >>>>>>>>>>> Unfortunately, > > >>>>>>>>>>>>> they didn't provide any scripts. > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> For the case that infra moves forward with disabling the > > >>> signup > > >>>>>>>>>> without > > >>>>>>>>>>>> us > > >>>>>>>>>>>>> having come up with a decision and its actual execution > > >>> (i.e. > > >>>>>>>>>> migrating > > >>>>>>>>>>>> the > > >>>>>>>>>>>>> Jira issues to GH), I would prefer having users send a > > >>> request > > >>>> to > > >>>>>>>>> the > > >>>>>>>>>>>>> mailing list. I would rather have a temporary phase where > > >>>>>>>> there's a > > >>>>>>>>>> bit > > >>>>>>>>>>>> of > > >>>>>>>>>>>>> overhead of registering the users in the Apache Jira than > > >>>> having > > >>>>>>>>> two > > >>>>>>>>>>>>> locations for bug tracking. I suspect that there are no > > >>>>>>>> statistics > > >>>>>>>>> on > > >>>>>>>>>>> how > > >>>>>>>>>>>>> many new users register with Jira in a given timeframe to > > >>>>>>>>> contribute > > >>>>>>>>>> to > > >>>>>>>>>>>>> Flink? > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> Matthias > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> [1] > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > >>>>>>>> > > >>>>>> > > >>>>> > > >>>> > > >>> > > > https://spring.io/blog/2021/01/07/spring-data-s-migration-from-jira-to-github-issues > > >>>>>>>>>>>>> [2] > > >>>>>>>>> > > >>> https://lists.apache.org/thread/pjb5jzvw41xjtzgf4w0gggpqrt2fq6ov > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> On Mon, Oct 24, 2022 at 10:28 AM Xintong Song < > > >>>>>>>>> tonysong...@gmail.com > > >>>>>>>>>>>>> wrote: > > >>>>>>>>>>>>> > > >>>>>>>>>>>>>> I agree with you that option 1) would be the best for us. > > >>>> Let's > > >>>>>>>>>> keep > > >>>>>>>>>>>>> hoping > > >>>>>>>>>>>>>> for the best. > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> Option 4), as you said, comes with prices. At the moment, > I > > >>>>>>>> don't > > >>>>>>>>>>> have > > >>>>>>>>>>>>>> thorough answers to your questions. > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> Just one quick response, I think there's a good chance > > >>> that we > > >>>>>>>>> can > > >>>>>>>>>>>> import > > >>>>>>>>>>>>>> current Jira tickets into GH. Jira supports exporting > > >>> issues > > >>>>>>>> with > > >>>>>>>>>>>> fields > > >>>>>>>>>>>>>> that you specified as CSV/XML/... files. With a brief > > >>> google > > >>>>>>>>>> search, > > >>>>>>>>>>> I > > >>>>>>>>>>>>>> found some tools that help bulk creating issues in GH. > > >>> E.g., > > >>>>>>>>>>>>>> github-csv-tools [1] is described to support importing > > >>> issues > > >>>>>>>>> with > > >>>>>>>>>>>> title, > > >>>>>>>>>>>>>> body, labels, status and milestones from a CSV file. > That's > > >>>>>>>>>> probably > > >>>>>>>>>>>> good > > >>>>>>>>>>>>>> enough for us to search/filter the issues in GH, and a > > >>> link to > > >>>>>>>>> the > > >>>>>>>>>>> Jira > > >>>>>>>>>>>>>> ticket can be posted in the GH issue for complete > > >>> conversation > > >>>>>>>>>>> history > > >>>>>>>>>>>>> and > > >>>>>>>>>>>>>> other details. > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> Best, > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> Xintong > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> [1] https://github.com/gavinr/github-csv-tools > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> On Mon, Oct 24, 2022 at 3:58 PM Martijn Visser < > > >>>>>>>>>>>> martijnvis...@apache.org > > >>>>>>>>>>>>>> wrote: > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> Hi Xintong, > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> I'm also not in favour of option 2, I think that two > > >>> systems > > >>>>>>>>> will > > >>>>>>>>>>>>> result > > >>>>>>>>>>>>>>> in an administrative burden and less-efficient workflow. > > >>> I'm > > >>>>>>>>> also > > >>>>>>>>>>> not > > >>>>>>>>>>>>> in > > >>>>>>>>>>>>>>> favour of option 3, I think that this will result in > first > > >>>>>>>> time > > >>>>>>>>>>>>>>> users/contributors in not-filling their first bug report, > > >>>>>>>> user > > >>>>>>>>>>>> question > > >>>>>>>>>>>>>> or > > >>>>>>>>>>>>>>> feature request. > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> I'm still hoping for option 1 while the discussion is not > > >>>>>>>>>> finished > > >>>>>>>>>>>> with > > >>>>>>>>>>>>>>> Infra. > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> If we assume that option 1 won't be possible, then I > think > > >>>>>>>>>> option 4 > > >>>>>>>>>>>>> will > > >>>>>>>>>>>>>>> be the best-option-left. I'm not necessarily in favour, > > >>>>>>>> because > > >>>>>>>>>> of > > >>>>>>>>>>> a > > >>>>>>>>>>>>>> number > > >>>>>>>>>>>>>>> of problems it will introduce: > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> 1. I don't think importing current Jira tickets into > > >>> Github > > >>>>>>>>>> Issues > > >>>>>>>>>>>> is a > > >>>>>>>>>>>>>>> realistic option. So we would have two administrations. > > >>>>>>>> Before > > >>>>>>>>>> you > > >>>>>>>>>>>>>> create a > > >>>>>>>>>>>>>>> new ticket, you should check if it exists both as a Jira > > >>>>>>>> ticket > > >>>>>>>>>> and > > >>>>>>>>>>>> as > > >>>>>>>>>>>>> a > > >>>>>>>>>>>>>>> Github Issue. > > >>>>>>>>>>>>>>> 2. How would we deal with completing a PR? There must be > > >>> one > > >>>>>>>>>>>>>>> administration leading for the changelog generation (to > > >>> avoid > > >>>>>>>>>> that > > >>>>>>>>>>>>> you're > > >>>>>>>>>>>>>>> missing an item), which could then only be Github Issues. > > >>> So > > >>>>>>>>>> would > > >>>>>>>>>>> we > > >>>>>>>>>>>>>>> require all PRs that are merged to exist as a Github > > >>> Issue? > > >>>>>>>>>>>>>>> 3. There's no longer one central administration, which is > > >>>>>>>>>>> especially > > >>>>>>>>>>>>>>> valuable to track all issues across projects like the > > >>>>>>>> different > > >>>>>>>>>>>>>> connectors, > > >>>>>>>>>>>>>>> Flink ML, Table Store etc. > > >>>>>>>>>>>>>>> 4. Our current CI labeling works on the Jira issues, not > > >>> on > > >>>>>>>> the > > >>>>>>>>>>>> Github > > >>>>>>>>>>>>>>> Issues labels. > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> Best regards, > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> Martijn > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> On Mon, Oct 24, 2022 at 7:29 AM Xintong Song < > > >>>>>>>>>>> tonysong...@gmail.com> > > >>>>>>>>>>>>>>> wrote: > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> Hi devs and users, > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> As many of you may have already noticed, Infra announced > > >>>>>>>> that > > >>>>>>>>>> they > > >>>>>>>>>>>>> will > > >>>>>>>>>>>>>>>> soon disable public Jira account signups [1]. That > > >>> means, in > > >>>>>>>>>> order > > >>>>>>>>>>>> for > > >>>>>>>>>>>>>>>> someone who is not yet a Jira user to open or comment on > > >>> an > > >>>>>>>>>> issue, > > >>>>>>>>>>>>>> he/she > > >>>>>>>>>>>>>>>> has to first reach out to a PMC member to create an > > >>> account > > >>>>>>>>> for > > >>>>>>>>>>>>> him/her. > > >>>>>>>>>>>>>>>> This raises the bar for new contributors and users to > > >>>>>>>>>> participate > > >>>>>>>>>>> in > > >>>>>>>>>>>>>>>> community interactions, making it necessary for us to > > >>>>>>>> consider > > >>>>>>>>>>>> whether > > >>>>>>>>>>>>>> (and > > >>>>>>>>>>>>>>>> how) we should change our issue tracking workflows. > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> I can see a few possible options. > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> 1. Reaching out to Infra and trying to change their mind > > >>> on > > >>>>>>>>> this > > >>>>>>>>>>>>>>>> decision. I’ve already been trying this [2], and so far > > >>> the > > >>>>>>>>>>> feedback > > >>>>>>>>>>>>>> seems > > >>>>>>>>>>>>>>>> unoptimistic. > > >>>>>>>>>>>>>>>> 2. Using both Jira (for development issues) & Github > > >>> Issues > > >>>>>>>>> (for > > >>>>>>>>>>>>>>>> customer-facing issues), as Infra suggested. > > >>>>>>>>>>>>>>>> 3. Stay with using Jira only, so that new Jira users > > >>> need to > > >>>>>>>>> ask > > >>>>>>>>>>> on > > >>>>>>>>>>>>> the > > >>>>>>>>>>>>>>>> mailing lists / Slack for creating accounts. > > >>>>>>>>>>>>>>>> 4. Migrating to Github Issues completely. > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> Personally, I’m leaning toward option 4). > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> TBH, I don’t see any good reason for option 2). I’d > > >>> expect > > >>>>>>>>> using > > >>>>>>>>>>> two > > >>>>>>>>>>>>>>>> different issue tracking tools at the same time would be > > >>>>>>>>> complex > > >>>>>>>>>>> and > > >>>>>>>>>>>>>>>> chaotic. Option 3) is probably more friendly to existing > > >>>>>>>>>>> developers > > >>>>>>>>>>>>> and > > >>>>>>>>>>>>>>>> users, while being less friendly to newcomers. Option 4) > > >>> on > > >>>>>>>>> the > > >>>>>>>>>>>>>> contrary, > > >>>>>>>>>>>>>>>> is more friendly to newcomers, at some migration cost > > >>> which > > >>>>>>>>>> might > > >>>>>>>>>>> be > > >>>>>>>>>>>>>>>> non-trivial but once for all. > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> Github issues have been widely used by many open source > > >>>>>>>>>> projects, > > >>>>>>>>>>>>>>>> including Kubernetes, Flink CDC, and Apache projects > > >>> Iceberg > > >>>>>>>>> and > > >>>>>>>>>>>>>> Airflow. > > >>>>>>>>>>>>>>>> With a set of well-designed labels, we should be able to > > >>>>>>>>> achieve > > >>>>>>>>>>>> most > > >>>>>>>>>>>>> of > > >>>>>>>>>>>>>>>> the Jira functions / features that we currently rely on. > > >>>>>>>>>> Moreover, > > >>>>>>>>>>>> it > > >>>>>>>>>>>>>>>> better integrates the issue tracking and code > > >>> contributing > > >>>>>>>>>>> systems, > > >>>>>>>>>>>>> and > > >>>>>>>>>>>>>>>> would be easier to access (I believe there’s more GH > > >>> users > > >>>>>>>>> than > > >>>>>>>>>>>> Jira / > > >>>>>>>>>>>>>>>> mailing lists). > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> All in all, I’d suggest to keep monitoring Infra’s > > >>> feedback > > >>>>>>>> on > > >>>>>>>>>>>> option > > >>>>>>>>>>>>>> 1), > > >>>>>>>>>>>>>>>> while taking steps (investigation, workflow & label > > >>> design) > > >>>>>>>>>>>> preparing > > >>>>>>>>>>>>>> for > > >>>>>>>>>>>>>>>> option 4). > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> Looking forward to hearing what you think about this. > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> Best, > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> Xintong > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> [1] > > >>>>>>>>>>>> > > >>>> https://lists.apache.org/thread/jx9d7sp690ro660pjpttwtg209w3m39w > > >>>>>>>>>>>>>>>> [2] > > >>>>>>>>>>>> > > >>>> https://lists.apache.org/thread/fjjtk30dxf6fyoo4q3rmkhh028or40fw > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> -- > > >>>>>>>>>>>> https://twitter.com/snntrable > > >>>>>>>>>>>> https://github.com/knaufk > > >>>>>>>>>>>> > > >>>>>>>> -- > > >>>>>>>> Martijn > > >>>>>>>> https://twitter.com/MartijnVisser82 > > >>>>>>>> https://github.com/MartijnVisser > > >>>>>>>> > > >>>>>> > > >>>>>> > > >>>>> > > >>>> -- > > >>>> Martijn > > >>>> https://twitter.com/MartijnVisser82 > > >>>> https://github.com/MartijnVisser > > >>>> > > >>> > > >> -- > > > Martijn > > > https://twitter.com/MartijnVisser82 > > > https://github.com/MartijnVisser > > > > >
