Skip to Content

Wiki source code of Contributor Processes

Last modified by Robert Schaub on 2025/12/17 18:07
Show last authors
1 = Contributor Processes =
2
3 == 1. Purpose ==
4
5 This page explains the **practical workflows** for contributors in FactHarbor:
6 how changes are proposed, reviewed, approved, and how conflicts or behaviour
7 issues are handled.
8
9 It complements the [[Contributor Models>>FactHarbor.Organisation.Contributor Models]]
10 page, which focuses on **roles and levels of trust**.
11
12 == 2. Contributor Journey (summary) ==
13
14 A typical journey looks like this:
15
16 1. **Visitor** – reads documentation, explores repositories, may open issues.
17 2. **New Contributor** – submits first small contributions (typo fixes, clarifications).
18 3. **Contributor** – contributes regularly and follows project rules.
19 4. **Trusted Contributor** – has a track record of high-quality, constructive work.
20 5. **Reviewer** – reviews and approves changes for correctness and alignment.
21 6. **Moderator** – focuses on behaviour, tone, and conflict moderation.
22 7. **Expert (optional)** – provides domain insight without gaining automatic
23 approval authority.
24
25 Detailed responsibilities are described on the
26 [[Contributor Models>>FactHarbor.Organisation.Contributor Models]] page.
27
28 == 3. Standard Change Process ==
29
30 This process applies to most documentation and code changes.
31
32 === 3.1 Proposal ===
33
34 * A contributor creates a proposal (issue, merge request, or page draft).
35 * The proposal explains **what should change**, **why**, and any known risks.
36
37 === 3.2 Discussion ===
38
39 * Contributors, reviewers, and affected roles discuss the proposal.
40 * Alternatives and open questions are documented in the same place.
41 * The goal is to surface assumptions and potential side effects early.
42
43 === 3.3 Review ===
44
45 * A **Reviewer** checks:
46 * correctness and clarity,
47 * consistency with existing rules and models,
48 * neutrality and evidence practices,
49 * licensing and attribution where relevant.
50 * The Reviewer may ask for changes or clarifications.
51
52 === 3.4 Approval and Implementation ===
53
54 * When the Reviewer is satisfied, the change is approved.
55 * The change is merged or applied to the relevant page / repository.
56 * If the change is sensitive (e.g. governance, licensing, finance),
57 additional approval from the **Organisation Lead** or **Governing Team**
58 may be required.
59
60 === 3.5 Versioning and Communication ===
61
62 * Important changes are recorded in a **changelog** or release note.
63 * If the change affects users or contributors, it should be highlighted in
64 appropriate communication channels.
65
66 == 4. Conflict Resolution Process ==
67
68 Conflicts can arise about content, process, or behaviour.
69 The escalation path should be **predictable and transparent**.
70
71 Typical escalation path:
72
73 1. **Direct conversation** – Contributors first try to resolve the issue directly.
74 2. **Moderator** – If this fails or behaviour becomes problematic, a Moderator
75 helps mediate.
76 3. **Governance Steward** – For persistent conflicts or questions of neutrality.
77 4. **Executive Lead** – For cross-domain or high-impact issues.
78 5. **Governing Team** – For rare, serious, or precedent-setting cases.
79
80 At each step:
81
82 * document the issue briefly (what happened, who is involved, what was tried),
83 * focus on behaviour and process, not on personal attacks,
84 * prefer restorative solutions over punishment where possible.
85
86 == 5. Moderation Process ==
87
88 Moderators focus on **how** people interact, not on whether they are “right”.
89
90 Key tasks:
91
92 * remind participants of communication principles (respect, neutrality, clarity),
93 * de-escalate heated discussions,
94 * intervene when conversations become abusive, discriminatory, or manipulative,
95 * recommend time-outs or thread locks when needed.
96
97 Serious or repeated violations are escalated according to the Conflict
98 Resolution Process above.
99
100 == 6. Onboarding and Support ==
101
102 To make it easier for new contributors:
103
104 * Provide clear “first steps” issues or tasks.
105 * Link to relevant documentation from welcome messages.
106 * Offer short explanations of FactHarbor’s mission, domains, and expectations.
107 * Encourage questions – “unclear” is better than silent misunderstanding.
108
109 Where possible, an **Onboarding Coordinator** or another designated person
110 helps newcomers find suitable tasks and understand the workflows.
111
112 == 7. Relationship to Other Organisation Pages ==
113
114 This page should be read together with:
115
116 * [[Contributor Models>>FactHarbor.Organisation.Contributor Models]] – roles and responsibilities.
117 * [[Open Source Model and Licensing>>FactHarbor.Organisation.Open Source Model and Licensing]] – licensing and governance principles.
118 * [[Decision Processes>>FactHarbor.Organisation.Decision-Processes]] – escalation paths and decision documentation.
119
120 These pages together define **who** is involved, **how** decisions are made,
121 and **which processes** keep collaboration fair and transparent.