-
Notifications
You must be signed in to change notification settings - Fork 0
WORKING_GROUPS.md
Document Type: Community Organization & Working Groups Framework
Project: CeloHT
Status: Active / Evolving
Last Updated: August 2026
Authors: Johnny Dubic & CeloHT Community
CeloHT Working Groups are focused teams that coordinate specific areas of the CeloHT ecosystem.
Working Groups allow contributors to collaborate without requiring every community member to participate in every operational decision.
They are designed to improve:
Coordination
Accountability
Expertise
Execution
Transparency
Community participation
Working Groups exist to transform community priorities into organized work.
A Working Group may:
Research an issue
Develop a program
Maintain documentation
Build software
Coordinate volunteers
Monitor impact
Prepare proposals
Execute approved initiatives
All Working Groups should operate according to:
Transparency
Accountability
Collaboration
Defined responsibilities
Appropriate authority
Security
Respect
Evidence-based decision-making
A typical Working Group may include:
Community
↓
Working Group
↓
Coordinator
↓
Contributors
↓
Deliverables
↓
Public Reporting
The exact structure may vary according to the group's purpose.
CeloHT may establish Working Groups for areas such as:
Education
Technology
Community
Governance
Research
Environment
Communications
Partnerships
Documentation
Security
Impact Measurement
Working Groups may be created, merged, modified, or retired as project needs evolve.
The Education Working Group may coordinate:
Training programs
Educational materials
Web3 education
Financial-literacy initiatives
Workshops
Learning assessments
Educational partnerships
Relevant documentation may include:
PROGRAMS.md
TUTORIALS.md
WEB3_101.md
The Technology Working Group may coordinate:
Software development
Infrastructure
Technical architecture
Integrations
Developer documentation
Testing
Technical improvements
Technical contributions should follow applicable development and security policies.
The Community Working Group may support:
Community engagement
Local initiatives
Events
Volunteer coordination
Community feedback
Participation programs
The Governance Working Group may support:
Governance documentation
Proposal processes
Voting systems
Governance education
Governance analytics
Community governance improvements
It should not exercise authority beyond its delegated mandate.
The Research Working Group may conduct:
Market research
Technology research
Community research
Impact studies
Competitive analysis
Literature reviews
Research should distinguish clearly between:
Verified facts
Estimates
Assumptions
Opinions
The Environmental Working Group may coordinate:
Reforestation
Tree-planting activities
Environmental education
Seedling programs
Monitoring
Environmental partnerships
Relevant documentation:
REFORESTATION.md
The Communications Working Group may support:
Public announcements
Social media
Press materials
Community updates
Educational content
Brand communications
Official statements should follow the project's authorization requirements.
The Partnerships Working Group may identify and coordinate potential collaborations.
Activities may include:
Partner research
Initial outreach
Partnership proposals
Relationship management
Partnership reporting
Material partnerships should follow applicable approval procedures.
The Documentation Working Group may maintain:
Wiki pages
Guides
Technical documentation
Policies
Tutorials
FAQs
Contributor documentation
Documentation should remain consistent with authoritative project decisions.
Where established, the Security Working Group may support:
Security reviews
Vulnerability reporting
Security education
Incident coordination
Access-control reviews
Security documentation
Sensitive vulnerabilities should not be publicly disclosed before appropriate remediation.
The Impact Working Group may measure:
People trained
Training completion
Community participation
Transactions
Program outcomes
Environmental activity
Other relevant indicators
Metrics should have clear definitions and supporting evidence.
A new Working Group should generally have:
Name
Purpose
Scope
Coordinator
Initial members
Responsibilities
Expected deliverables
Reporting method
Each Working Group should maintain a short charter defining:
Mission
Scope
Responsibilities
Authority
Members
Coordinator
Deliverables
Reporting
Review Period
A Working Group Coordinator is responsible for helping the group remain organized.
Responsibilities may include:
Scheduling meetings
Assigning tasks
Tracking deliverables
Removing blockers
Reporting progress
Escalating important issues
The Coordinator is not automatically the owner of all decisions.
Working Group membership may include:
Core contributors
Volunteers
Subject-matter experts
Community representatives
Technical contributors
Partner representatives where appropriate
Membership should be based on the group's needs.
Interested contributors may express interest through the appropriate community channel.
Selection may consider:
Skills
Experience
Availability
Contribution history
Community needs
Members may leave a Working Group.
They should ideally:
Communicate their departure
Transfer active responsibilities
Return or remove project access
Document unfinished work
Working Groups operate within delegated authority.
They should not independently:
Commit unauthorized treasury funds
Change critical governance rules
Alter security controls without authorization
Make legal commitments on behalf of CeloHT
Represent themselves as the entire organization
Working Groups should prefer consensus for routine decisions.
When consensus cannot be reached, the group may use an internal voting process where appropriate.
Major decisions outside the group's mandate should be escalated.
An internal Working Group vote may use:
Simple majority
Consensus
Coordinator decision within delegated authority
Formal escalation
The chosen method should be appropriate to the decision.
Members should disclose material conflicts of interest.
A member may be asked to abstain from decisions where they have a significant personal or financial interest.
Working Groups may meet:
Online
In person
Asynchronously
Meetings should have a clear purpose.
Important decisions should be documented.
Where appropriate, meeting records should include:
Date
Participants
Topics
Decisions
Action items
Responsible contributors
Deadlines
Not every informal conversation requires a formal record.
Tasks should ideally have:
Description
Owner
Priority
Deadline
Status
Related proposal or issue
Possible statuses:
Planned
↓
In Progress
↓
Review
↓
Completed
Every Working Group should produce identifiable outputs.
Examples:
Report
Software
Training
Event
Documentation
Research
Partnership proposal
Environmental activity
Governance recommendation
Working Groups should periodically report:
Completed work
Current work
Upcoming priorities
Blockers
Risks
Resource requirements
Reporting frequency should match the group's activity.
Working Group activities should be transparent when there is no legitimate reason for confidentiality.
Public information may include:
Mission
Members
Objectives
Deliverables
Progress
Decisions
Certain Working Group information may require restricted access.
Examples include:
Security vulnerabilities
Personal data
Confidential negotiations
Private partner information
Credentials
Confidentiality should not be used to conceal ordinary project accountability.
Working Groups with access to project systems should follow least-privilege principles.
Access should be:
Necessary
Limited
Reviewable
Revoked when no longer required
Technical Working Groups should follow:
CONTRIBUTING.mdSECURITY.mdTESTING.mdSMART_CONTRACTS.mdApplicable repository policies
Code should be reviewed before production deployment.
Working Groups may request funding for approved activities.
Requests should explain:
Amount
Purpose
Expected outcome
Timeline
Responsible parties
Reporting requirements
Working Groups should not treat treasury funds as discretionary personal resources.
Working Groups proposing partnerships should provide:
Partner identity
Purpose
Strategic value
Responsibilities
Risks
Expected outcomes
Material agreements should receive appropriate review.
A Working Group developing a new program should define:
Problem
↓
Target Community
↓
Intervention
↓
Resources
↓
Expected Outcome
↓
Measurement
Working Groups should avoid reporting activity as impact without justification.
For example:
"500 people attended"
is not automatically equivalent to:
"500 people improved their financial literacy."
The measurement methodology should be explicit.
Working Group documentation should be:
Clear
Accurate
Version-controlled where practical
Consistent with project terminology
Reviewed when materially changed
Working Groups may collaborate through GitHub repositories, issues, pull requests, and discussions.
Contributions should follow the applicable repository rules.
Volunteers can contribute to Working Groups without necessarily holding governance authority.
Their responsibilities should be clearly defined.
See:
VOLUNTEERS.md
Working Groups should provide appropriate mechanisms for receiving feedback.
Feedback may be collected through:
Community discussions
Surveys
Meetings
GitHub discussions
Program evaluations
A Working Group should escalate an issue when it:
Exceeds its authority
Creates significant financial risk
Creates security risk
Creates legal risk
Requires governance approval
Affects multiple Working Groups
Urgent security or safety issues may require immediate escalation rather than waiting for a normal Working Group meeting.
Emergency actions should be documented afterward.
Performance may be evaluated using:
Deliverables completed
Quality
Timeliness
Community participation
Resource efficiency
Impact
Transparency
Working Groups should periodically review:
Whether the group is still necessary
Whether its mandate remains relevant
Whether responsibilities are clear
Whether membership is appropriate
Whether deliverables are being produced
Two Working Groups may be merged when their responsibilities substantially overlap.
The merged group should receive an updated charter.
A Working Group may be closed when:
Its mission is completed
Its responsibilities become unnecessary
Its work is transferred elsewhere
The project restructures
Important records should be preserved.
Working Groups should have enough autonomy to execute their responsibilities while remaining accountable to the broader CeloHT governance and organizational framework.
Autonomy does not mean unlimited authority.
Working Groups should coordinate when responsibilities overlap.
For example:
Education
↕
Community
↕
Technology
↕
Impact
Cross-functional collaboration should be encouraged where it improves outcomes.
Before beginning major work, Working Groups should check whether:
Another group is already working on the issue.
Existing documentation solves the problem.
A previous proposal already exists.
Existing infrastructure can be reused.
Working Groups should document important lessons learned.
This helps prevent knowledge from becoming dependent on one individual.
When a contributor leaves, the Working Group should be able to continue operating.
Important processes should therefore be documented rather than kept exclusively in private knowledge.
Meaningful Working Group contributions may be recognized through:
Contributor credits
Public acknowledgements
Project profiles
Community recognition
Recognition should reflect actual contribution.
Working Groups should operate honestly and avoid:
Misrepresentation
Hidden conflicts
Unauthorized fundraising
Manipulation
Harassment
Misuse of project resources
False impact claims
Working Groups are part of the broader CeloHT governance structure.
They may recommend actions, execute approved responsibilities, or make delegated operational decisions.
They should not bypass established governance procedures.
The Founder may establish, support, or participate in Working Groups.
However, Working Group authority should remain defined by its documented mandate and applicable governance framework.
External partners may participate in Working Group activities when appropriate.
Participation should not automatically grant governance authority.
Working Groups should periodically ask:
What are we accomplishing?
What is not working?
What evidence do we have?
What should change?
What resources are required?
What should be stopped?
This prevents Working Groups from becoming permanent structures without meaningful output.
A Working Group may maintain:
Area | Information -- | -- Mission | Purpose Coordinator | Responsible person Members | Active contributors Goals | Current objectives Tasks | Active work Deliverables | Completed outputs Risks | Known issues Metrics | Performance indicators Budget | Approved resources Status | Current conditionName:
Technology Working Group
Mission:
Maintain and improve CeloHT's technical infrastructure.
Coordinator:
Designated contributor
Responsibilities:
- Software development
- Testing
- Documentation
- Technical reviews
Authority:
Within approved technical scope.
Deliverables:
- Releases
- Documentation
- Technical improvements
Reporting:
Monthly or as required.
Working Groups should exist to accomplish work, not merely to create organizational titles.
A successful Working Group is one that:
Has a clear mission, defined authority, accountable contributors, measurable deliverables, and visible results.
Document Status: Active / Evolving
Maintained By: CeloHT Community
Founder: Johnny Dubic
Primary Principle: Organized collaboration with clear responsibility, measurable execution, and community accountability
© 2026 CeloHT - Open Source. Global Impact. Licensed under Apache.