Thanks for helping shape OrgScript.
- Clarity over cleverness
- Explicit semantics over shorthand
- Human readability and machine parseability at the same time
- Small, composable language features
- Strong examples from real operational workflows
Check new ideas against these questions:
- Does this help describe business logic more clearly?
- Can a non-programmer still read it?
- Can a parser interpret it deterministically?
- Does it avoid turning OrgScript into a programming language?
- Can AI reason about it without guessing hidden meaning?
- Improve examples from real domains
- Tighten wording in the specification
- Propose canonical model fields
- Build parser test cases and fixtures
- Contribute localization design notes without changing the English core
Starter issue drafts for public contributors live in docs/issues/contributors/.
When opening GitHub issues, prefer using:
good first issuefor clearly bounded beginner-friendly workhelp wantedfor tasks where outside contributions are actively welcome
orgscript validate- canonical AST node definitions
- JSON export for parsed files
- deterministic formatting rules
- first semantic lint rules
- add or update golden snapshots when valid language behavior changes
- add invalid fixtures for every bug fix in parsing or validation
- keep AST and canonical model snapshots stable and reviewable
Please avoid proposals for:
- loops
- functions
- custom operators
- hidden side effects
- implicit state mutation
- free-form natural language parsing
These may look powerful, but they weaken the core purpose of the language.