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
