Re: [DISCUSS] KIE Proposal

[Jason Porter]

Hmm… I don’t seem to have edit access :(

Jason Porter
Software Engineer
He/Him/His

IBM

On Jan 3, 2023, at 11:55, PJ Fanning  wrote:

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  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  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  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,  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  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 
Sent: Tuesday, December 13, 2022 08:37
To: general@incubator.apache.org 
Subject: [EXTERNAL] RE: [DISCUSS] KIE Proposal




From: Calvin Kirs 
Sent: Monday, December 12, 2022 23:31
To: general@incubator.apache.org 
Subject: [EXTERNAL] Re: [DISCUSS] KIE Proposal

On Fri, Dec 9, 2022 at 11:45 PM Jason Porter  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

Re: [DISCUSS] KIE Proposal

[PJ Fanning]

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  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  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  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,  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  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 
> >> Sent: Tuesday, December 13, 2022 08:37
> >> To: general@incubator.apache.org 
> >> Subject: [EXTERNAL] RE: [DISCUSS] KIE Proposal
> >>
> >>
> >>
> >> 
> >> From: Calvin Kirs 
> >> Sent: Monday, December 12, 2022 23:31
> >> To: general@incubator.apache.org 
> >> Subject: [EXTERNAL] Re: [DISCUSS] KIE Proposal
> >>
> >> On Fri, Dec 9, 2022 at 11:45 PM Jason Porter  
> >> 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 engineer

Re: [DISCUSS] KIE Proposal

[PJ Fanning]

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  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  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,  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  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 
>> Sent: Tuesday, December 13, 2022 08:37
>> To: general@incubator.apache.org 
>> Subject: [EXTERNAL] RE: [DISCUSS] KIE Proposal
>>
>>
>>
>> 
>> From: Calvin Kirs 
>> Sent: Monday, December 12, 2022 23:31
>> To: general@incubator.apache.org 
>> Subject: [EXTERNAL] Re: [DISCUSS] KIE Proposal
>>
>> On Fri, Dec 9, 2022 at 11:45 PM Jason Porter  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 individu

Re: [DISCUSS] KIE Proposal

[Jason Porter]

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  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, 
mailto: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 
mailto: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 mailto:jpor...@ibm.com.INVALID>>
Sent: Tuesday, December 13, 2022 08:37
To: general@incubator.apache.org<mailto:general@incubator.apache.org> 
mailto:general@incubator.apache.org>>
Subject: [EXTERNAL] RE: [DISCUSS] KIE Proposal




From: Calvin Kirs mailto:k...@apache.org>>
Sent: Monday, December 12, 2022 23:31
To: general@incubator.apache.org<mailto:general@incubator.apache.org> 
mailto:general@incubator.apache.org>>
Subject: [EXTERNAL] Re: [DISCUSS] KIE Proposal

On Fri, Dec 9, 2022 at 11:45 PM Jason Porter 
mailto: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 Ap

Re: [DISCUSS] KIE Proposal

[Jason Porter]

Sure, how do I go about doing that?

Jason Porter
Software Engineer
He/Him/His

IBM

On Jan 3, 2023, at 09:42, PJ Fanning  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, 
mailto: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 
mailto: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 mailto:jpor...@ibm.com.INVALID>>
Sent: Tuesday, December 13, 2022 08:37
To: general@incubator.apache.org<mailto:general@incubator.apache.org> 
mailto:general@incubator.apache.org>>
Subject: [EXTERNAL] RE: [DISCUSS] KIE Proposal




From: Calvin Kirs mailto:k...@apache.org>>
Sent: Monday, December 12, 2022 23:31
To: general@incubator.apache.org<mailto:general@incubator.apache.org> 
mailto:general@incubator.apache.org>>
Subject: [EXTERNAL] Re: [DISCUSS] KIE Proposal

On Fri, Dec 9, 2022 at 11:45 PM Jason Porter 
mailto: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-proj

Re: [DISCUSS] KIE Proposal

[PJ Fanning]

Could we get the proposal doc up on the ASF wiki?

On Tue 3 Jan 2023, 17:25 Jason Porter,  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  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 
> Sent: Tuesday, December 13, 2022 08:37
> To: general@incubator.apache.org 
> Subject: [EXTERNAL] RE: [DISCUSS] KIE Proposal
>
>
>
> 
> From: Calvin Kirs 
> Sent: Monday, December 12, 2022 23:31
> To: general@incubator.apache.org 
> Subject: [EXTERNAL] Re: [DISCUSS] KIE Proposal
>
> On Fri, Dec 9, 2022 at 11:45 PM Jason Porter 
> 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 no

Re: [DISCUSS] KIE Proposal

[Jason Porter]

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  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 
Sent: Tuesday, December 13, 2022 08:37
To: general@incubator.apache.org 
Subject: [EXTERNAL] RE: [DISCUSS] KIE Proposal




From: Calvin Kirs 
Sent: Monday, December 12, 2022 23:31
To: general@incubator.apache.org 
Subject: [EXTERNAL] Re: [DISCUSS] KIE Proposal

On Fri, Dec 9, 2022 at 11:45 PM Jason Porter  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

RE: [DISCUSS] KIE Proposal

[Jason Porter]

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 
Sent: Tuesday, December 13, 2022 08:37
To: general@incubator.apache.org 
Subject: [EXTERNAL] RE: [DISCUSS] KIE Proposal




From: Calvin Kirs 
Sent: Monday, December 12, 2022 23:31
To: general@incubator.apache.org 
Subject: [EXTERNAL] Re: [DISCUSS] KIE Proposal

On Fri, Dec 9, 2022 at 11:45 PM Jason Porter  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 technol

RE: [DISCUSS] KIE Proposal

[Jason Porter]

From: Calvin Kirs 
Sent: Monday, December 12, 2022 23:31
To: general@incubator.apache.org 
Subject: [EXTERNAL] Re: [DISCUSS] KIE Proposal

On Fri, Dec 9, 2022 at 11:45 PM Jason Porter  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  wrote:
>
> On Tue, 6 Dec 2022 at 16:27, Jason Porter 

Re: [DISCUSS] KIE Proposal

[Calvin Kirs]

On Fri, Dec 9, 2022 at 11:45 PM Jason Porter  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  wrote:
>
> On Tue, 6 Dec 2022 at 16:27, Jason Porter 
> mailto:jpor...@ibm.com.invalid>> wrote:
>
>
> On Dec 6, 2022, at 01:43, Christofer Dutz 
> 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, 

Re: [DISCUSS] KIE Proposal

[Jason Porter]

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.


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  wrote:

On Tue, 6 Dec 2022 at 16:27, Jason Porter 
mailto:jpor...@ibm.com.invalid>> wrote:


On Dec 6, 2022, at 01:43, Christofer Dutz 
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 

Re: [DISCUSS] KIE Proposal

[Niall Pemberton]

On Tue, 6 Dec 2022 at 16:27, Jason Porter  wrote:

>
> > On Dec 6, 2022, at 01:43, Christofer Dutz 
> 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

Re: [DISCUSS] KIE Proposal

[Christofer Dutz]

Hi Jason,

now this looks a lot more like something we can help support :-)

And projects don’t necessarily have to be mono repos. Stuff like examples, 
project websites … that’s quite common to be in separate repositories.

I guess the amount of additional work would not be that much … yeah … the 
reports have to be written, but most use templates for that and just fill in 
special things being noted.
Writing the reports for a project usually doesn’t take much time.

Regarding setting up of infra … I guess you would go a GitHub approach and not 
sign up for Jira and Confluence now that public user registrations are disabled.
I would dare to say the amount of work to set this up for one project and 
multiple project would be identical.

Chris


From: Jason Porter 
Date: Tuesday, 6. December 2022 at 17:27
To: general@incubator.apache.org 
Subject: Re: [DISCUSS] KIE Proposal

> On Dec 6, 2022, at 01:43, Christofer Dutz  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

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

IBMB�CB��[��X��ܚX�KK[XZ[
��[�\�[ ][��X��ܚX�P[��X�]܋�\X�K�ܙ�B��܈Y][ۘ[��[X[��K[XZ[
��[�\�[ Z[[��X�]܋�\X�K�ܙ�B

Re: [DISCUSS] KIE Proposal

[Jason Porter]

> On Dec 6, 2022, at 01:43, Christofer Dutz  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

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

Re: [DISCUSS] KIE Proposal

[Christofer Dutz]

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

From: Jason Porter 
Date: Monday, 5. December 2022 at 19:08
To: general@incubator.apache.org 
Subject: Re: [DISCUSS] KIE Proposal
On Dec 5, 2022, at 01:23, Christofer Dutz  wrote:

Hi all,

as you already mentioned PLC4X, I think in general supporting something to do 
logic-decisions based on industrial data-streams would be a nice addition.  I 
do also agree that adding 80 projects might be quite a big gulp for us to 
ingest.

How many people are we talking about being on the IPMC/committers? Mentoring a 
project with hundreds of people would probably require a fleet of mentors.

Hey Chris,

The size of the PPMC is a good question. Per the Incubator site 
[https://incubator.apache.org/guides/ppmc.html] it is typically made up of the 
initial committers and mentors. We have 51 people currently tagged for being 
initial committers and three people as mentors. Most have not done anything 
with Apache. That feels like a lot of people for an initial PPMC. We were 
initially thinking of something small around 7 people initially. Not sure how 
that plays in with the list of initial committers though, unless we par that 
down as well and bring people in during the incubation.

WRT the number of projects, we’re not looking at donating all of those. We’re 
still in discussion on the final list, but that list is considerably smaller. 
Discussions are leaning toward 12 or so.

Jason Porter
Software Engineer
He/Him/His

IBM

Chris

From: Willem Jiang mailto:willem.ji...@gmail.com>>
Date: Monday, 5. December 2022 at 04:15
To: general@incubator.apache.org<mailto:general@incubator.apache.org> 
mailto:general@incubator.apache.org>>
Subject: Re: [DISCUSS] KIE Proposal
We need to go through the IP clearance and help the project to do the
release that follows the Apache police.
It could be a nightmare for the incubator if we donate an "Umbrella Project."
Can we consider donating sub-projects such as kogito one by one?


Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Fri, Dec 2, 2022 at 9:21 AM Niall Pemberton
 wrote:

Wow, 137 GitHub repositories!

OK, so 38 are archived and 19 are forks, but that still leaves 80! Do you
have a rough idea of how many of those would be part of the incubation?

Historically, Apache has been against "Umbrella Projects" - encouraging
them to break up and become individual Top Level Projects (TLP) in their
own right - the biggest example of that was Jakarta which used to be
anything java related - but there have been others where sub-projects which
have a life of their own have moved out to become TLPs.

To me this looks like it should be 4 or 5 projects - its not clear whether
kie is a product in its own right (with releasable artifcats) or just the
umbrella that the others are grouped under?
 * drools
 * jbpm
 * kogito
 * optaplanner
 * kie ???

Niall


On Thu, 1 Dec 2022 at 21:36, Jason Porter  wrote:

Abstract

KIE (Knowledge is Everything) is a community of solutions and supporting
tooling for knowledge engineering and process automation, focusing on
events, rules, and workflows.

Proposal<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#proposal


KIE is a community dedicated to supporting knowledge engineering and
process automation, using standards from groups like OMG (BPMN, CMMN, DMN),
CNCF (Serverless Workflow, Cloud Events), and DMG (PMML, PFA). KIE is
comprised of leading open-source projects (like Drools and jBPM), which
provide modeling and code authoring tools in this space. The work has a
strong emphasis on being a first-class citizen for Kubernetes but will
continue to support embedded and other environments such as edge computing.
Drools and jBPM are well-known projects in their areas of rules and
workflow and they will be joined by another project, building on a shared
core with jBPM, for CNCF’s Serverless Workflow - this project is going
through a naming process at the time of this application. Kogito is the
foundation project for workflow which jBPM and CNCF’s Serverless Workflow
build on. Services and frameworks are pro

Re: [DISCUSS] KIE Proposal

[Jason Porter]

On Dec 5, 2022, at 01:23, Christofer Dutz  wrote:

Hi all,

as you already mentioned PLC4X, I think in general supporting something to do 
logic-decisions based on industrial data-streams would be a nice addition.  I 
do also agree that adding 80 projects might be quite a big gulp for us to 
ingest.

How many people are we talking about being on the IPMC/committers? Mentoring a 
project with hundreds of people would probably require a fleet of mentors.

Hey Chris,

The size of the PPMC is a good question. Per the Incubator site 
[https://incubator.apache.org/guides/ppmc.html] it is typically made up of the 
initial committers and mentors. We have 51 people currently tagged for being 
initial committers and three people as mentors. Most have not done anything 
with Apache. That feels like a lot of people for an initial PPMC. We were 
initially thinking of something small around 7 people initially. Not sure how 
that plays in with the list of initial committers though, unless we par that 
down as well and bring people in during the incubation.

WRT the number of projects, we’re not looking at donating all of those. We’re 
still in discussion on the final list, but that list is considerably smaller. 
Discussions are leaning toward 12 or so.

Jason Porter
Software Engineer
He/Him/His

IBM

Chris

From: Willem Jiang mailto:willem.ji...@gmail.com>>
Date: Monday, 5. December 2022 at 04:15
To: general@incubator.apache.org<mailto:general@incubator.apache.org> 
mailto:general@incubator.apache.org>>
Subject: Re: [DISCUSS] KIE Proposal
We need to go through the IP clearance and help the project to do the
release that follows the Apache police.
It could be a nightmare for the incubator if we donate an "Umbrella Project."
Can we consider donating sub-projects such as kogito one by one?


Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Fri, Dec 2, 2022 at 9:21 AM Niall Pemberton
 wrote:

Wow, 137 GitHub repositories!

OK, so 38 are archived and 19 are forks, but that still leaves 80! Do you
have a rough idea of how many of those would be part of the incubation?

Historically, Apache has been against "Umbrella Projects" - encouraging
them to break up and become individual Top Level Projects (TLP) in their
own right - the biggest example of that was Jakarta which used to be
anything java related - but there have been others where sub-projects which
have a life of their own have moved out to become TLPs.

To me this looks like it should be 4 or 5 projects - its not clear whether
kie is a product in its own right (with releasable artifcats) or just the
umbrella that the others are grouped under?
 * drools
 * jbpm
 * kogito
 * optaplanner
 * kie ???

Niall


On Thu, 1 Dec 2022 at 21:36, Jason Porter  wrote:

Abstract

KIE (Knowledge is Everything) is a community of solutions and supporting
tooling for knowledge engineering and process automation, focusing on
events, rules, and workflows.

Proposal<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#proposal


KIE is a community dedicated to supporting knowledge engineering and
process automation, using standards from groups like OMG (BPMN, CMMN, DMN),
CNCF (Serverless Workflow, Cloud Events), and DMG (PMML, PFA). KIE is
comprised of leading open-source projects (like Drools and jBPM), which
provide modeling and code authoring tools in this space. The work has a
strong emphasis on being a first-class citizen for Kubernetes but will
continue to support embedded and other environments such as edge computing.
Drools and jBPM are well-known projects in their areas of rules and
workflow and they will be joined by another project, building on a shared
core with jBPM, for CNCF’s Serverless Workflow - this project is going
through a naming process at the time of this application. Kogito is the
foundation project for workflow which jBPM and CNCF’s Serverless Workflow
build on. Services and frameworks are provided to enable those projects in
a cloud-native environment and tooling is made available through KIE Tools.

Background<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#background


Experience has shown that a holistic approach is a practical requirement
for any  knowledge engineering and process automation. This requires a
breadth of capabilities able to model and execute an application’s data
models, rules, workflows, and events. These projects aim to provide a
holistic approach with a strong emphasis on congruency across them.

Rationale<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#rationale


Knowledge engineering and process automation have been and continue to
play a large part in today’s software lifecycle. To date, there have been
few truly open-source implementations of any of the specifications (DMN,
PMML, BPMN, CNCF Workflow, etc). The projects within Red Hat implement
these standards and fill that gap of having an open-source impl

Re: [DISCUSS] KIE Proposal

[Christofer Dutz]

Hi all,

as you already mentioned PLC4X, I think in general supporting something to do 
logic-decisions based on industrial data-streams would be a nice addition.  I 
do also agree that adding 80 projects might be quite a big gulp for us to 
ingest.

How many people are we talking about being on the IPMC/committers? Mentoring a 
project with hundreds of people would probably require a fleet of mentors.

Chris

From: Willem Jiang 
Date: Monday, 5. December 2022 at 04:15
To: general@incubator.apache.org 
Subject: Re: [DISCUSS] KIE Proposal
We need to go through the IP clearance and help the project to do the
release that follows the Apache police.
It could be a nightmare for the incubator if we donate an "Umbrella Project."
Can we consider donating sub-projects such as kogito one by one?


Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Fri, Dec 2, 2022 at 9:21 AM Niall Pemberton
 wrote:
>
> Wow, 137 GitHub repositories!
>
> OK, so 38 are archived and 19 are forks, but that still leaves 80! Do you
> have a rough idea of how many of those would be part of the incubation?
>
> Historically, Apache has been against "Umbrella Projects" - encouraging
> them to break up and become individual Top Level Projects (TLP) in their
> own right - the biggest example of that was Jakarta which used to be
> anything java related - but there have been others where sub-projects which
> have a life of their own have moved out to become TLPs.
>
> To me this looks like it should be 4 or 5 projects - its not clear whether
> kie is a product in its own right (with releasable artifcats) or just the
> umbrella that the others are grouped under?
>   * drools
>   * jbpm
>   * kogito
>   * optaplanner
>   * kie ???
>
> Niall
>
>
> On Thu, 1 Dec 2022 at 21:36, Jason Porter  wrote:
>
> > Abstract
> >
> > KIE (Knowledge is Everything) is a community of solutions and supporting
> > tooling for knowledge engineering and process automation, focusing on
> > events, rules, and workflows.
> >
> > Proposal<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#proposal
> > >
> >
> > KIE is a community dedicated to supporting knowledge engineering and
> > process automation, using standards from groups like OMG (BPMN, CMMN, DMN),
> > CNCF (Serverless Workflow, Cloud Events), and DMG (PMML, PFA). KIE is
> > comprised of leading open-source projects (like Drools and jBPM), which
> > provide modeling and code authoring tools in this space. The work has a
> > strong emphasis on being a first-class citizen for Kubernetes but will
> > continue to support embedded and other environments such as edge computing.
> > Drools and jBPM are well-known projects in their areas of rules and
> > workflow and they will be joined by another project, building on a shared
> > core with jBPM, for CNCF’s Serverless Workflow - this project is going
> > through a naming process at the time of this application. Kogito is the
> > foundation project for workflow which jBPM and CNCF’s Serverless Workflow
> > build on. Services and frameworks are provided to enable those projects in
> > a cloud-native environment and tooling is made available through KIE Tools.
> >
> > Background<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#background
> > >
> >
> > Experience has shown that a holistic approach is a practical requirement
> > for any  knowledge engineering and process automation. This requires a
> > breadth of capabilities able to model and execute an application’s data
> > models, rules, workflows, and events. These projects aim to provide a
> > holistic approach with a strong emphasis on congruency across them.
> >
> > Rationale<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#rationale
> > >
> >
> > Knowledge engineering and process automation have been and continue to
> > play a large part in today’s software lifecycle. To date, there have been
> > few truly open-source implementations of any of the specifications (DMN,
> > PMML, BPMN, CNCF Workflow, etc). The projects within Red Hat implement
> > these standards and fill that gap of having an open-source implementation.
> >
> >
> > The projects within KIE also mesh well with other Apache projects such as
> > Apache Camel and Apache Airavata. Integrations could be done at the IoT
> > level with Apache PLC4X and others.
> >
> >
> > Developers need a solution that follows, implements, and collaborates with
> > these industry specifications. The Apache Software Foundation would allow
> > these 

Re: [DISCUSS] KIE Proposal

[Willem Jiang]

We need to go through the IP clearance and help the project to do the
release that follows the Apache police.
It could be a nightmare for the incubator if we donate an "Umbrella Project."
Can we consider donating sub-projects such as kogito one by one?


Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Fri, Dec 2, 2022 at 9:21 AM Niall Pemberton
 wrote:
>
> Wow, 137 GitHub repositories!
>
> OK, so 38 are archived and 19 are forks, but that still leaves 80! Do you
> have a rough idea of how many of those would be part of the incubation?
>
> Historically, Apache has been against "Umbrella Projects" - encouraging
> them to break up and become individual Top Level Projects (TLP) in their
> own right - the biggest example of that was Jakarta which used to be
> anything java related - but there have been others where sub-projects which
> have a life of their own have moved out to become TLPs.
>
> To me this looks like it should be 4 or 5 projects - its not clear whether
> kie is a product in its own right (with releasable artifcats) or just the
> umbrella that the others are grouped under?
>   * drools
>   * jbpm
>   * kogito
>   * optaplanner
>   * kie ???
>
> Niall
>
>
> On Thu, 1 Dec 2022 at 21:36, Jason Porter  wrote:
>
> > Abstract
> >
> > KIE (Knowledge is Everything) is a community of solutions and supporting
> > tooling for knowledge engineering and process automation, focusing on
> > events, rules, and workflows.
> >
> > Proposal<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#proposal
> > >
> >
> > KIE is a community dedicated to supporting knowledge engineering and
> > process automation, using standards from groups like OMG (BPMN, CMMN, DMN),
> > CNCF (Serverless Workflow, Cloud Events), and DMG (PMML, PFA). KIE is
> > comprised of leading open-source projects (like Drools and jBPM), which
> > provide modeling and code authoring tools in this space. The work has a
> > strong emphasis on being a first-class citizen for Kubernetes but will
> > continue to support embedded and other environments such as edge computing.
> > Drools and jBPM are well-known projects in their areas of rules and
> > workflow and they will be joined by another project, building on a shared
> > core with jBPM, for CNCF’s Serverless Workflow - this project is going
> > through a naming process at the time of this application. Kogito is the
> > foundation project for workflow which jBPM and CNCF’s Serverless Workflow
> > build on. Services and frameworks are provided to enable those projects in
> > a cloud-native environment and tooling is made available through KIE Tools.
> >
> > Background<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#background
> > >
> >
> > Experience has shown that a holistic approach is a practical requirement
> > for any  knowledge engineering and process automation. This requires a
> > breadth of capabilities able to model and execute an application’s data
> > models, rules, workflows, and events. These projects aim to provide a
> > holistic approach with a strong emphasis on congruency across them.
> >
> > Rationale<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#rationale
> > >
> >
> > Knowledge engineering and process automation have been and continue to
> > play a large part in today’s software lifecycle. To date, there have been
> > few truly open-source implementations of any of the specifications (DMN,
> > PMML, BPMN, CNCF Workflow, etc). The projects within Red Hat implement
> > these standards and fill that gap of having an open-source implementation.
> >
> >
> > The projects within KIE also mesh well with other Apache projects such as
> > Apache Camel and Apache Airavata. Integrations could be done at the IoT
> > level with Apache PLC4X and others.
> >
> >
> > Developers need a solution that follows, implements, and collaborates with
> > these industry specifications. The Apache Software Foundation would allow
> > these projects to continue to grow in a vendor-neutral environment and
> > promote further collaboration with existing integrations and future
> > partners.
> >
> > Initial Goals<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#initial-goals
> > >
> >
> > First and foremost, we aim to enlarge the community. KIE has primarily
> > been an open-source community of Red Hat Developers and users outside of
> > Red Hat. Adding IBM to the list of developers helps, but we would like to
> > see more. We have ideas for the various sub-projects, such as
> > straight-through processing support in Kogito, better spec compliance for
> > the tooling, and more research into language bindings for non-Java
> > languages. We believe we can address some of these while an Apache
> > Incubator project.
> >
> > Current Status<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#current-status
> > >
> >
> > Code for the various projects with the KIE 

Re: [DISCUSS] KIE Proposal

[Niall Pemberton]

Wow, 137 GitHub repositories!

OK, so 38 are archived and 19 are forks, but that still leaves 80! Do you
have a rough idea of how many of those would be part of the incubation?

Historically, Apache has been against "Umbrella Projects" - encouraging
them to break up and become individual Top Level Projects (TLP) in their
own right - the biggest example of that was Jakarta which used to be
anything java related - but there have been others where sub-projects which
have a life of their own have moved out to become TLPs.

To me this looks like it should be 4 or 5 projects - its not clear whether
kie is a product in its own right (with releasable artifcats) or just the
umbrella that the others are grouped under?
  * drools
  * jbpm
  * kogito
  * optaplanner
  * kie ???

Niall


On Thu, 1 Dec 2022 at 21:36, Jason Porter  wrote:

> Abstract
>
> KIE (Knowledge is Everything) is a community of solutions and supporting
> tooling for knowledge engineering and process automation, focusing on
> events, rules, and workflows.
>
> Proposal<
> https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#proposal
> >
>
> KIE is a community dedicated to supporting knowledge engineering and
> process automation, using standards from groups like OMG (BPMN, CMMN, DMN),
> CNCF (Serverless Workflow, Cloud Events), and DMG (PMML, PFA). KIE is
> comprised of leading open-source projects (like Drools and jBPM), which
> provide modeling and code authoring tools in this space. The work has a
> strong emphasis on being a first-class citizen for Kubernetes but will
> continue to support embedded and other environments such as edge computing.
> Drools and jBPM are well-known projects in their areas of rules and
> workflow and they will be joined by another project, building on a shared
> core with jBPM, for CNCF’s Serverless Workflow - this project is going
> through a naming process at the time of this application. Kogito is the
> foundation project for workflow which jBPM and CNCF’s Serverless Workflow
> build on. Services and frameworks are provided to enable those projects in
> a cloud-native environment and tooling is made available through KIE Tools.
>
> Background<
> https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#background
> >
>
> Experience has shown that a holistic approach is a practical requirement
> for any  knowledge engineering and process automation. This requires a
> breadth of capabilities able to model and execute an application’s data
> models, rules, workflows, and events. These projects aim to provide a
> holistic approach with a strong emphasis on congruency across them.
>
> Rationale<
> https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#rationale
> >
>
> Knowledge engineering and process automation have been and continue to
> play a large part in today’s software lifecycle. To date, there have been
> few truly open-source implementations of any of the specifications (DMN,
> PMML, BPMN, CNCF Workflow, etc). The projects within Red Hat implement
> these standards and fill that gap of having an open-source implementation.
>
>
> The projects within KIE also mesh well with other Apache projects such as
> Apache Camel and Apache Airavata. Integrations could be done at the IoT
> level with Apache PLC4X and others.
>
>
> Developers need a solution that follows, implements, and collaborates with
> these industry specifications. The Apache Software Foundation would allow
> these projects to continue to grow in a vendor-neutral environment and
> promote further collaboration with existing integrations and future
> partners.
>
> Initial Goals<
> https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#initial-goals
> >
>
> First and foremost, we aim to enlarge the community. KIE has primarily
> been an open-source community of Red Hat Developers and users outside of
> Red Hat. Adding IBM to the list of developers helps, but we would like to
> see more. We have ideas for the various sub-projects, such as
> straight-through processing support in Kogito, better spec compliance for
> the tooling, and more research into language bindings for non-Java
> languages. We believe we can address some of these while an Apache
> Incubator project.
>
> Current Status<
> https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#current-status
> >
>
> Code for the various projects with the KIE community is all hosted on
> GitHub. This includes Kogito, Drools, jBPM, and KIE Tools. All of the code
> is Apache 2 licensed. Red Hat has been the project’s custodian since its
> inception and has maintained leadership in that area. Moving forward into
> the Apache Incubator, we would need to establish the habit of holding votes
> and meetings and the project updates per the Apache Way.
>
>
> We also currently maintain a YouTube channel dedicated to the community
> and projects, a Twitter presence, and a LinkedIn page for the KIE Community.
>
> 

Re: [DISCUSS] KIE Proposal

[PJ Fanning]

Is it possible the name is too generic and could cause confusion with
this existing ASF project?

* https://kie.readthedocs.io/en/latest/
* https://github.com/apache/servicecomb-kie

On Thu, 1 Dec 2022 at 22:36, Jason Porter  wrote:
>
> Abstract
>
> KIE (Knowledge is Everything) is a community of solutions and supporting 
> tooling for knowledge engineering and process automation, focusing on events, 
> rules, and workflows.
>
> Proposal
>
> KIE is a community dedicated to supporting knowledge engineering and process 
> automation, using standards from groups like OMG (BPMN, CMMN, DMN), CNCF 
> (Serverless Workflow, Cloud Events), and DMG (PMML, PFA). KIE is comprised of 
> leading open-source projects (like Drools and jBPM), which provide modeling 
> and code authoring tools in this space. The work has a strong emphasis on 
> being a first-class citizen for Kubernetes but will continue to support 
> embedded and other environments such as edge computing. Drools and jBPM are 
> well-known projects in their areas of rules and workflow and they will be 
> joined by another project, building on a shared core with jBPM, for CNCF’s 
> Serverless Workflow - this project is going through a naming process at the 
> time of this application. Kogito is the foundation project for workflow which 
> jBPM and CNCF’s Serverless Workflow build on. Services and frameworks are 
> provided to enable those projects in a cloud-native environment and tooling 
> is made available through KIE Tools.
>
> Background
>
> Experience has shown that a holistic approach is a practical requirement for 
> any  knowledge engineering and process automation. This requires a breadth of 
> capabilities able to model and execute an application’s data models, rules, 
> workflows, and events. These projects aim to provide a holistic approach with 
> a strong emphasis on congruency across them.
>
> Rationale
>
> Knowledge engineering and process automation have been and continue to play a 
> large part in today’s software lifecycle. To date, there have been few truly 
> open-source implementations of any of the specifications (DMN, PMML, BPMN, 
> CNCF Workflow, etc). The projects within Red Hat implement these standards 
> and fill that gap of having an open-source implementation.
>
>
> The projects within KIE also mesh well with other Apache projects such as 
> Apache Camel and Apache Airavata. Integrations could be done at the IoT level 
> with Apache PLC4X and others.
>
>
> Developers need a solution that follows, implements, and collaborates with 
> these industry specifications. The Apache Software Foundation would allow 
> these projects to continue to grow in a vendor-neutral environment and 
> promote further collaboration with existing integrations and future partners.
>
> Initial 
> Goals
>
> First and foremost, we aim to enlarge the community. KIE has primarily been 
> an open-source community of Red Hat Developers and users outside of Red Hat. 
> Adding IBM to the list of developers helps, but we would like to see more. We 
> have ideas for the various sub-projects, such as straight-through processing 
> support in Kogito, better spec compliance for the tooling, and more research 
> into language bindings for non-Java languages. We believe we can address some 
> of these while an Apache Incubator project.
>
> Current 
> Status
>
> Code for the various projects with the KIE community is all hosted on GitHub. 
> This includes Kogito, Drools, jBPM, and KIE Tools. All of the code is Apache 
> 2 licensed. Red Hat has been the project’s custodian since its inception and 
> has maintained leadership in that area. Moving forward into the Apache 
> Incubator, we would need to establish the habit of holding votes and meetings 
> and the project updates per the Apache Way.
>
>
> We also currently maintain a YouTube channel dedicated to the community and 
> projects, a Twitter presence, and a LinkedIn page for the KIE Community.
>
> Meritocracy:
>
> Red Hat runs all of its open-source projects as meritocracies, the KIE 
> Community is no different. This aspect would not change any. Kogito currently 
> does not make a distinction between “committer” and “PMC member” the same way 
> Apache does. That aspect would need implementation.
>
> Community:
>
> The KIE Community has an active base of contributors within and outside Red 
> Hat. Community 

[DISCUSS] KIE Proposal

[Jason Porter]

Abstract

KIE (Knowledge is Everything) is a community of solutions and supporting 
tooling for knowledge engineering and process automation, focusing on events, 
rules, and workflows.

Proposal

KIE is a community dedicated to supporting knowledge engineering and process 
automation, using standards from groups like OMG (BPMN, CMMN, DMN), CNCF 
(Serverless Workflow, Cloud Events), and DMG (PMML, PFA). KIE is comprised of 
leading open-source projects (like Drools and jBPM), which provide modeling and 
code authoring tools in this space. The work has a strong emphasis on being a 
first-class citizen for Kubernetes but will continue to support embedded and 
other environments such as edge computing. Drools and jBPM are well-known 
projects in their areas of rules and workflow and they will be joined by 
another project, building on a shared core with jBPM, for CNCF’s Serverless 
Workflow - this project is going through a naming process at the time of this 
application. Kogito is the foundation project for workflow which jBPM and 
CNCF’s Serverless Workflow build on. Services and frameworks are provided to 
enable those projects in a cloud-native environment and tooling is made 
available through KIE Tools.

Background

Experience has shown that a holistic approach is a practical requirement for 
any  knowledge engineering and process automation. This requires a breadth of 
capabilities able to model and execute an application’s data models, rules, 
workflows, and events. These projects aim to provide a holistic approach with a 
strong emphasis on congruency across them.

Rationale

Knowledge engineering and process automation have been and continue to play a 
large part in today’s software lifecycle. To date, there have been few truly 
open-source implementations of any of the specifications (DMN, PMML, BPMN, CNCF 
Workflow, etc). The projects within Red Hat implement these standards and fill 
that gap of having an open-source implementation.


The projects within KIE also mesh well with other Apache projects such as 
Apache Camel and Apache Airavata. Integrations could be done at the IoT level 
with Apache PLC4X and others.


Developers need a solution that follows, implements, and collaborates with 
these industry specifications. The Apache Software Foundation would allow these 
projects to continue to grow in a vendor-neutral environment and promote 
further collaboration with existing integrations and future partners.

Initial 
Goals

First and foremost, we aim to enlarge the community. KIE has primarily been an 
open-source community of Red Hat Developers and users outside of Red Hat. 
Adding IBM to the list of developers helps, but we would like to see more. We 
have ideas for the various sub-projects, such as straight-through processing 
support in Kogito, better spec compliance for the tooling, and more research 
into language bindings for non-Java languages. We believe we can address some 
of these while an Apache Incubator project.

Current 
Status

Code for the various projects with the KIE community is all hosted on GitHub. 
This includes Kogito, Drools, jBPM, and KIE Tools. All of the code is Apache 2 
licensed. Red Hat has been the project’s custodian since its inception and has 
maintained leadership in that area. Moving forward into the Apache Incubator, 
we would need to establish the habit of holding votes and meetings and the 
project updates per the Apache Way.


We also currently maintain a YouTube channel dedicated to the community and 
projects, a Twitter presence, and a LinkedIn page for the KIE Community.

Meritocracy:

Red Hat runs all of its open-source projects as meritocracies, the KIE 
Community is no different. This aspect would not change any. Kogito currently 
does not make a distinction between “committer” and “PMC member” the same way 
Apache does. That aspect would need implementation.

Community:

The KIE Community has an active base of contributors within and outside Red 
Hat. Community members currently use Zulip chat or mailing lists hosted by 
Google Groups as communication tools. It has been that way for many years. 
Before that, we were using IRC at Freenode for many years. There are also 
mailing lists hosted on Google Groups that are leveraged for those who prefer 
mailing list communication. Zulip was started as a standard communication 
medium for KIE