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
