Skip to content

Welcome to Open Cap Table Format (OCF) contributing guide #

Thank you for investing your time in contributing to our project! We welcome all contributions, whether they be feature requests, proposed features, bug fixes, etc..

In this guide you will get an overview of the contribution workflow from opening an issue, creating a PR, reviewing, and merging the PR.

New contributor guide#

To get an overview of the project, read the README. Here are some resources to help you get started with open source contributions:

Types of contributions#

You can contribute to the GitHub Docs content and site in several ways. This repo is a place to discuss and collaborate on docs.github.com! Our small, but mighty 💪 docs team is maintaining this repo, to preserve our bandwidth, off topic conversations will be closed.

1) Discussions#

Discussions are where we have conversations.

If you'd like help troubleshooting a docs PR you're working on, have a great new idea, or want to share something amazing you've learned in our docs, join us in discussions.

2) 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.

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 have a conversation about the problem you want to fix.

Create a new issue#

If you spot a problem with the docs, search if an issue already exists. If a related issue doesn't exist, you can open a new issue using a relevant issue form.

Solve an issue#

Scan through our existing issues to find one that interests you. You can narrow down the search using labels as filters. See Labels for more information.

3) Pull requests for feature proposals and code edits#

A pull request is a way to suggest changes in our repository.

We welcome all contributions, but, due to the volume of requests we receive and the need to develop an industry-wide specification, we may not be able to accept all contributions and merge them into our code base.

a) Make small, simple changes in the UI#

Click Make a contribution at the bottom of any docs page to make small changes such as a typo, sentence fix, or a broken link. This takes you to the .md file where you can make your changes and create a pull request for a review.

b) Make substantive change suggestions locally#

  1. Fork the repository.

  2. Using GitHub Desktop:

  3. Getting started with GitHub Desktop will guide you through setting up Desktop.

  4. Once Desktop is set up, you can use it to fork the repo!

  5. Using the command line:

  6. Fork the repo so that you can make your changes without affecting the original project until you're ready to merge them.

  7. GitHub Codespaces:

  8. Fork, edit, and preview using GitHub Codespaces without having to install and run the project locally.

  9. Install VSCode if you don't already use it.

  10. Create a working branch and start making your changes!

  11. When you're finished with the changes, create a pull request, also known as a PR.

  12. Fill the "Ready for review" template so that we can review your PR. This template helps reviewers understand your changes as well as the purpose of your pull request.

  13. Don't forget to link PR to issue if you are solving one.
  14. Enable the checkbox to allow maintainer edits so the branch can be updated for a merge. Once you submit your PR, a team member will review your proposal. We may ask questions or request for additional information.
  15. We may ask for changes to be made before a PR can be merged, either using suggested changes or pull request comments. You can apply suggested changes directly through the UI. You can make any other changes in your fork, then commit them to your branch.
  16. As you update your PR and apply changes, mark each conversation as resolved.
  17. If you run into any merge issues, checkout this git tutorial to help you resolve merge conflicts and other issues.

4) Support Requests#

OCF is currently in alpha and the specification is not finalized. Its implementation is not yet supported by this team in any way. It is under active and heavy development. It is subject to change and we make no promises re: its suitability for a given purpose, its fitness for purpose, or the accuracy of any documentation in this repo. Please do use this repo to make support requests for issues re: implementing the unfinished standard.

Caveats for Windows#

This site can be developed on Windows, however a few potential gotchas need to be kept in mind:

  1. Regular Expressions: Windows uses \r\n for line endings, while Unix based systems use \n. Therefore when working on Regular Expressions, use \r?\n instead of \n in order to support both environments. The Node.js os.EOL property can be used to get an OS-specific end-of-line marker.
  2. Paths: Windows systems use \ for the path separator, which would be returned by path.join and others. You could use path.posix, path.posix.join etc and the slash module, if you need forward slashes - like for constructing URLs - or ensure your code works with either.
  3. Bash: Not every Windows developer has a terminal that fully supports Bash, so it's generally preferred to write scripts in JavaScript instead of Bash.
  4. Filename too long error: There is a 260 character limit for a filename when Git is compiled with msys. While the suggestions below are not guaranteed to work and could possibly cause other issues, a few workarounds include:
  5. Update Git configuration: git config --system core.longpaths true
  6. Consider using a different Git client on Windows