Ok, I was searching "HEADS UP" and it was "HEADS-UP" ;), my fault. So, then I guess the proposal is that every time a committer has opened a PR with no small (size is always relative, but let's use common sense for that) changes, then it should send an e-mail to the list. Have a nice weekend
On Fri, Apr 5, 2024 at 5:25 PM Alex Porcelli <porce...@apache.org> wrote: > Check the wiki link and you can find the following: > > “[HEADS-UP] - Non-small changes to the code base are underway, and the list > should take note” > > - > Alex > > On Fri, Apr 5, 2024 at 11:23 AM Francisco Javier Tirado Sarti < > ftira...@redhat.com> wrote: > > > 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 > > > > > > > > >
