Alex, I did not see any heads up etiquette on the reference you linked, so I was assuming you refer to Zulip. So, whats exactly your proposal for this kind of case?
On Fri, Apr 5, 2024 at 4:14 PM Alex Porcelli <a...@porcelli.me> wrote: > Francisco, > > Zulip is not an official channel, so I strongly recommend using ML for > that. > > This is valid for everyone in the community, individuals should not be > single out for any reason. > > On Fri, Apr 5, 2024 at 10:10 AM Francisco Javier Tirado Sarti > <ftira...@redhat.com> wrote: > > > > Yes, that was the idea, to mention the need for a change on jbpm-flow on > > Zulip, pinging Enrique. > > Of course, if I'm also an interested stakeholder for any change in > > jbpm-flow, I expect this to be reciprocal ;) > > > > > > On Fri, Apr 5, 2024 at 4:01 PM Alex Porcelli <porce...@apache.org> > wrote: > > > > > Francisco, > > > > > > As stated here [1], the particular case you mention would not exactly > > > require a DISCUSS or PROPOSAL, but certainly the HEADS UP could be > > > used as the changes applied modified the engine behavior to some > > > extent. > > > > > > I really would encourage you to AVOID have private conversation > > > between individuals, because Enrique is only one of the interested > > > stakeholders... we should not excluded other community members from > > > such discussions. That's exactly the reason we have the communication > > > procedures established. > > > > > > - > > > Alex > > > > > > [1] - > > > > https://cwiki.apache.org/confluence/display/KIE/Communication+within+Apache > > > > > > On Fri, Apr 5, 2024 at 9:54 AM Francisco Javier Tirado Sarti > > > <ftira...@redhat.com> wrote: > > > > > > > > Hi Alex, > > > > > > > > Of course, we will be delighted to continue maintaining our high > > > standards > > > > of collaboration that define our community. > > > > However, it is unclear to me if for any community issue that arises > as a > > > > consequence of a bug (or perceived bug) in our code base, there is a > need > > > > to write a proposal. > > > > I firmly believe proposals should be shared for new features that are > > > large > > > > enough or changes that affect existing functionalities, but I have > doubts > > > > that bug fixes (they already have the associated issue) should > require a > > > > proposal to be discussed formally through a mail list. > > > > There is not agreement about if this bug fix > > > > https://github.com/apache/incubator-kie-kogito-runtimes/pull/3459 > should > > > > have been precluded by a proposal. In the context in which I made > the > > > > decision to change an internal (I should remark the word internal) > public > > > > method that was exposing an internal map, it seems correct to not > bore > > > > everyone in this mailing list with a discussion about a V7 inherited > > > code. > > > > A code that is pretty specific to Split node and that have side > effects > > > on > > > > the XML dumper and a couple of visitor classes that were covered by > the > > > PR. > > > > I think it will be more practical if, starting from now, I just > contact > > > > Enrique before changing any code under jbpm-flow, and in case we do > not > > > > agree on a solution, move the discussion to the overall list so we > whole > > > > team vote based on pros and cons of each proposal (although it can be > > > > argued that people unfamiliar with that part of the code will not > have > > > > enough elements to make an informed vote). In this particular case, I > > > > should have contacted Enrique to make sure he was fine with the > solution > > > > taken. > > > > Thanks for bringing up the topic. > > > > > > > > > > > > On Fri, Apr 5, 2024 at 2:52 PM Alex Porcelli <porce...@apache.org> > > > wrote: > > > > > > > > > I kindly remind everyone of the importance of adhering to our > > > > > established procedures and communication etiquette. These > guidelines > > > > > have been implemented to ensure our community operates efficiently, > > > > > respectfully, and inclusively. > > > > > > > > > > For convenience, here are the links to the relevant information [1] > > > [2]. > > > > > > > > > > We all share a commitment to the success of the Apache KIE project, > > > > > and following these agreed-upon practices plays a crucial role in > > > > > achieving our collective goals. It helps streamline our > interactions > > > > > and ensures a productive and positive environment for all > > > > > contributors. > > > > > > > > > > Should you have any questions or suggestions about these > guidelines, > > > > > please feel free to engage in this thread. Let's continue to > support > > > > > each other and work together to maintain the high standards of > > > > > collaboration that define our community. > > > > > > > > > > - > > > > > Alex > > > > > > > > > > [1] > > > > > > > > > https://cwiki.apache.org/confluence/display/KIE/Communication+within+Apache > > > > > [2] > https://lists.apache.org/thread/x499xlrdf5b6vb57mbywxgl7f9mokvkq > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > > > > > For additional commands, e-mail: dev-h...@kie.apache.org > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > > > For additional commands, e-mail: dev-h...@kie.apache.org > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > For additional commands, e-mail: dev-h...@kie.apache.org > >
