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