KodaDot NFT gallery has a plan to be builders-owned and become ultimate public good
We are welcoming community contributions from you by rewarding your contributions. Take a sneak peek on good first issues, comment, and make PR. If everything goes well, chances that you will be rewarded are high.
We might give retro-active reward, where the bounty label wasn't present, if we like your contribution.
For better coordination, please join our [Development channel (#coordination) on KodaDot Ecosystem Telegram
Before you jump in:
- We utilize Node.js as a development tool. To avoid potential compatibility issues, check if you're on the version of Node.js we support.
- Make sure that you use pnpm as the package manager.
- Please have a read the code of conduct
- Learn how to set up your environment for the first time
- Get familiar with our coding conventions & recommendations
- Read up on our tech stack to get a better picture of the infrastructure we rely on
- Familiarise yourself with our contributor culture to better understand the dynamics by which we operate
-
For an instant setup of the development environment, please follow the instructions provided below. If you’re setting up for the first time and need a detailed guide, you can refer to our First-Time Setup Guide first-time setup
-
Click on the button below:
-
Copy and paste these commands to your terminal: (It will install all dependencies and start the server.)
pnpm i;
pnpm dev
KodaDot will be available at localhost:9090.
Recommended VSCode Extensions:
We usually work using two metrics:
- priorities by labels p1-p5, p1 means urgent, p5 in research mode.
- bounty labels for issues in the range of $ - $$$$$. Check Rewards
If you are going to contribute, please select issues with the highest urgency (p1, p2) first. It makes a significant difference for users to fix high-priority issues. If there is no such issue, our best advice is to choose issues reflecting your skillset and experience.
Labels can also help you find a perfect issue for your skills, as the example above:
- The good first issue label is for problems or updates we think are ideal for beginners.
- Each developer has a limit of 5 issues assigned to him at any time.
- Each bounty label has allocated time for assignment in the increment of 24 hours
$: 24h, $$: 48h, $$$: 72h, $$$$: 96h, $$$$$: 120h. Frequent contributors (10+ merged PRs) get a bonus of 50% of the allocated time. - Whenever you find an issue that you want to fix, you can get it assigned by commenting on the issue with the emote
:wave:-> 👋 which will trigger KodaBot to assign this issue to you - If there is an ongoing assignment, the bot can get into the
queuefor the issue with the emote:wave:-> 👋, and in case the assignee won't finish in time, you will have anoption periodof 12 hours to pick the issue up with the emote:wave:-> 👋. - In case you want to drop out of the assignment, you can manually unassign yourself
- If you'd like to get out of the
queueor pass during youroption periodto pick an issue, commentingpasswill make you drop out - Once your assignment runs out, KodaBot will unassign you and leave a chance open for other participants
- Opening PR in time will ensure that you won't get unassigned, and that issue stays yours until the PR gets resolved
- Getting unassigned, dropping out of the queue, or passing on the option to pick the issue forbids you from further participation in this particular issue.
- ignoring issue: sometimes, you might work on an issue that doesn't need supervision / assigning from a bot or help from the team. As an example, consider a small issue, quick fix, something without a bounty label, etc. In this case, you can comment
ignoreto the issue to prevent KodaBot from reacting to this issue. This feature is available only to collaborators on nft-gallery.
Whenever you open PR against our repository, our best recommendation is to finish it quickly, i.e., being merged under 72h since opening/last discussion, if it's not a complex issue requiring more profound attention of more members. Otherwise, you will be raising the chance to face many merge conflicts.
- Once you submit your PR, others from the developers community will review it with you. The first thing you'll want to do is a self-review; When self-reviewing, be aware of the quality of your contribution, if your PR has too many visible issues on UI or too many comments from Developers, it will be promptly closed.
- After that, we may have questions; check back on your PR and its current labels to keep up with the conversation.
- Did you have an issue, like a merge conflict? Check out our git tutorial on how to resolve merge conflicts and other issues.
We use labels to keep track on how the PR is going, some examples:
waiting for review - PR is waiting for developer review works for me: QA team has tested your PR visual-ok: Design team has checked and approved your PR changes-requested: Someone from our team identified that something needs to be changed/fixed on your PR stale: PR which haven't seen any changes for last 3 days and its prone to closing blocked: PR is currently blocked and cannot be merged
Congratulations! The whole Metaprime & KodaDot community thanks you. ✨
When the issue is converted to a draft, and you don't reply within 48h, we will close it and unassign you from the task to leave room for someone else to finish the PR who has more availability and codebase understanding.
Our team has high standards when it comes to contributions, if our team identifies that you have a high rate of closed PRs we will prevent you from contributing in our repository.
Continue to REWARDS.md
Continue to HIRING.md
You can contribute to the GitHub KodaDot & Metaprime content and site in several ways. This repo is a place to discuss and collaborate on kodadot.xyz!
Our small but mighty 💪 developer community is maintaining this repo. To preserve our bandwidth, off-topic conversations will be closed.
Issues are used to track tasks that contributors can help with. If an issue has a triage label, we haven't reviewed it yet, and you shouldn't begin work on it.
Issues are precious to this project.
- Ideas are a valuable source of contributions others can make
- Problems show where this project is lacking
- With a question, you show where contributors can improve the user experience
Thank you for creating them.
If you've found something in the content or the website that should be updated, search open issues to see if someone else has reported the same thing. If it's something new, open an issue using a template. We'll use the issue to talk about the problem you want to fix.
A pull request is a way to suggest changes in our repository. When we merge those changes, they should be deployed to the live site within 24 hours.
Please have a look before making PR for a directory with PR templates. PRs ignoring our PR template will be closed. When you open a pull request, you must fill out one of our PR templates. This template helps reviewers understand your changes and the purpose of your pull request. When deciding if we merge in a pull request, we look at the following things:
You should be clear about which problem you're trying to solve with your contribution.
For example:
Add a link to code of conduct in README.md
Doesn't tell me anything about why you're doing that
Add a link to code of conduct in README.md because users don't always look in the CONTRIBUTING.md
Tell me the problem you have found, and the pull request shows me the action you have taken to solve it.
- There are no spelling mistakes
- It reads well
- For English language contributions: Has a good score on Grammarly or Hemingway App
- Haven't used force-push. If that is the case, PR will be closed.
As on daily basis is no wonder we can get 10-20 pull-requests on daily basis, code reviews are current bottleneck. To help us, you should have enough contributed and merged PRs into main branch, familiarity with code base and prefer high quality code. If you want to be member let us know in coordination channel best to be part of Code Review Guild of KodaDot
We are a small team working hard to keep up with the documentation demands of a continuously changing product. Unfortunately, we can't help with support questions in this repository. If you are experiencing a problem with GitHub unrelated to our documentation, please get in touch with GitHub Support directly. Any issues, discussions, or pull requests opened here requesting support will be given information about contacting GitHub Support, then closed and locked.
If you're having trouble with your GitHub account, contact support.
We (usually the core team, sometimes KodaDot engineers or support too!) review PR where they have been requested to do so.
The purpose of reviews is to create the best content for people who use KodaDot and raise code-quality at each pull-request.
💛 Reviews are always respectful, acknowledging that everyone did the best possible job with the knowledge they had at the time.
💛 Reviews discuss content, not the person who created it.
💛 Reviews are constructive and start a conversation around feedback.
You should always review your PR first.
For content changes, make sure that you:
- Confirm that the changes address every part of the content design plan from your issue (if there are differences, explain them).
- Review the content for technical accuracy.
- Review the entire pull request using the localization checklist.
- Copy-edit the changes for grammar, spelling, and adherence to the style guide.
- Check new or updated Liquid statements to confirm that versioning is correct.
- Check that all of your changes render correctly in staging. Remember that lists and tables can be tricky.
- If there are any failing checks in your PR, troubleshoot them until they're all passing.
We run E2E tests using Playwright. Tests will run automatically as GitHub actions to catch bugs introduced by development. Still, it's essential to do your part by manually testing your PR to see if you can find any errors and request a review from the @kodadot/qa-guild.
Example:
<button
id="main"
class="btn btn-large"
name="submission"
role="button"
data-testid="submit">
Submit
</button>Try to submit your PR as soon as possible. That's always an excellent way to avoid conflict with other commits.
However, if the conflict happens, we want you always use merge to resolve it. The reason is
we don't want to mix the merging strategies, and we want to see only your commits in your PR.
- We follow what we have in
.eslintrc.js, and you can see warnings and errors by runningpnpm lint. Withpnpm lint --fix, you will get auto fixed code. - We've formed STYLE_GUIDE.md to help you answer formatting questions.
You need to fork the repository, commit a change to your repository, and create pull request.
The aim of this repository is:
- To provide a README and assorted documents anyone can copy and paste into their project
- The content is usable by someone who hasn't written something like this before
- Foster a culture of respect and gratitude in the open-source community.
For crafting much better culture and Developer Experience, we recommend some extension to browse issues faster
- Refined Github
- Github HoverCard
- Gifs for Github
- Feel free to add your extension, which helps you organize and be productive on GitHub.
This repository has a code of conduct and we will remove things that do not respect it.