Governance#

Everything below is generated from CONTRIBUTING.md in the repository. It is the same text a contributor meets when they open a pull request, and it is not maintained separately here — a governance page that can quietly drift from the document it describes is worse than no governance page at all.

A company stewarding an open standard it wrote is the normal starting point, not an anomaly. Most standards worth adopting began this way and moved to a foundation later, once enough people depended on them that neutral governance was worth the overhead. That is the path we expect to follow, and a foundation ratifies adoption rather than creating it, so it is not a step we can usefully take today.

Touchstone is stewarded by Grailology, LLC, and it has one maintainer today. That maintainer decides every proposal alone, and works for a company that builds commercial products on Touchstone and is entering the card grading and authentication market. That makes the steward a direct competitor of many of the labs and tools most likely to adopt Touchstone. That is a real conflict of interest, not a disclosure formality. Weigh it before you build on this. It is here because a standard whose steward hides its position in the market is not worth adopting.

Proposals are decided by the Chair, in the pull request, in writing, with reasons stated. When the project has three or more maintainers, decisions move to maintainer consensus, with the Chair holding a tie-break and a veto that must be publicly justified.

There is one maintainer because the project is new and nobody has asked to be another. That is the reason, not a preference. We want more, and we want them from outside Grailology most of all, because a standard maintained only by the company that sells against it is worth less to everyone including us. The path is the ordinary one: contribute, keep contributing, and say you want it. There is no committee to get past.

We won't invite lightly. A maintainer's judgement decides what every implementation of this standard has to do, and a grade computed under it is someone's money. So the bar is sustained work rather than one good pull request, and we would rather leave a seat empty than fill it to look open. If you're serious, so are we.

Until then, be clear about where that leaves you. Maintainers are appointed by the Chair. There is no independence requirement. That three-maintainer threshold counts maintainers, not independent ones, so reaching it does not by itself put anyone from outside Grailology in the room. Once there is more than one, each maintainer is listed with their affiliation, so you can check that rather than infer it from a count.

We intend to rotate the Chair rather than hold it indefinitely. We are not putting a date on that, because a rotation among one person is theatre and the prerequisite is a standard enough people rely on that the seat is worth having. That is the work. Help us do it.

This document is amended by the process it describes, with one exception. The licensing commitment above may be broadened but never narrowed, and this process cannot reach it.

Proposing a change#

Typos, a broken link, tooling, a number the vectors already contradict. Just open a pull request.

Anything that changes what a conforming implementation must do goes through a TIP, a Touchstone Improvement Proposal:

1. Open a pull request that adds one file to proposals/.
2. Once the pull request has a number, rename the file to match it: proposals/0042-binding-region-tiebreak.md.
3. Write these five sections, in this order:
   • Motivation - what is wrong today, with a card that shows it.
   • Specification - the normative change, precise enough to implement from without reading the discussion.
   • Rationale and Alternatives - why this shape, and what you rejected.
   • Backward Compatibility - which previously valid inputs score differently, and what implementers have to do about it.
   • Reference Implementation - the change to scoring.mjs and the rubric data.

No proposal reaches final without both a reference implementation and a conformance vector: at least one vector that tells the new behaviour apart from the old. Agreement in the thread is not the bar. Running code and a vector that pins it are.

Sign off on your commits#

Every commit needs a Signed-off-by: line. Git will add one for you:

git commit -s -m "your message"
        

If you forget, git commit --amend -s and force-push the branch. Commits without a sign-off can't be merged.

The sign-off is the Developer Certificate of Origin, version 1.1: a short statement that you wrote the change, or otherwise have the right to submit it under this project's licence. Not a copyright assignment, not a CLA. You keep your copyright.

We use a DCO rather than a contributor licence agreement on purpose. It buys you three things. We acquire no rights in your contribution that you and every third party do not equally hold. Nothing we have already published can be taken back. Any fork starts on exactly the footing we stand on.

It does not, by itself, guarantee that this project's licence can never change. We are not going to claim that it does. What is promised, and what binds, is in the licensing commitment below.