This policy regulates all work relationships between Teamed.io and you, a remote team member. We follow the principles of the eXtremely Distributed Software Development (XDSD) methodology. Read how XDSD is different than others. Also, see our FAQ.
These articles are mandatory for everybody to read:
- Stop Chatting, Start Coding
- How XDSD Is Different
- Definition of Done
- No Obligations
- Five Principles of Bug Tracking
- Bugs Are Welcome
- How to Cut Corners and Stay Cool
- It’s Not a School!
- Project Lifecycle in Teamed.io
Note: paragraphs are numbered, but not ordered — this is done intentionally.
§1 When we start working with you, you’ll get a few tasks in a few of our campus projects. They are paid, managed, and rated the same way as all other tasks, but the projects are open source and hosted in GitHub.
§2 Once we see that you’re capable of working on a commercial project, we’ll electronically sign a formal contract with you and invite you to a few commercial projects.
§3 We communicate with you via Netbout.com. Please create an account there and send your username to us by email.
§4 Project communications are kept solely in tickets. We don’t use any other communication tools, like emails, Skype, phone, conferences, or chats. Read these articles: Five Principles of Bug Tracking and Stop Chatting, Start Coding.
§5 Each task has a pre-defined budget, in minutes, which is announced by the project manager. The budget is not negotiable. When the task is done, you’ll get a payment equal to the number of minutes in the budget multiplied by your hourly rate, no matter how much time you actually spent on it.
§6 Our definition of done is simple: The task is done if its author accepts the deliverables. Read this article: Definition of Done.
§7 If you don’t complete the task, you’ll get no payment, no matter what the reason for incompletion was, including someone else’s mistakes.
§8 For a code review task, you’ll get 15 minutes plus as many minutes as the number of comments you post in the discussion. Whether you accept the code or reject it, you’ll still get the payment.
§9 If you don’t want to work with a task — for any reason, post a message to the project manager asking to “assign someone else.” In this case, you’ll lose as many points as there are minutes in the task budget.
§23 If you want to stop getting new tasks for a time, inform us through Netbout, and you won’t get any new assignments for any of our projects during the desired period. Just post “@alice away” there.
§10 If you can’t complete a task on time, inform the project manager about it. Just post a message to him right in the ticket and ask for “more time.” If he accepts your request, you won’t be penalized for any delays.
§11 If you can’t complete a task on time because you’re waiting for another task to be completed first, inform the project manager. Post a message to him right in the ticket, saying you are “waiting for #123” (123 is the number of the ticket you’re waiting on). If he accepts your request, you won’t be penalized for any delays.
§12 When you find a bug in existing source code or documentation, report it properly, and it is accepted by the project architect, you’ll get 15 minutes added to your account. Read this: Bugs Are Welcome.
§13 Small, easy-to-find, easy-to-fix, or cosmetic bugs and tasks are not paid, even if they lead to a code change and project improvement. This decision is made by a project architect and is not negotiable.
§14 When you close a task, we’ll increase your rating by as many points as there are minutes in the task budget.
§15 When you complete a task, we’ll measure the speed of delivery, which is the time interval between the moment you were informed of the task by the project manager and the moment you were paid for its completion.
§22 If you complete a task in less than 24 hours, you’ll get a 100 percent bonus on top of the task’s budget. If you complete it in less than 48 hours, you’ll get a 50 percent bonus. If you complete it in less than 72 hours, you’ll get a 25 percent bonus.
§31 If you complete a task that has a boost factor attached to it, your payment, together with the bonus, will be multiplied by that factor.
§16 You have 10 days to complete a task. If you fail, no matter the reason, we’ll assign the task to another performer, and your rating will receive twice as many negative points as there were minutes in the task budget. Read this No Obligations principle.
§30 If you hold a task for longer than seven days, you may get a notice from a project manager and be docked points for your rating in the amount of the minutes in the task budget.
§17 At any moment of time and at our own discretion, we may decide to stop giving you tasks and remove you from any and/or all projects. This usually happens for one of these reasons: 1) Your communication skills are poor; 2) Your rating is too low; 3) Your code quality is low.
§18 If you want to increase your hourly rate, send us a message via Netbout.com. There is no guarantee you will get a raise, but these factors will be taken into account: 1) your rating, 2) your average speed of delivery, 3) your communication skills, and 4) the number of bugs you report. This article explains even more: How Hourly Rate Is Calculated.
§19 All payment processing fees are reimbursed by us. No matter which payment instrument is used (PayPal, Upwork, or Bitcoins), we guarantee that you get exactly the amount you earned.
§32 There is a certain limit of tasks we’ll assign to you concurrently. When you start working with us, you’ll have two tasks maximum. When your rating is over 60, you’ll get up to five tasks. When it’s over 600, you’ll get up to 10 tasks. When it’s over 1,600, you’ll get up to 20 tasks.
System Analyst (SA)
§39 As a system analyst, you are responsible for validation and verification of product scope. First, you validate requirements to make sure the specification is accurate. Second, you verify that our product is in line with the specification. The specification (README file in GitHub) is your deliverables. Follow these guidelines: How We Write a Product Vision and Worst Technical Specifications Have No Glossaries.
§40 You’re allowed to communicate with the product owner via Skype, Slack, phone calls, and emails. Communication with programmers still has to go through GitHub tickets only.
Every time we pay for one hour to anyone in the project, you receive 10 minutes on your account. (suspended)
§42 While the project is in Thinking phase, you’re allowed to report any time spent. You will be paid according to your reports. Just say “I have spent 120 minutes for …” to the project manager.
§20 For each release you publish as an architect, you’ll get 30 minutes plus as many minutes as this formula calculates. A release is “published” when its status in GitHub is set to “final.” You have to ask the project owner to change the status when a new version is released and it satisfies the product owner.
§21 Each bug has to be accepted by an architect before it is paid and dispatched for fixing. As an architect, when you see a new bug submitted, inform the project manager that it is a valid bug by posting a message similar to “it is a valid bug,” or explain to the reporter what is wrong with the issue reported. Read this: Five Principles of Bug Tracking.
§26 As an architect, you can prioritize tasks into three categories: urgent, normal, and postponed. Urgent tasks are assigned to performers immediately. Normal tasks are assigned to performers only when the project has fewer than 10 assigned tasks. Postponed tasks are never assigned. To change any task priority, just ask a project manager with a statement like “this task is urgent,” or “this task is postponed,” or “this task is not urgent anymore.”
§27 As an architect, you can assign any ticket to one of the project milestones. To do that, just ask a project manager to, for example, “set milestone to 1.4.”
§29 As an architect, you can ask a project manager to assign any task to anyone; just say, for example, “assign @yegor256.”
§28 For each merged pull request, you’ll get 10 minutes if the quality is “good,” according to QA. To motivate code reviewer to pay more attention to details, you may ask QA to give “bad” quality to the pull request. In this case, the reviewer will not be paid, while you and QA will still be paid.
§33 Every few days, projects are checked by a project manager to detect mistakes in ticket planning, milestone organization, release discipline, etc. If any problems are found, you as an architect will get 25 points docked from your rating. If no problems are found, you’ll get 120 minutes. These rules are applied: 1) All tasks are dispatched within five days; 2) The latest release is either final or less than 10 days old; 3) There are no milestones missed for more than five days; 4) No tasks are stuck (in progress for more than 20 days); 5) There are fewer than six urgent tasks.
§34 As an architect, you’ll get an extra 15 minutes for each bug reported, on top of what you get according to §12.
§35 You may be designated in Netbout as an interviewer when we recruit new programmers. Apply your best judgement and try to be objective, as this article suggests. When ready, post “@alice verdict …” to the bout, explaining your decision. No matter what your verdict is, you’ll get 15 minutes.
§36 You may ask a project manager to mark any ticket as invalid or duplicate, just say something like “this is invalid” or “this is duplicate”.
§37 You can add a boost factor to any task, just ask a project manager to do so, for example: “boost factor is 2x”.
§38 While the project is in Building phase, you’re allowed to report any time spent. You will be paid according to your reports. Just say “I have spent 120 minutes for …” to the project manager.
Quality Assurance (QA)
§24 As a QA engineer, you’ll earn 10 minutes for each ticket reviewed according to our quality rules. You’ll get the payment right after you inform the project manager that the ticket passed the review. Your message should include your measurement of the quality, like “quality is good,” “quality is acceptable,” or “quality is bad.” No matter what remarks you make, you’ll get paid right after you post it.
§25 A ticket performer will get his or her payment only after the ticket receives your quality review. When you give a “good” mark, the performer gets a bonus. If you give an “acceptable” mark, the performer doesn’t get a bonus. When you give a “bad” mark, the performer is not paid for the ticket.
If you have any suggestions concerning this policy, please submit a ticket to XDSD repo. If you have a correction, please submit a pull request.