From b0d125d4832d55c4cb764c7fe90ecffee311367e Mon Sep 17 00:00:00 2001 From: Andrew Petro Date: Tue, 25 Feb 2020 10:04:02 -0600 Subject: [PATCH 1/6] style: wrap Markdown files at 80 char --- .editorconfig | 2 ++ CHANGELOG.md | 16 ++++++++++------ CONTRIBUTING.md | 48 ++++++++++++++++++++++++++++-------------------- 3 files changed, 40 insertions(+), 26 deletions(-) diff --git a/.editorconfig b/.editorconfig index c5c70d2..663398c 100644 --- a/.editorconfig +++ b/.editorconfig @@ -9,3 +9,5 @@ indent_style = space insert_final_newline = true trim_trailing_whitespace = true +[*.md] +max_line_length=80 diff --git a/CHANGELOG.md b/CHANGELOG.md index 97294ca..0be13a4 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -2,19 +2,21 @@ ## 1.3.1 -* Added more components to local demo to test mobile search positioning +* Added more components to local demo to test mobile search positioning ## 1.3.0 -* Added `myuw-search` CustomEvent that exposes the value in the search field when a search is submitted +* Added `myuw-search` CustomEvent that exposes the value in the search field + when a search is submitted ## 1.2.4 -* Added CSS variable to explicitly set mobile search bar origin position (sets the value of `right`). +* Added CSS variable to explicitly set mobile search bar origin position + (sets the value of `right`). ## 1.2.3 -### Added +### Added * Responsive theming support @@ -22,7 +24,8 @@ ### Added -* Now supports setting the `--myuw-search-border` CSS variable to better support theming. +* Now supports setting the `--myuw-search-border` CSS variable to better + support theming. ## Changed @@ -30,4 +33,5 @@ ## 1.1.8 -This patch adds attribute mirroring so that changes to observed attributes that occur _after_ the initial load are correctly reflected in the component. \ No newline at end of file +This patch adds attribute mirroring so that changes to observed attributes +that occur _after_ the initial load are correctly reflected in the component. diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 151bad5..166ca1d 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,24 +1,31 @@ # Contributing -When contributing to this repository, please first discuss the change you wish to make via issue, -email, in person, or any other method with the owners of this repository before making a change. +When contributing to this repository, please first discuss the change you wish +to make via issue, email, in person, or any other method with the owners of this +repository before making a change. -Please note we have a code of conduct, please follow it in all your interactions with the project. +Please note we have a code of conduct, please follow it in all your interactions +with the project. ## Pull Request Process 1. Ensure any build or configuration artifacts are removed before submission -2. Increase the version number to the new version that this Pull Request would represent. +2. Increase the version number to the new version that this Pull Request would + represent. 3. Update the README.md with relevant details of the change. - variables, exposed ports, etc. - The versioning scheme we use is [SemVer](http://semver.org/). -4. Open a pull request from your fork to the upstream master branch. Include 'WIP' in the title - if the changeset is not yet ready to merge and use in production settings. Remove it once finalized. -5. Squash commits to the smallest meaningful number of revisions. Do not include merge commits. -6. Fully test the change—collaborating with maintainers as necessary—before merging the pull request. -7. You may merge the Pull Request in once you feel comfortable with it and have the sign-off of at - least one other developer, or if you do not have permission to do that, you may request the - reviewer to merge it for you. + variables, exposed ports, etc. + The versioning scheme we use is [SemVer](http://semver.org/). +4. Open a pull request from your fork to the upstream master branch. Include + 'WIP' in the title if the changeset is not yet ready to merge and use in + production settings. + Remove it once finalized. +5. Squash commits to the smallest meaningful number of revisions. + Do not include merge commits. +6. Fully test the change—collaborating with maintainers as necessary—before + merging the pull request. +7. You may merge the Pull Request in once you feel comfortable with it and have + the sign-off of at least one other developer, or if you do not have permission + to do that, you may request the reviewer to merge it for you. ## Code of Conduct @@ -27,9 +34,9 @@ Please note we have a code of conduct, please follow it in all your interactions 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, gender identity and expression, level of experience, -nationality, personal appearance, race, religion, or sexual identity and -orientation. +size, disability, ethnicity, gender identity and expression, level of +experience, nationality, personal appearance, race, religion, or sexual identity +and orientation. ### Our Standards @@ -80,8 +87,9 @@ Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team by [email][email]. 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. +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 @@ -89,8 +97,8 @@ members of the project's leadership. ### Attribution -This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, -available at [http://contributor-covenant.org/version/1/4][version] +This Code of Conduct is adapted from the [Contributor Covenant][homepage], +version 1.4, available at [http://contributor-covenant.org/version/1/4][version] [email]: mailto:info@my.wisc.edu [homepage]: http://contributor-covenant.org From 6457988feed224e2561c1edf607a69d647e309f1 Mon Sep 17 00:00:00 2001 From: Andrew Petro Date: Tue, 25 Feb 2020 10:04:42 -0600 Subject: [PATCH 2/6] contributing: express openness to Pull Request as communication --- CONTRIBUTING.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 166ca1d..32e97ff 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,8 +1,10 @@ # Contributing -When contributing to this repository, please first discuss the change you wish -to make via issue, email, in person, or any other method with the owners of this -repository before making a change. +When contributing to this repository, consider first discussing the change you +wish to make via issue, email, in person, or any other method with the owners of +this repository before making a change. That said, sometimes a Pull Request is +the most effective way to communicate an idea and it's fine to lead with a Pull +Request so long as you're open to discussion from there. Please note we have a code of conduct, please follow it in all your interactions with the project. From e468606644701f924fc3f789427ca684d3c11ca5 Mon Sep 17 00:00:00 2001 From: Andrew Petro Date: Tue, 25 Feb 2020 10:06:10 -0600 Subject: [PATCH 3/6] copyedit: brevity: "first" implied "before" "before making a change" was implied by "first" so is extra words without extra meaning, tightening up for brevity. --- CONTRIBUTING.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 32e97ff..cd87f53 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -2,9 +2,9 @@ When contributing to this repository, consider first discussing the change you wish to make via issue, email, in person, or any other method with the owners of -this repository before making a change. That said, sometimes a Pull Request is -the most effective way to communicate an idea and it's fine to lead with a Pull -Request so long as you're open to discussion from there. +this repository. That said, sometimes a Pull Request is the most effective way +to communicate an idea and it's fine to lead with a Pull Request so long as +you're open to discussion from there. Please note we have a code of conduct, please follow it in all your interactions with the project. From 75948af926f94c06b52ba921af543905f761ea2a Mon Sep 17 00:00:00 2001 From: Andrew Petro Date: Tue, 25 Feb 2020 10:08:22 -0600 Subject: [PATCH 4/6] contributing: mention SemVer at the first mention of versioning Reference SemVer at the first point where the contributor is being asked to increase a version number. --- CONTRIBUTING.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index cd87f53..37c3019 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -13,10 +13,9 @@ with the project. 1. Ensure any build or configuration artifacts are removed before submission 2. Increase the version number to the new version that this Pull Request would - represent. + represent. This product uses [SemVer](http://semver.org/). 3. Update the README.md with relevant details of the change. variables, exposed ports, etc. - The versioning scheme we use is [SemVer](http://semver.org/). 4. Open a pull request from your fork to the upstream master branch. Include 'WIP' in the title if the changeset is not yet ready to merge and use in production settings. From ea4afa1a2f42e7595e71f2eaf64d4303d0f43a84 Mon Sep 17 00:00:00 2001 From: Andrew Petro Date: Tue, 25 Feb 2020 10:18:37 -0600 Subject: [PATCH 5/6] contributing: suggest using GitHub's draft feature to express WIP --- CONTRIBUTING.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 37c3019..0cefc3d 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -16,10 +16,11 @@ with the project. represent. This product uses [SemVer](http://semver.org/). 3. Update the README.md with relevant details of the change. variables, exposed ports, etc. -4. Open a pull request from your fork to the upstream master branch. Include - 'WIP' in the title if the changeset is not yet ready to merge and use in - production settings. - Remove it once finalized. +4. Open a pull request from your fork to the upstream master branch. + Communicate that the Pull Request is a work-in-progress if it is not yet ready + to merge and use in production settings, by using + [GitHub's draft Pull Requests feature][] or prepending "WIP: " to the Pull + Request title. 5. Squash commits to the smallest meaningful number of revisions. Do not include merge commits. 6. Fully test the change—collaborating with maintainers as necessary—before @@ -104,3 +105,5 @@ version 1.4, available at [http://contributor-covenant.org/version/1/4][version] [email]: mailto:info@my.wisc.edu [homepage]: http://contributor-covenant.org [version]: http://contributor-covenant.org/version/1/4/ + +[GitHub's draft Pull Requests feature]: https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests#draft-pull-requests From fcefe2397e49f8672f8b3ab847615f7a77a0065a Mon Sep 17 00:00:00 2001 From: Andrew Petro Date: Tue, 25 Feb 2020 10:25:46 -0600 Subject: [PATCH 6/6] contributing: soften to avoid barriers to contribution Emphasize that the contributing guidelines should help contributors do their best, not prove a barrier to contributors doing their best. --- CONTRIBUTING.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 0cefc3d..05f5595 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -9,6 +9,13 @@ you're open to discussion from there. Please note we have a code of conduct, please follow it in all your interactions with the project. +**All of the technical guidance here is on a try-your-best basis.** +All anyone can ask is that you try your best. Definitely do not let code +formatting or organizing your commits just so or questions about Semantic +Versioning or anything else be a barrier to contributing. Maintainers can help +you work through all of that and more in collaborating on your contribution, +and if need be can post-process contributions to smooth out rough edges. + ## Pull Request Process 1. Ensure any build or configuration artifacts are removed before submission