GitHub Discussions
Open RFCs, language-port questions and core-spec debates live here. Every change starts as an issue.
github.com/testml-lang/testmlCOMMUNITYtestml-lang
Built in the open. Shipped by polyglot teams.
TestML is an open-source project. The spec, the runtimes, and the docs all live on GitHub. People who write tests for a living shape what lands next. No vendor. No quota. No closed fork.
02/ channels
Where the work actually happens.
Four open spaces. Each one has a clear job. No private slack. No paid forum. Pick the channel that fits the task and post.
Spec Working Group
A small public group reviews syntax changes. Notes are posted. Pull requests stay open for two weeks.
spec.testml.org/wgMailing List
Low-traffic email thread for release notes and breaking-change windows. One digest per month.
lists.testml.org/announceOffice Hours
Maintainers host a public call every other Thursday. Bring a snippet. Stay for the review.
calendar / iCal feed03/ runtimes
Language ports we maintain.
One spec. Many runtimes. Every port runs the same test suite. A change passes only when all stable runtimes go green.
LanguageStatusNote
PythonstableReference runtime. pip install testml.
JavaScriptstablenpm i testml. Node 18+ and modern browsers.
Rubystablegem install testml. Bundler-friendly.
PerlstableFirst port. Still tracks every spec bump.
JavabetaMaven central. Awaiting JDK 21 long-tail tests.
GodraftCommunity fork in review. Looking for a co-maintainer.
04/ contribute
How a patch lands, end to end.
Most first contributions take an hour. The process is short on purpose. You can ship a fix before lunch.
Step 1
Read the spec
Skim the YAML-like grammar and run a sample suite. You get the feel in twenty minutes.
Step 2
Pick a good-first-issue
Tagged tickets cover doc fixes, fixture loaders and CLI polish. No port-language needed.
Step 3
Open a draft PR early
Talk it out in the diff. Maintainers reply within two days. Tests run on every push.
Step 4
Ship the change
Squash, merge, and the next release notes credit your handle. The cycle takes one week.
05/ governance
Four rules the community runs on.
These show up in every review. They keep TestML small, portable, and free. Read them once. They stay short.
Spec first, code second
Every runtime obeys the same grammar. We change the spec in the open before any port lands.
No vendor lock-in
TestML is MIT. No tier, no quota, no cloud account. You own your suite. You own your data.
Polyglot by default
Tests are portable across Python, JavaScript, Ruby, Perl, and Java. New runtimes follow the same gate.
Kind review, sharp standards
We are blunt about code and warm about people. Read the code of conduct. It is short and real.
06/ mission
We build TestML so that a test written once stays useful for ten years. Across every runtime your team picks up next.
— TestML maintainers · MIT · since 200907/ faq
Common questions before you join.
Short answers from the maintainers. If your question is missing, post it in GitHub Discussions and we will add it here.
Do I need to know every TestML runtime to contribute?
No. Most patches touch the spec, the docs, or one runtime. The core team handles cross-port checks for you.
How are decisions made?
Through public RFCs on GitHub. Each RFC names two reviewers. After two weeks, a maintainer merges or closes it.
Is there commercial backing?
No paid tier. No closed fork. Some contributors work at companies that use TestML in CI, and they share fixes upstream.
Where do I report a security bug?
Mail contact@testml.org with details. We confirm within two working days. Public disclosure follows a fix.
08/ join
Ship your first patch this week. We will review it.
Pick a good-first-issue. Open a draft pull request. Maintainers reply within two working days. Real reviews, kind tone.