Current
proposal workflow
Every proposal type uses the same core governance model, but the route can branch depending on peer decisions, Admin review, forwarded review, EGM decisions, hold states, rejection, and reopening.
Stage 1 — Proposal Created
A member submits a proposal with the required details and at least 2 tagged peer reviewers. Client-side validation runs before the proposal is saved to the server and enters workflow tracking.
- Who acts: The proposer submits the form.
- Who is notified: Submission completes immediately; the notification fan-out begins as the proposal enters peer review.
Stage 2 — Peer Review Opens
The proposal enters peer review. Tagged members are notified by email on first submission, Admin is notified of the new proposal, and the proposer can still edit only until the first peer response is recorded.
- Admin — Receives notification that a new proposal entered review
- Tagged Members — Receive review email links and can respond inside M-Board
- Proposer — Can track status and may still edit only before any peer has responded
- Newly added tagged members on later draft edits — Receive email only if they were added before any peer response
Stage 3 — Peer Decisions
Tagged members review the proposal inside M-Board. At least 2 approvals are required for the proposal to move beyond peer review. Once peer responses begin, normal editing locks unless Admin later reopens the proposal.
| Outcome | What happens |
|---|---|
| ✔ 2+ Approvals | Enough peer approvals are recorded. The proposal advances for Admin handling and the next workflow decision. |
| ✗ Fewer than 2 | If peer review does not pass, the proposal does not advance. A later Admin reopen can reset peer review and allow editing again. |
- Tagged Members 1–3 — Actively reviewing and voting in M-Board dashboard
- Proposer & Admin — Can see each reviewer's status in real time
Stage 4 — Admin Review
Admin reviews the proposal and decides what happens next. Depending on the case, Admin may reject it, reopen it later, forward it for outside review, send it toward EGM, place it on hold, or move it onward in the approval workflow.
- Admin / Board side — Reviews the proposal and chooses the next workflow action
- Proposer — Can follow the current stage from Tracking and My Proposals
- Tagged Members — Continue to see the proposal status, but no longer act unless the workflow returns to peer review
Stage 5 — Reopen or Reject Paths
If Admin rejects a proposal, it stays locked until Admin explicitly reopens it for editing. A reopen-for-edit resets peer approvals to pending, clears earlier peer responses, and sends the proposal back into peer review after the proposer resubmits.
| Decision | What happens |
|---|---|
| Reject or Reopen | If Admin later reopens a rejected proposal for edit, peer review is reset to pending and the proposer edits and resubmits into peer review again. |
| Reject | Proposer is notified. The proposal stays locked until Admin explicitly reopens it for editing. |
- Admin — Controls whether the rejected proposal stays closed or reopens for edit
- Proposer & Tagged Members — Can track the rejection state and any later reopen action
Stage 6 — Forwarded Review
Admin can forward the proposal to relevant Bodies, Departments, or Committees for detailed review. If forwarded reviewers reject it, Admin may allow a special resubmission path where the proposer edits the proposal without clearing prior peer approvals or forwarding history.
| Decision | What happens |
|---|---|
| Forwarded review passes | The proposal can move onward to the next governance step, which may include EGM or final Board handling depending on Admin action. |
| Forwarded review requests resubmission | Admin may allow a special resubmission path. In that path, the proposer edits the proposal, peer approvals stay preserved, and only Admin is notified after resubmission. |
- Relevant Body / Dept / Committee — Receives the forwarded review request and records its decision
- Admin — Monitors forwarded decisions and chooses the next action
- Proposer — Watches body reviews and may be invited to resubmit without resetting peer approvals
Stage 7 — EGM Decision (When Used)
Some proposals are sent to an Extraordinary General Meeting (EGM). In that path, the membership receives the agenda and the proposal moves forward or stops based on the EGM result.
| Decision | What happens |
|---|---|
| General Body Approves | Final BoD approval requested. → Goes to Stage 8. |
| General Body Rejects | If rejected at EGM, the proposal stops there unless Admin later reopens it through the applicable workflow path. |
- All General Body Members — Email: EGM notice & agenda
- Proposer — Email: "🎉 Going to General Body!"
- BoD & Tagged Members — In-app: "EGM — your proposal is live!"
Stage 8 — Final Board Review / Hold
Before implementation, the proposal may return for final Board action. At this stage it can be finally approved, rejected, or placed on hold and later resumed.
| Decision | What happens |
|---|---|
| Approve for Implementation | 🎉 Full approval granted. Implementation mandate sent to responsible Body/Dept. All stakeholders notified. → Goes to Stage 9. |
| Hold Temporarily | Board pauses with a valid reason. Proposal is not rejected — tracked in M-Board and may resume later. |
| Reject (Rare) | Proposer encouraged to significantly revise. Restarts from Stage 3. |
- Board of Directors — Final deliberation in progress
- Proposer — Can follow final review, hold, or resume states from Tracking
- Admin & other stakeholders — Watching, awaiting the final decision
Stage 9 — Implementation & Completion
Once fully approved, the responsible Body, Department, or Committee implements the proposal. Progress and completion are tracked in M-Board as part of the official governance record.
- Proposer, Admin & BoD — Marked Approved in M-Board
- Responsible Body / Dept — Email: "Implementation mandate"
- General Body — In-app: "Proposal approved & live!"
- Tagged Members — Marked Approved: "Your proposal is approved!"