Just a quick follow-up on this topic regarding the non-apache JIRA projects for the transferred projects.
We need to make sure that no one can add new issues to these old JIRAs. However, we should keep all the old information there because it's useful. People can look at the old stuff to understand the history or to connect it to new tasks. From now on, any new tasks should be written up in GitHub Issues, not JIRA. Even though we will be using GitHub Issues for new work, if there is already an issue in the old JIRA that explains a problem well, we don't need to write it all over again in GitHub. Just putting a link to the old JIRA issue in the new GitHub Issue is good enough. If we need to talk about an issue in detail, we will decide how to do that on a case-by-case basis. But mostly, we want to use GitHub Issues to talk things over. On Tue, Oct 31, 2023 at 1:58 PM Alex Porcelli <[email protected]> wrote: > > +1 from me :) > > > On Tue, Oct 31, 2023 at 1:55 PM ricardo zanini fernandes > <[email protected]> wrote: >> >> Oh that makes perfect sense. >> >> I agree that we can use the global one for fixing CVEs across all the >> repos, for example. Also, all the other use cases you mentioned. >> >> That's clear now, many thanks for clarifying. >> >> I'd like to hear from others. Do we have a +1 to use repo level issues? >> >> cheers! >> >> On Tue, Oct 31, 2023 at 2:50 PM Alex Porcelli <[email protected]> wrote: >> >> > Sorry my lack of clarity on my previous email. >> > >> > What I wanted to say is that we can use both, and move issues around >> > where we see better fit. I just don't think we can avoid a >> > commons/global one. >> > >> > On Tue, Oct 31, 2023 at 1:43 PM ricardo zanini fernandes >> > <[email protected]> wrote: >> > > >> > > Hey Alex! >> > > >> > > Thanks for the replies! >> > > >> > > I believe the use cases you just mentioned might have issues opened in >> > the >> > > other repositories and have GH to link them. Wouldn't that make sense? >> > > Plus, I believe these use cases are not the rule, but the exception. >> > > Usually, what we have is a single issue in the scope of a single repo. >> > > >> > > > So, based on the list above, the use of a centralized repo makes >> > > sense. But you know what? Moving issues around is quite easy within >> > > the same organization, so based on my input above I'd argue we can't >> > > live without a centralized repo... but you can certainly move issues >> > > to individual repos if they make more sense there.. as part of the >> > > developer workflow. >> > > >> > > Not sure if I understood your statement here 😅 >> > > >> > > So can we or not use the repo level approach? For example, see these I >> > > created yesterday: [1,2]. I had to add the "[SonataFlow Operator]" to the >> > > title to give context. Maybe adding more labels? :( >> > > >> > > Anyhow, I think we should take a path. If the usage is this central repo >> > > for issues, so be it. But I think, based on the feedback I got here, that >> > > we should focus on having the issues at the repo level. >> > > >> > > +1 for the comms strategy after having a release. >> > > >> > > [1] https://github.com/apache/incubator-kie-issues/issues/661 >> > > [2] https://github.com/apache/incubator-kie-issues/issues/660 >> > > >> > > On Tue, Oct 31, 2023 at 2:22 PM Alex Porcelli <[email protected]> wrote: >> > > >> > > > On Mon, Oct 30, 2023 at 9:17 AM ricardo zanini fernandes >> > > > <[email protected]> wrote: >> > > > > >> > > > > Hey folks! >> > > > > >> > > > > Last community meeting we had this topic pending regarding the >> > > > > communication of opening issues. >> > > > > >> > > > > I understand that we must use kie-issues now for opening issues and >> > not >> > > > an >> > > > > internal JIRA anymore. Great! I like GH issues more. Although, I >> > have a >> > > > few >> > > > > Qs and observations: >> > > > > >> > > > > 1) Why use a central repository for opening issues and not opening >> > issues >> > > > > in the respective repository? This is the convention, and each repo >> > might >> > > > > have different requirements. Like adding different labels or bots. >> > > > Having a >> > > > > central repo for issues seems an anti-pattern. >> > > > >> > > > I agree in principle, however I think this is more complex than that. >> > > > The default use of centralized issue repository helps in the following >> > > > scenarios: >> > > > >> > > > - Issues that span multiple repositories (ie. a library upgrade) >> > > > - Some issues may be surfaced on one component but the real issue is >> > > > actually happening in another component. (ie. DMN Runner in KIE >> > > > Sandbox fails with certain input, JIT DMN Runner is failing, but the >> > > > bug is on DMN core engine) >> > > > - General users won't necessary know what repository stores the code >> > > > of the component that they are using >> > > > >> > > > So, based on the list above, the use of a centralized repo makes >> > > > sense. But you know what? Moving issues around is quite easy within >> > > > the same organization, so based on my input above I'd argue we can't >> > > > live without a centralized repo... but you can certainly move issues >> > > > to individual repos if they make more sense there.. as part of the >> > > > developer workflow. >> > > > >> > > > And just keep in mind, for all the purposes in the context of Apache, >> > > > the only real project is KIE, others are only submodules. >> > > > >> > > > > 2) Can't we have templates when opening issues? How do we >> > communicate to >> > > > > the community how to open issues? If we go with this central issues >> > repo, >> > > > > then we need to communicate in each repo that issues can't be opened >> > > > there. >> > > > > Or at least disable the issues tab via .asf.yaml file. This passes a >> > > > weird >> > > > > message to the community, IMO. The first impression is that we might >> > not >> > > > > accept issues. A newcomer will have to look for a contrib/readme >> > file to >> > > > > find where to open. >> > > > >> > > > +1 for templates. And I don't think we need to block the github issues >> > > > in repos, we can change this right now (my +1 for that). >> > > > >> > > > For general communication, I think we all agreed to focus first on the >> > > > codebase move + a CI baseline... once we are able to cut our first >> > > > release, I suspect our focus will turn to our communications. >> > > > >> > > > > 3) Do we have to migrate internal opening JIRAs to GH Issues? If so, >> > can >> > > > we >> > > > > do it as we start working on them instead of a batch migration? >> > > > >> > > > The agreement was to not migrate existing... but for anything to be >> > > > worked... it's expected the individual will copy-n-paste from JIRA to >> > > > GHI to track the work. >> > > > >> > > > > >> > > > > Thank u! >> > > > > -- >> > > > > Zanini >> > > > >> > > > --------------------------------------------------------------------- >> > > > To unsubscribe, e-mail: [email protected] >> > > > For additional commands, e-mail: [email protected] >> > > > >> > > > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [email protected] >> > For additional commands, e-mail: [email protected] >> > >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
