Reduce the cost of change

[rosenhouse]

Currently, there is no automatic way for a change to this repo to propagate to the feedback forms that managers use to collect feedback for their reports.

In other words, if a PR is merged here, that change is only reflected here. In order for that change to affect how feedback is collected, individual managers would need to individually modify the feedback forms for each of their reports. This is a very high cost for change.

This issue is to track efforts related to reducing the cost of change to our feedback forms and heatmaps.

[rosenhouse]

One possible solution is to build out CI/CD to enable a PR-based workflow. For example, imagine things worked like this....

New report

1. a manager gets a new report
2. a manager clones the feedback form and heatmap templates, renames them for their report
3. manager registers the feedback forms for their ICs through some interface: e.g. by listing it at http://bit.ly/feedback-for-all

Change to the areas of contribution

1. an IC opens a PR against this repo which adds a new bullet point to "technical execution" in the P3 level.
2. github triggers a job that automatically updates the feedback form and heatmap spreadsheet for a "test user" via the Forms API in Google Apps Script.
3. the job validates that the update succeeded (no errors in the Forms API).
4. the job runs tests against the updated form, validating that pre-existing data migrated correctly (e.g. the summary page still shows correct totals).
5. the job succeeds, leaving a ✅ in the PR status checks list.
6. humans review the PR, discussing the change, and ultimately approving it.
7. the PR is merged (by human or by bot?)
8. post-merge, a separate job runs the same Apps Script against all registered Feedback Forms.

At the end, everyone's feedback forms now include the new skill in the correct page.

[hiremaga]

A couple of side-effects of reducing the cost of making and propagating changes to consider:

• trends might get harder to see as skill lists and phrasing change over time
• responses might not no longer be valid if the phrasing of a skill changes

Possible solution:

• version skill descriptions, track responses against versioned skill descriptions

[rnandi]

We did it 🎉

[rosenhouse]

Just to elaborate a bit:

• We've now merged several pull-requests that change the contents of this repo, and have cut a new release 0.2.0.
• There is a Google Sheets Add-on that enables migration of a feedback Form and response data from one version of these skills to another.

[rosenhouse]

Currently, our CI system is very rudimentary and doesn't yet provide the level of confidence that is proposed in my earlier comment #11 (comment)