With Bug 1286075, many tasks have a `run-on-projects` magic, which in cases where its NOT run on try by default, it omits listing `try` This has caused a few concerns/pieces-of-confusion during review phases on the various patches there. With IRC chat with :dustin, we came up with a rough plan for improving cognition on these definitions: ```(yml) [partially pseudo-code] foo: try-style: explicit-only run-on-projects: all bar: try-style: runs-when: <ref: build-linux64> run-on-projects: [release, try] drunk: run-on-projects: try # Optional: try-style: all sanity: run-on-projects: release, inbound # try-style here could be fatal, since not run on try ``` where foo is only run on try if specified, bar is run when specified or when build-linux64 triggers (*and* if file restriction is present, when those files are touched) drunk runs on -p all, and sanity never runs on try. :dustin also suggested alternative format: run-on-projects: integration try: explicit === This proposal includes runs-when: which can be a means to move the RIDEALONG_BUILDS logic closer to the actual task definition, but is not strictly required for the reasoning behind suggesting this improvement.

As we get away from try-option-syntax, I think this is less critical.