Contribution guidelines for docs
@snreynolds -- Hey there, I'm interested in doing some fine-tuning to the README.md and CONTRIBUTING.md. I realize the existing content has the bare bones info. Nevertheless, I'd like to propose getting the content closer to these contribution guideline examples.
Moreover, there are a few specific issues that could use fine-tuning (not exhaustive):
The first section in CONTRIBUTING.md is "Creating a Pull Request". The information in the section "Contribution Requests" really fits before "Creating a Pull Request", as prospective contributors want to first know who can contribute and what is fair game to contribute, and to know those things before they read any info on creating a PR. And if the use case is an existing contributor who just needs to quickly confirm the guidelines/steps for creating a PR, that use case can be solved for by including a TOC at the top of the page. As a new contributor fixing a CSS bug, I wanted easier-to-follow instructions for setting up the project and building it locally, such as:
- Install the required versions of Node.js and Yarn.
- Fork the repo.
- Clone your fork.
-
yarn install -
yarn run start
In the section "Contribution Requests", I can't tell from the text "Below are a couple of ways anyone can start contributing…" if that means those are the requested ways (implying "please don't venture beyond these ways") or those are just examples of the many ways, all of which are not listed for brevity's sake. For example, as a contributor, can I fix a bug in a CSS file? And what if a bug has already been created for a problem with a CSS file, but that bug is not assigned. Can I submit a PR with the fix or do I need to request that a project maintainer assign the bug to me first?
To make a more compelling case for my proposed changes, I took the liberty (and risk) of creating a PR that takes the README.md and CONTRIBUTING.md one step closer to the examples. However, due to time constraints, I only took one step. There's a second step, which I captured in a second bug as an outline/checklist of remaining sections that should be added or improved by myself or someone else at some point in the future.
Of course, I defer to you as to whether this work is just too low priority right now. I'm also happy to respond to questions/concerns, make adjustments, or abort. :-)
Thanks for considering this!
Thank you Marty! Connor can you please review?