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