🤝 Contributing to FKvim

Thank you for your interest in contributing to FKvim – your time and effort mean a lot to us! 💜 Whether you're reporting a bug, suggesting an enhancement, or writing your first pull request – you're welcome here. Let’s build a supportive space for contributors of all experience levels. 🚀

---

📌 Table of Contents

• 📋 How to Contribute
• 🧠 Code Style Guidelines
• ✅ PR Review Process
• 💬 Community & Communication
• 📝 Contribution Rules
• 🎯 Points & Difficulty Levels
• 🛡 Code of Conduct

---

📋 How to Contribute

🐞 Bug Reports

• Open a new issue using the bug label.
• Include a clear title, a concise description, and the file name/line number if possible.
• Mention expected behavior vs actual behavior.
• Provide steps to reproduce the issue.
• Add screenshots or screen recordings to help us understand better.

🌟 Feature Requests / Docs Improvements

• Open a new issue using the feature or docs label.
• Describe what you’re proposing and why it matters.
• Include UI mockups, screenshots, or API flow diagrams, if applicable.
• Keep ideas beginner-friendly and scalable.

🧑‍💻 Code Contributions (Pull Requests)

Here’s a quick overview of the contribution flow:

🔁 Contribution Workflow

1. Star and Fork the repo.

2. Clone your fork:

git clone https://github.com/TheFlashCodes/FKvim.git

3. Create a new branch:

git checkout -b yourname/feature-name

4. Make your changes:

• Stick to the project structure.
• Use helpful commit messages, eg:
• fix: corrected typo in README.md
• feat: added new keybinding for split window

5. Test everything!
   Ensure your changes work as expected in the FKvim environment before submitting.

6. Push your branch:

git push origin yourname/feature-name

7. Open a Pull Request (PR) from your fork:

• Reference related issue(s): Fixes #<issue-number>
• Add a clear title and summary.

---

🧠 Code Style Guidelines

To ensure consistency and maintainability, please adhere to these guidelines:

• Use camelCase for variables and function names.
• Component files should be PascalCase: KeyMappingConfig.lua.
• Keep functions modular and reusable.
• Use descriptive variable names (leaderKeyMapping > temp123).
• Avoid hardcoded values – use constants/configs where possible.

---

✅ PR Review Process

We aim to keep things smooth and transparent:

• Once your PR is submitted, a maintainer will review it.
• You may be asked to:
• Fix styling issues.
• Add missing documentation/tests.
• Break large PRs into smaller pieces.
• After approval:
• Your PR will be merged with a squash merge to keep history clean.
• You’ll receive feedback, even if the PR isn’t merged immediately.
• ⌛ Reviews may take 24–72 hours depending on activity. Thanks for your patience!

---

💬 Community & Communication

We’re friendly and open – come say hi! 👋

Whether you’re stuck or want to share an idea, reach out through:

• 💬 GitHub Discussions

---

📝 Contribution Rules

To ensure a smooth and fair contribution process:

• Always Star and Fork before contributing.
• Browse open issues and comment to get assigned.
• One PR per issue – stay focused and scoped.
• Don’t start work on an issue unless you’re assigned.
• If you raised an issue, you’ll be assigned by default.
• Avoid making "drive-by PRs" or unrelated fixes — they’ll be closed.

---

🎯 Points & Difficulty Levels

Your contributions earn points that count toward GSSoC'25 and your NeoNest Leaderboard status!

Difficulty	Points
Level 1	10
Level 2	7
Level 3	5

Note: The scoring system applies only to GSSOC contributors.

---

🛡 Code of Conduct

We’re committed to creating a welcoming, friendly, and respectful space for everyone.
By participating in this project, you agree to:

• Be kind and respectful to others.
• Give constructive feedback, not personal criticism.
• Welcome new contributors and encourage learning.
• Avoid any behavior that could be considered harassment or discrimination.

Let’s collaborate in a way that makes everyone feel valued and included.

---

📜 License

By contributing to this project, you agree that your contributions will be licensed under the MIT License.

This helps ensure that all contributions are open, consistent, and usable for the community.

We’re excited to see what you’ll build.