Initial commit

.editorconfig

@@ -0,0 +1,17 @@
+root = true
+
+[*]
+indent_style = tab
+indent_size = 4
+end_of_line = lf
+charset = utf-8
+trim_trailing_whitespace = true
+insert_final_newline = true
+
+[*.{ym,yml,yaml,js,json,scss}]
+indent_style = space
+indent_size = 2
+
+[*.{php,md}]
+indent_style = space
+indent_size = 4

.github/CODE_OF_CONDUCT.md

@@ -0,0 +1,133 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+We as members, contributors, and leaders pledge to make participation in our
+community a harassment-free experience for everyone, regardless of age, body
+size, visible or invisible disability, ethnicity, sex characteristics, gender
+identity and expression, level of experience, education, socio-economic status,
+nationality, personal appearance, race, caste, color, religion, or sexual identity
+and orientation.
+
+We pledge to act and interact in ways that contribute to an open, welcoming,
+diverse, inclusive, and healthy community.
+
+## Our Standards
+
+Examples of behavior that contributes to a positive environment for our
+community include:
+
+* Demonstrating empathy and kindness toward other people
+* Being respectful of differing opinions, viewpoints, and experiences
+* Giving and gracefully accepting constructive feedback
+* Accepting responsibility and apologizing to those affected by our mistakes,
+  and learning from the experience
+* Focusing on what is best not just for us as individuals, but for the
+  overall community
+
+Examples of unacceptable behavior include:
+
+* The use of sexualized language or imagery, and sexual attention or
+  advances of any kind
+* Trolling, insulting or derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or email
+  address, without their explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Enforcement Responsibilities
+
+Community leaders are responsible for clarifying and enforcing our standards of
+acceptable behavior and will take appropriate and fair corrective action in
+response to any behavior that they deem inappropriate, threatening, offensive,
+or harmful.
+
+Community leaders 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, and will communicate reasons for moderation
+decisions when appropriate.
+
+## Scope
+
+This Code of Conduct applies within all community spaces, and also applies when
+an individual is officially representing the community in public spaces.
+Examples of representing our community include using an official e-mail address,
+posting via an official social media account, or acting as an appointed
+representative at an online or offline event.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported to the community leaders responsible for enforcement at
+admin 'at' 8fold 'dot' pro.
+
+All complaints will be reviewed and investigated promptly and fairly.
+
+All community leaders are obligated to respect the privacy and security of the
+reporter of any incident.
+
+## Enforcement Guidelines
+
+Community leaders will follow these Community Impact Guidelines in determining
+the consequences for any action they deem in violation of this Code of Conduct:
+
+### 1. Correction
+
+**Community Impact**: Use of inappropriate language or other behavior deemed
+unprofessional or unwelcome in the community.
+
+**Consequence**: A private, written warning from community leaders, providing
+clarity around the nature of the violation and an explanation of why the
+behavior was inappropriate. A public apology may be requested.
+
+### 2. Warning
+
+**Community Impact**: A violation through a single incident or series
+of actions.
+
+**Consequence**: A warning with consequences for continued behavior. No
+interaction with the people involved, including unsolicited interaction with
+those enforcing the Code of Conduct, for a specified period of time. This
+includes avoiding interactions in community spaces as well as external channels
+like social media. Violating these terms may lead to a temporary or
+permanent ban.
+
+### 3. Temporary Ban
+
+**Community Impact**: A serious violation of community standards, including
+sustained inappropriate behavior.
+
+**Consequence**: A temporary ban from any sort of interaction or public
+communication with the community for a specified period of time. No public or
+private interaction with the people involved, including unsolicited interaction
+with those enforcing the Code of Conduct, is allowed during this period.
+Violating these terms may lead to a permanent ban.
+
+### 4. Permanent Ban
+
+**Community Impact**: Demonstrating a pattern of violation of community
+standards, including sustained inappropriate behavior,  harassment of an
+individual, or aggression toward or disparagement of classes of individuals.
+
+**Consequence**: A permanent ban from any sort of public interaction within
+the community.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage],
+version 2.1, available at
+[https://www.contributor-covenant.org/version/2/1/code_of_conduct.html][v2.1].
+
+Community Impact Guidelines were inspired by
+[Mozilla's code of conduct enforcement ladder][Mozilla CoC].
+
+For answers to common questions about this code of conduct, see the FAQ at
+[https://www.contributor-covenant.org/faq][FAQ]. Translations are available
+at [https://www.contributor-covenant.org/translations][translations].
+
+[homepage]: https://www.contributor-covenant.org
+[v2.1]: https://www.contributor-covenant.org/version/2/1/code_of_conduct.html
+[Mozilla CoC]: https://github.com/mozilla/diversity
+[FAQ]: https://www.contributor-covenant.org/faq
+[translations]: https://www.contributor-covenant.org/translations

.github/CONTRIBUTING.md

@@ -0,0 +1,43 @@
+# Contributing
+
+Contributions are **welcome** and will be **credited**. We accept contributions via pull requests to the GitHub project repository.
+
+## Priorities
+
+We leverage GitHub's labeling system to inform prioritization of issues. The higher the number, the higher priority.
+
+Security and accessibility are always the highest priority within the applicable scope of the project. Therefore, some packages are low-level and intended for developers and give the flexibility to them to surround the package within a security layer.
+
+## Overall goals (philosophy and values)
+
+There are a lot of philosphical things tied in to the way we strive to do software development. Some you are most likely familiar with, others maybe not so much.
+
+**You ain't gonna need it (YAGNI):** If someone hasn't asked for it, someone's not paying for it, and it's not needed to finish what has been asked and paid for, then don't develop that thing. (There are some extreme corner cases here, but they are extreme and rare.) (Drawback: Exploration and innovation often require doing things people haven't asked for and aren't paying for.)
+
+**Don't repeat yourself (DRY):** If you are about to copy and paste that bit of code, reconsider. If you have a method that does exactly what you need it to, creating two means there's a possibility one will get out of sync or miss out on that update you make in a few months. (Drawback: DRY can sometimes lead to abstractions that would be easier to maintain if they remained more concrete.)
+
+**Keep it simple, stupid:** (I could really live without the "stupid" piece.) Write the simplest code that could work. (This one actually comes with a lot of caveats, but it does hold true quite often.)
+
+**Make it SOLID:** This is actually a set of principles in and of itself:
+
+- *Single responsibility principle:* Each thing you write should have one responsibility. Specifically classes.
+- *Open/closed principle:* Objects should be open for extension, but closed to modification.
+- *Liskov substitution principle:* Object should be replaceable by subtypes without affecting the correctness of the program.
+- *Interface segregation principle:* Prefer client-specific interfaces over generic catch-all interfaces.
+- *Dependency inversion principle:* Admittedly, don't really know this one well enough to say we follow it or not. (Most likely not as well as we could.)
+
+**Solutions over scapegoats:** There are times when these principles will not be followed or someone will make a mistake. Berating the offender doesn't get any of us any closer to improving the execution of these principles.
+
+**The Community Principle:** If you create or acquire it you help maintain it; time, food, money, and so on.
+
+## Code promotion
+
+Capabilities should be implemented at a low, concrete level before being promoted to higher-levels and made more abstract.
+
+## Code access
+
+If the language being used allows access levels on variables, constants, methods, and so on, it is preferred that the access level begins at the most strict and becomes less restrictive out of necessity. (A desire to create a test for the thing, does not constitute a necessity.)
+
+This reduces the size of the public API, which makes the class easier to consume by developers.
+
+Further, it is preferred that class properties remain private, always. This means pre- and post-processing for setting and getting properties can be added without being a breaking change to developers.

.github/FUNDING.yml

@@ -0,0 +1 @@
+github: [joshbruce, 8fold]

.github/GOVERNANCE.md

@@ -0,0 +1,62 @@
+# Overview
+
+This project is led by a benevolent dictator and managed by the community. That is, the community actively contributes to the day-to-day maintenance of the project, but the general strategic line is drawn by the benevolent dictator. In case of disagreement, they have the last word. It is the benevolent dictator’s job to resolve disputes within the community and to ensure that the project is able to progress in a coordinated way. In turn, it is the community’s job to guide the decisions of the benevolent dictator through active engagement and contribution.
+
+## Roles And Responsibilities
+
+### Benevolent dictator (project lead)
+
+Typically, the benevolent dictator, or project lead, is self-appointed. However, because the community always has the ability to fork, this person is fully answerable to the community. The project lead’s role is a difficult one: they set the strategic objectives of the project and communicate these clearly to the community. They also have to understand the community as a whole and strive to satisfy as many conflicting needs as possible, while ensuring that the project survives in the long term.
+
+In many ways, the role of the benevolent dictator is less about dictatorship and more about diplomacy. The key is to ensure that, as the project expands, the right people are given influence over it and the community rallies behind the vision of the project lead. The lead’s job is then to ensure that the committers (see below) make the right decisions on behalf of the project. Generally speaking, as long as the committers are aligned with the project’s strategy, the project lead will allow them to proceed as they desire.
+
+### Committers
+
+Committers are contributors who have made several valuable contributions to the project and are now relied upon to both write code directly to the repository and screen the contributions of others. In many cases they are programmers but it is also possible that they contribute in a different role. Typically, a committer will focus on a specific aspect of the project, and will bring a level of expertise and understanding that earns them the respect of the community and the project lead. The role of committer is not an official one, it is simply a position that influential members of the community will find themselves in as the project lead looks to them for guidance and support.
+
+Committers have no authority over the overall direction of the project. However, they do have the ear of the project lead. It is a committer’s job to ensure that the lead is aware of the community’s needs and collective objectives, and to help develop or elicit appropriate contributions to the project. Often, committers are given informal control over their specific areas of responsibility, and are assigned rights to directly modify certain areas of the source code. That is, although committers do not have explicit decision-making authority, they will often find that their actions are synonymous with the decisions made by the lead.
+
+### Contributors
+
+Contributors are community members who either have no desire to become committers, or have not yet been given the opportunity by the benevolent dictator. They make valuable contributions, such as those outlined in the list below, but generally do not have the authority to make direct changes to the project code. Contributors engage with the project through communication tools, such as email lists, and via reports and patches attached to issues in the issue tracker.
+
+Anyone can become a contributor. There is no expectation of commitment to the project, no specific skill requirements and no selection process. To become a contributor, a community member simply has to perform one or more actions that are beneficial to the project.
+
+Some contributors will already be engaging with the project as users, but will also find themselves doing one or more of the following:
+
+- supporting new users (current users often provide the most effective new user support)
+- reporting bugs
+- identifying requirements
+- supplying graphics and web design
+- programming
+- assisting with project infrastructure
+- writing documentation
+- fixing bugs
+- adding features
+
+As contributors gain experience and familiarity with the project, they may find that the project lead starts relying on them more and more. When this begins to happen, they gradually adopt the role of committer, as described above.
+
+### Users
+
+Users are community members who have a need for the project. They are the most important members of the community: without them, the project would have no purpose. Anyone can be a user; there are no specific requirements.
+
+Users should be encouraged to participate in the life of the project and the community as much as possible. User contributions enable the project team to ensure that they are satisfying the needs of those users. Common user activities include (but are not limited to):
+
+- evangelising about the project
+- informing developers of project strengths and weaknesses from a new user’s perspective
+- providing moral support (a ‘thank you’ goes a long way)
+- providing financial support
+
+Users who continue to engage with the project and its community will often find themselves becoming more and more involved. Such users may then go on to become contributors, as described above.
+
+## Support
+
+All participants in the community are encouraged to provide support for new users within the project management infrastructure. This support is provided as a way of growing the community. Those seeking support should recognise that all support activity within the project is voluntary and is therefore provided as and when time allows. A user requiring guaranteed response times or results should therefore seek to purchase a support contract from a vendor. (Of course, that vendor should be an active member of the community.) However, for those willing to engage with the project on its own terms, and willing to help support other users, the community support channels are ideal.
+
+## Contribution Process
+
+Anyone can contribute to the project, regardless of their skills, as there are many ways to contribute. For instance, a contributor might be active on the project mailing list and issue tracker, or might supply patches.
+
+## Decision-Making Process
+
+The benevolent dictatorship model does not need a formal conflict resolution process, since the project lead’s word is final. If the community chooses to question the wisdom of the actions of a committer, the project lead can review their decisions by checking various communications related to the interaction.

.github/ISSUE_TEMPLATE/Bug_report.md

@@ -0,0 +1,13 @@
+---
+name: Bug report
+about: 8fold Laravel Provider says it does this thing but does not
+---
+
+**Describe the bug**
+A clear and concise description of what the bug is.
+
+**To Reproduce**
+Steps to reproduce the behavior:
+
+**Expected behavior**
+A clear and concise description of what you expected to happen.

.github/ISSUE_TEMPLATE/Deprecation_notice_or_request.md

@@ -0,0 +1,10 @@
+---
+name: Deprecation Notice or Request
+about: Notify or request a feature be deprecated
+---
+
+**What feature should be deprecated?**
+
+**Why should the feature be deprecated?**
+
+**What alternative means delivers similar or same results?**

.github/ISSUE_TEMPLATE/Feature_request.md

@@ -0,0 +1,13 @@
+---
+name: Feature request
+about: 8fold Laravel Provider doesn't do this thing and I think it should
+---
+
+**Describe the feature**
+A clear and concise description of what you would like.
+
+**Why is this feature necessary?**
+A clear and concise description of why.
+
+**Describe alternatives you've considered**
+A clear and concise description of any alternative solutions or features you've considered.

.github/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2021 8fold
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,5 @@
+[Describe what this PR is about]
+
+## List of issues fixed
+
+[Please use GitHub notation to automatically close the issues: Fixes #{issue number}]

.github/PULL_REQUEST_TEMPLATE/deprecation.md

@@ -0,0 +1,14 @@
+---
+name: Deprecation Notice or Request
+about: Notify or request a feature be deprecated
+---
+
+**What feature should be deprecated?**
+
+**Why should the feature be deprecated?**
+
+**What alternative means delivers similar or same results?**
+
+## List of issues fixed
+
+[Please use GitHub notation to automatically close the issues: Fixes #{issue number}]

.github/PULL_REQUEST_TEMPLATE/release.md

@@ -0,0 +1,13 @@
+## Publisher
+
+- [ ] Release notes in [draft GitHub release](https://github.com/8fold/laravel-provider/releases) are up to date?
+- [ ] Committer checklist is complete.
+- [ ] Merge PR.
+- [ ] Publish GitHub release using `master` with correct version number.
+- [ ] Create draft GitHub release to prepare next release.
+
+## Committer
+
+In most cases, this should be someone different than the publisher.
+
+- [ ] CI is green (no forced merge required).

.github/SECURITY.md

@@ -0,0 +1,7 @@
+# Security Policy
+
+The only completely secure system is the one that doesn't exist in the first place. Having said that, we take security seriously.
+
+## Reporting a Vulnerability
+
+Please disclose potential security issues by email to [joshbruce](https://github.com/joshbruce). We will provide an initial assessment of security reports within 72 hours and should apply patches within 2 weeks (also, feel free to contribute a fix for the issue).