Hi Victoria, thank you for an excellent example of a well-crafted cover letter. Also, thank you for your fresh perspective, I believe you raised a valid point when you pointed out that there are better ways to describe Scalar's intention than the term "opinionated". On Wed, 29 Jun 2022, Victoria Dye via GitGitGadget wrote: > A plan for Scalar > ================= > > Given the slightly tweaked "philosophy" above, my ultimate goal for Scalar > is to have it contain only what is too experimental or too large > repo-focused to be a default option or behavior in Git. Over time, some > features may be moved out of Scalar and into Git defaults as they are proven > stable and beneficial to the vast majority of users [4]. > > So what do we need to get there? > > At a high level, the remaining work to "finalize" Scalar (past this RFC) can > be broken into three parts: > > 1. Complete a few more features and subcommands of Scalar (integrate with > the built-in FSMonitor & implement scalar help). > 2. Move stable, general-purpose parts of 'scalar.c' into other Git > builtins/libraries (mainly scalar diagnose, either as part of git > bug-report [5] or a new git built-in). > 3. Move Scalar out of contrib/ and into the "top-level" of Git. Includes > expanded testing, especially performance testing. > > The first makes scalar "feature complete" enough to be valuable to large > repo users (per my entirely subjective assessment, at least). The second > brings it in line with the goal of making Scalar only contain what can't > exist as a default feature of Git. Once those are finished, I think Scalar > will be out of its "work-in-progress" phase and ready to use as a built-in > component of Git (accompanied by sufficient testing, of course). This plan makes a ton of sense to me. Earlier, I tried to skip step 2, but you are absolutely correct that it would benefit the Git project much more if it wasn't skipped. Thank you for working on this! Dscho
