feat: added Issues template

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,38 @@
+---
+name: Bug report
+about: Create a report to help us improve
+title: ''
+labels: ''
+assignees: ''
+
+---
+
+**Describe the bug**
+A clear and concise description of what the bug is.
+
+**To Reproduce**
+Steps to reproduce the behavior:
+1. Go to '...'
+2. Click on '....'
+3. Scroll down to '....'
+4. See error
+
+**Expected behavior**
+A clear and concise description of what you expected to happen.
+
+**Screenshots**
+If applicable, add screenshots to help explain your problem.
+
+**Desktop (please complete the following information):**
+- OS: [e.g. iOS]
+- Browser [e.g. chrome, safari]
+- Version [e.g. 22]
+
+**Smartphone (please complete the following information):**
+- Device: [e.g. iPhone6]
+- OS: [e.g. iOS8.1]
+- Browser [e.g. stock browser, safari]
+- Version [e.g. 22]
+
+**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: ''
+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/ISSUE_TEMPLATE/job-story.md

@@ -0,0 +1,207 @@
+---
+name: Job Story
+about: Full details on the Implementation of a feature request
+title: ''
+labels: ''
+assignees: ''
+
+---
+
+## Why build this feature?
+
+## Proposal
+
+A good user story template captures the “who,” the “what,” and the “why” of a feature in a simple and concise way. This sentence is often written in the everyday or business language of the end user to convey what they want or need to do.\
+Detailed mocks & feature requirements. You can start by expanding on the scoping section from the brief. Work with your engineers & designer to ensure you've gone into enough detail and covered all the cases.
+
+**Job Story Description:**
+
+The purpose of job stories is to explain the roles of users in a system, their desired activities, and what they intend to accomplish by successfully completing a user story. For Agile teams, user stories are the primary method of identifying user needs.
+
+Role – The user should be an actual human who interacts with the system.
+
+- Be as specific as possible
+
+- The development team is NOT a user
+
+Action – The behavior of the system should be written as an action.
+
+- Usually unique for each User Story
+
+- The “system” is implied and does not get written in the story
+
+- Active voice, not passive voice (“I can be notified”)
+
+Benefits – The benefit should be a real-world result that is non-functional or external to the system.
+
+- Many stories may share the same benefit statement.
+
+- The benefit may be for other users or customers, not just for the user in the story.
+
+As a _(_**_type of user_**_)_, I want to _(_**_perform some action_**_)_ so that I _(_**_can achieve some goal/result/value_**_)_.”
+
+When ……………………………………… I want ……………………………………………so I can………..\
+When = Situation
+
+I want = Motivation
+
+So I can = Expected Outcome
+
+**I = Independent**—Can this story be completed by the team? We want the team to be able to complete the whole story rather than be dependent on a different team to do the GUI, for example.
+
+**N = Negotiable**—The story is not so detailed as to describe exactly how long the fields should be or give specifics about date formats and the like. Most likely there will be common routines or libraries that will allow the development team to implement in the way that makes the most sense for them.
+
+**V = Valuable**—The product owner describes that the value being sought is the ability for the trainer to be able to advertise upcoming classes. This is clear in the "why" of the original statement and re-emphasized in the conversation.
+
+**E = Estimable**—The team will ask enough questions and gather the details to feel confident in their ability to estimate the story.
+
+**S = Small**—The team needs to feel confident that they’ll be able to complete the story within a sprint. If they do not, they might split the story. For instance, in our sample story, they may decide to make the ability to gather the student information be a different story and simply display information about the class for this story.
+
+**T = Testable**—With clear acceptance criteria, both the happy path and error conditions can be tested.
+
+
+## Requirements & Goals
+
+Requirements for the different teams which participate at the specific story
+
+## Workflows & Scenarios
+
+List rules to guide design and development
+
+1. Address common scenarios and edge cases
+
+2. List the features that shape the solution
+
+3. Ideally in priority order
+
+4. Draw the boundaries, so the team can focus on how to fill it in
+
+5. Challenge the size to see if a smaller component can be shipped independently
+
+It is often easier to write these out than rely on design to show every permutation\
+The preconditions required before the use case can begin
+
+- The main flow of events (also called the basic flow) describing a user’s path, step by step, to completing an action with the product
+
+- Alternate and exception flows, meaning variant paths a user might take with the product to complete the same or similar goal
+
+- Possibly a visual diagram depicting the entire workflow
+
+**How do we educate customers about this feature?**
+
+
+## Featured Workflows & Key Features
+
+## Concept & Mockups
+
+Requirements for the different teams which participate at the specific story
+
+### Known Limitations
+
+Brainstorm things that could go wrong with your team and partner teams. For each risk, plan appropriate mitigations.\
+**Rough Scoping & Timeline**
+
+At a high level, what's included in V1 vs. later versions? How big of a project is this? What's the roll out / testing plan? Consider the major pieces of functionality, Mobile, Platform, Internationalization, Entry Points, User Onboarding, Premium.
+
+This is part of  the feasibility and Stakeholders of all departments have to attend and be accountable for their department decisions. 
+
+## Success Criteria
+
+What does success look like? Include quant and qual metrics as appropriate.
+
+|            |                     |                   |                         |
+| :--------: | :-----------------: | :---------------: | :---------------------: |
+| **Metric** | **Baseline (Date)** | **Target (Date)** | **Latest (Updated On)** |
+|            |                     |                   |                         |
+
+## Definition of Done
+
+e.g. What does it take for the Development team to put the Product into Production?
+
+DoD is a shared understanding within the Scrum Team on what it takes to make your Product Increment releasable.
+
+The team agrees on, and displays prominently somewhere in the team room, a list of criteria which must be met before a product increment “often a user story” is considered “done”. Failure to meet these criteria at the end of a sprint normally implies that the work should not be counted toward that sprint’s velocity.
+
+the DoD consists of 3 main components:
+
+- Business or Functional requirements
+
+- Quality
+
+- Non-Functional Requirements
+
+## Roll out Plan
+
+Put details and a complete plan how the roll-out will be developed from the Engineering team.
+
+
+## Open Questions
+
+Gather open questions here while the spec is in progress.
+
+**Acceptance Criteria**Each acceptance criteria written in this format has the following statements:
+
+Scenario – the name for the behavior that will be described
+
+Given – the beginning state of the scenario
+
+When – specific action that the user makes
+
+Then – the outcome of the action in “When”
+
+And – used to continue any of three previous statements
+
+
+### What are Acceptance Criteria Used For?
+
+- **To define boundaries.** Acceptance criteria help development teams define the boundaries of a user story. In other words, acceptance criteria help you confirm when the application functions as desired, meaning that a user story is completed.
+
+- **To reach a consensus.** Having acceptance criteria synchronizes the development team with the client. The team knows exactly what conditions should be met, just as the client knows what to expect from the app.
+
+- **To serve as a basis for tests.** Last but not least, acceptance criteria are a cornerstone of positive and negative testing aimed at checking if a system works as expected.
+
+- **To allow for accurate planning and estimation.** Acceptance criteria scenarios allow for the correct division of user stories into tasks so user stories are correctly estimated and planned.
+
+- Keep your criteria well-defined so any member of the project team understands the idea you’re trying to convey.
+
+- Keep the criteria realistic and achievable. Define the minimum piece of functionality you’re able to deliver and stick to it. On the other hand, don’t try to describe every detail since you risk cluttering up your backlog and getting buried under many small tasks.
+
+- Coordinate with all the stakeholders so your acceptance criteria are based on consensus.
+
+- **Create measurable criteria that allow you to adequately estimate development time so you’re able to stay within budget and time constraints.**
+
+- **Consider providing checklists that enable you to see what user stories are covered with acceptance criteria.**
+
+
+## Revisions
+
+Add revisions that are mentioned on comments and we keep them here for better organizing
+
+## Appendix: Research
+
+Include useful research, such as competitive analysis, metrics, or surveys.
+
+Notes: ­ 
+
+- A story must always fit on a printed A4 page. If it does not, you haven’t a clear enough view of the problem yet. Keep working on it. ­ 
+
+* Always have active and upcoming Intermissions printed in your team area or war room. ­ 
+
+* Always use plain simple English, no technical terminology or codenames. Write this document as you would describe the problem to a colleague face to face. 
+
+* The PM owns the Intermission, but should always always solicit input from the full team
+
+Team Handshake:
+
+- 1\. Each story has a respective stakeholder who is responsible for the implementation, feedback and update to his team.
+
+- 2\. Stories are short, compact descriptions illustrating a user need and desired outcome for a specific department ( Design, Engineering, Marketing etc )
+
+- 3\. Stories include the following format:\
+  The Details of the problem they are solving\
+  To whom they are for\
+  The Goal
+
+- The Reason
+
+- The Details of the problem they are solving