You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Jason Porter <jp...@ibm.com.INVALID> on 2023/01/03 16:24:41 UTC
Re: [DISCUSS] KIE Proposal
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 <jp...@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 <jp...@ibm.com.INVALID>
Sent: Tuesday, December 13, 2022 08:37
To: general@incubator.apache.org <ge...@incubator.apache.org>
Subject: [EXTERNAL] RE: [DISCUSS] KIE Proposal
________________________________
From: Calvin Kirs <ki...@apache.org>
Sent: Monday, December 12, 2022 23:31
To: general@incubator.apache.org <ge...@incubator.apache.org>
Subject: [EXTERNAL] Re: [DISCUSS] KIE Proposal
On Fri, Dec 9, 2022 at 11:45 PM Jason Porter <jp...@ibm.com.invalid> wrote:
We don’t feel like KIE and Servicecomb-kie clash. One is an acronym (KIE- Knowledge Is Everything), and the other is a suffix. Both projects are very different as well. Servicecomb-kie is a configuration center for microservices written in Go, whereas KIE is a knowledge engineering and process automation solution written in Java. For example, how was this handled in the context of Apache DeltaCloud and Apache DeltaSpike; or Apache DataFu and Apache DataLab? Is there precedence within the ASF for similarly named projects? The two communities have also co-existed for roughly the same time, using the same names without clashes.
That's not a problem If two projects are in different fields.
we'd just need to be careful with the project description.
Perfect! Thank you, Calvin.
As was stated previously, the number of projects is much smaller than the number of GitHub repos. This is because KIE did not use a singular repository model within the GitHub organization. The projects we’re currently considering in this proposal are Kogito, jBPM, Drools, KIE-Tools, and another project for the CNCF Serverless Workflow implementation that is going through a naming process now. KIE-Tools is a little odd, though, as it doesn’t stand on its own well. The existing code base contains a lot of modules and code, which could be considered legacy, which we do not plan to move over. There will be a cleaning and pruning process to ensure a more relevant, sustainable, and forward-looking set of modules as code is moved over. This should further reduce the amount of code that is moved over. We understand we may need to collapse the repositories moving over to the ASF. Let us know if you want to see how everything rolls into a more flat structure.
Regarding umbrella versus standalone projects, we believe that the unified and cohesive experience provides more value than just the sum of its parts. This is also not just about where we are now, but where we hope to evolve as a knowledge engineering platform. On the surface, those projects can be seen as independent in their business rules, decisions, and workflow domains. However, real-world use cases are more complex. Usually, they require a lot of interdependencies, for example, business rules orchestration is accomplished by using a workflow file definition (i.e., BPMN), and complex workflow decisions are better modeled in DMN models. The aim is to try and drive consistency and ease of use across those technologies, in an integrated and holistic manner.
If those projects end up as individual TLPs, it'll be up to users to write a lot of boiler-plate code - or create additional new projects to handle and abstract the unified experience.
Of course, as a consequence of the unified vision, the current codebase is taking advantage of this unification, which means there's a lot of shared code among the projects. Moving away from this will also result in more top-level supporting projects to provide additional code, needed as foundational code or integration code, which may actually create more complexity and end-user confusion.
Although it might not be the most popular example within Apache, KIE aims to provide a similar umbrella cohesiveness that Apache OpenOffice has for their sub-projects like Write and Calc. We really want the community to think of knowledge engineering as a whole domain of technologies for problem-solving, and not on individual silo technologies.
Lastly, fracturing the community we have already created around the KIE brand and concept is certainly not ideal and will weaken the overall project brands and success. We believe we'll be able to leverage further what we currently have in the community and build upon it to create a more cohesive knowledge-processing solution if everything stays together and people remain invested in the success of the knowledge engineering platform as a whole, rather than their individual technologies.
We would like to initially keep the PPMC small, ideally 5-7 people. We have around 50 people identified as initial committers, but having a PMC that large during incubation is not ideal for the issues that have been mentioned.
Jason Porter
Software Engineer
He/Him/His
IBM
On Dec 9, 2022, at 08:17, Niall Pemberton <ni...@gmail.com> wrote:
On Tue, 6 Dec 2022 at 16:27, Jason Porter <jp...@ibm.com.invalid>> wrote:
On Dec 6, 2022, at 01:43, Christofer Dutz <ch...@c-ware.de>
wrote:
Hi Jason,
Well, those numbers are a bit better than the initial ones.
Thing is: Mentors will not only have to help onboard people to Apache
and teach them how to do things, if they are doing their job correctly,
they should also really audit the releases being done and help get the
codebase into shape first.
Even with 12 sub-projects, work-wise that would put a load on the
mentors, as if they signed up for mentoring 12 projects.
So how about bringing in projects separately (where it makes sense)?
There each project could have their initial PPMC and committer lists and it
would spread out the load a bit. However I would expect staffing 12
projects with enough work-willing mentors will still be challenging and I
would assume not all of them to find enough of them, but it could be one
first step.
Or is there an advantage of considering all projects as one unity?
Chris
[snip]
That is part of a broader question. Some of those repos are things like
examples for kogito, the website, etc. Things that are part of the projects
themselves, but don’t have a life outside of the project to which they
belong. I understand we’ll probably have to collapse the structures within
Apache and have a single repo per project. What we’re really looking at as
far as projects being donated:
Kogito
Drools
jBPM
I really think these should be separate projects. I realize theres a
dependency/hierarchy between them (jBPM using Drools as its rules engine
and Kogito using jBPM for its business process/workflow) - but people use
Drools without jBPM and (I assume) jBPM without Kogito. Even if the current
set of contributors all work on all three projects, the aspiration here at
Apache has to be to grow the community of contributors from the user
community which will not be completely the same for the three projects.
I've used Drools in the past, but not jBPM or Kogito.
Niall
Then there are the supporting repos for things like examples, docs,
website, tooling, etc. Many of the people working on these projects work on
all of them, so it would probably be the same group of people with very
little deviation in the list of committers. Could they be different PPMCs,
but they’d basically be the same group, just more work with the reports,
setup, infra, etc.
Jason Porter
Software Engineer
He/Him/His
IBM
--
Best wishes！
CalvinKirs
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] KIE Proposal
Posted by Jason Porter <jp...@ibm.com.INVALID>.
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 <fa...@apache.org> wrote:
This Message Is From an External Sender
This message came from outside your organization.
Could we get the proposal doc up on the ASF wiki?
On Tue 3 Jan 2023, 17:25 Jason Porter, <jp...@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 <jp...@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 <jp...@ibm.com.INVALID>>
Sent: Tuesday, December 13, 2022 08:37
To: general@incubator.apache.org<ma...@incubator.apache.org> <ge...@incubator.apache.org>>
Subject: [EXTERNAL] RE: [DISCUSS] KIE Proposal
________________________________
From: Calvin Kirs <ki...@apache.org>>
Sent: Monday, December 12, 2022 23:31
To: general@incubator.apache.org<ma...@incubator.apache.org> <ge...@incubator.apache.org>>
Subject: [EXTERNAL] Re: [DISCUSS] KIE Proposal
On Fri, Dec 9, 2022 at 11:45 PM Jason Porter <jp...@ibm.com.invalid>> wrote:
We don’t feel like KIE and Servicecomb-kie clash. One is an acronym (KIE- Knowledge Is Everything), and the other is a suffix. Both projects are very different as well. Servicecomb-kie is a configuration center for microservices written in Go, whereas KIE is a knowledge engineering and process automation solution written in Java. For example, how was this handled in the context of Apache DeltaCloud and Apache DeltaSpike; or Apache DataFu and Apache DataLab? Is there precedence within the ASF for similarly named projects? The two communities have also co-existed for roughly the same time, using the same names without clashes.
That's not a problem If two projects are in different fields.
we'd just need to be careful with the project description.
Perfect! Thank you, Calvin.
As was stated previously, the number of projects is much smaller than the number of GitHub repos. This is because KIE did not use a singular repository model within the GitHub organization. The projects we’re currently considering in this proposal are Kogito, jBPM, Drools, KIE-Tools, and another project for the CNCF Serverless Workflow implementation that is going through a naming process now. KIE-Tools is a little odd, though, as it doesn’t stand on its own well. The existing code base contains a lot of modules and code, which could be considered legacy, which we do not plan to move over. There will be a cleaning and pruning process to ensure a more relevant, sustainable, and forward-looking set of modules as code is moved over. This should further reduce the amount of code that is moved over. We understand we may need to collapse the repositories moving over to the ASF. Let us know if you want to see how everything rolls into a more flat structure.
Regarding umbrella versus standalone projects, we believe that the unified and cohesive experience provides more value than just the sum of its parts. This is also not just about where we are now, but where we hope to evolve as a knowledge engineering platform. On the surface, those projects can be seen as independent in their business rules, decisions, and workflow domains. However, real-world use cases are more complex. Usually, they require a lot of interdependencies, for example, business rules orchestration is accomplished by using a workflow file definition (i.e., BPMN), and complex workflow decisions are better modeled in DMN models. The aim is to try and drive consistency and ease of use across those technologies, in an integrated and holistic manner.
If those projects end up as individual TLPs, it'll be up to users to write a lot of boiler-plate code - or create additional new projects to handle and abstract the unified experience.
Of course, as a consequence of the unified vision, the current codebase is taking advantage of this unification, which means there's a lot of shared code among the projects. Moving away from this will also result in more top-level supporting projects to provide additional code, needed as foundational code or integration code, which may actually create more complexity and end-user confusion.
Although it might not be the most popular example within Apache, KIE aims to provide a similar umbrella cohesiveness that Apache OpenOffice has for their sub-projects like Write and Calc. We really want the community to think of knowledge engineering as a whole domain of technologies for problem-solving, and not on individual silo technologies.
Lastly, fracturing the community we have already created around the KIE brand and concept is certainly not ideal and will weaken the overall project brands and success. We believe we'll be able to leverage further what we currently have in the community and build upon it to create a more cohesive knowledge-processing solution if everything stays together and people remain invested in the success of the knowledge engineering platform as a whole, rather than their individual technologies.
We would like to initially keep the PPMC small, ideally 5-7 people. We have around 50 people identified as initial committers, but having a PMC that large during incubation is not ideal for the issues that have been mentioned.
Jason Porter
Software Engineer
He/Him/His
IBM
On Dec 9, 2022, at 08:17, Niall Pemberton <ni...@gmail.com>> wrote:
On Tue, 6 Dec 2022 at 16:27, Jason Porter <jp...@ibm.com.invalid>>> wrote:
On Dec 6, 2022, at 01:43, Christofer Dutz <ch...@c-ware.de>>
wrote:
Hi Jason,
Well, those numbers are a bit better than the initial ones.
Thing is: Mentors will not only have to help onboard people to Apache
and teach them how to do things, if they are doing their job correctly,
they should also really audit the releases being done and help get the
codebase into shape first.
Even with 12 sub-projects, work-wise that would put a load on the
mentors, as if they signed up for mentoring 12 projects.
So how about bringing in projects separately (where it makes sense)?
There each project could have their initial PPMC and committer lists and it
would spread out the load a bit. However I would expect staffing 12
projects with enough work-willing mentors will still be challenging and I
would assume not all of them to find enough of them, but it could be one
first step.
Or is there an advantage of considering all projects as one unity?
Chris
[snip]
That is part of a broader question. Some of those repos are things like
examples for kogito, the website, etc. Things that are part of the projects
themselves, but don’t have a life outside of the project to which they
belong. I understand we’ll probably have to collapse the structures within
Apache and have a single repo per project. What we’re really looking at as
far as projects being donated:
Kogito
Drools
jBPM
I really think these should be separate projects. I realize theres a
dependency/hierarchy between them (jBPM using Drools as its rules engine
and Kogito using jBPM for its business process/workflow) - but people use
Drools without jBPM and (I assume) jBPM without Kogito. Even if the current
set of contributors all work on all three projects, the aspiration here at
Apache has to be to grow the community of contributors from the user
community which will not be completely the same for the three projects.
I've used Drools in the past, but not jBPM or Kogito.
Niall
Then there are the supporting repos for things like examples, docs,
website, tooling, etc. Many of the people working on these projects work on
all of them, so it would probably be the same group of people with very
little deviation in the list of committers. Could they be different PPMCs,
but they’d basically be the same group, just more work with the reports,
setup, infra, etc.
Jason Porter
Software Engineer
He/Him/His
IBM
--
Best wishes！
CalvinKirs
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org<ma...@incubator.apache.org>
For additional commands, e-mail: general-help@incubator.apache.org<ma...@incubator.apache.org>
Re: [DISCUSS] KIE Proposal
Posted by Jason Porter <jp...@ibm.com.INVALID>.
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 <fa...@gmail.com> 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 <fa...@gmail.com> wrote:
I did some of the wikification of the email but it's pretty time
consuming and I want to finish up for the evening.
The main item remaining is to put all the initial committers into the table.
On Tue, 3 Jan 2023 at 19:26, Jason Porter <jp...@ibm.com> wrote:
I was just going to do this but looks like you beat me to it, PJ, thank you.
Jason Porter
Software Engineer
He/Him/His
IBM
On Jan 3, 2023, at 09:42, PJ Fanning <fa...@apache.org> wrote:
This Message Is From an External Sender
This message came from outside your organization.
Could we get the proposal doc up on the ASF wiki?
On Tue 3 Jan 2023, 17:25 Jason Porter, <jp...@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 <jp...@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 <jp...@ibm.com.INVALID>
Sent: Tuesday, December 13, 2022 08:37
To: general@incubator.apache.org <ge...@incubator.apache.org>
Subject: [EXTERNAL] RE: [DISCUSS] KIE Proposal
________________________________
From: Calvin Kirs <ki...@apache.org>
Sent: Monday, December 12, 2022 23:31
To: general@incubator.apache.org <ge...@incubator.apache.org>
Subject: [EXTERNAL] Re: [DISCUSS] KIE Proposal
On Fri, Dec 9, 2022 at 11:45 PM Jason Porter <jp...@ibm.com.invalid> wrote:
We don’t feel like KIE and Servicecomb-kie clash. One is an acronym (KIE- Knowledge Is Everything), and the other is a suffix. Both projects are very different as well. Servicecomb-kie is a configuration center for microservices written in Go, whereas KIE is a knowledge engineering and process automation solution written in Java. For example, how was this handled in the context of Apache DeltaCloud and Apache DeltaSpike; or Apache DataFu and Apache DataLab? Is there precedence within the ASF for similarly named projects? The two communities have also co-existed for roughly the same time, using the same names without clashes.
That's not a problem If two projects are in different fields.
we'd just need to be careful with the project description.
Perfect! Thank you, Calvin.
As was stated previously, the number of projects is much smaller than the number of GitHub repos. This is because KIE did not use a singular repository model within the GitHub organization. The projects we’re currently considering in this proposal are Kogito, jBPM, Drools, KIE-Tools, and another project for the CNCF Serverless Workflow implementation that is going through a naming process now. KIE-Tools is a little odd, though, as it doesn’t stand on its own well. The existing code base contains a lot of modules and code, which could be considered legacy, which we do not plan to move over. There will be a cleaning and pruning process to ensure a more relevant, sustainable, and forward-looking set of modules as code is moved over. This should further reduce the amount of code that is moved over. We understand we may need to collapse the repositories moving over to the ASF. Let us know if you want to see how everything rolls into a more flat structure.
Regarding umbrella versus standalone projects, we believe that the unified and cohesive experience provides more value than just the sum of its parts. This is also not just about where we are now, but where we hope to evolve as a knowledge engineering platform. On the surface, those projects can be seen as independent in their business rules, decisions, and workflow domains. However, real-world use cases are more complex. Usually, they require a lot of interdependencies, for example, business rules orchestration is accomplished by using a workflow file definition (i.e., BPMN), and complex workflow decisions are better modeled in DMN models. The aim is to try and drive consistency and ease of use across those technologies, in an integrated and holistic manner.
If those projects end up as individual TLPs, it'll be up to users to write a lot of boiler-plate code - or create additional new projects to handle and abstract the unified experience.
Of course, as a consequence of the unified vision, the current codebase is taking advantage of this unification, which means there's a lot of shared code among the projects. Moving away from this will also result in more top-level supporting projects to provide additional code, needed as foundational code or integration code, which may actually create more complexity and end-user confusion.
Although it might not be the most popular example within Apache, KIE aims to provide a similar umbrella cohesiveness that Apache OpenOffice has for their sub-projects like Write and Calc. We really want the community to think of knowledge engineering as a whole domain of technologies for problem-solving, and not on individual silo technologies.
Lastly, fracturing the community we have already created around the KIE brand and concept is certainly not ideal and will weaken the overall project brands and success. We believe we'll be able to leverage further what we currently have in the community and build upon it to create a more cohesive knowledge-processing solution if everything stays together and people remain invested in the success of the knowledge engineering platform as a whole, rather than their individual technologies.
We would like to initially keep the PPMC small, ideally 5-7 people. We have around 50 people identified as initial committers, but having a PMC that large during incubation is not ideal for the issues that have been mentioned.
Jason Porter
Software Engineer
He/Him/His
IBM
On Dec 9, 2022, at 08:17, Niall Pemberton <ni...@gmail.com> wrote:
On Tue, 6 Dec 2022 at 16:27, Jason Porter <jp...@ibm.com.invalid>> wrote:
On Dec 6, 2022, at 01:43, Christofer Dutz <ch...@c-ware.de>
wrote:
Hi Jason,
Well, those numbers are a bit better than the initial ones.
Thing is: Mentors will not only have to help onboard people to Apache
and teach them how to do things, if they are doing their job correctly,
they should also really audit the releases being done and help get the
codebase into shape first.
Even with 12 sub-projects, work-wise that would put a load on the
mentors, as if they signed up for mentoring 12 projects.
So how about bringing in projects separately (where it makes sense)?
There each project could have their initial PPMC and committer lists and it
would spread out the load a bit. However I would expect staffing 12
projects with enough work-willing mentors will still be challenging and I
would assume not all of them to find enough of them, but it could be one
first step.
Or is there an advantage of considering all projects as one unity?
Chris
[snip]
That is part of a broader question. Some of those repos are things like
examples for kogito, the website, etc. Things that are part of the projects
themselves, but don’t have a life outside of the project to which they
belong. I understand we’ll probably have to collapse the structures within
Apache and have a single repo per project. What we’re really looking at as
far as projects being donated:
Kogito
Drools
jBPM
I really think these should be separate projects. I realize theres a
dependency/hierarchy between them (jBPM using Drools as its rules engine
and Kogito using jBPM for its business process/workflow) - but people use
Drools without jBPM and (I assume) jBPM without Kogito. Even if the current
set of contributors all work on all three projects, the aspiration here at
Apache has to be to grow the community of contributors from the user
community which will not be completely the same for the three projects.
I've used Drools in the past, but not jBPM or Kogito.
Niall
Then there are the supporting repos for things like examples, docs,
website, tooling, etc. Many of the people working on these projects work on
all of them, so it would probably be the same group of people with very
little deviation in the list of committers. Could they be different PPMCs,
but they’d basically be the same group, just more work with the reports,
setup, infra, etc.
Jason Porter
Software Engineer
He/Him/His
IBM
--
Best wishes！
CalvinKirs
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] KIE Proposal
Posted by PJ Fanning <fa...@gmail.com>.
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 <fa...@gmail.com> wrote:
>
> I did some of the wikification of the email but it's pretty time
> consuming and I want to finish up for the evening.
>
> The main item remaining is to put all the initial committers into the table.
>
> On Tue, 3 Jan 2023 at 19:26, Jason Porter <jp...@ibm.com> wrote:
> >
> > I was just going to do this but looks like you beat me to it, PJ, thank you.
> >
> > Jason Porter
> > Software Engineer
> > He/Him/His
> >
> > IBM
> >
> > On Jan 3, 2023, at 09:42, PJ Fanning <fa...@apache.org> wrote:
> >
> > This Message Is From an External Sender
> > This message came from outside your organization.
> > Could we get the proposal doc up on the ASF wiki?
> >
> > On Tue 3 Jan 2023, 17:25 Jason Porter, <jp...@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 <jp...@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 <jp...@ibm.com.INVALID>
> >> Sent: Tuesday, December 13, 2022 08:37
> >> To: general@incubator.apache.org <ge...@incubator.apache.org>
> >> Subject: [EXTERNAL] RE: [DISCUSS] KIE Proposal
> >>
> >>
> >>
> >> ________________________________
> >> From: Calvin Kirs <ki...@apache.org>
> >> Sent: Monday, December 12, 2022 23:31
> >> To: general@incubator.apache.org <ge...@incubator.apache.org>
> >> Subject: [EXTERNAL] Re: [DISCUSS] KIE Proposal
> >>
> >> On Fri, Dec 9, 2022 at 11:45 PM Jason Porter <jp...@ibm.com.invalid> wrote:
> >>
> >> We don’t feel like KIE and Servicecomb-kie clash. One is an acronym (KIE- Knowledge Is Everything), and the other is a suffix. Both projects are very different as well. Servicecomb-kie is a configuration center for microservices written in Go, whereas KIE is a knowledge engineering and process automation solution written in Java. For example, how was this handled in the context of Apache DeltaCloud and Apache DeltaSpike; or Apache DataFu and Apache DataLab? Is there precedence within the ASF for similarly named projects? The two communities have also co-existed for roughly the same time, using the same names without clashes.
> >>
> >> That's not a problem If two projects are in different fields.
> >> we'd just need to be careful with the project description.
> >>
> >> Perfect! Thank you, Calvin.
> >>
> >>
> >>
> >> As was stated previously, the number of projects is much smaller than the number of GitHub repos. This is because KIE did not use a singular repository model within the GitHub organization. The projects we’re currently considering in this proposal are Kogito, jBPM, Drools, KIE-Tools, and another project for the CNCF Serverless Workflow implementation that is going through a naming process now. KIE-Tools is a little odd, though, as it doesn’t stand on its own well. The existing code base contains a lot of modules and code, which could be considered legacy, which we do not plan to move over. There will be a cleaning and pruning process to ensure a more relevant, sustainable, and forward-looking set of modules as code is moved over. This should further reduce the amount of code that is moved over. We understand we may need to collapse the repositories moving over to the ASF. Let us know if you want to see how everything rolls into a more flat structure.
> >>
> >>
> >> Regarding umbrella versus standalone projects, we believe that the unified and cohesive experience provides more value than just the sum of its parts. This is also not just about where we are now, but where we hope to evolve as a knowledge engineering platform. On the surface, those projects can be seen as independent in their business rules, decisions, and workflow domains. However, real-world use cases are more complex. Usually, they require a lot of interdependencies, for example, business rules orchestration is accomplished by using a workflow file definition (i.e., BPMN), and complex workflow decisions are better modeled in DMN models. The aim is to try and drive consistency and ease of use across those technologies, in an integrated and holistic manner.
> >>
> >>
> >> If those projects end up as individual TLPs, it'll be up to users to write a lot of boiler-plate code - or create additional new projects to handle and abstract the unified experience.
> >>
> >>
> >> Of course, as a consequence of the unified vision, the current codebase is taking advantage of this unification, which means there's a lot of shared code among the projects. Moving away from this will also result in more top-level supporting projects to provide additional code, needed as foundational code or integration code, which may actually create more complexity and end-user confusion.
> >>
> >>
> >>
> >> Although it might not be the most popular example within Apache, KIE aims to provide a similar umbrella cohesiveness that Apache OpenOffice has for their sub-projects like Write and Calc. We really want the community to think of knowledge engineering as a whole domain of technologies for problem-solving, and not on individual silo technologies.
> >>
> >>
> >> Lastly, fracturing the community we have already created around the KIE brand and concept is certainly not ideal and will weaken the overall project brands and success. We believe we'll be able to leverage further what we currently have in the community and build upon it to create a more cohesive knowledge-processing solution if everything stays together and people remain invested in the success of the knowledge engineering platform as a whole, rather than their individual technologies.
> >>
> >>
> >> We would like to initially keep the PPMC small, ideally 5-7 people. We have around 50 people identified as initial committers, but having a PMC that large during incubation is not ideal for the issues that have been mentioned.
> >>
> >> Jason Porter
> >> Software Engineer
> >> He/Him/His
> >>
> >> IBM
> >>
> >> On Dec 9, 2022, at 08:17, Niall Pemberton <ni...@gmail.com> wrote:
> >>
> >> On Tue, 6 Dec 2022 at 16:27, Jason Porter <jp...@ibm.com.invalid>> wrote:
> >>
> >>
> >> On Dec 6, 2022, at 01:43, Christofer Dutz <ch...@c-ware.de>
> >> wrote:
> >>
> >> Hi Jason,
> >>
> >> Well, those numbers are a bit better than the initial ones.
> >> Thing is: Mentors will not only have to help onboard people to Apache
> >> and teach them how to do things, if they are doing their job correctly,
> >> they should also really audit the releases being done and help get the
> >> codebase into shape first.
> >>
> >> Even with 12 sub-projects, work-wise that would put a load on the
> >> mentors, as if they signed up for mentoring 12 projects.
> >>
> >> So how about bringing in projects separately (where it makes sense)?
> >> There each project could have their initial PPMC and committer lists and it
> >> would spread out the load a bit. However I would expect staffing 12
> >> projects with enough work-willing mentors will still be challenging and I
> >> would assume not all of them to find enough of them, but it could be one
> >> first step.
> >>
> >> Or is there an advantage of considering all projects as one unity?
> >>
> >> Chris
> >>
> >> [snip]
> >>
> >> That is part of a broader question. Some of those repos are things like
> >> examples for kogito, the website, etc. Things that are part of the projects
> >> themselves, but don’t have a life outside of the project to which they
> >> belong. I understand we’ll probably have to collapse the structures within
> >> Apache and have a single repo per project. What we’re really looking at as
> >> far as projects being donated:
> >>
> >> Kogito
> >> Drools
> >> jBPM
> >>
> >>
> >> I really think these should be separate projects. I realize theres a
> >> dependency/hierarchy between them (jBPM using Drools as its rules engine
> >> and Kogito using jBPM for its business process/workflow) - but people use
> >> Drools without jBPM and (I assume) jBPM without Kogito. Even if the current
> >> set of contributors all work on all three projects, the aspiration here at
> >> Apache has to be to grow the community of contributors from the user
> >> community which will not be completely the same for the three projects.
> >> I've used Drools in the past, but not jBPM or Kogito.
> >>
> >> Niall
> >>
> >>
> >>
> >> Then there are the supporting repos for things like examples, docs,
> >> website, tooling, etc. Many of the people working on these projects work on
> >> all of them, so it would probably be the same group of people with very
> >> little deviation in the list of committers. Could they be different PPMCs,
> >> but they’d basically be the same group, just more work with the reports,
> >> setup, infra, etc.
> >>
> >> Jason Porter
> >> Software Engineer
> >> He/Him/His
> >>
> >> IBM
> >>
> >>
> >>
> >> --
> >> Best wishes！
> >> CalvinKirs
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] KIE Proposal
Posted by PJ Fanning <fa...@gmail.com>.
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 <jp...@ibm.com> wrote:
>
> I was just going to do this but looks like you beat me to it, PJ, thank you.
>
> Jason Porter
> Software Engineer
> He/Him/His
>
> IBM
>
> On Jan 3, 2023, at 09:42, PJ Fanning <fa...@apache.org> wrote:
>
> This Message Is From an External Sender
> This message came from outside your organization.
> Could we get the proposal doc up on the ASF wiki?
>
> On Tue 3 Jan 2023, 17:25 Jason Porter, <jp...@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 <jp...@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 <jp...@ibm.com.INVALID>
>> Sent: Tuesday, December 13, 2022 08:37
>> To: general@incubator.apache.org <ge...@incubator.apache.org>
>> Subject: [EXTERNAL] RE: [DISCUSS] KIE Proposal
>>
>>
>>
>> ________________________________
>> From: Calvin Kirs <ki...@apache.org>
>> Sent: Monday, December 12, 2022 23:31
>> To: general@incubator.apache.org <ge...@incubator.apache.org>
>> Subject: [EXTERNAL] Re: [DISCUSS] KIE Proposal
>>
>> On Fri, Dec 9, 2022 at 11:45 PM Jason Porter <jp...@ibm.com.invalid> wrote:
>>
>> We don’t feel like KIE and Servicecomb-kie clash. One is an acronym (KIE- Knowledge Is Everything), and the other is a suffix. Both projects are very different as well. Servicecomb-kie is a configuration center for microservices written in Go, whereas KIE is a knowledge engineering and process automation solution written in Java. For example, how was this handled in the context of Apache DeltaCloud and Apache DeltaSpike; or Apache DataFu and Apache DataLab? Is there precedence within the ASF for similarly named projects? The two communities have also co-existed for roughly the same time, using the same names without clashes.
>>
>> That's not a problem If two projects are in different fields.
>> we'd just need to be careful with the project description.
>>
>> Perfect! Thank you, Calvin.
>>
>>
>>
>> As was stated previously, the number of projects is much smaller than the number of GitHub repos. This is because KIE did not use a singular repository model within the GitHub organization. The projects we’re currently considering in this proposal are Kogito, jBPM, Drools, KIE-Tools, and another project for the CNCF Serverless Workflow implementation that is going through a naming process now. KIE-Tools is a little odd, though, as it doesn’t stand on its own well. The existing code base contains a lot of modules and code, which could be considered legacy, which we do not plan to move over. There will be a cleaning and pruning process to ensure a more relevant, sustainable, and forward-looking set of modules as code is moved over. This should further reduce the amount of code that is moved over. We understand we may need to collapse the repositories moving over to the ASF. Let us know if you want to see how everything rolls into a more flat structure.
>>
>>
>> Regarding umbrella versus standalone projects, we believe that the unified and cohesive experience provides more value than just the sum of its parts. This is also not just about where we are now, but where we hope to evolve as a knowledge engineering platform. On the surface, those projects can be seen as independent in their business rules, decisions, and workflow domains. However, real-world use cases are more complex. Usually, they require a lot of interdependencies, for example, business rules orchestration is accomplished by using a workflow file definition (i.e., BPMN), and complex workflow decisions are better modeled in DMN models. The aim is to try and drive consistency and ease of use across those technologies, in an integrated and holistic manner.
>>
>>
>> If those projects end up as individual TLPs, it'll be up to users to write a lot of boiler-plate code - or create additional new projects to handle and abstract the unified experience.
>>
>>
>> Of course, as a consequence of the unified vision, the current codebase is taking advantage of this unification, which means there's a lot of shared code among the projects. Moving away from this will also result in more top-level supporting projects to provide additional code, needed as foundational code or integration code, which may actually create more complexity and end-user confusion.
>>
>>
>>
>> Although it might not be the most popular example within Apache, KIE aims to provide a similar umbrella cohesiveness that Apache OpenOffice has for their sub-projects like Write and Calc. We really want the community to think of knowledge engineering as a whole domain of technologies for problem-solving, and not on individual silo technologies.
>>
>>
>> Lastly, fracturing the community we have already created around the KIE brand and concept is certainly not ideal and will weaken the overall project brands and success. We believe we'll be able to leverage further what we currently have in the community and build upon it to create a more cohesive knowledge-processing solution if everything stays together and people remain invested in the success of the knowledge engineering platform as a whole, rather than their individual technologies.
>>
>>
>> We would like to initially keep the PPMC small, ideally 5-7 people. We have around 50 people identified as initial committers, but having a PMC that large during incubation is not ideal for the issues that have been mentioned.
>>
>> Jason Porter
>> Software Engineer
>> He/Him/His
>>
>> IBM
>>
>> On Dec 9, 2022, at 08:17, Niall Pemberton <ni...@gmail.com> wrote:
>>
>> On Tue, 6 Dec 2022 at 16:27, Jason Porter <jp...@ibm.com.invalid>> wrote:
>>
>>
>> On Dec 6, 2022, at 01:43, Christofer Dutz <ch...@c-ware.de>
>> wrote:
>>
>> Hi Jason,
>>
>> Well, those numbers are a bit better than the initial ones.
>> Thing is: Mentors will not only have to help onboard people to Apache
>> and teach them how to do things, if they are doing their job correctly,
>> they should also really audit the releases being done and help get the
>> codebase into shape first.
>>
>> Even with 12 sub-projects, work-wise that would put a load on the
>> mentors, as if they signed up for mentoring 12 projects.
>>
>> So how about bringing in projects separately (where it makes sense)?
>> There each project could have their initial PPMC and committer lists and it
>> would spread out the load a bit. However I would expect staffing 12
>> projects with enough work-willing mentors will still be challenging and I
>> would assume not all of them to find enough of them, but it could be one
>> first step.
>>
>> Or is there an advantage of considering all projects as one unity?
>>
>> Chris
>>
>> [snip]
>>
>> That is part of a broader question. Some of those repos are things like
>> examples for kogito, the website, etc. Things that are part of the projects
>> themselves, but don’t have a life outside of the project to which they
>> belong. I understand we’ll probably have to collapse the structures within
>> Apache and have a single repo per project. What we’re really looking at as
>> far as projects being donated:
>>
>> Kogito
>> Drools
>> jBPM
>>
>>
>> I really think these should be separate projects. I realize theres a
>> dependency/hierarchy between them (jBPM using Drools as its rules engine
>> and Kogito using jBPM for its business process/workflow) - but people use
>> Drools without jBPM and (I assume) jBPM without Kogito. Even if the current
>> set of contributors all work on all three projects, the aspiration here at
>> Apache has to be to grow the community of contributors from the user
>> community which will not be completely the same for the three projects.
>> I've used Drools in the past, but not jBPM or Kogito.
>>
>> Niall
>>
>>
>>
>> Then there are the supporting repos for things like examples, docs,
>> website, tooling, etc. Many of the people working on these projects work on
>> all of them, so it would probably be the same group of people with very
>> little deviation in the list of committers. Could they be different PPMCs,
>> but they’d basically be the same group, just more work with the reports,
>> setup, infra, etc.
>>
>> Jason Porter
>> Software Engineer
>> He/Him/His
>>
>> IBM
>>
>>
>>
>> --
>> Best wishes！
>> CalvinKirs
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] KIE Proposal
Posted by Jason Porter <jp...@ibm.com.INVALID>.
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 <fa...@apache.org> wrote:
This Message Is From an External Sender
This message came from outside your organization.
Could we get the proposal doc up on the ASF wiki?
On Tue 3 Jan 2023, 17:25 Jason Porter, <jp...@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 <jp...@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 <jp...@ibm.com.INVALID>>
Sent: Tuesday, December 13, 2022 08:37
To: general@incubator.apache.org<ma...@incubator.apache.org> <ge...@incubator.apache.org>>
Subject: [EXTERNAL] RE: [DISCUSS] KIE Proposal
________________________________
From: Calvin Kirs <ki...@apache.org>>
Sent: Monday, December 12, 2022 23:31
To: general@incubator.apache.org<ma...@incubator.apache.org> <ge...@incubator.apache.org>>
Subject: [EXTERNAL] Re: [DISCUSS] KIE Proposal
On Fri, Dec 9, 2022 at 11:45 PM Jason Porter <jp...@ibm.com.invalid>> wrote:
We don’t feel like KIE and Servicecomb-kie clash. One is an acronym (KIE- Knowledge Is Everything), and the other is a suffix. Both projects are very different as well. Servicecomb-kie is a configuration center for microservices written in Go, whereas KIE is a knowledge engineering and process automation solution written in Java. For example, how was this handled in the context of Apache DeltaCloud and Apache DeltaSpike; or Apache DataFu and Apache DataLab? Is there precedence within the ASF for similarly named projects? The two communities have also co-existed for roughly the same time, using the same names without clashes.
That's not a problem If two projects are in different fields.
we'd just need to be careful with the project description.
Perfect! Thank you, Calvin.
As was stated previously, the number of projects is much smaller than the number of GitHub repos. This is because KIE did not use a singular repository model within the GitHub organization. The projects we’re currently considering in this proposal are Kogito, jBPM, Drools, KIE-Tools, and another project for the CNCF Serverless Workflow implementation that is going through a naming process now. KIE-Tools is a little odd, though, as it doesn’t stand on its own well. The existing code base contains a lot of modules and code, which could be considered legacy, which we do not plan to move over. There will be a cleaning and pruning process to ensure a more relevant, sustainable, and forward-looking set of modules as code is moved over. This should further reduce the amount of code that is moved over. We understand we may need to collapse the repositories moving over to the ASF. Let us know if you want to see how everything rolls into a more flat structure.
Regarding umbrella versus standalone projects, we believe that the unified and cohesive experience provides more value than just the sum of its parts. This is also not just about where we are now, but where we hope to evolve as a knowledge engineering platform. On the surface, those projects can be seen as independent in their business rules, decisions, and workflow domains. However, real-world use cases are more complex. Usually, they require a lot of interdependencies, for example, business rules orchestration is accomplished by using a workflow file definition (i.e., BPMN), and complex workflow decisions are better modeled in DMN models. The aim is to try and drive consistency and ease of use across those technologies, in an integrated and holistic manner.
If those projects end up as individual TLPs, it'll be up to users to write a lot of boiler-plate code - or create additional new projects to handle and abstract the unified experience.
Of course, as a consequence of the unified vision, the current codebase is taking advantage of this unification, which means there's a lot of shared code among the projects. Moving away from this will also result in more top-level supporting projects to provide additional code, needed as foundational code or integration code, which may actually create more complexity and end-user confusion.
Although it might not be the most popular example within Apache, KIE aims to provide a similar umbrella cohesiveness that Apache OpenOffice has for their sub-projects like Write and Calc. We really want the community to think of knowledge engineering as a whole domain of technologies for problem-solving, and not on individual silo technologies.
Lastly, fracturing the community we have already created around the KIE brand and concept is certainly not ideal and will weaken the overall project brands and success. We believe we'll be able to leverage further what we currently have in the community and build upon it to create a more cohesive knowledge-processing solution if everything stays together and people remain invested in the success of the knowledge engineering platform as a whole, rather than their individual technologies.
We would like to initially keep the PPMC small, ideally 5-7 people. We have around 50 people identified as initial committers, but having a PMC that large during incubation is not ideal for the issues that have been mentioned.
Jason Porter
Software Engineer
He/Him/His
IBM
On Dec 9, 2022, at 08:17, Niall Pemberton <ni...@gmail.com>> wrote:
On Tue, 6 Dec 2022 at 16:27, Jason Porter <jp...@ibm.com.invalid>>> wrote:
On Dec 6, 2022, at 01:43, Christofer Dutz <ch...@c-ware.de>>
wrote:
Hi Jason,
Well, those numbers are a bit better than the initial ones.
Thing is: Mentors will not only have to help onboard people to Apache
and teach them how to do things, if they are doing their job correctly,
they should also really audit the releases being done and help get the
codebase into shape first.
Even with 12 sub-projects, work-wise that would put a load on the
mentors, as if they signed up for mentoring 12 projects.
So how about bringing in projects separately (where it makes sense)?
There each project could have their initial PPMC and committer lists and it
would spread out the load a bit. However I would expect staffing 12
projects with enough work-willing mentors will still be challenging and I
would assume not all of them to find enough of them, but it could be one
first step.
Or is there an advantage of considering all projects as one unity?
Chris
[snip]
That is part of a broader question. Some of those repos are things like
examples for kogito, the website, etc. Things that are part of the projects
themselves, but don’t have a life outside of the project to which they
belong. I understand we’ll probably have to collapse the structures within
Apache and have a single repo per project. What we’re really looking at as
far as projects being donated:
Kogito
Drools
jBPM
I really think these should be separate projects. I realize theres a
dependency/hierarchy between them (jBPM using Drools as its rules engine
and Kogito using jBPM for its business process/workflow) - but people use
Drools without jBPM and (I assume) jBPM without Kogito. Even if the current
set of contributors all work on all three projects, the aspiration here at
Apache has to be to grow the community of contributors from the user
community which will not be completely the same for the three projects.
I've used Drools in the past, but not jBPM or Kogito.
Niall
Then there are the supporting repos for things like examples, docs,
website, tooling, etc. Many of the people working on these projects work on
all of them, so it would probably be the same group of people with very
little deviation in the list of committers. Could they be different PPMCs,
but they’d basically be the same group, just more work with the reports,
setup, infra, etc.
Jason Porter
Software Engineer
He/Him/His
IBM
--
Best wishes！
CalvinKirs
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org<ma...@incubator.apache.org>
For additional commands, e-mail: general-help@incubator.apache.org<ma...@incubator.apache.org>
Re: [DISCUSS] KIE Proposal
Posted by PJ Fanning <fa...@apache.org>.
Could we get the proposal doc up on the ASF wiki?
On Tue 3 Jan 2023, 17:25 Jason Porter, <jp...@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 <jp...@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 <jp...@ibm.com.INVALID>
> Sent: Tuesday, December 13, 2022 08:37
> To: general@incubator.apache.org <ge...@incubator.apache.org>
> Subject: [EXTERNAL] RE: [DISCUSS] KIE Proposal
>
>
>
> ________________________________
> From: Calvin Kirs <ki...@apache.org>
> Sent: Monday, December 12, 2022 23:31
> To: general@incubator.apache.org <ge...@incubator.apache.org>
> Subject: [EXTERNAL] Re: [DISCUSS] KIE Proposal
>
> On Fri, Dec 9, 2022 at 11:45 PM Jason Porter <jp...@ibm.com.invalid>
> wrote:
>
> We don’t feel like KIE and Servicecomb-kie clash. One is an acronym (KIE-
> Knowledge Is Everything), and the other is a suffix. Both projects are very
> different as well. Servicecomb-kie is a configuration center for
> microservices written in Go, whereas KIE is a knowledge engineering and
> process automation solution written in Java. For example, how was this
> handled in the context of Apache DeltaCloud and Apache DeltaSpike; or
> Apache DataFu and Apache DataLab? Is there precedence within the ASF for
> similarly named projects? The two communities have also co-existed for
> roughly the same time, using the same names without clashes.
>
> That's not a problem If two projects are in different fields.
> we'd just need to be careful with the project description.
>
> Perfect! Thank you, Calvin.
>
>
>
> As was stated previously, the number of projects is much smaller than the
> number of GitHub repos. This is because KIE did not use a singular
> repository model within the GitHub organization. The projects we’re
> currently considering in this proposal are Kogito, jBPM, Drools, KIE-Tools,
> and another project for the CNCF Serverless Workflow implementation that is
> going through a naming process now. KIE-Tools is a little odd, though, as
> it doesn’t stand on its own well. The existing code base contains a lot of
> modules and code, which could be considered legacy, which we do not plan to
> move over. There will be a cleaning and pruning process to ensure a more
> relevant, sustainable, and forward-looking set of modules as code is moved
> over. This should further reduce the amount of code that is moved over. We
> understand we may need to collapse the repositories moving over to the ASF.
> Let us know if you want to see how everything rolls into a more flat
> structure.
>
>
> Regarding umbrella versus standalone projects, we believe that the unified
> and cohesive experience provides more value than just the sum of its parts.
> This is also not just about where we are now, but where we hope to evolve
> as a knowledge engineering platform. On the surface, those projects can be
> seen as independent in their business rules, decisions, and workflow
> domains. However, real-world use cases are more complex. Usually, they
> require a lot of interdependencies, for example, business rules
> orchestration is accomplished by using a workflow file definition (i.e.,
> BPMN), and complex workflow decisions are better modeled in DMN models. The
> aim is to try and drive consistency and ease of use across those
> technologies, in an integrated and holistic manner.
>
>
> If those projects end up as individual TLPs, it'll be up to users to write
> a lot of boiler-plate code - or create additional new projects to handle
> and abstract the unified experience.
>
>
> Of course, as a consequence of the unified vision, the current codebase is
> taking advantage of this unification, which means there's a lot of shared
> code among the projects. Moving away from this will also result in more
> top-level supporting projects to provide additional code, needed as
> foundational code or integration code, which may actually create more
> complexity and end-user confusion.
>
>
>
> Although it might not be the most popular example within Apache, KIE aims
> to provide a similar umbrella cohesiveness that Apache OpenOffice has for
> their sub-projects like Write and Calc. We really want the community to
> think of knowledge engineering as a whole domain of technologies for
> problem-solving, and not on individual silo technologies.
>
>
> Lastly, fracturing the community we have already created around the KIE
> brand and concept is certainly not ideal and will weaken the overall
> project brands and success. We believe we'll be able to leverage further
> what we currently have in the community and build upon it to create a more
> cohesive knowledge-processing solution if everything stays together and
> people remain invested in the success of the knowledge engineering platform
> as a whole, rather than their individual technologies.
>
>
> We would like to initially keep the PPMC small, ideally 5-7 people. We
> have around 50 people identified as initial committers, but having a PMC
> that large during incubation is not ideal for the issues that have been
> mentioned.
>
> Jason Porter
> Software Engineer
> He/Him/His
>
> IBM
>
> On Dec 9, 2022, at 08:17, Niall Pemberton <ni...@gmail.com>
> wrote:
>
> On Tue, 6 Dec 2022 at 16:27, Jason Porter <jporter@ibm.com.invalid<mailto:
> jporter@ibm.com.invalid>> wrote:
>
>
> On Dec 6, 2022, at 01:43, Christofer Dutz <ch...@c-ware.de>
> wrote:
>
> Hi Jason,
>
> Well, those numbers are a bit better than the initial ones.
> Thing is: Mentors will not only have to help onboard people to Apache
> and teach them how to do things, if they are doing their job correctly,
> they should also really audit the releases being done and help get the
> codebase into shape first.
>
> Even with 12 sub-projects, work-wise that would put a load on the
> mentors, as if they signed up for mentoring 12 projects.
>
> So how about bringing in projects separately (where it makes sense)?
> There each project could have their initial PPMC and committer lists and it
> would spread out the load a bit. However I would expect staffing 12
> projects with enough work-willing mentors will still be challenging and I
> would assume not all of them to find enough of them, but it could be one
> first step.
>
> Or is there an advantage of considering all projects as one unity?
>
> Chris
>
> [snip]
>
> That is part of a broader question. Some of those repos are things like
> examples for kogito, the website, etc. Things that are part of the projects
> themselves, but don’t have a life outside of the project to which they
> belong. I understand we’ll probably have to collapse the structures within
> Apache and have a single repo per project. What we’re really looking at as
> far as projects being donated:
>
> Kogito
> Drools
> jBPM
>
>
> I really think these should be separate projects. I realize theres a
> dependency/hierarchy between them (jBPM using Drools as its rules engine
> and Kogito using jBPM for its business process/workflow) - but people use
> Drools without jBPM and (I assume) jBPM without Kogito. Even if the current
> set of contributors all work on all three projects, the aspiration here at
> Apache has to be to grow the community of contributors from the user
> community which will not be completely the same for the three projects.
> I've used Drools in the past, but not jBPM or Kogito.
>
> Niall
>
>
>
> Then there are the supporting repos for things like examples, docs,
> website, tooling, etc. Many of the people working on these projects work on
> all of them, so it would probably be the same group of people with very
> little deviation in the list of committers. Could they be different PPMCs,
> but they’d basically be the same group, just more work with the reports,
> setup, infra, etc.
>
> Jason Porter
> Software Engineer
> He/Him/His
>
> IBM
>
>
>
> --
> Best wishes！
> CalvinKirs
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
>