Problem: The JupyterLab tech stack and build/CI systems are highly complex and under-documented in ways that can hurt new developer/contributor experiences.
Solution: We want to begin addressing these problems by building a prototype workflow using a concrete area of JupyterLab as a testcase: the build system.
Concrete improvements to the docs
Suggestions (to take inspiration from)
Checklist for PRs to ask if build system was modified
Well documented CI checks that look for changes (using a diff tool) to build system files to make sure that changes are properly documented and that the benefits/motivations are explained
Provide .diff output as an artifact on the CI run summary
notebook that produces the diff and explains what it is, and all the context surrounding this process and the managed complexity program.
This was a confusing behavior of the build system that was pointed out in the JupyterLab meeting, which can be fixed as noted by @krassowski.
Use epics or milestones for complexity management, and link them to releases.
This issue is a good testbed for docs working group work processes
related to developer experience initiative in issue #24
can also convene moot(s) for this as discussed in guide
Problem: The JupyterLab tech stack and build/CI systems are highly complex and under-documented in ways that can hurt new developer/contributor experiences.
Solution: We want to begin addressing these problems by building a prototype workflow using a concrete area of JupyterLab as a testcase: the build system.
.diffoutput as an artifact on the CI run summaryThis issue is a good testbed for docs working group work processes