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