There are a set of conventions in the world of triple scripts intended to make it more attractive to prospective collaborators to work on projects that adopt triple scripts for project metatooling, in comparison to projects that rely on other traditional build systems and other workflows.
What characterizes a project built upon triple script-backed infrastructure?
First, if it doesn't ship in a single source tree all the dependencies needed to do a full build, the project offers a tool that is straightforward to use that will fetch all externally provided dependencies in a single shot. Whether intended by the authors of the third-party code or not, the collection of all external dependencies can be considered the "SDK" that the program targets, and it is this SDK which is needed to do a full build. Other projects in the world of triple scripts, on the other hand, will provide all dependencies within a single source tree. By closely following this pattern, projects which adopt triple scripts are already able to eliminate much of what comprises implicit step zero unfortunately inherent to most traditional software development. (NB: while this approach is presented as an option, projects are strongly encouraged not to rely on external dependencies that must be fetched from elsewhere. Project maintainers should treat this option as a last resort and instead consider shipping these dependencies in the project's own source tree. Note also that even for projects that do opt for a separate dependency acquisition step, any tool that handles fetching dependencies is technically not a triple script, because triple scripts do not have network access, owing to the self-containedness principle.)
Second, the tools used for building the project are triple scripts embedded directly within the project source tree itself. In traditional workflows, if you were to work on a project that targets, say, .NET, for example, you might declare to downstream participants (in natural language in e.g. a README file) that you and any other project maintainers are using a certain set of tools and targeting a certain framework version, and you expect that downstream participants will go learn about getting and working with those things on their own time. This is the part of implicit step zero that sometimes goes by the description "setting up a development environment". In traditional workflows, a project may or may not explicitly include documentation for getting past this milestone, and what documentation does exist may or may not be up-to-date and sufficient. In the triple scripts ecosystem, we know that any potential collaborator is able to vault this hurdle because the acquisition and build tools are included along with the source code. If the project uses a source code management system such as Git, then copies of the aforementioned tools are checked in to version control, too, so that any collaborator has the tools they need to get the project built and working simply by virtue of having cloned the repository.
It is optional but encouraged in the world of triple scripts that projects include any other tool that guides collaborators towards the most effective means of the contribution process (e.g. preparing patches, submitting them for review, et cetera).
These could be called the ABCs of triple scripts:
- Acquire – fetch all external dependencies that are not shipped directly in the project's own source tree, if any
- Build – produce an executable program (i.e. the form that is capable of doing useful work)
- Customize and contribute/collaborate – make meaningful changes to the program and provide those changes to the wider community
It is recommended the projects follow these ABCs and actually ship these tools as Acquire.app.htm, Build.app.htm, and Collaborate.app.htm (where Build.app.htm is the only constant that is expected to be included in any given project—since some projects will have no third-party dependencies to acquire and others will not have a complex or rigid contribution process).
Furthermore, for projects which are implemented as triple scripts themselves, the intended experience for those hoping to contribute is to be able to take advantage of the property of SDIPD (aka "non-destructive compilation") and make meaningful changes to the program by starting with the triple script "executable" itself as the basis for development. Although this doesn't preclude anyone opting for a more "traditional" workflow that involves cloning the project repository and building from source, note that this MUST come at the discretion of the user—any program for which the "executable" cannot serve as an equivalent to having the source repository that produced it is not a triple script.