Hey there! We're genuinely excited you're here.
Whether you're fixing your first bug, adding a game-changing feature, or just curious about how things work—you're exactly why we open-sourced this project. We've been where you are: staring at a new codebase, wondering if your contribution will be good enough, hoping you don't break anything.
Spoiler alert: You're going to do great. And we're here to help you every step of the way.
Every contribution, no matter how small, makes OCTALUME better for everyone. We mean this.
# Clone your fork
git clone https://github.com/YOUR_USERNAME/OCTALUME.git
cd OCTALUME
# Install dependencies
cd .claude/mcp-server
npm install
# Start development
npm run dev📖 New to Git or GitHub? We got you.
Git is a version control system—it's like a time machine for your code. You can save snapshots, experiment safely, and collaborate with others.
GitHub is where the code lives online. Think of it as a workshop where everyone can contribute.
Basic workflow:
- Fork = Make your own copy of the workshop
- Clone = Download your copy to your computer
- Branch = Create a separate workspace to experiment
- Commit = Save your changes
- Push = Upload your changes back to GitHub
- Pull Request = Ask us to add your changes to the main project
Confused? That's completely normal! Open a "question" issue and we'll walk you through it.
You're basically a hero right now. Bugs are sneaky, and finding them helps everyone.
Before you report:
- Search existing issues—someone else might have found it too
- Check if it's already fixed in the latest version
When you report: Use our bug report template (we made it to help us help you faster). Include:
- What happened (steps to reproduce)
- What you expected to happen
- What actually happened (screenshots are gold!)
- Your setup (OS, Node.js version—these things matter)
Real talk: The more detail you give, the faster we can fix it. But even a basic report like "It crashes when I click save" helps—we'll ask questions if we need more info.
We LOVE feature ideas. Seriously. Some of our best features came from community suggestions.
Before you suggest:
- Search existing feature requests
- Check if it fits the framework's vision (ask us if you're unsure!)
When you suggest: Use the feature request template. Tell us:
- What problem would this solve?
- Who would benefit?
- How would you envision it working?
What makes a good feature request?
Great feature requests answer: "Why does this matter?"
Example:
- "Add dark mode"
- "Add dark mode because I work late at night and the bright interface causes eye strain. It would improve comfort for night-shift developers and anyone working in low-light environments."
See the difference? The second one helps us understand the real-world impact.
This is where the magic happens. Let's make something awesome together.
The workflow:
# 1. Create a feature branch (your safe workspace)
git checkout -b feature/your-feature
# 2. Make your changes
# ... code, code, code ...
# 3. Test your changes
npm test
npm run lint
# 4. Commit with a clear message
git commit -m "feat: add your feature"
# 5. Push to your fork
git push origin feature/your-feature
# 6. Open a Pull Request (celebrate time!)Why branches? They keep the main code stable while you experiment. If something goes wrong, no problem—just delete the branch and start fresh. It's like having a sandbox.
Here's the thing about code style: It's not about being picky. It's about making the codebase readable for everyone—including future you.
Our guidelines:
- Follow the existing style (consistency is your friend)
- Use clear, descriptive names (
calculateUserAgenotcalc) - Add comments for complex logic (explain why, not what)
- Update documentation (your contribution should help the next person)
- Keep commits focused (one thing per commit = easier to review)
Deep dive: Writing great commit messages
A good commit message tells a story:
** Bad:** "fixed stuff"
** Good:** "fix: resolve memory leak in user authentication (P5-CODE-001)
- Close connection pool after authentication
- Add timeout to prevent hanging connections
- Add unit tests for connection management
- Add integration tests for auth flow
Artifacts: P5-CODE-001, P5-TEST-001 Feature: F-001 Status: passing"
Why it matters:
- Six months from now, you'll know WHY you made the change
- Reviewers understand the full context
- Git history becomes searchable and useful
Commit message format:
<type>: <description>
[optional body - what you changed and why]
[optional footer - artifacts, references]
Artifacts: P{N}-{SECTION}-{###}
Feature: F-{XXX}
Status: passing
Types:
feat: New featurefix: Bug fixdocs: Documentation changesstyle: Code formatting (doesn't change logic)refactor: Code restructuring (same behavior, cleaner code)test: Adding or updating testschore: Maintenance tasks (dependencies, configs)
Confession: Even experienced developers write buggy code. That's why tests exist—they catch mistakes before users do.
Before submitting:
# Run all tests
npm test
# Run linting (catches style issues)
npm run lintIf tests fail: Don't panic! Read the error message carefully. Still stuck? Ask us—that's what we're here for.
Why tests matter (a cautionary tale)
True story: A contributor once fixed a bug but broke three other things. Without tests, we wouldn't know until users reported issues. With tests, we caught it immediately.
Tests are your safety net. They give you confidence to make changes without breaking things. They're like a robot reviewer that checks your work instantly.
Embrace tests. They'll save you more than once.
You've opened a Pull Request—now what?
- Automated checks run (tests, linting, etc.)
- We review your code (usually within 24-48 hours)
- We might ask for changes (not because it's bad, but to make it even better)
- We merge it! (celebration time )
During review:
- We'll explain why we request changes
- We'll teach you something new if we can
- We'll be respectful and constructive
- We'll celebrate your contribution
Feedback culture: We give feedback because we care about quality and your growth. It's not criticism—it's collaboration.
Please reach out. Seriously.
- Open an issue with the "question" label
- Email us: [email protected]
- Website: https://www.harery.com/
There are no stupid questions. Every expert was once a beginner. If you're wondering about something, chances are someone else is too.
We pledge to:
Treat every contribution with respect and appreciation
Respond to every PR and issue (even if it takes a few days)
Explain our feedback clearly and constructively
Help you learn and grow as a developer
Celebrate your contributions, big or small
Create a welcoming, inclusive community
In return, we ask you to:
Be patient (we're volunteers with day jobs too)
Be open to feedback (we're all learning together)
Follow these guidelines (they help everyone)
Help other contributors (pay it forward!)
Contributing to open source is more than code—it's community.
You're now part of a global network of developers, designers, testers, and users working together to build something amazing. Your name will appear in our contributors list. Your code will run on systems worldwide. Your ideas will shape the framework's future.
That's pretty incredible, don't you think?
🐛 Bug Report → Use bug template → Include details → Wait for response
Feature Idea → Use feature template → Explain the "why" → Discuss with team
Code Change → Branch → Test → Commit → Push → Open PR → Celebrate
❓ Question → Open issue with "question" label → We'll help!
Thank you.
Thank you for your time, your skills, and your willingness to contribute. Thank you for making OCTALUME better. Thank you for being part of this community.
Now let's build something amazing together.
Need immediate help? Email [email protected]
Want to learn more? Check out our documentation and join the conversation!
P.S. We meant it—you're going to do great.
Version 1.0.0 | OCTALUME Enterprise Lifecycle Framework