115 describes one prerequisite for this to work: A designer or engineer working on a release of a font project will likely (because it's good practice) work on a feature branch that is not master (or, if we'll allow it the, a special gf-releases-upstream branch). In that process, the author will want to test the feature branch against the QA-assembly-line, but without merging into master all the time and without triggering an actual pull request .
Short term
I want to establish a switch, when initiating a new process, between: sandbox and production. That will change:
At the very moment, the deployed version of FBD is by default in the Sandboxed mode, but that means there's no way to make production PRs. Also, #115 blocks the Sandboxes mode to be actually useful for our engineers, who also asked in #114 to be able to play with the dispatcher without the worries of breaking stuff or annoying anyone.
The "feature branch workflow" also suggests, that once an engineer is happy with the branch, the branch will be merged into the master (gf-production) branch and from there the dispatcher can be used in "production" mode to create an actual PR to google/fonts, which will be recognized and assessed by the gf-engineers.
User Stories
@vv-monsalve and @eliheuer are working on different font projects in feature branches. They want to monitor and (re-)assess their efforts repeatedly before merging their feature branches into the production/master branches of their respective projects. Both can be trusted to be granted direct writing access to the "[dashboard SANDBOX Copy]" spreadsheet.
Mid Term
For the short term approach, we still need to give to trusted people access to the "[dashboard SANDBOX Copy]" spreadsheet or just do it via our engineers. But, if anyone is interested in releasing a font via google fonts, access to the QA tools (via the dispatcher) should be easy in sandbox mode. Further, switching the "input" spreadsheet only allows for one sandbox repository+branch per family, where in a distributed workflow many branches may be required to check different repos+branches in sandbox mode. Hence the sandbox mode should allow for easy registration and usage (maybe just per process -> copy the branch github url, maybe save in a personal profile) of a feature branch.
User Stories
a new contributor wants to check a new and unregistered project with our tools, quietly, before requesting the initial on-boarding of the new family
a project is enhanced with many new scripts made by many designers around the world at the same time, each designer wants to check their new, locally different version, against QA before merging (PRing) into the project master/release branch.
Mentioned in #114 and #115.
115 describes one prerequisite for this to work: A designer or engineer working on a release of a font project will likely (because it's good practice) work on a feature branch that is not
master
(or, if we'll allow it the, a special gf-releases-upstream branch). In that process, the author will want to test the feature branch against the QA-assembly-line, but without merging into master all the time and without triggering an actual pull request .Short term
I want to establish a switch, when initiating a new process, between: sandbox and production. That will change:
At the very moment, the deployed version of FBD is by default in the Sandboxed mode, but that means there's no way to make production PRs. Also, #115 blocks the Sandboxes mode to be actually useful for our engineers, who also asked in #114 to be able to play with the dispatcher without the worries of breaking stuff or annoying anyone.
The "feature branch workflow" also suggests, that once an engineer is happy with the branch, the branch will be merged into the
master
(gf-production) branch and from there the dispatcher can be used in "production" mode to create an actual PR to google/fonts, which will be recognized and assessed by the gf-engineers.User Stories
Mid Term
For the short term approach, we still need to give to trusted people access to the "[dashboard SANDBOX Copy]" spreadsheet or just do it via our engineers. But, if anyone is interested in releasing a font via google fonts, access to the QA tools (via the dispatcher) should be easy in sandbox mode. Further, switching the "input" spreadsheet only allows for one sandbox repository+branch per family, where in a distributed workflow many branches may be required to check different repos+branches in sandbox mode. Hence the sandbox mode should allow for easy registration and usage (maybe just per process -> copy the branch github url, maybe save in a personal profile) of a feature branch.
User Stories