What makes a good PR?

[olgarrahan]

Hello, I was wondering what kind of non-functional requirements would make a pull request more likely to be accepted? Would love to hear if there are any code formatting requirements or guidelines that make a high quality PR for this project.

[JOJ0]

For code formatting requirements I think I can say from submitting a couple of PR's that these are pretty well covered by the test suite. It would tell you if your PR is lacking something formatting-wise. Actually a similar situation with functionalitay, there is a very huge amount of tests, checking anything and everything. I think opening your PR and checking and fixing according to unittests will be a good start. HTH

[JOJ0]

Some conventions in the docs as well: https://beets.readthedocs.io/en/stable/contributing.html#coding-conventions

[sampsyo]

It's a great question! Aside from the coding conventions writeup that @JOJ0 referenced, here are some high-order bits:

1. Style. We automatically check style using flake8. You can run this yourself locally—just try tox -e lint (after installing tox) for an easy way.
2. Tests. If you make a functional change, it is usually a good idea to add unit tests that demonstrate that the new functionality works.
3. Documentation. We take documentation pretty seriously in this project. If there's a new feature or a new configuration option or something, thinking about exactly how to best explain that functionality to a new user is greatly appreciated. It's not always easy to do well!
4. "Quality." This is incredibly hard to convey, but we want code contributions to high-quality: written clearly, unlikely to contain bugs, etc. I wish I had a way of giving specific advice about this, but it is usually best to open a PR and then be open to feedback about quality issues—I'm not sure there's an easy way to describe what this looks like a priori.