Initial commit

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,36 @@
+---
+name: Bug report
+about: Create a report to help us improve
+title: ''
+labels: 'bug'
+assignees: ''
+
+---
+
+**Describe the bug**
+A clear and concise description of what the bug is.
+
+**To Reproduce**
+Steps to reproduce the behavior:
+1. First I '...'
+2. Then I '...'
+3. And then '...'
+4. 
+
+**Expected behavior**
+A clear and concise description of what you expected to happen.
+
+**Screenshots**
+If applicable, add screenshots to help explain your problem.
+
+**Smartphone (please complete the following information):**
+ - Device: [e.g. iPhone11]
+ - OS: [e.g. iOS14.1]
+ - Browser [e.g. stock browser, safari]
+ - Version [e.g. 59]
+
+**Were you using an @‎application when the bug was found?**
+  - [e.g. @‎buzz, @‎tmosphere]
+
+**Additional context**
+Add any other context about the problem here.

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,20 @@
+---
+name: Feature request
+about: Suggest an idea for this project
+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.

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,20 @@
+<!--
+Please make sure you've read and understood our contributing guidelines in CONTRIBUTING.md
+
+If this is a bug fix, make sure your description includes "fixes #xxxx", or
+"closes #xxxx"
+
+Please provide the following information:
+-->
+
+**- What I did**
+
+**- How I did it**
+
+**- How to verify it**
+
+**- Description for the changelog**
+<!--
+Write a short (one line) summary that describes the changes in this
+pull request for inclusion in the changelog:
+-->

.github/dependabot.yml

@@ -0,0 +1,7 @@
+version: 2
+updates:
+  # Maintain dependencies for GitHub Actions
+  - package-ecosystem: "github-actions"
+    directory: "/"
+    schedule:
+      interval: "daily"

CONTRIBUTING.md

@@ -0,0 +1,170 @@
+<img src="https://atsign.dev/assets/img/@dev.png?sanitize=true">
+
+### Now for a little internet optimism
+
+# Contributing guidelines
+
+We 💙 [Pull Requests](https://help.github.com/articles/about-pull-requests/)
+for fixing issues or adding features. Thanks for your contribution!
+
+Please read our [code of conduct](code_of_conduct.md), which is based on
+[![Contributor Covenant](https://img.shields.io/badge/Contributor%20Covenant-2.0-4baaaa.svg)](code_of_conduct.md)
+
+
+For small changes, especially documentation, you can simply use the "Edit" button
+to update the Markdown file, and start the
+[pull request](https://help.github.com/articles/about-pull-requests/) process.
+Use the preview tab in GitHub to make sure that it is properly
+formatted before committing.
+A pull request will cause integration tests to run automatically, so please review
+the results of the pipeline and correct any mistakes that are reported.
+
+If you plan to contribute often or have a larger change to make, it is best to
+setup an environment for contribution, which is what the rest of these guidelines
+describe.
+
+## Development Environment Setup
+
+
+### Prerequisites
+
+   ``` sh
+   # show how to install the tools needed to work with the code here
+   ```
+
+
+### GitHub Repository Clone
+
+To prepare your dedicated GitHub repository:
+
+1. Fork in GitHub https://github.com/atsign-foundation/REPO
+2. Clone *your forked repository* (e.g., `git clone [email protected]:yourname/REPO`)
+3. Set your remotes as follows:
+
+   ```sh
+   cd REPO
+   git remote add upstream [email protected]:atsign-foundation/REPO.git
+   git remote set-url upstream --push DISABLED
+   ```
+
+   Running `git remote -v` should give something similar to:
+
+   ```text
+   origin  [email protected]:yourname/REPO.git (fetch)
+   origin  [email protected]:yourname/REPO.git (push)
+   upstream        [email protected]:atsign-foundation/REPO.git (fetch)
+   upstream        DISABLED (push)
+   ```
+
+   The use of `upstream --push DISABLED` is to prevent those
+   with `write` access to the main repository from accidentally pushing changes
+   directly.
+
+### Development Process
+
+1. Fetch latest changes from main repository:
+
+   ```sh
+   git fetch upstream
+   ```
+
+1. Reset your fork's `trunk` branch to exactly match upstream `trunk`:
+
+   ```sh
+   git checkout trunk
+   git reset --hard upstream/trunk
+   git push --force
+   ```
+
+   **IMPORTANT**: Do this only once, when you start working on new feature as
+   the commands above will completely overwrite any local changes in `trunk` content.
+1. Edit, edit, edit, and commit your changes to Git:
+
+   ```sh
+   # edit, edit, edit
+   git add *
+   git commit -m 'A useful commit message'
+   git push
+   ```
+
+1. How to run tests:
+
+   ``` sh
+   # explain tests here
+   ```
+
+1. Open a new Pull Request to the main repository using your `trunk` branch
+
+
+## @‎library release process
+
+The @ Foundation produces several widgets and libraries that the app developer
+can make use of to develop apps on @‎protocol. These libraries are developed in
+Dart & Flutter and published to [pub.dev](https://pub.dev/publishers/atsign.org/packages).
+
+![alt_text](images/image1.png "Version flow")
+
+## Following the changes
+
+The @ Foundation publishes libraries and widgets to
+[https://pub.dev/publishers/atsign.org/packages](https://pub.dev/publishers/atsign.org/packages).
+Each of these libraries contains a tab called “Changelog” that shows various
+published versions and a short description of what changes that went in.
+
+![alt_text](images/image2.png "Changelog screenshot")
+
+Also the “Versions” tab shows the versions published in the reverse
+chronological order.
+
+![alt_text](images/image3.png "Versions screenshot")
+
+## Reporting a bug
+
+The best place to start reporting bugs on the libraries published by 
+@‎protocol would be the “View/report issues” link available on
+[pub.dev](https://pub.dev/publishers/atsign.org/packages).
+
+![alt_text](images/image4.png "View/report issues highlight")
+
+Once the link is clicked, one should be redirected to GitHub repo where the
+issue can be reported by clicking on the “New issue” button.
+
+![alt_text](images/image5.png "Issues list")
+
+Clicking on the  “New issue” button should take you to the screen to choose
+where the issue is a Bug or an Enhancement.
+
+![alt_text](images/image6.png "Choose Bug report")
+
+Upon clicking on the “Get started” button against the “Bug Report” you should
+be directed to a page with a bug template provided by the @company. Filling
+out all of the fields in the template gives the @company a better chance to
+reproduce and fix the bug.
+
+![alt_text](images/image7.png "Filling a Bug report")
+
+## Bug fix and delivery process
+
+* Bugs will initially be placed into the Sprint Planning Board so that they
+can be triaged, estimated and scheduled.
+* Once work on a bug is scheduled one or more engineers will be assigned to
+fixing the bug, and story points will be allocated to match the time estimated
+to fix the bug.
+* Progress on fixing the bug will be updated in the associated GitHub issue,
+and reviewed during subsequent sprint planning meetings where necessary.
+* Once a fix is created we will work with the reporter to ensure that the fix
+is appropriate to their needs, and where possible this should happen prior to
+release to pub.dev
+
+## Closure of the bug
+
+* Where possible the issue associated with the bug should be closed by mutual
+consent with the reporter. This could be:
+    * The reporter closing the issue because they have found a workaround.
+    * The reporter closing the issue because they are satisfied with a fix
+    provided.
+    * A team member closes the issue after the reporter leaves a comment
+    indicating that they are happy for it to be closed.
+* If the reporter does not respond within 14 calendar days then we must assume
+that they no longer have an interest in fixing the bug and work in progress can
+be closed out at the team’s discretion.

LICENSE

@@ -0,0 +1,29 @@
+BSD 3-Clause License
+
+Copyright (c) 2021, The @ Foundation
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions are met:
+
+1. Redistributions of source code must retain the above copyright notice, this
+   list of conditions and the following disclaimer.
+
+2. Redistributions in binary form must reproduce the above copyright notice,
+   this list of conditions and the following disclaimer in the documentation
+   and/or other materials provided with the distribution.
+
+3. Neither the name of the copyright holder nor the names of its
+   contributors may be used to endorse or promote products derived from
+   this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
+FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
+OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

README.md

@@ -0,0 +1,75 @@
+<img src="https://atsign.dev/assets/img/@dev.png?sanitize=true">
+
+### Now for a little internet optimism
+
+# Sample README
+
+Open with intent - we welcome contributions - we want pull requests and to hear about issues.
+
+## Who is this for?
+
+The README should be addressed to somebody who's never seen this before.
+But also don't assume that they're a novice.
+
+### Code user
+
+Does this repo publish to [pub.dev](https://pub.dev) or similar?
+In which case the code user just needs a pointer there - e.g. [at_client on pub.dev](https://pub.dev/packages/at_client)
+
+### Contributor
+
+This is the person who we want working with us here.
+[CONTRIBUTING.md](CONTRIBUTING.md) is going to have the detailed guidance on how to setup their tools,
+tests and how to make a pull request.
+
+## Why, What, How?
+
+### Why?
+
+What is the purpose of this project?
+
+### What?
+
+What is needed to get the project and its dependencies installed?
+
+### How?
+
+How does this work? How is this used to fulfil its intended purpose?
+
+## Checklist
+
+### Writing
+
+Does the writing flow, with proper grammar and correct spelling?
+
+### Links
+
+Are the links to external resources correct?
+Are the links to other parts of the project correct
+(beware stuff carried over from previous repos where the
+project might have lived during earlier development)?
+
+### Description
+
+Has the Description field been filled out?
+
+### Acknowledgement/Attribution
+
+Have we correctly acknowledged the work of others (and their Trademarks etc.)
+where appropriate (per the conditions of their LICENSE?
+
+### LICENSE
+
+Which LICENSE are we using?  
+Is the LICENSE(.md) file present?  
+Does it have the correct dates, legal entities etc.?
+
+## Maintainers
+
+Who created this?  
+
+Do they have complete GitHub profiles?  
+
+How can they be contacted?  
+
+Who is going to respond to pull requests?