Could we get the proposal doc up on the ASF wiki? On Tue 3 Jan 2023, 17:25 Jason Porter, <jpor...@ibm.com.invalid> wrote:
> Sounds like there aren’t any further questions, but I can appreciate > people just getting back to work from the end of the year. I’ll give it > another day before we move on to the next stage, which I believe is a call > for a vote, correct? > > Jason Porter > Software Engineer > He/Him/His > > IBM > > On Dec 23, 2022, at 09:20, Jason Porter <jpor...@ibm.com.INVALID> wrote: > > 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 > > >
