<div dir="ltr"><div><div><div><div><div><div>I'd like to float the idea of a soft moratorium on big architectural changes in the notebook between 4.0 and 5.0. That is, as 4.0 will mostly be 3.x's features on a new foundation, 5.0 would be mostly the 4.0's foundations with added & polished features.<br><br></div>With 4.0, we'll have made two consecutive major releases where the headline changes are architectural: the kernelspec machinery and changes for language agnosticity in 3.0, and the Big Split in 4.0. We've done all of this for good reasons, but I worry that we're becoming captivated by the endless programmer dream of creating the perfect framework to solve all our problems.<br><br>One of the principles to which we attribute the success of the project so far is that we solve the problems in front of us and restructure when we need to, rather than rushing into building grand architecture. I think that we need a cycle to digest the architectural changes we've recently made before we dive into another round. In particular, the talk of refactoring all our frontend machinery concerns me. I don't want to stop us from planning this, but I think it would be a mistake to try to do it for 5.0.<br><br></div>There are a lot of important features that we have been saying for some time we will work on - like multi cell selection, find & replace across the notebook, improved tab completion, and an HTML console interface. We've deferred these tasks while we worked on the architecture, and it's starting to be embarrassing that the interface is not moving forwards quicker. There would also be less impetus for people to turn to competing projects if we sanded some of the rough edges off the notebook interface.<br><br></div>On that note, I'd like us to try doing 'user Fridays', where we pretend that we can't change the Jupyter/IPython code, and work on making interesting notebooks, extensions, and other parts of the ecosystem. Every time I work on such things, it highlights problems I wasn't aware of, or rough edges I hadn't fully appreciated. Having a semi-official mechanism to encourage us to do this in regular small chunks would be valuable in keeping us focussed on users rather than just architecture.<br><br></div>The moratorium I propose would be left to our judgement to implement - it's a principle rather than a rule. I'd make an exception for the conversion to Typescript, because Matthias has already spent significant time on that, and I know he's champing at the bit to finish it. Widgets would be exempt, because we've made it very clear that they're liable to change significantly, and they shouldn't much affect development of the notebook itself.<br><br></div>Thanks,<br></div>Thomas<br></div>