Contribution Guide
Thank you for contributing to the Ubujima technology ecosystem.
Ubujima develops technology through a combination of internal development, open-source collaboration, community co-creation, partner projects, and commercial product development.
This guide establishes the general principles contributors should follow when participating in Ubujima projects.
Contribution Principles
We encourage contributors to:
- Build collaboratively
- Communicate clearly
- Respect other contributors
- Prioritize user value
- Protect user privacy and security
- Write maintainable code
- Document important decisions
- Test changes before submission
- Respect project architecture
- Respect intellectual property and licensing requirements
Individual repositories may contain additional project-specific requirements.
Finding Work
Before starting a contribution, review:
- Repository documentation
- Open issues
- Project roadmap
- Existing pull requests
- Technical documentation
- Contribution requirements
When possible, select an existing issue or communicate with the project maintainers before beginning substantial development.
This helps prevent duplicated work and ensures that proposed changes align with the direction of the project.
Issues
Issues should clearly describe the problem, opportunity, or proposed improvement.
A useful issue normally includes:
- A clear title
- Description of the problem
- Expected behavior or outcome
- Relevant technical context
- Screenshots or examples where useful
- Possible implementation considerations
Do not include passwords, API keys, personal data, private credentials, or other sensitive information in public issues.
Branches
Contributors should make changes in a dedicated branch rather than directly on the main branch.
Use descriptive branch names where possible.
Examples:
feature/user-profile
fix/login-validation
docs/api-authentication
refactor/notification-service
Repository-specific conventions take priority where they exist.
Commits
Commit messages should be clear and describe the purpose of the change.
Examples:
Add profile validation
Fix mobile navigation issue
Update developer onboarding documentation
Refactor notification service
Avoid unclear messages such as:
changes
update
stuff
fix
Good commit history makes collaboration and future maintenance easier.
Pull Requests
Most code contributions should be submitted through a pull request.
A pull request should explain:
- What was changed
- Why the change was made
- How the implementation works
- How the change was tested
- Any known limitations
- Related issues
Keep pull requests focused where practical. Very large unrelated changes are harder to review and maintain.
Code Review
Pull requests may require review before they are merged.
Reviewers may evaluate:
- Correctness
- Architecture
- Security
- Performance
- Maintainability
- Testing
- Documentation
- User impact
- Compatibility with existing systems
Requested changes should be addressed before merging unless otherwise agreed with the maintainer.
Testing
Contributors are responsible for testing their changes appropriately.
Depending on the project, this may include:
- Unit tests
- Integration tests
- Manual testing
- UI testing
- API testing
- Regression testing
Do not knowingly submit changes that break existing functionality.
Documentation
Documentation is part of the product.
When a contribution changes behavior, architecture, APIs, setup procedures, or developer workflows, update the relevant documentation as part of the contribution.
Documentation contributions are also welcome independently of code changes.
Security
Never commit sensitive information to a repository.
This includes:
- Passwords
- API keys
- Access tokens
- Private keys
- Database credentials
- Production secrets
- Personal or confidential user information
Use approved environment variables and secret-management mechanisms.
If you discover a security vulnerability, do not publicly expose sensitive exploit details before the issue can be responsibly reviewed and addressed.
Intellectual Property and Licensing
Contributors must only submit work they have the right to contribute.
Do not copy proprietary code, copyrighted material, incompatible open-source code, or other intellectual property into Ubujima projects without appropriate permission and licensing.
Different projects within the Ubujima ecosystem may use different licenses and contribution arrangements.
Always review the repository's license and project-specific requirements before contributing.
Open Source and Private Projects
Not every Ubujima project or repository is necessarily open source.
The ecosystem may include:
- Open-source software
- Proprietary products
- Internal infrastructure
- Community projects
- Research initiatives
- Partner projects
- Commercial development
Access and contribution requirements may therefore differ between projects.
Public open-source contributors do not automatically require access to private repositories or internal systems.
Community Conduct
Contributors should communicate professionally and constructively.
Disagreement about technical approaches is normal. Discussions should focus on ideas, evidence, architecture, implementation, and user outcomes rather than individuals.
Harassment, discrimination, threats, or intentionally disruptive behavior are not acceptable within the contributor community.
Contributor Recognition and Benefits
Ubujima is built around co-creation.
Contributing to the ecosystem can provide opportunities to build real-world experience, strengthen your portfolio, collaborate with other developers and organizations, contribute to meaningful technology projects, and grow into larger technical or leadership responsibilities.
Meaningful contributions may also be recognized through Ubujima's contributor recognition programs.
Ubuntu Points
Ubuntu Points are designed to recognize participation and contribution across the Ubujima ecosystem.
Eligible activities and contributions may earn Ubuntu Points, helping create a visible record of participation, collaboration, and contribution within the community.
The amount and eligibility of points may vary depending on the activity, project, or program.
Ubujima DECA
Certain eligible contributions may also qualify for recognition through Ubujima DECA, Ubujima's contribution-based economic participation program.
DECA is intended to recognize meaningful value created by people contributing to the development and growth of the Ubujima ecosystem.
DECA eligibility, allocation, vesting or earning conditions, conversion or economic rights, and other terms are governed by the applicable DECA program documentation or agreement.
Contributing code or participating in an Ubujima project does not automatically create an entitlement to DECA, equity, compensation, or other financial benefits unless specifically provided under the applicable program.
Growing Through Contribution
As contributors build experience and trust within the ecosystem, opportunities may expand beyond individual issues.
Contributors may have opportunities to:
- Take responsibility for larger development areas
- Become project maintainers
- Lead technical initiatives
- Mentor other contributors
- Collaborate with ecosystem partners
- Participate in paid projects or bounties
- Join future teams or programs
- Receive community recognition
- Qualify for applicable contributor incentive programs
Specific rewards, compensation, DECA allocations, Ubuntu Points, bounties, or other benefits will depend on the relevant project, program, and applicable terms.
Start Contributing
If you are new to the ecosystem, begin with the Developer Onboarding guide.
Then explore the available projects and Opportunities to find an area where you can contribute.