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
