Contributor Processes

Last modified by Robert Schaub on 2025/12/16 21:39

Contributor Processes

1. Purpose

This page explains the practical workflows for contributors in FactHarbor:
how changes are proposed, reviewed, approved, and how conflicts or behaviour
issues are handled.

It complements the Contributor Models
page, which focuses on roles and levels of trust.

2. Contributor Journey (summary)

A typical journey looks like this:

  1. Visitor – reads documentation, explores repositories, may open issues.
    2. New Contributor – submits first small contributions (typo fixes, clarifications).
    3. Contributor – contributes regularly and follows project rules.
    4. Trusted Contributor – has a track record of high-quality, constructive work.
    5. Reviewer – reviews and approves changes for correctness and alignment.
    6. Moderator – focuses on behaviour, tone, and conflict moderation.
    7. Expert (optional) – provides domain insight without gaining automatic
     approval authority.

Detailed responsibilities are described on the
Contributor Models page.

3. Standard Change Process

This process applies to most documentation and code changes.

3.1 Proposal

  • A contributor creates a proposal (issue, merge request, or page draft).
  • The proposal explains what should change, why, and any known risks.

3.2 Discussion

  • Contributors, reviewers, and affected roles discuss the proposal.
  • Alternatives and open questions are documented in the same place.
  • The goal is to surface assumptions and potential side effects early.

3.3 Review

  • A Reviewer checks:
  • correctness and clarity,
  • consistency with existing rules and models,
  • neutrality and evidence practices,
  • licensing and attribution where relevant.
  • The Reviewer may ask for changes or clarifications.

3.4 Approval and Implementation

  • When the Reviewer is satisfied, the change is approved.
  • The change is merged or applied to the relevant page / repository.
  • If the change is sensitive (e.g. governance, licensing, finance),
     additional approval from the Organisation Lead or Governing Team
     may be required.

3.5 Versioning and Communication

  • Important changes are recorded in a changelog or release note.
  • If the change affects users or contributors, it should be highlighted in
     appropriate communication channels.

4. Conflict Resolution Process

Conflicts can arise about content, process, or behaviour.
The escalation path should be predictable and transparent.

Typical escalation path:

  1. Direct conversation – Contributors first try to resolve the issue directly.
    2. Moderator – If this fails or behaviour becomes problematic, a Moderator
     helps mediate.
    3. Governance Steward – For persistent conflicts or questions of neutrality.
    4. Executive Lead – For cross-domain or high-impact issues.
    5. Governing Team – For rare, serious, or precedent-setting cases.

At each step:

  • document the issue briefly (what happened, who is involved, what was tried),
  • focus on behaviour and process, not on personal attacks,
  • prefer restorative solutions over punishment where possible.

5. Moderation Process

Moderators focus on how people interact, not on whether they are “right”.

Key tasks:

  • remind participants of communication principles (respect, neutrality, clarity),
  • de-escalate heated discussions,
  • intervene when conversations become abusive, discriminatory, or manipulative,
  • recommend time-outs or thread locks when needed.

Serious or repeated violations are escalated according to the Conflict
Resolution Process above.

6. Onboarding and Support

To make it easier for new contributors:

  • Provide clear “first steps” issues or tasks.
  • Link to relevant documentation from welcome messages.
  • Offer short explanations of FactHarbor’s mission, domains, and expectations.
  • Encourage questions – “unclear” is better than silent misunderstanding.

Where possible, an Onboarding Coordinator or another designated person
helps newcomers find suitable tasks and understand the workflows.

7. Relationship to Other Organisation Pages

This page should be read together with:

These pages together define who is involved, how decisions are made,
and which processes keep collaboration fair and transparent.