Hi Anton! I am not in favor of increasing formalism or swinging too far in either direction; doing everything without IEPs, or relying solely on them, both seem concerning at this stage.
I would suggest keeping the current approach where major changes or features require an IEP, while small or minor ones can simply be discussed on the dev list. Don't you think that by introducing a stricter development process, we might increase development time where it isn't necessary? Regarding your points: 1. You could provide more explanations and examples here. Take `SELECT FOR UPDATE`, for instance, which was introduced recently. As I understand it, since this was a change to the public API, the procedure should have been to create an IEP, go through its full lifecycle, and only then begin implementation? What should be done if problems are found in the current IEP, or something was overlooked, and it needs to be improved, does that also require a new IEP? 2. Who will be responsible for verifying that no backward compatibility cases have been overlooked? What do you mean by "support"? Who will be responsible for the IEPs and their bug fixes? 3. And how does it differ from the current mechanism? 4. Why specifically multiple PRs instead of Jira tickets? Have you seen similar practices in other public projects?
