Skip to content

Latest commit

 

History

History
275 lines (171 loc) · 14.9 KB

CONTRIBUTING.md

File metadata and controls

275 lines (171 loc) · 14.9 KB

Contributing to KodaDot: NFT gallery

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

Deploy Kodadot nft gallery to Netlify

Deploy to Netlify

Getting started

Before you jump in:

Codespaces

  • 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:

    Open in GitHub Codespaces

  • 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:

Which issue should you pick?

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.

Assigning Issues

  • 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 queue for the issue with the emote :wave: -> 👋, and in case the assignee won't finish in time, you will have an option period of 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 queue or pass during your option period to pick an issue, commenting pass will 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 ignore to the issue to prevent KodaBot from reacting to this issue. This feature is available only to collaborators on nft-gallery.

Opening Pull Requests

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.

Submit your PR & Get it reviewed

  • 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.

Check the labels on your Pull Request

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

Your PR is merged!

Congratulations! The whole Metaprime & KodaDot community thanks you. ✨

Avoiding stalled PRs

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.

Avoid getting banned from contributing

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.

Rewards

Continue to REWARDS.md

Hiring process

Continue to HIRING.md

Types of contributions 📝

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.

Regarding Issues 🐞

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.

Regarding Pull requests 🛠️

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.

Pull request template

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:

State your intentions

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.

Is it of good quality

  • 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.

Code reviews 🕵️‍♀️

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

Support ❓

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.

Reviewing

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.

Self-review

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.

Keeping tests relevant🔬

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>

Update strategy: always use merge

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.

Troubleshooting

Code quality

  • We follow what we have in .eslintrc.js, and you can see warnings and errors by running pnpm lint. With pnpm lint --fix, you will get auto fixed code.
  • We've formed STYLE_GUIDE.md to help you answer formatting questions.

Don't have access to push directly into the repository?

You need to fork the repository, commit a change to your repository, and create pull request.

Does it move this repository closer to my vision for the repository

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.

Better comfort

For crafting much better culture and Developer Experience, we recommend some extension to browse issues faster

Does it follow the contributor covenant

This repository has a code of conduct and we will remove things that do not respect it.

Want to ask question?

Ask smart questions best

Follow us