I think these are all good things to be touched upon.

- All code that is submitted should have appropriate test coverage.
How do you think we should define appropriate, and do we need to verify the test coverage, or just take people's word?

- Make sure code style guidelines are met.
Does PEP 8 seem good enough for style, or are you still feeling like Black is a better option? I haven't had a chance to dig into it yet.

- Steps to report bugs.
Obviously we need to know the error and the steps that caused it, but is there more to this I'm not realizing?

- Steps to request enhancements and other features.
Submit as an issue with the enhancement tag?

I also realize now that I'm not the only one on this project, I need to do a bit more when it comes to documenting what I'm doing and how. Should have been doing that before, I realize, but this is all a learning process for me. Never really thought anyone else would be interesting in working on it. :-)

from mpv.

"How do you think we should define appropriate, and do we need to verify the test coverage, or just take people's word?"

Testing is an interesting topic, @zachtheclimber as the creator and lead developer of the application you should decide if testing is a path you want to go down.

If so, I think as a base requirement to add to contributing guideline documents, as a rule, any code that is added should be submitted with tests backing up the code (for now since we don't have a test suite implemented, this would exist only in the guidelines for the time being). We can then open an issue to implement a test suite and configure a testing environment.

"Does PEP 8 seem good enough for style, or are you still feeling like Black is a better option? I haven't had a chance to dig into it yet."

Totally up to you if you want to move forward with including a code formatter in the style guidelines! I can help answer questions you might have about them in general. Other things to include might be using type hinting and function annotations, making it clear that you like/dislike commented code etc. Those are just examples but you can choose many of your personal preferences to include inside of the style guidelines.

"Obviously we need to know the error and the steps that caused it, but is there more to this I'm not realizing?"

No not really, if people have bugs they wish to submit, its nice to make sure they include steps to reproduce those bugs in the bug report. Nothing really detailed needs to be incuded there, you would think that is common sense but it is surprising how many times you might get a "<cool_feature> is broken" as a bug report. Lol, Okay what about the feature is broken, what error are you getting, how can I reproduce the error? This could be as simple as adding something like:

Steps to report bugs:

• Open an issue

• Briefly explain the behavior of the application.

• Include explicit steps on how to reproduce the bug, including screenshots, stacktrace, and error logs.

• < Optional > proposed steps towards a solution

"Submit as an issue with the enhancement tag?"

Some contributing guideline documents have a section about adding new features that include the steps you wish to have people follow before just submitting a random pull request with <new_cool_feature> added. Some things I've seen out there are along the lines of:

New feature requests

• Ask yourself:

  • Is this feature needed?

  • Does this feature have any breaking changes?

  • Does this change affect the UI/ frontend of the application?

• Discuss feature with @zachtheclimber before beginning work.

• After approval from @zachtheclimber, fork repo and create branch, and submit your changes

Those are just examples but you can really include anything you want people to follow. Only you, and anyone else you invite to be a contributor can tag branches.

"This is all a learning process for me. Never really thought anyone else would be interesting in working on it. :-)"

No worries the project looks great and has been getting some awesome feedback on mountain prject! Thanks for being open to letting others contribute!! I think working as a team and with other people is a great way we can all learn new things, practice new skills and share those things with others along the way.

from mpv.

I'm going to leave this open, just because I think you identified some other things that could be added to the contribution guidelines. I'll work through getting them updated as time permits. :-)

from mpv.

Updated the contributing guidelines to reflect the things I wanted to bring over from here, so I'm closing. :-)

from mpv.