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
