I also agree with the proposed changes, they seem sensible and pragmatic +1
Cheers, --- *Chris Sampson* Principal Software Engineer Naimuri On Tue, 12 May 2026, 01:57 Matt Burgess, <[email protected]> wrote: > This sounds reasonable to me. Please carry my +1 through to any vote > > On Wed, May 6, 2026 at 4:52 PM Mark Payne <[email protected]> wrote: > > > Team, > > > > In August of 2024, we introduced the notion of NiFi Improvement Proposals > > (NIPs). The intent here was to > > "consider adopting a more formal process around changes that impact the > > fundamental API contracts that > > NiFi provides.” Largely, this was a formalization of the less formal NiFi > > Feature Proposals that had taken place > > prior. > > > > Since then, we have seen quite a few NIPs land and get approved. I > believe > > this was a step in the right direction > > and has been helpful to ensure that when someone contributes a new > > capability that we will not encounter > > frustrating and awkward scenarios where the community decides to reject a > > proposed feature after significant work > > has been put into developing in. It’s also helped in ensuring that we > > adequately product the API from changes that > > cannot be easily undone later. > > > > On the other hand, it has created significant delays for very minor > > updates to the APIs. For example, we recently > > introduced NiFi Connectors into the API as an experimental feature. There > > have been numerous NIPs related to small > > tweaks to the Connector API such as NIP-28 [1] and NIP-29 [1]. The delays > > come in that we need to create the NIP itself, > > then generally we create a DISCUSS thread. This typically is left open > for > > a few days at least. We then launch a lazy-consensus > > vote, which is open for 3 days. Upon approval of that, we can update the > > API, get the PR merged, and then wait for the next > > minor release of the API, which may take a while. Once that release > > begins, it again must wait for a 3-day voting period. > > Only after all of this has happened can we put up a Pull Request for the > > NiFi feature (as the NiFi codebase will depend on a > > SNAPSHOT version of the API until this point). And of course that must > > then go through the typical process. > > > > While I believe the NIP process is advantageous, I would like to propose > > some updates to the process that we follow that > > would allow “low-risk” changes to move much more quickly by moving to a > > 24-hour voting period and skipping the DISCUSS thread. > > The definition of “low-risk” is, however, subjective. So my proposal does > > not attempt to define what is or is not low-risk but instead > > eave that determination up to the proposer. > > > > My proposal, then, is to update our process as follows: > > > > > > * For any NIP that is introduced, it is up to the person proposing it > > to indicate whether it is a 24-hour or a 72-hour lazy consensus vote. > > * For any 24-hour vote, any PMC member can request that it be changed > > to a 72-hour vote, to allow more time to consider it. Any request to do > so > > immediately changes it to a 72-hour vote. This must be done by replying > to > > the Vote thread and indicating that the vote is being changed to a > 72-hour > > vote. > > * There is no need for a NIP to have a DISCUSS thread, but it is > > strongly encouraged for any proposal that is initiated with a 72-hour > vote. > > * Updates to the API that qualify for a 24-hour lazy consensus vote > > also qualify for being released in a dot-release of the API instead of a > > minor release. > > * Ideally, we should get in the habit of creating dot-releases of the > > API frequently when there are NIP-approved updates pending release. > > * Dot-releases of the API can be a 24-hour voting (not lazy > consensus) > > period, whereas minor or major should retain their 72-hour voting > windows. > > * 24-hour voting periods always exclude the weekend (i.e., if a > > 24-hour vote starts at 10 am on Friday, it goes to 10 am Monday). 72-hour > > voting periods do not have this restriction. > > > > Thanks > > -Mark > > > > [1] https://issues.apache.org/jira/browse/NIP-28 > > [2] https://issues.apache.org/jira/browse/NIP-29 > > > > >
