kytrinyx
commented
7 years ago First off: ✨ 💚 🌺 💚 🌺 💚 ✨ thank you
I have feedback, but none of it is major, it's all about smoothing the process out more, and following norms.
One of the most important things when opening a pull request is to provide context about what/why you're fixing. If it's something you stumbled across yourself, then add some background about how and why you think your fix is the right thing. In this case, you're fixing an open issue, so you don't need to convince the maintainers it's worth doing :) They come pre-convinced. That said, there are over 100 maintainers involved in this project, and a bunch of them might not be aware of the open issue. Here your best bet is to add a link to that open issue in the body of the pull request (not the title, but rather in the body of the comment—try editing both to add a link and see why I prefer the body not the title).
Even when providing a link, it's great to summarize the purpose of the PR. Notice that the purpose is just about the only thing a maintainer can't know by looking at it. From looking at the PR even without a description I can quickly see which file you added and where (by clicking on the "files" tab). It's really helpful if you can summarize the why rather than the what. Something like "this is part of the effort of consolidating project-wide documentation that is currently scattered across different repositories", or even "this brings in documentation that currently lives in x-common".
The next thing to think about is following the standards of git commits when writing your subject line and body (both for the commits and the PRs). Some people care a lot about this—others not at all. I probably care more than is healthy :) Some people care only about commit messages, others only about PRs. The best short introduction to this is http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html and the best long one is https://chris.beams.io/posts/git-commit/
Finally, if you ended up with an "oops" commit, the maintainers will typically be pretty grateful if you squash your commits into a single commit. If you're newish to Git that can feel ridiculously scary, and of course, Git being Git, there are a bajillion ways you could do it. The good news is, it only takes one! I tend to point people to http://blog.steveklabnik.com/posts/2012-11-08-how-to-squash-commits-in-a-github-pull-request
💛 🌻 💛
rpottsoh
acgillette
File is inside the contributing-to-language-tracks directory.