move content from general to operations (#83)

* create: project checklist

* create: email template

* fix metadata

* create: new operation post

* move content from general to operations

operations/annual-bonus-for-sales.md

@@ -0,0 +1,28 @@
+---
+tags: 
+  - operations
+  - project
+title: Annual bonus for sales
+date: 2020-01-01
+description: Guide to calculate annual bonus for sales
+authors: 
+  - hnh
+menu: playbook
+type: null
+hide_frontmatter: false
+---
+
+The annual bonus for sales are the sum of 2 portions
+
+### New deals of current year
+The annual will be calculated based on the total commission you earn that year. They are divided into 3 tiers as in the table above.
+
+- Low: earn extra **$600 to $4k** for new deployment team size of **4 - 8 in 12 months**
+- Medium: earn extra **$9k to $60k** for new deployment team size of **12 - 20 in 12 months**
+- High: earn extra **$72k to $96k** for new deployment team size of **24 - 32 in 12 months**
+
+### Previous deals
+For previous deals, you will earn extra **2% of the old money commission**.
+
+### FAQ
+- Upselling is considered as new money

operations/bunk-license-check.md

@@ -0,0 +1,23 @@
+---
+tags: 
+  - operations
+  - project
+title: Bunk license check
+date: 2020-01-01
+description: Glice is a Golang license and dependency checker, providing detailed insights into dependencies and their licenses
+authors: 
+  - hnh
+menu: playbook
+type: null
+hide_frontmatter: false
+---
+
+## License detector tool: Glice
+Golang license and dependency checker. Prints list of all dependencies (both from std and 3rd party), number of times used, their license and saves all the license files in /licenses.
+
+### Build
+- Clone Glice to your local workspace: `$go get github.com/ribice/glice`
+- Go install to your $GOBIN: `$ go install github.com/ribice/glice`
+
+### Run
+`$ glice`

operations/collaboration-guidelines.md

@@ -0,0 +1,165 @@
+---
+tags: 
+  - operations
+  - project
+title: Collaboration Guidelines
+date: 2020-01-01
+description: Guidelines for project collaboration between Dwarves and our Clients.  
+authors: 
+  - hnh
+menu: playbook
+type: null
+hide_frontmatter: false
+---
+
+Guidelines for project collaboration between Dwarves and our Clients.
+
+## Tools
+- Project management & communication: Basecamp (invited as Client)
+- Sprint planning & tracking: Jira/Basecamp
+- Meeting: Google Meet
+- Source control platform: Github/Gitlab (self-hosted)
+- Design: Figma/Sketch
+
+## Schedule
+- Project kick-off meeting: **1 session**
+- Sprint length: **1 week**/**2 week**
+- Sprint planning meeting: **1 per sprint**
+- Sprint review & retrospective meeting: **1 per sprint**
+- Sprint **daily standup** meetings (can as well be done via a communication channel or Basecamp's check-ins)
+- Project/team feedback meeting (with Account Manager): **1 per week** or **1 every 2 weeks**
+
+Meeting notes for Sprint planning and Sprint retrospective will be sent within 30 minutes after the meeting.
+
+## Workflow
+### Project Management
+- All team members must be involved in Sprint planning
+- Milestones and features (epics) should be put on Jira/Basecamp during the Project kick-off phase
+- New features/change requests will be put into Icebox/Backlog, estimated, and planned for future Sprints
+- Bugs can be added to the current Sprint depends on priority, complexity, and available points of the Sprint
+- The intention of every Sprint is “Potentially Shippable” Software, things can go wrong and features might get pushed to the next Sprint
+- Every 2 weeks, the Team Lead, Product Manager/Project Manager, and Account Manager will have a quick 15 minutes meeting to review the work progress and resolve any conflicts (if any)
+
+### Design <> Development
+- The design team should at least provide:
+    - Color palette (all that are used throughout the UI)
+    - Heading / Font size should be defined by scale (similar to [Tailwind's](https://tailwindcss.com/docs/font-size/#usage))
+    - Base components (.eg headings, button variants, and states,...)
+- A new design version is expected to be available and reviewed **by the development team** before the Sprint started
+
+### Backend <> Frontend
+- Pre-requisite:
+    - API versioning & documentation (.eg Swagger)
+    - Dedicated environments for Development / Staging / Production
+- Backend should enable CORS on either API gateway or at the application level
+- Both sides should agree on the same glossary/naming conventions / data schema, preferably within the first Sprint
+
+### Quality Assurance <> Development
+- Bugs/issues raised should include:
+    - Steps to reproduce, behaviorally described from application's entry to bug encounter
+    - Affected platform, version, feature, language (if applicable)
+    - Severity level
+- For Frontend (web), each feature's Pull Request will have a dedicated environment for testing. Use it to run feature tests before it got merged
+
+## Release
+- We release the end of each Sprint (on Sprint wrap-up day - the day before the Retrospective meeting)
+- Hotfix releases are ad-hoc
+- What's included in a release:
+    - Semantic version tagging
+    - release notes, changelogs, known issues
+    - release's artifacts
+- Backend and Frontend (or each micro-service in the system) will be released individually based on the Semantic version
+
+## Customer feedback
+We received and response to feedback via direct message, email, or video calls. Specific feedback should be directed to specific PIC in a project team:
+
+- Implementation/Development: Team Lead, Project Lead
+- Sprint result: Project Lead, Account Manager
+- Project progress: Project Lead, Account Manager
+- Pricing/Billing: Account Manager
+- Communication issues: Project Lead
+
+## Issues management
+We promise to respond and resolve in a timely fashion when problems arise, depends on priority & severity.
+
+After issues were resolved, we will conduct an issue investigation and provide preventive measures (if applicable).
+
+There are **4 levels** of severity:
+
+### Critical: 4
+The production system is down or a major function is unusable and there is no acceptable alternative method to achieve the required results. Support in such emergency issues is available via our hotline.
+
+- Contact channel: hotline
+- Response time: within 10 minutes
+- Promised resolve time: less than 30 minutes
+
+### Major: 3
+Major features of the product are failed and/or performance issues impacting the normal functioning of multiple users.
+
+- Contact channel: email, primarily communication channel
+- Response time: within 30 minutes
+- Promised resolve time: from 2 to 5 hours
+
+### Moderate: 2
+Moderate loss of application functionality or performance degradation. The system is still operating but doesn't meet promised standard operation.
+
+- Contact channel: primary communication channel
+- Response time: within 45 minutes
+- Promised resolve time: within 7 hours
+
+### Minor: 1
+Minor issues such as visual incorrectness .eg color or font size, product feature requests, and how-to questions.
+
+- Contact channel: primary communication channel
+- Response time: within 1 business day
+- Promised resolve time: within 1 business day
+
+Subject to the above limitations, we promise to respond to support requests within twenty-four (24) hours.
+
+## Billing
+Through every month, our Accountant and Account Manager will compose and send invoices to our Clients during the **23rd-25th**. The total invoice will base on the deployed resources, whether the project type is Fixed-price or Time & Materials (T&M). This method will enable a constant monthly cost, allows the Accountant from both parties to control the project costs & budgets more efficiently, as well as helping the Project Manager to foresee and eliminate any arising miscellaneous fees.
+
+Our rates are always recorded in **NET** amount, excluded from all types of taxes, bank fees, and account-related fees.
+
+Our invoice will contain the necessary information for the Client to proceed with the internal approval and wiring requirements:
+
+- Bank information
+- Invoice description
+- Invoice details
+
+The Client will have **10** **(Ten) business days** to complete these invoices. If the Client needs to extend the payment deadline, the Client is required to submit a written request to Dwarves Foundation within *72 hours* after the invoice date. A new deadline then will be decided and agreed by both parties, before it can be implemented officially.
+
+Our Accountant and Account Manager will send out reminders to the Clients who may have forgotten about the outstanding invoices. If any Client failed to complete the payment on time and failed to submit a request for an extended payment deadline to Dwarves Foundation, we will add a *10% interest rate/month* to the outstanding invoice(s).
+
+## Project Responsibility Scope
+To avoid us as a project team from stepping on each other's foot and to ensure a healthy relationship for the team and Client.
+
+**Team lead**
+- Main PIC of the offshore development team
+- Define technical stacks (together with the Client's team, if applicable)
+- Main PIC of project's infrastructure (if applicable, there are cases where infrastructure is managed/provided by Client's team)
+- Daily/bi-weekly/weekly progress sync-up and report to Client
+- Receive, discuss and make plans for project milestones
+- Run the development Sprint with offshore team and Client
+
+**Account Manager**
+- Receive Client's direct feedback
+- Make improvement plans for the offshore team from provided feedback
+- Maintaining the relationship between both sides
+- Ensuring development time, workforce and workload maps accurately to the Client's budget
+
+**Project Manager?**
+- Designing and applying appropriate project management standards
+- Managing the production of the required deliverables, and project administration
+- Adopting any delegation and use of project assurance roles within agreed reporting structures
+- Managing project risks, including the development of contingency plans.
+liaison with program management (if the project is part of a program) and related projects to ensure that work is neither overlooked nor duplicated.
+- Monitoring overall progress and use of resources, initiating corrective action where necessary
+applying change control and configuration management processes.
+- Reporting through agreed lines on project progress through highlight reports and end-stage assessments.
+- Liaison with appointed project assurance representatives to assure the overall direction and integrity of the project.
+- Maintaining an awareness of potential interdependencies with other projects and their impact
+adopting and applying appropriate technical and quality strategies and standards
+- Identifying and obtaining support and advice required for the management, planning and control of the project.
+- Conducting a project evaluation review to assess how well the project was managed
+preparing any follow-on action recommendations

operations/compliance-check-process.md

@@ -0,0 +1,54 @@
+---
+tags: 
+  - operations
+  - project
+title: Compliance Check Process
+date: 2020-01-01
+description: A comprehensive compliance program encompassing monthly audits, transparent progress tracking, and consequences for non-compliance, aiming to foster accountability and transparency within the team.
+authors: 
+  - hnh
+menu: playbook
+type: null
+hide_frontmatter: false
+---
+
+## Compliance Checklist
+Compliance master list is stored [here](https://docs.google.com/spreadsheets/d/16HtA3skVpEdDpuJ9UEkPb5Ae_SK6IiJ5Czfl_94XqN4/edit#gid=449337167).
+
+## Compliance execution
+Compliance check will be done in the monthly basis:
+
+- Each month compliance team will pick 30% projects to execute compliance checklist.
+- The master compliance checklist will be cloned to another file and name as df-compliance-<field-where-executed>-<yyyy><mm>. The file will be stored at same root folder with the master checklist.
+Example: *df-compliance-project-201905*.
+- Each file will contain the sheets for each project that being checked.
+- Compliance PIC will create a todo on Basecamp and assign to the PICs of those projects.
+
+## Result verification and action
+- After the compliance checklist is completed by the PIC of the project, compliance individual will do the clarification round by either:
+    - Sit with the PIC to ask questions about the result of the checklist.
+    - Assign the checklist for another team member of that project and compare the result.
+- PIC of the project will be responsible for the actions to fix the problems discovered during the compliance check session.
+- Compliance report will be produced by compliance PIC and will be presented to the whole team during engineering meeting.
+
+## Fame or Shame
+- Projects that have a good measurement in the compliance session will have "Fame" (TBD)
+- Projects that have a bad measurement in the compliance session will have "Shame" (TBD)
+    - If you have completed the compliance checklist but failed or cannot explain some categories, it is REQUIRED that you need a proper training on that topic.
+- Compliance checklist will be mandatory for the newcomers in order to pass their probation period.
+
+---
+
+I think the bottom line is what we aim to "audit" - our first attemption to audit (sometimes last year) was mostly technical, and we didn't run it seriously thus it ended in void (.eg none cares to fix raised issues).
+
+Now that I think about it, and after seeing what happened in setel, the most important thing to run these kind of program is to be transparent AND clearly point out action points & consequences.Transparent here means everyone knows about it .eg what/why/how as well as implicitly aware the consequences of not progressing as planned (bad ranking? khai trừ khỏi đ?ang?)almost all similar audits in Setel happened like this:
+
+1. announcement (why/what/how/expected outcome)
+2. progress tracking at team level (which team has done, in progress or no progress)
+3. weekly progress announcement & call to action
+4. why a team has not started? ask TL for reason & ask him to come up with a plan/tasks
+5. all done, announcement of completeness & outcome, phát phiếu bé ngoan
+
+We can leverage 2-3 to put an invisble heavy stone on someone's back for having to plan it himself to do it properly.
+
+Also it should be noted that all above 5 points above happened publicy - which helps to enforce individuals to aware & participate - seeing others progressing while I don't even know how to do it is a real stress, forcing me to proactively ask/lookup for more info. That's where work begins, with consistency it can educate members to fit in our workflow.

operations/email-communication-and-email.md

@@ -0,0 +1,56 @@
+---
+tags: 
+  - operations
+  - people
+title: Email Communication and Use
+date: 2020-01-01
+description: We use email as our formal tool for both internal and external communication. Every email is utilized for a specific field, which comes along with different instructions.  
+authors: 
+  - hnh
+menu: playbook
+type: null
+hide_frontmatter: false
+---
+
+We use email as our formal tool for both internal and external communication.
+Every email is utilized for a specific field, which comes along with different instructions.
+
+We currently go with these:
+
+## Communication
+### team@d.foundation
+For external communication. Clients or people outside the company should only know this email to communicate with us.
+
+Every email composed by team@d.foundation should be meant for external contacts, such as agreement or announcement.
+
+### ops@d.foundation
+For internal communication. Everything happens in the company, the operation email should be in the cc.
+
+ops@d.foundation email is used to
+
+- Inform employee on his/her employment issue (term of employment, salary adjustment, review, meeting)
+- Log conversation with clients from other personal team accounts (through cc)
+- etc
+
+### spawn@d.foundation
+For hiring. spawn@d.foundation stores every material used for the hiring process, which includes
+
+- Invitation for tests ( Pre-Assessment/ Assignment)
+- Receive *DO-NOT-REPLY* notification from CCAT (our resource to assess applicant's competence )
+- Confirmation/Reject email for applicants
+- Job offer
+- Automated receive CV from job sites (IT Viec)
+
+### accounting@d.foundation
+As it sounds, accounting@d.foundation is all for the issue that relates to money transaction.
+- Invoice information (in & out)
+- Notification on employee salary adjustment (through cc from Operation)
+- Tax
+
+## Development
+### miner@d.foundation
+Miner email is used by our Developers to create an account and log in all of our mobile applications for mobile testing.
+Whenever a problem or bug comes in our app, a notification should be dropped at this email.
+
+### thug@d.foundation
+For Infras registration e.g. Cloudflare, Google Cloud, AWS ...

operations/naming-convention.md

@@ -0,0 +1,38 @@
+---
+tags: 
+  - operations
+  - people
+title: Naming convention
+date: 2020-01-01
+description: This is the guide how to name your Email, Basecamp, Slack, Trello username.   
+authors: 
+  - hnh
+menu: playbook
+type: null
+hide_frontmatter: false
+---
+
+## Email
+- Email convention: <first_name><last_name_alias>@d.foundation
+- - Example: huytq@d.foundation
+-- Exception: Operations members with frequent communication will use <first_name>@d.foundation instead. Example: *han@d.foundation*
+- Google Profile need to be filled with github id OR name: <first_name> <last_name>
+
+![](assets/naming-convention_email-naming.webp)
+
+## Basecamp
+- Photo with your face picture
+- Name: <first_name> <last_name>
+- Title: Title at Dwarves Foundation
+
+## Slack
+- Avatar: Prefer that you put your face picture on
+- Fullname: Your full Vietnamese name. Example: Tiêu Quang Huy
+- Display name: Suggest to put your github id if you are a developer. Otherwise you can use <first_name> <last_name>
+- What I do: Your role @ dwarves foundation
+
+![](assets/naming-convention_slack-naming.webp)
+
+## Trello/Jira and other project tools
+- Advised to set avatar as your face picture.
+- Name/Nickname should be set as your github name. Otherwise please use <first_name> <last_name>