Are there any further questions anyone has about KIE? I know we're nearing the end of the year and people may not be watching as closely, but wanted to make sure since the discussion has died down.
If there are no further questions, are we able to go to a vote? ________________________________ From: Jason Porter <jpor...@ibm.com.INVALID> Sent: Tuesday, December 13, 2022 08:37 To: general@incubator.apache.org <general@incubator.apache.org> Subject: [EXTERNAL] RE: [DISCUSS] KIE Proposal ________________________________ From: Calvin Kirs <k...@apache.org> Sent: Monday, December 12, 2022 23:31 To: general@incubator.apache.org <general@incubator.apache.org> Subject: [EXTERNAL] Re: [DISCUSS] KIE Proposal On Fri, Dec 9, 2022 at 11:45 PM Jason Porter <jpor...@ibm.com.invalid> wrote: > > We don’t feel like KIE and Servicecomb-kie clash. One is an acronym (KIE- > Knowledge Is Everything), and the other is a suffix. Both projects are very > different as well. Servicecomb-kie is a configuration center for > microservices written in Go, whereas KIE is a knowledge engineering and > process automation solution written in Java. For example, how was this > handled in the context of Apache DeltaCloud and Apache DeltaSpike; or Apache > DataFu and Apache DataLab? Is there precedence within the ASF for similarly > named projects? The two communities have also co-existed for roughly the same > time, using the same names without clashes. That's not a problem If two projects are in different fields. we'd just need to be careful with the project description. Perfect! Thank you, Calvin. > > > As was stated previously, the number of projects is much smaller than the > number of GitHub repos. This is because KIE did not use a singular repository > model within the GitHub organization. The projects we’re currently > considering in this proposal are Kogito, jBPM, Drools, KIE-Tools, and another > project for the CNCF Serverless Workflow implementation that is going through > a naming process now. KIE-Tools is a little odd, though, as it doesn’t stand > on its own well. The existing code base contains a lot of modules and code, > which could be considered legacy, which we do not plan to move over. There > will be a cleaning and pruning process to ensure a more relevant, > sustainable, and forward-looking set of modules as code is moved over. This > should further reduce the amount of code that is moved over. We understand we > may need to collapse the repositories moving over to the ASF. Let us know if > you want to see how everything rolls into a more flat structure. > > > Regarding umbrella versus standalone projects, we believe that the unified > and cohesive experience provides more value than just the sum of its parts. > This is also not just about where we are now, but where we hope to evolve as > a knowledge engineering platform. On the surface, those projects can be seen > as independent in their business rules, decisions, and workflow domains. > However, real-world use cases are more complex. Usually, they require a lot > of interdependencies, for example, business rules orchestration is > accomplished by using a workflow file definition (i.e., BPMN), and complex > workflow decisions are better modeled in DMN models. The aim is to try and > drive consistency and ease of use across those technologies, in an integrated > and holistic manner. > > > If those projects end up as individual TLPs, it'll be up to users to write a > lot of boiler-plate code - or create additional new projects to handle and > abstract the unified experience. > > > Of course, as a consequence of the unified vision, the current codebase is > taking advantage of this unification, which means there's a lot of shared > code among the projects. Moving away from this will also result in more > top-level supporting projects to provide additional code, needed as > foundational code or integration code, which may actually create more > complexity and end-user confusion. > > > > Although it might not be the most popular example within Apache, KIE aims to > provide a similar umbrella cohesiveness that Apache OpenOffice has for their > sub-projects like Write and Calc. We really want the community to think of > knowledge engineering as a whole domain of technologies for problem-solving, > and not on individual silo technologies. > > > Lastly, fracturing the community we have already created around the KIE brand > and concept is certainly not ideal and will weaken the overall project brands > and success. We believe we'll be able to leverage further what we currently > have in the community and build upon it to create a more cohesive > knowledge-processing solution if everything stays together and people remain > invested in the success of the knowledge engineering platform as a whole, > rather than their individual technologies. > > > We would like to initially keep the PPMC small, ideally 5-7 people. We have > around 50 people identified as initial committers, but having a PMC that > large during incubation is not ideal for the issues that have been mentioned. > > Jason Porter > Software Engineer > He/Him/His > > IBM > > On Dec 9, 2022, at 08:17, Niall Pemberton <niall.pember...@gmail.com> wrote: > > On Tue, 6 Dec 2022 at 16:27, Jason Porter > <jpor...@ibm.com.invalid<mailto:jpor...@ibm.com.invalid>> wrote: > > > On Dec 6, 2022, at 01:43, Christofer Dutz <christofer.d...@c-ware.de> > wrote: > > Hi Jason, > > Well, those numbers are a bit better than the initial ones. > Thing is: Mentors will not only have to help onboard people to Apache > and teach them how to do things, if they are doing their job correctly, > they should also really audit the releases being done and help get the > codebase into shape first. > > Even with 12 sub-projects, work-wise that would put a load on the > mentors, as if they signed up for mentoring 12 projects. > > So how about bringing in projects separately (where it makes sense)? > There each project could have their initial PPMC and committer lists and it > would spread out the load a bit. However I would expect staffing 12 > projects with enough work-willing mentors will still be challenging and I > would assume not all of them to find enough of them, but it could be one > first step. > > Or is there an advantage of considering all projects as one unity? > > Chris > > [snip] > > That is part of a broader question. Some of those repos are things like > examples for kogito, the website, etc. Things that are part of the projects > themselves, but don’t have a life outside of the project to which they > belong. I understand we’ll probably have to collapse the structures within > Apache and have a single repo per project. What we’re really looking at as > far as projects being donated: > > Kogito > Drools > jBPM > > > I really think these should be separate projects. I realize theres a > dependency/hierarchy between them (jBPM using Drools as its rules engine > and Kogito using jBPM for its business process/workflow) - but people use > Drools without jBPM and (I assume) jBPM without Kogito. Even if the current > set of contributors all work on all three projects, the aspiration here at > Apache has to be to grow the community of contributors from the user > community which will not be completely the same for the three projects. > I've used Drools in the past, but not jBPM or Kogito. > > Niall > > > > Then there are the supporting repos for things like examples, docs, > website, tooling, etc. Many of the people working on these projects work on > all of them, so it would probably be the same group of people with very > little deviation in the list of committers. Could they be different PPMCs, > but they’d basically be the same group, just more work with the reports, > setup, infra, etc. > > Jason Porter > Software Engineer > He/Him/His > > IBM > -- Best wishes！ CalvinKirs --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
