From 9e4b3813f9391702ed283dc80243918e944c9ec1 Mon Sep 17 00:00:00 2001 From: Dan Lawrence Date: Fri, 22 Nov 2019 11:43:17 +0000 Subject: [PATCH 1/6] Create CODE_OF_CONDUCT.md --- CODE_OF_CONDUCT.md | 76 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 76 insertions(+) create mode 100644 CODE_OF_CONDUCT.md diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md new file mode 100644 index 00000000..c8ae4314 --- /dev/null +++ b/CODE_OF_CONDUCT.md @@ -0,0 +1,76 @@ +# Contributor Covenant Code of Conduct + +## Our Pledge + +In the interest of fostering an open and welcoming environment, we as +contributors and maintainers pledge to making participation in our project and +our community a harassment-free experience for everyone, regardless of age, body +size, disability, ethnicity, sex characteristics, gender identity and expression, +level of experience, education, socio-economic status, nationality, personal +appearance, race, religion, or sexual identity and orientation. + +## Our Standards + +Examples of behavior that contributes to creating a positive environment +include: + +* Using welcoming and inclusive language +* Being respectful of differing viewpoints and experiences +* Gracefully accepting constructive criticism +* Focusing on what is best for the community +* Showing empathy towards other community members + +Examples of unacceptable behavior by participants include: + +* The use of sexualized language or imagery and unwelcome sexual attention or + advances +* Trolling, insulting/derogatory comments, and personal or political attacks +* Public or private harassment +* Publishing others' private information, such as a physical or electronic + address, without explicit permission +* Other conduct which could reasonably be considered inappropriate in a + professional setting + +## Our Responsibilities + +Project maintainers are responsible for clarifying the standards of acceptable +behavior and are expected to take appropriate and fair corrective action in +response to any instances of unacceptable behavior. + +Project maintainers have the right and responsibility to remove, edit, or +reject comments, commits, code, wiki edits, issues, and other contributions +that are not aligned to this Code of Conduct, or to ban temporarily or +permanently any contributor for other behaviors that they deem inappropriate, +threatening, offensive, or harmful. + +## Scope + +This Code of Conduct applies both within project spaces and in public spaces +when an individual is representing the project or its community. Examples of +representing a project or community include using an official project e-mail +address, posting via an official social media account, or acting as an appointed +representative at an online or offline event. Representation of a project may be +further defined and clarified by project maintainers. + +## Enforcement + +Instances of abusive, harassing, or otherwise unacceptable behavior may be +reported by contacting the project team at dan@myrespace.com. All +complaints will be reviewed and investigated and will result in a response that +is deemed necessary and appropriate to the circumstances. The project team is +obligated to maintain confidentiality with regard to the reporter of an incident. +Further details of specific enforcement policies may be posted separately. + +Project maintainers who do not follow or enforce the Code of Conduct in good +faith may face temporary or permanent repercussions as determined by other +members of the project's leadership. + +## Attribution + +This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, +available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html + +[homepage]: https://www.contributor-covenant.org + +For answers to common questions about this code of conduct, see +https://www.contributor-covenant.org/faq From acedf3566bbfcc84b2441c434b2a36a35a1d35cd Mon Sep 17 00:00:00 2001 From: Dan Lawrence Date: Fri, 22 Nov 2019 11:49:24 +0000 Subject: [PATCH 2/6] Update issue templates --- .github/ISSUE_TEMPLATE/bug_report.md | 31 +++++++++++++++++++++++ .github/ISSUE_TEMPLATE/feature_request.md | 20 +++++++++++++++ 2 files changed, 51 insertions(+) create mode 100644 .github/ISSUE_TEMPLATE/bug_report.md create mode 100644 .github/ISSUE_TEMPLATE/feature_request.md diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md new file mode 100644 index 00000000..152ec42b --- /dev/null +++ b/.github/ISSUE_TEMPLATE/bug_report.md @@ -0,0 +1,31 @@ +--- +name: Bug report +about: Create a report to help us improve Pygame GUI! +title: '' +labels: bug +assignees: '' + +--- + +**Describe the bug** +A clear and concise description of what the bug is. + +**To Reproduce** +Steps to reproduce the behaviour: +1. +2. +3. + +**Expected behaviour** +A clear and concise description of what you expected to happen. + +**Screenshots** +If applicable, add screenshots to help explain your problem. + +**Platform and software (please complete the following information):** + - OS: [e.g. Windows, Linux, Mac] + - Pygame GUI version [e.g. 0.4.0] + - Pygame version [e.g. 1.9.6] + +**Additional context** +Add any other context about the problem here. diff --git a/.github/ISSUE_TEMPLATE/feature_request.md b/.github/ISSUE_TEMPLATE/feature_request.md new file mode 100644 index 00000000..28586e13 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/feature_request.md @@ -0,0 +1,20 @@ +--- +name: Feature request +about: Suggest an idea to improve or add to Pygame GUI! +title: '' +labels: enhancement +assignees: '' + +--- + +**Is your feature request related to a problem? Please describe.** +A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] + +**Describe the solution you'd like** +A clear and concise description of what you want to happen. + +**Describe alternatives you've considered** +A clear and concise description of any alternative solutions or features you've considered. + +**Additional context** +Add any other context or screenshots about the feature request here. From 445368c2512ecfaee536684cf0ee67d70b2a5af5 Mon Sep 17 00:00:00 2001 From: Dan Lawrence Date: Sat, 23 Nov 2019 10:32:04 +0000 Subject: [PATCH 3/6] Adding contribution guidelines. --- CONTRIBUTING.md | 48 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 48 insertions(+) create mode 100644 CONTRIBUTING.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 00000000..9e982a6a --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,48 @@ +Contributing to Pygame GUI +-------------------------- + +Basic guidlines for contributing +================================ + +1. Pygame GUI uses PEP8 as a style guide, mainly because it is enforced by PyCharm. Contributions should be in the same general style. +2. Pygame GUI tries to use type hinting from the 'typing' module as much as possible. This is mainly to help with code auto completion and refactoring operations, [See here](https://docs.python.org/3/library/typing.html) for the typing documentaion if you are unfamiliar with it's use. +3. Pygame GUI uses docstrings (most of the time) to help encourage better documentation. +4. Pygame GUI tries to use pygame-like approaches wherver possible. This is to make using the library as familiar to users of pygame as possible. This is why we use the pygame event system for communicating GUI events and pygame sprites for drawing GUI elements. +5. Pygame GUI has a game focus - but we also don't want to get too-specific to an individual project. New elements should have applicability to a reasonably wide range of game projects. +6. Pygame GUI aims to be easy to use for relative novices, while still be practical for proper released projects. It's a tricky balance, but in general we want to minimise the amount of code to get _something_ up and running, and keep extra depth a little more tucked away. +7. Good documentation & tutorials. In keeping with our newbie friendly approach, the Pygame GUI documentation aims to be up-to-date and friendly. +8. Be nice to one another when contributing! +9. These are guidelines rather than hard rules. Submitted issues are pretty much always welcome in whatever form as it lets us know someone is making use of the library! The creators of Pygame GUI are fallible humans and just as likely to not be doing something right as the next person, if you think we are doing something wrong and it doesn't fit these guidelines, just let us know. + +Building the library +==================== + +Building Pygame GUI as a developer has a few additional dependecies. + +For building the library you will need: + + - stringify + +For building the documentation you will need: + + - sphinx + - sphinx_rtd_theme + +For running the tests you will need: + + - pytest + + + All should be pip installable. + + + Helpful checklist to go through before submitting a big pull request + ==================================================================== + + 1. Do the tests run? + 2. Do the relevent examples at https://github.com/MyreMylar/pygame_gui_examples run & look OK? + 3. Have I documented any new features/code in a helpful fashion. If so, does the documentation build and look OK? + + + Thank you for reading and considering contributing. + From 472697422649b5c75472373d50d58864fecebb58 Mon Sep 17 00:00:00 2001 From: Dan Lawrence Date: Sat, 23 Nov 2019 10:35:57 +0000 Subject: [PATCH 4/6] Update CONTRIBUTING.md --- CONTRIBUTING.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 9e982a6a..0b2b6bdb 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -4,15 +4,15 @@ Contributing to Pygame GUI Basic guidlines for contributing ================================ -1. Pygame GUI uses PEP8 as a style guide, mainly because it is enforced by PyCharm. Contributions should be in the same general style. -2. Pygame GUI tries to use type hinting from the 'typing' module as much as possible. This is mainly to help with code auto completion and refactoring operations, [See here](https://docs.python.org/3/library/typing.html) for the typing documentaion if you are unfamiliar with it's use. -3. Pygame GUI uses docstrings (most of the time) to help encourage better documentation. -4. Pygame GUI tries to use pygame-like approaches wherver possible. This is to make using the library as familiar to users of pygame as possible. This is why we use the pygame event system for communicating GUI events and pygame sprites for drawing GUI elements. -5. Pygame GUI has a game focus - but we also don't want to get too-specific to an individual project. New elements should have applicability to a reasonably wide range of game projects. -6. Pygame GUI aims to be easy to use for relative novices, while still be practical for proper released projects. It's a tricky balance, but in general we want to minimise the amount of code to get _something_ up and running, and keep extra depth a little more tucked away. -7. Good documentation & tutorials. In keeping with our newbie friendly approach, the Pygame GUI documentation aims to be up-to-date and friendly. -8. Be nice to one another when contributing! -9. These are guidelines rather than hard rules. Submitted issues are pretty much always welcome in whatever form as it lets us know someone is making use of the library! The creators of Pygame GUI are fallible humans and just as likely to not be doing something right as the next person, if you think we are doing something wrong and it doesn't fit these guidelines, just let us know. +1. *Pygame GUI uses PEP8 as a style guide*, mainly because it is enforced by PyCharm. Contributions should be in the same general style. +2. *Pygame GUI tries to use type hinting as much as possible*. This is mainly to help with code auto completion and refactoring operations, [See here](https://docs.python.org/3/library/typing.html) for the typing documentaion if you are unfamiliar with it's use. +3. *Pygame GUI uses docstrings*. At least most of the time; this is to help encourage better documentation. +4. *Pygame GUI tries to use pygame-like approaches wherever possible*. This is to make using the library as familiar to users of pygame as possible. This is why we use the pygame event system for communicating GUI events and pygame sprites for drawing GUI elements. +5. *Pygame GUI has a game focus* - but we also don't want to get too-specific to an individual project. New elements should have applicability to a reasonably wide range of game projects. +6. *Pygame GUI aims to be easy to use* - so it is approachable for relative novices, while still being practical for proper released projects. It's a tricky balance, but in general we want to minimise the amount of code to get _something_ up and running, and keep extra depth a little more tucked away. +7. *Pygame GUI has good documentation & tutorials*. In keeping with our newbie friendly approach, the Pygame GUI documentation aims to be up-to-date and friendly. +8. *Be nice* - try to remember to be nice & helpful to another when contributing! +9. *These are guidelines rather than hard rules*. Submitted issues are pretty much always welcome in whatever form as it lets us know someone is making use of the library! The creators of Pygame GUI are fallible humans and just as likely to not be doing something right as the next person, if you think we are doing something wrong and it doesn't fit these guidelines, just let us know. Building the library ==================== From ef6fe6fc9f7cf9bc98e46713e874a57365d609bd Mon Sep 17 00:00:00 2001 From: Dan Lawrence Date: Sat, 23 Nov 2019 10:36:43 +0000 Subject: [PATCH 5/6] Update CONTRIBUTING.md --- CONTRIBUTING.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 0b2b6bdb..8510bf5a 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -4,15 +4,15 @@ Contributing to Pygame GUI Basic guidlines for contributing ================================ -1. *Pygame GUI uses PEP8 as a style guide*, mainly because it is enforced by PyCharm. Contributions should be in the same general style. -2. *Pygame GUI tries to use type hinting as much as possible*. This is mainly to help with code auto completion and refactoring operations, [See here](https://docs.python.org/3/library/typing.html) for the typing documentaion if you are unfamiliar with it's use. -3. *Pygame GUI uses docstrings*. At least most of the time; this is to help encourage better documentation. -4. *Pygame GUI tries to use pygame-like approaches wherever possible*. This is to make using the library as familiar to users of pygame as possible. This is why we use the pygame event system for communicating GUI events and pygame sprites for drawing GUI elements. -5. *Pygame GUI has a game focus* - but we also don't want to get too-specific to an individual project. New elements should have applicability to a reasonably wide range of game projects. -6. *Pygame GUI aims to be easy to use* - so it is approachable for relative novices, while still being practical for proper released projects. It's a tricky balance, but in general we want to minimise the amount of code to get _something_ up and running, and keep extra depth a little more tucked away. -7. *Pygame GUI has good documentation & tutorials*. In keeping with our newbie friendly approach, the Pygame GUI documentation aims to be up-to-date and friendly. -8. *Be nice* - try to remember to be nice & helpful to another when contributing! -9. *These are guidelines rather than hard rules*. Submitted issues are pretty much always welcome in whatever form as it lets us know someone is making use of the library! The creators of Pygame GUI are fallible humans and just as likely to not be doing something right as the next person, if you think we are doing something wrong and it doesn't fit these guidelines, just let us know. +1. **Pygame GUI uses PEP8 as a style guide**, mainly because it is enforced by PyCharm. Contributions should be in the same general style. +2. **Pygame GUI tries to use type hinting as much as possible**. This is mainly to help with code auto completion and refactoring operations, [See here](https://docs.python.org/3/library/typing.html) for the typing documentaion if you are unfamiliar with it's use. +3. **Pygame GUI uses docstrings**. At least most of the time; this is to help encourage better documentation. +4. **Pygame GUI tries to use pygame-like approaches wherever possible**. This is to make using the library as familiar to users of pygame as possible. This is why we use the pygame event system for communicating GUI events and pygame sprites for drawing GUI elements. +5. **Pygame GUI has a game focus** - but we also don't want to get too-specific to an individual project. New elements should have applicability to a reasonably wide range of game projects. +6. **Pygame GUI aims to be easy to use** - so it is approachable for relative novices, while still being practical for proper released projects. It's a tricky balance, but in general we want to minimise the amount of code to get _something_ up and running, and keep extra depth a little more tucked away. +7. **Pygame GUI has good documentation & tutorials**. In keeping with our newbie friendly approach, the Pygame GUI documentation aims to be up-to-date and friendly. +8. **Be nice** - try to remember to be nice & helpful to another when contributing! +9. **These are guidelines rather than hard rules**. Submitted issues are pretty much always welcome in whatever form as it lets us know someone is making use of the library! The creators of Pygame GUI are fallible humans and just as likely to not be doing something right as the next person, if you think we are doing something wrong and it doesn't fit these guidelines, just let us know. Building the library ==================== From fc693088f7e03ce4fe02ca15c1ebe13957c072f3 Mon Sep 17 00:00:00 2001 From: Dan Lawrence Date: Sat, 23 Nov 2019 10:37:19 +0000 Subject: [PATCH 6/6] Update CONTRIBUTING.md --- CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 8510bf5a..70b23042 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -40,7 +40,7 @@ For running the tests you will need: ==================================================================== 1. Do the tests run? - 2. Do the relevent examples at https://github.com/MyreMylar/pygame_gui_examples run & look OK? + 2. Do the relevent [examples](https://github.com/MyreMylar/pygame_gui_examples) run & look OK? 3. Have I documented any new features/code in a helpful fashion. If so, does the documentation build and look OK?