https://cwiki.apache.org/confluence/display/INCUBATOR/KIE+Proposal is the work in progress page.
On Tue, 3 Jan 2023 at 19:53, PJ Fanning <fannin...@gmail.com> wrote: > > I did some of the wikification of the email but it's pretty time > consuming and I want to finish up for the evening. > > The main item remaining is to put all the initial committers into the table. > > On Tue, 3 Jan 2023 at 19:26, Jason Porter <jpor...@ibm.com> wrote: > > > > I was just going to do this but looks like you beat me to it, PJ, thank you. > > > > Jason Porter > > Software Engineer > > He/Him/His > > > > IBM > > > > On Jan 3, 2023, at 09:42, PJ Fanning <fannin...@apache.org> wrote: > > > > This Message Is From an External Sender > > This message came from outside your organization. > > 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 > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
