Contributors Guide

A standard guideline for how to contribute to Hiro's documentation and content.

One of the most important ways that Hiro can build out the Stacks developer community and ecosystem is by having feedback and contributions from the developer community.

Issues

If the content is obsolete, technically inaccurate, or unclear, please create a GitHub Issue. This is a great way to give specific feedback and ensure the technical content is up-to-date and technically accurate.

Terminal
cd /path/to/hiro-docs-repository
gh issue create

Pull requests

To suggest more comprehensive changes or updates to the content, make documentation changes and then submit a pull request.

Create a new branch and make your changes

To submit a pull request to update the docs, fork the Hiro Docs repository and clone it.

Terminal
git checkout -b my-new-feature

Create a new hello-world project

Now let's create a hello-world project. This will scaffold all the necessary files and directories for us to get started.

Terminal
clarinet new hello-world

Create a say-hello contract

Now that our project has been generated we can start creating our first contract. Let's name this one say-hello.

Terminal
cd hello-world
clarinet contract new say-hello

Create a read-only function called say-hi

Now that we have our say-hello.clar file generated, let's create a read-only function that prints out "Hello World".

say-hello.clar
(define-read-only (say-hi)
  (print "Hello World")
)

Verify your contracts

In order to verify that our code is valid, we can run clarinet check inside of our project directory to ensure our say-hi function is valid.

Terminal
clarinet check
✔ 1 contract checked

  1. Add or modify the GitHub Markdown files in the directories.

  2. When the suggested changes are complete, commit them with a message with a brief summary message:

    git commit -m "commit message"

  3. Push the branch up:

    git push origin <branch-name>

When the changes are final, create a pull request from the working branch by following GitHub's guide.

Titles and descriptions

For pull requests, please keep the following in mind:

  • Pull request titles should be descriptive enough for reviewers to understand what is being changed. Some ways of doing this are better than others.

  • Every pull request should have a description that explains why the change is being made. The description adds context that is critical for reviewers when giving feedback.

  • For a quick GitHub refresher, please refer to the GitHub Get Started Guide.

  • For more tips, see GitHub's blog entry on how to write the perfect pull request.

Last updated on

Rate Limiting

On this page

IssuesPull requestsTitles and descriptions
Edit on Github