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 > >
