Hey guys, Here is the STIP PR[1], please leave a message if you have any suggestions. Any suggestion will be appreciated. Thank you!
1. https://github.com/apache/seatunnel-website/pull/446 Best Regards, David Linkedin: https://www.linkedin.com/in/davidzollo On Thu, Apr 9, 2026 at 3:34 PM Doyeon Kim <[email protected]> wrote: > > +1, good proposal. > > On Thu, Apr 9, 2026 at 2:39 PM David Zollo <[email protected]> wrote: > > > Hi SeaTunnel Community, > > > > I would like to propose that we formally adopt STIP (SeaTunnel > > Improvement Proposal) as the standard process for proposing > > significant new features or architectural changes in Apache SeaTunnel. > > > > Looking back at our GitHub issue history, the community has already > > created 22 design-level proposals tracked with the `design` label, > > which have been numbered starts from STIP-1: > > > > - STIP-1: [#1608] Decoupling connectors from compute engines > > - STIP-2: [#1947] Add Server for SeaTunnel > > - STIP-3: [#2210] ST new engine server design > > - STIP-4: [#2261] Generate LogicalPlan from JobConfig file > > - STIP-5: [#2272] ST-Engine Design And Task Tracking > > - STIP-6: [#2274] The design of Checkpoint > > - STIP-7: [#2279] TaskExecutionService and Task related design > > - STIP-8: [#2333] Design of Job Submit > > - STIP-9: [#2339] Design of TaskGroup Scheduler > > - STIP-10: [#2398] Job History Storage Design > > - STIP-11: [#2430] How to deal with network partitions > > - STIP-12: [#3175] CDC Connector Design > > ... > > > > These proposals shaped the core architecture of our project. However, > > they were created in an ad-hoc manner. As the project matures, it is > > time to make this process official and consistent. > > > > Going forward, I propose the following: > > > > When contributor wants to propose a significant new feature or design > > change, please open a GitHub Issue in the apache/seatunnel repository > > and prefix the title with `[STIP-N]`, where N is the next sequential > > number (the next one is STIP-23). The proposal should include the > > motivation, goals, a design overview, and any alternatives considered. > > Once there is rough consensus from the community, implementation can > > proceed via normal PRs referencing the STIP issue. The STIP is closed > > when the feature is fully implemented or explicitly withdrawn. > > > > This process gives the community visibility into what significant work > > is being planned, provides a historical record of design decisions, > > and makes it easier for new contributors to understand the direction > > of the project. It is also fully aligned with the Apache Way of open > > and transparent community-driven development. > > > > I will follow up with a documentation PR to add a `STIP.md` guide to > > the website. > > > > > > Best Regards, > > David > > LinkedIn: https://www.linkedin.com/in/davidzollo > >
