Community Review Process

Status: proposed direction. Viathorne does not yet have a formal community review programme, reviewer group, or community endorsement. This page describes what a responsible future process should consider and requires review before adoption.

The Community Review Process describes how ViaSign should eventually involve feedback led by Deaf community members, review notes, corrections, and ongoing improvement.

This proposed process exists because sign language accessibility should not be built only from technical assumptions.

It should be shaped with the people who use, understand, teach, and live with signed languages.

For ViaSign, community review is not a final checkbox.

It belongs in the foundation.

Why Community Review Matters

AI systems can produce output that looks correct but still feels wrong.

For signed languages, this risk is even higher because meaning can depend on grammar, space, movement, timing, facial expression, body posture, cultural context, and natural signing use.

A system may generate something that looks like signing, but does not fully carry the intended meaning.

A sentence may be technically structured, but still feel unnatural.

A motion may look smooth, but still need correction.

A sign choice may be understandable in one context, but not appropriate in another.

Community review helps reduce these risks.

It keeps the system grounded in real language use.

Review Is Part of Building

Review should not happen only after everything is finished.

For ViaSign, review should happen throughout the process:

1. During grammar exploration
2. During parser testing
3. During motion planning
4. During sample output review
5. During documentation updates
6. During future avatar or signing output testing

This helps mistakes become learning points instead of hidden failures.

A review-first process makes the work safer, clearer, and easier to improve.

Who May Be Involved

Community review may involve different kinds of contributors.

This may include:

• Deaf signers
• Singapore Sign Language users
• Deaf teachers
• interpreters
• accessibility practitioners
• language learners
• community reviewers
• technical contributors working with feedback from Deaf reviewers

Different people may notice different things.

A Deaf signer may notice naturalness.

A teacher may notice whether an explanation is clear.

An interpreter may notice meaning, context, or phrasing.

A learner may notice whether the system is understandable.

A developer may notice where the system needs better structure.

The goal is not to make one person carry the whole responsibility.

The goal is to create a process where feedback can be collected, respected, and acted on.

What Review May Check

Community review may look at several parts of the system.

Grammar

Reviewers may check whether the sentence structure makes sense for signed language use.

This may include:

• question structure
• negation
• time markers
• topic-comment structure
• reference setup
• location references
• completion markers
• rhetorical question patterns

Naturalness

Reviewers may check whether the output feels natural.

This may include:

• whether the signing order feels awkward
• whether the expression feels incomplete
• whether the phrasing feels too English-like
• whether the meaning is understandable
• whether the output would make sense to a signer

Motion

Reviewers may check whether movement needs correction.

This may include:

• movement path
• direction
• speed
• hold
• transition
• signing space
• hand role
• placeholder movement

Non-Manual Signals

Reviewers may check whether meaning depends on signals outside the hands.

This may include:

• facial expression
• eyebrow movement
• head movement
• gaze
• body shift
• timing
• mouth pattern placeholders

Cultural Context

Reviewers may check whether the output respects community usage.

This may include:

• whether the sign choice is appropriate
• whether the explanation is respectful
• whether the system overclaims
• whether something needs cultural or community guidance

Feedback Format

To make review easier, feedback should be structured.

A review note may include:

• the sentence being reviewed
• the generated grammar output
• the motion or signing output, if available
• what feels correct
• what feels wrong
• what needs clarification
• suggested correction
• reviewer notes
• whether more review is needed

This helps feedback become useful for both documentation and engineering.

Example Review Note

A simple review note may look like this:

Natural-English input:
Where is your school?

Prototype status:
Surface analysis only.
No SgSL sequence generated.

Review note:
SgSL grammar and sign order are
outside the current system's
authority. Non-manual signals also
require qualified review.

Suggested update:
Keep the output blocked:
review_required=true
motion_ready=false

Status:
Blocked before sign or
motion output.

The exact format can change over time.

The important part is that feedback should be easy to understand, easy to trace, and easy to act on.

From Feedback to System Updates

Feedback should not disappear after review.

It should lead to updates.

A possible process is:

1. Collect feedback
2. Identify the issue
3. Classify the issue
4. Update documentation or rules
5. Update parser, motion, or review flags if needed
6. Test again
7. Record the change
8. Continue review

This keeps the system auditable.

It also helps explain why the system changes over time.

Review Status

Each reviewed item may have a status.

Examples include:

• draft
• needs_review
• reviewed
• needs_correction
• accepted_for_now
• community_review_needed
• not_ready_for_motion
• ready_for_motion_testing

These status labels are not final.

They are examples of how ViaSign may track review progress.

Respecting Contributors

Community review should be respectful.

Feedback takes time, attention, and lived knowledge.

Contributors should not be treated as free validation tools.

They should be treated as people whose knowledge matters.

This means review sessions should be clear, voluntary, and respectful of time and energy.

Where possible, structured or detailed review work should be appreciated and compensated.

Even when compensation is not immediately possible, the process should be honest about expectations and limitations.

Transparency

ViaSign should stay transparent about what has been reviewed and what has not.

A system should not present experimental output as final.

It should not hide uncertainty.

It should not imply that generated signing is correct simply because it looks polished.

Transparency helps protect users, reviewers, and the language itself.

Guiding Principle

Community review is not an obstacle to building ViaSign.

Community review is how ViaSign becomes better.

The goal is not to build something alone and ask for approval at the end.

The goal is to build carefully, listen early, correct often, and keep the work accountable.

For ViaSign, review is part of the system.

Not after the work.

Inside the work.