Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
120 lines (83 loc) · 4.89 KB

CONTRIBUTING.md

File metadata and controls

120 lines (83 loc) · 4.89 KB

Contributing to Foblex Flow

👋 Welcome, and thank you for your interest in contributing to Foblex Flow!
Your support helps the project grow and evolve — whether through code, feedback, or ideas.

🔍 How You Can Help

We welcome contributions of all kinds, including:

  • Bug Reports – Found something broken? Check issues and discussions first, then open a new issue.
  • Answering Questions – Help others by responding in GitHub Discussions.
  • Creating Tutorials & Content – Made a video, article, or demo? Share it with us — we’ll help spread the word!
  • Feature Suggestions – Got an idea? Let’s discuss it in the New Features section.

Non-code contributions are just as important as code — and often even more impactful.

💡 Suggesting Enhancements

If you want to suggest or implement a new feature:

  1. Start a discussion – Post your idea in Discussions, usually in Feature Request for new capabilities or Q&A for implementation guidance.
  2. Describe the problem first – Explain the blocked workflow or missing capability before proposing implementation details.
  3. Get feedback – Core team and community members may suggest changes, alternatives, or existing examples that already solve the use case.
  4. Open or link an issue – Once scope is clear, move the work into a focused GitHub issue with acceptance criteria.
  5. Coordinate efforts – To avoid duplicated work, we recommend syncing before sending a PR.

We value your time and want to make sure efforts align with the project's vision.

🧾 Writing Good Issues

We use a few simple rules to keep issues clear and actionable:

  • One issue = one user-facing goal. Avoid combining unrelated fixes, refactors, and docs work in the same issue.
  • Write titles for users, not internals. Prefer "[Feature]: enable wheel zoom during active drag-and-drop interactions" over internal implementation titles like "refactor drag handlers".
  • Describe the problem before the solution. Explain what is blocked, slow, confusing, or inconsistent.
  • Add acceptance criteria. A short checklist makes scope and completion much easier to review.
  • Mark public API changes clearly. If imports, names, inputs, or outputs change, call that out explicitly and include migration notes when relevant.

Recommended issue structure:

  • Feature request
    • Describe the Feature
    • What problem does it solve?
    • Scope
    • Acceptance Criteria
    • Alternatives
  • Bug report
    • Steps to Reproduce
    • Expected Behavior
    • Actual Behavior
    • Acceptance Criteria
  • Help request
    • What are you trying to achieve?
    • What have you tried so far?
    • Relevant example or documentation page
    • Additional context

Recommended labeling:

  • Use one type label: bug, feature request, help, or documentation
  • Add one or two area labels such as area:zoom, area:drag-and-drop, area:connections, or area:external-item
  • Add optional support labels only when needed, for example performance, breaking change, tests, or release

Recommended discussion usage:

  • Use Feature Request for new capabilities and API ideas
  • Use Q&A for usage questions, architecture guidance, and integration help
  • Use Show and tell for demos, experiments, and community showcases
  • Keep discussions broad and exploratory; move implementation-ready work into issues

📦 Pull Requests

Want to improve the library? Fantastic!

Before submitting a PR:

  • Make sure your code follows our style and naming conventions.
  • Keep your commits clean and meaningful.
  • Link the relevant issue or discussion.
  • Describe the user-facing outcome first, then the implementation details.
  • Call out any public API changes explicitly.
  • Update docs, examples, changelog, and migration notes when they are affected.

We review all contributions, but priority is given to bug fixes, performance improvements, and well-scoped features.

Recommended PR structure:

  • Summary – What changed for users
  • Related Issue – What this PR closes or follows
  • Problem – Why the change was needed
  • Scope – Which areas were touched
  • Public API Impact – Whether the library contract changed
  • Documentation and Examples – What was updated
  • Testing – How the change was verified

📫 Contact

If you're unsure where to start or have a bigger idea to discuss privately:
📧 Email us at support@foblex.com

📜 Code of Conduct

Please be kind and respectful in all interactions.
See our Code of Conduct for more.

Thank you for being a part of Foblex Flow!