Formatting cleanups

Signed-off-by: Joe Block <jpb@unixorn.net>
This commit is contained in:
Joe Block 2023-07-03 08:00:24 -06:00
parent 69b2cf71da
commit 5952a59218
2 changed files with 17 additions and 18 deletions

View file

@ -38,7 +38,7 @@ This Code of Conduct applies both within project spaces and in public spaces whe
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at jpb@unixorn.net. The project team will review and investigate all complaints, and will respond in a way that it deems 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.
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at <jpb@unixorn.net>. The project team will review and investigate all complaints, and will respond in a way that it deems 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.

View file

@ -8,39 +8,38 @@ I want to be clear that real, useful PRs are always welcome. _But_ if you came h
### General
* Please make sure all new framework, plugin, themes or completions entries have a license file. Some users are particular about the code they use and want to be sure they are compliant with licensing, so please make sure it's easy for them to determine what the license is. I am aware that there are existing entries without licenses, they were added before I instituted the license policy.
- Please make sure all new framework, plugin, themes or completions entries have a license file. Some users are particular about the code they use and want to be sure they are compliant with licensing, so please make sure it's easy for them to determine what the license is. I am aware that there are existing entries without licenses, they were added before I instituted the license policy.
* Please make sure new entries have a readme. While obviously it's good to read the source code for things we're adding to our environment, it's even better if users can get an overall idea of what a plugin does so they know if it is even potentially useful to them first.
- Please make sure new entries have a readme. While obviously it's good to read the source code for things we're adding to our environment, it's even better if users can get an overall idea of what a plugin does so they know if it is even potentially useful to them first.
* Descriptions should be clear, concise, and non-promotional.
- Descriptions should be clear, concise, and non-promotional.
* The list is split into sections for frameworks, plugins, themes and completions, please add your entries to the appropriate section(s). If an entry is a plugin that provides both plugin functionality and tab completions, add it to the plugins section. If an entry is a plugin that provides both plugin functionality and a theme, please add it to the theme section. The completions section is meant for projects that only provide extra tab completions.
- The list is split into sections for frameworks, plugins, themes and completions, please add your entries to the appropriate section(s). If an entry is a plugin that provides both plugin functionality and tab completions, add it to the plugins section. If an entry is a plugin that provides both plugin functionality and a theme, please add it to the theme section. The completions section is meant for projects that only provide extra tab completions.
* Descriptions should follow the link, on the same line, with capitalization consistent with the other entries in the section.
- Descriptions should follow the link, on the same line, with capitalization consistent with the other entries in the section.
* Each entry should be a single line that ends in a period. This makes keeping the sections sorted easier.
- Each entry should be a single line that ends in a period. This makes keeping the sections sorted easier.
* Plugin, theme and completions entries _must_ be a single line and be added in alphabetical order in their respective sections of the list. We let GitHub's markdown formatter handle adding any required line breaks rather than embedding line breaks in the entries ourselves, this also allows us to work correctly with any browser window width.
- Plugin, theme and completions entries _must_ be a single line and be added in alphabetical order in their respective sections of the list. We let GitHub's markdown formatter handle adding any required line breaks rather than embedding line breaks in the entries ourselves, this also allows us to work correctly with any browser window width.
* For consistency, please use all caps for ZSH in all entry descriptions.
- For consistency, please use all caps for ZSH in all entry descriptions.
* Each entry should be limited to one link, and that link should be the first part of the line. It is ok to submit more than one entry in a PR.
- Each entry should be limited to one link, and that link should be the first part of the line. It is ok to submit more than one entry in a PR.
* Please make sure all framework, plugin, themes or completions list entries are sorted *alphabetically*.
- Please make sure all framework, plugin, themes or completions list entries are sorted _alphabetically_.
- The link should be named the name of the package or project. Please remove any leading or trailing `zsh-plugin`, `zsh-theme` from the visible portion of the link.
* The link should be named the name of the package or project. Please remove any leading or trailing `zsh-plugin`, `zsh-theme` from the visible portion of the link.
* Your PR should pass the Github Action checks. If the checks show an error that you didn't add (a previous plugin entry has gone 404, for example) you don't _have_ to fix those errors, though I'll certainly appreciate the help if you do, or if you create an issue documenting the problem so I can fix it.
- Your PR should pass the Github Action checks. If the checks show an error that you didn't add (a previous plugin entry has gone 404, for example) you don't _have_ to fix those errors, though I'll certainly appreciate the help if you do, or if you create an issue documenting the problem so I can fix it.
### Themes
* If you're submitting a theme, please make sure that the theme repo has a screen shot so that list users can tell what it looks like before installing it.
- If you're submitting a theme, please make sure that the theme repo has a screen shot so that list users can tell what it looks like before installing it.
* It is fine to have multiple new entries in a single PR. Just make sure they all have readmes and licenses, and screenshots for theme entries.
- It is fine to have multiple new entries in a single PR. Just make sure they all have readmes and licenses, and screenshots for theme entries.
* No need to squash commits. It is fine to have multiple commits in a PR.
- No need to squash commits. It is fine to have multiple commits in a PR.
## To remove an entry:
## To remove an entry
Open an issue to discuss why the entry should be removed, and optionally create a PR.