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 <jpor...@ibm.com.INVALID> Date: Monday, 5. December 2022 at 19:08 To: general@incubator.apache.org <general@incubator.apache.org> Subject: Re: [DISCUSS] KIE Proposal On Dec 5, 2022, at 01:23, Christofer Dutz <christofer.d...@c-ware.de> 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 <willem.ji...@gmail.com<mailto:willem.ji...@gmail.com>> Date: Monday, 5. December 2022 at 04:15 To: general@incubator.apache.org<mailto:general@incubator.apache.org> <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 <niall.pember...@gmail.com> 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 <jpor...@ibm.com.invalid> 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. Meritocracy:< https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#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:< https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#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 Community back in 2020. IRC has been used since 2003. Core Developers:< https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#core-developers Core developers would come from both Red Hat and IBM. They include people who have been working on related projects and the creation of the KIE Community since the beginning, and also people new to the project. Alignment:< https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#alignment Projects within the KIE Community align with multiple efforts within Apache, namely: * Apache OpenWhisk * Apache Airavata * Apache Camel We are currently actively involved in collaboration with Apache Camel, while the other two are more alignments and usages within the communities. There may be other Apache projects which could benefit from integration with KIE Community projects. jBPM, the proposed Serverless Workflow project and the Kogito workflow foundation are targeting serverless and microservice deployments. It helps to create automation and integration with other technologies in a simple-to-use and understandable way. The Apache Software Foundation is a great place to collaborate with multiple companies and technologies. We’re looking to build a community that is inclusive, helpful, and a good citizen to the larger Open Source community. Other projects within the KIE Community umbrella target a more standard enterprise software approach and deployment model. Known Risks< https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#known-risks The Kogito workflow foundation targets the Quarkus environment, an open-source project that Red Hat maintains. Should Red Hat no longer wish to maintain Quarkus or move it in a direction that harms Kogito, a pivot may be necessary. The Kogito workflow foundation will still run on other runtimes, so it is less of a risk as well. There should not be any risks for other projects. Project Name< https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#project-name All names and trademarks have been vetted by Red Hat’s legal team to be usable in the space. Transferring these over to Apache will not be a problem. Orphaned products< https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#orphaned-products Primary contributions to the KIE Community of projects will be made by engineers employed by Red Hat and IBM. IBM is a leading vendor in the Business Automation space. Red Hat up until the second half of 2022 was also a major vendor in the same space. While Red Hat is no longer pursuing the Business Automation market it does still need to augment the capabilities of its other products with workflow, rules, and event technologies in a way that aligns with Red Hat’s target audiences and Red Hat’s strategic direction. Red Hat will continue to pursue the development around CNCF serverless workflow, which will be built upon Kogito and Drools. There is no risk of these projects being orphaned by either company. Inexperience with Open Source:< https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#inexperience-with-open-source All initial committers are well-versed in Open Source development. Length of Incubation:< https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#length-of-incubation Incubation should take somewhere between six to twelve months. Homogenous Developers:< https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#homogenous-developers The list of initial project committers includes developers from IBM and Red Hat, all from different locations around the world. Reliance on Salaried Developers:< https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#reliance-on-salaried-developers Currently, the list of developers is from IBM and Red Hat. We’re hoping by moving to Apache we can grow this list of developers outside of those two companies. All the projects within KIE have been around for a long time and have a large user base. Developers have come and gone over the years, but the initial list of developers is coming from Red Hat and IBM. Relationships with Other Apache Products:< https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#relationships-with-other-apache-products The Apache Camel project has had integrations with KIE Community projects, namely jBPM and Drools. Camel K also has integrations with Kogito. Kogito and Camel also have integrations with Quarkus. Kogito is built using Apache Maven. An Excessive Fascination with the Apache Brand:< https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#a-excessive-fascination-with-the-apache-brand We have looked at both the Apache Software Foundation and the Eclipse Foundation and have decided that Apache would be a better place for the code base. Red Hat, and IBM, have worked with both foundations and continue to do so. While the Apache brand is indeed well known and has great recognition, we’re looking more toward the neutral nature of being at Apache and keeping the project alive in an environment that is not solely controlled by a single entity. Documentation< https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#documentation Kogito Documentation: https://docs.kogito.kie.org/latest/html_single/#con-kogito-automation_kogito-docs Drools Documentation: https://www.drools.org/learn/documentation.html jBPM Documentation: https://docs.jbpm.org/7.73.0.Final/jbpm-docs/html_single/ Drools DMN Engine landing page: https://www.drools.org/learn/dmn.html DMN Specification: https://www.omg.org/spec/DMN BPMN Specification: https://www.omg.org/spec/BPMN/2.0/ Cloud Events Specification: https://github.com/cloudevents/spec Initial Source< https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#initial-source All the code will be coming from the KIE Community GitHub repo at https://github.com/kiegroup . There will be multiple repositories including examples and code bases for Drools, jBPM, and Kogito. Source and Intellectual Property Submission Plan< https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#source-and-intellectual-property-submission-plan * Source code within GitHub * Domains: kie.org<http://kie.org/>, kogito.org<http://kogito.org/>, kogito.kie.org<http://kogito.kie.org/>, blog.kie.org<http://blog.kie.org/>, jbpm.org<http://jbpm.org/>, drools.org<http://drools.org/>, bpmn.new, dmn.new, pmml.new, and sandbox.kie.org<http://sandbox.kie.org/> are all currently owned by Red Hat External Dependencies:< https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#external-dependencies There are some LGPL, and Eclipse dependencies for some of the projects in the test or provided scopes of the Maven poms. For example jdt dependencies for the Eclipse plugins, logback, junit, and similar. Hibernate jars are LGPL as well, those are in jBPM. Cryptography:< https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#cryptography There are some calls to the JVM vault, for process migration. Required Resources< https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#required-resources Mailing lists:< https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#mailing-lists * priv...@kie.incubator.apache.org<mailto:priv...@kie.incubator.apache.org> * d...@kie.incubator.apache.org<mailto:d...@kie.incubator.apache.org> * comm...@kie.incubator.apache.org<mailto:comm...@kie.incubator.apache.org> Subversion Directory:< https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#subversion-directory None Git Repositories:< https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#git-repositories Assuming we can continue to use GitHub, though it may need to migrate to be beneath the Apache Organization. Issue Tracking:< https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#issue-tracking If possible, we would like to use GitHub issues. Other Resources:< https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#other-resources None. Initial Committers< https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#initial-committers List of GitHub names: Name GitHub Username Apache CLA Apache Email Mario Fusco mariofusco FALSE Toshiya Kobayashi tkobayas TRUE Matteo Mortari tarilabs TRUE Tristan Radisson radtriste FALSE Gabriele Cardosi gitgabrio FALSE Edoardo Vacchi evacchi FALSE Paolo Bizzarri pibizza FALSE Cristiano Nicolai cristianonicolai FALSE Michael Biarnés Kiefer mbiarnes FALSE Enrique González Martínez elguardian FALSE Vani Haripriya Mudadla vaniharipriya FALSE Jason Porter lightguard TRUE lightguar...@apache.org<mailto:lightguar...@apache.org> Gonzalo Muñoz gmunozfe FALSE Francisco Javier Tirado Sarti fjtirado FALSE Helber Belmiro hbelmiro TRUE Antonio Fernandez Alhambra afalhambra FALSE Abhijit Humbe abhijithumbe FALSE Martin Weiler martinweiler FALSE Enrique Mingorance Cano ginxo FALSE Tiago Dolphine tiagodolphine FALSE Alex Porcelli porcelli FALSE Kris Verlaenen krisv TRUE (requested kr...@apache.org<mailto:kr...@apache.org>) Pere Fernández pefernan FALSE Jan Stastny jstastny-cz FALSE Jozef Marko jomarko FALSE Walter Medvedeo wmedvede FALSE Kennedy Bowers kbowers-redhat FALSE Roberto Oliveira rgdoliveira FALSE Andrea Lamparelli lampajr FALSE Bai Xiaofeng bxf12315 FALSE Ruben Romero Montes ruromero FALSE Filippe Spolti spolti FALSE Massimiliano Dessì desmax74 TRUE Tiago Bento tiagobento FALSE Yeser Amer yesamer FALSE Guilherme Caponetto caponetto FALSE Paulo Martins paulovmr FALSE Thiago Lugli thiagoelg FALSE William Antônio Siqueira jesuino FALSE Fabrizio Antonangeli fantonangeli FALSE Valentino Pellegrino vpellegrino FALSE Ricardo Zanini ricardozanini FALSE Tibor Zimányi baldimir FALSE Eder Ignatowicz ederign FALSE Mark Proctor mdproctor FALSE Thiago Lugli thiagoelg FALSE Luiz João Motta ljmotta FALSE Jaime Enriquez inodeman FALSE Luca Molteni lucamolteni FALSE Davide Salerno davidesalerno TRUE Edson Tirelli etirelli FALSE Sponsors< https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#sponsors IBM and Red Hat are the sponsors for the project. Champion:< https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#champion Brian Proffitt Nominated Mentors:< https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#nominated-mentors Brian Proffitt Claus Ibsen Andrea Cosentino Sponsoring Entity:< https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#sponsoring-entity Apache Camel Jason Porter Software Engineer He/Him/His IBM --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org<mailto:general-unsubscr...@incubator.apache.org> For additional commands, e-mail: general-h...@incubator.apache.org<mailto:general-h...@incubator.apache.org>
