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]
