Consistent and Minimal

Most important rules:
Be consistent.
Be minimal.
Read these sections carefully.

Version plan

The version plan goal is to report your progress during the day. Your current task should be shortly described in the version plan header. All other tasks in the body of the version plan should be according to the version plan legend.

Header

The current task should be logged in the version plan header, together with a rough estimation of the task's duration.

stanislav (Stanislav Klyukin) infra/nir: show loading in graph header stanislav (Stanislav Klyukin) infra/nir: show loading in graph header 5d stanislav (Stanislav Klyukin) infra/nir: show loading in all graphs 5D stanislav (Stanislav Klyukin) infra/nir: show loading in graph header 1D

In case the task is less than a day, include your next task.

ekaterina (Ekaterina Perepelitsa) design/nir: lum icon 2H ekaterina (Ekaterina Perepelitsa) design/nir: lum icon 2H then hola icon 1D

In case the line is too long, make sure to add two (2) spaces at the start of the next line.

ekaterina (Ekaterina Perepelitsa) design/nir: hola cdn android and ios sdk pages redesign 2H then hola cdn banners redesign 1D ekaterina (Ekaterina Perepelitsa) design/nir: hola cdn android and ios sdk pages redesign 2H then hola cdn banners redesign 1D

Report the day you will come back from your vacation

niv (Niv Shimoni) infra/nir: 05-Nov-2017 - 10-Nov-2017: vacation niv (Niv Shimoni) infra/nir: vacation till 10-Nov-2017

Task header

First line of a task should contain the product and a short description

- change icon - mdoc.holaspark.com/cdn/lead: change activities add icon

If the requester is not you mentor, you should add him in brackets
When finishing the task, the 'Done' email should be sent to the requester and a CC to your mentor

- a task from derry: mdoc.holaspark.com/cdn/lead: change activities add icon - mdoc.holaspark.com/cdn/lead: change activities add icon (derry)

When task is from another tasks file, you should add that file, short version name for cvsed in square brackets.
You should add your name in brackets as the begining of the task in the task file and mark it with *
When done, you should mark + in both version_plan.txt and the task file. 'Done' email

- mdoc.holaspark.com/cdn/lead: change activities add icon (derry) [mt]

Legend

• - Planned task
• * In progress task
• + Done
• o On hold task
• ? Decision pending task
• c Canceled task

Body

The body of the version plan should contain all - (Planned), * (In progress) tasks:

* c/pl -> js * system/host/stored_hashes.c * convert to js (create a file called store_hashes.js) - system/host/create_user.pl -> js - system/vpn/connect_to_vpn.c -> js - more from move_to_js.txt - upgrade mongo 3.0 -> 3.2

Tasks that were requested by other then your regular mentor, should have the mentor name in brackets

- for omri: holaspark.com top headers are not aligned - holaspark.com top headers are not aligned (omri)

Do not use uppercase as first letter

* C/pl -> js * System/host/stored_hashes.c

Only tasks that benefit customers should be listed, typically tasks that:

• end with a commit
• end with a deployment
• fix a bug
• improve the product
• solve a problem for a customer

Learning is by-product of doing.

- get forms from IT * c/pk -> js - convert system/host/create_user.pl -> js - learn perl - convert to js (create file called create_user.js) - unit-test * c/pk -> js - convert system/host/create_user.pl -> js - convert to js (create file called create_user.js) - unit-test

Priorities

Tasks are sorted according to their priority (top-to-bottom).
* (In progress) tasks are usually very few (1-2), not more, representing your current work effort and should be added to the header of the version plan.
Tasks which started (code was partially written/committed) and then stopped, should be marked with o (On hold).

Work in progress

Incremental

Tasks longer than 1 day must be divided to committable subtasks

- system/host/store_hashes.c - convert to js (create a file called store_hashes.js) - unit-test - test&debug * system/host/store_hashes.c * convert to js (create a file called store_hashes.js) * convert read_hash - convert validate_hash - unit-test - test&debug

Updates

The version plan should be updated once a day, reflecting the current tasks you are dealing with.
Updating this file can be done easily with cvsed.

History: completed tasks

Done (+) and canceled (c) tasks are being cleaned automatically from the version plan every Sunday.
These tasks can be found in the doc/design/version_history.txt file.

Daily file

The goal of the daily file is to report your daily achievements, describe your commitment and state your next planned tasks.
In the commitment section, write the tasks you plan to finish tomorrow. In the planned section, write the task you will start after the tasks in the commitment section are done.
Update this file every day, usually at the end of the day (you may choose to update it in the beginning of the work day, summarizing your previous working day).

Updates

The daily should be updated at least once a day, reflecting the current tasks you are dealing with, as well as explaining what you are going to do next.
Updating this file can be done easily with cvsed.
People in Spark like to use cvsed vpd to constantly update their daily with every task they start or finish so everybody will be updated with their progress, as well as it won't take them long to update it at the end of the day.

Legend

We are using the same version plan legend.

Template

Report your daily achievements, describe the tasks you will complete for sure in the next day (commitment:), and the task/s your are about to start once completing your commitment (planned:).

01-Dec-2015: * GIF generation for hola homepage + fixed a bug in hola homepage 01-dec-2015: * GIF generation for hola homepage + fixed a bug in hola homepage 01-Dec-2015: + fixed a bug in hola homepage * GIF generation for hola homepage commitment: * GIF generation for hola homepage - complete (commit and deploy) phase 1 of GIF generation - continue work on rest of GIF generation - expected to be around 3 days planned: - implement new signup wizard

No uppercase as first letter

Do not use uppercases as first letters in the body of the daily file.
Uppercase as first letter is used only for the month in the header of the daily file.

13-Oct-2016: + Optimize lum/cdn top bar loading * Lum customer selector out of sync Commitment: * Lum customer selector out of sync Planned: - Unsubscribe from evaluation emails 13-Oct-2016: + optimize lum/cdn top bar loading * lum customer selector out of sync commitment: * lum customer selector out of sync planned: - unsubscribe from evaluation emails

Descending order

Your latest report should be the first one in the file.

13-Oct-2016: + optimize lum/cdn top bar loading * lum customer selector out of sync commitment: * lum customer selector out of sync planned: - unsubscribe from evaluation emails 14-Oct-2016: + lum customer selector out of sync * unsubscribe from evaluation emails + add unsubscribe token generation * build unsubscription front-end logic commitment: * build unsubscription front-end logic planned: - add eremind pagination 14-Oct-2016: + lum customer selector out of sync * unsubscribe from evaluation emails + add unsubscribe token generation * build unsubscription front-end logic commitment: * build unsubscription front-end logic planned: - add eremind pagination 13-Oct-2016: + optimize lum/cdn top bar loading * lum customer selector out of sync commitment: * lum customer selector out of sync planned: - unsubscribe from evaluation emails

Work week definition

State you usual working week days and hours, so everybody will know when to reach you. Include both your local time and IL time.

WORK_WEEK: Mon-Fri 11:00-18:00 WORK_WEEK: Mon-Fri 11:00-18:00 (14:00-21:00 YEKT)

Absence

Vacations and other out-of-office cases should be reported (in advance if possible).

23-Mar-2016: sick 23-Mar-2016: miluim 23-Mar-2016: day off 23-Mar-2016: 0.5 vacation 23-Mar-2016: 0.5 day vacation 23-Mar-2016: miluim

State if you worked only part of the day.

01-Dec-2015: 0.5 day off + optimize lum/cdn top bar loading * GIF generation for hola homepage commitment: * GIF generation for hola homepage - complete (commit and deploy) phase 1 of GIF generation

State planned vacations ahead of time.

23-Mar-2016 - 29-Mar-2016: vacation

Support

Support fill out every issue they work on in their daily file so we can see the big picture of what is bothering our customers and improve.

Format:

23-Mar-2016: HOURS_WORKED + HOURS CUSTOMER TOPIC: DESCRIPTION 23-Mar-2016: 0.15 + 0.05 adverif billing: did not receive invoice * 0.1 carrentals lpm: docker lpm crash over 100req/s

Hour notation is 0.1 = 1H:

+ 0.05 adverif billing: did not receive invoice + 0.5H adverif billing: did not receive invoice + 30min adverif billing: did not receive invoice

Only mention tasks above 0.05 (30min):

+ 0.05 adverif billing: did not receive invoice + 0.005 adverif billing: sent link to faq

Break tasks by topic:

+ 0.5 monitor: call with customers + 0.05 adverif billing: too many cc + 0.15 giboo blocked: trouble scraping buy.com/prod/123 + 0.1 dounut cp: buttons don't work on firefox + 0.1 cashflow billing: account susp[eneded for late payment + 0.1 bighat lpm: link tester crash on centos 5

Use standard topics so we can grep issues by topic.
Topics: mdoc, billing, lpm, bext, google, unblocker, cp, blocked

+ 0.05 adverif safecharge: too many cc + 0.05 adverif billing: too many cc

Design documents

We write designs for specific features to usually coordinate between several programmers and to layout the way we would like it to be created.
The document will hold a technical description of the feature as well as a list of prioritized tasks. We are using Jdoc to notify the relevant people on the status of the document as well the progress of every task.

Legend

We are using the same version plan legend.

Priorities

Since we believe in incremental development most likely the newly feature will be deployed very soon and a list of tasks will start to be piled up. To coordinate between several people working on the same feature the below defines handling priorities:

• P0: Critical functionality is completely broken. Stop everything you do and handle this task
• P1: A specific feature is broken or partially working. Handle top-to-bottom
• P2: Enhancement to be added. Handle top-to-bottom
• P3: A nice to have feature. Handle top-to-bottom
• P?: Not decided yet - task is waiting to be classified by the OWNER

- P1 bug: session_duration is broken. Should be fixed and add unit testing. - P1: session_duration is broken. Add unitest.

Assignments

Once the task is assigned, the developers login will be added to the task

- P1: session_duration is broken. Should be fixed and add unit testing. (alex) - P1 alex: session_duration is broken. Add unitest.

Task info

The requester should be added in brackets at the end of the task.

- P1 alex: session_duration is broken. Add unitest. (niv)

In case the task came from a customer, add him after the requester's login.

- P1 alex: session_duration is broken. Add unitest. (niv cust_id)

Once the task is completed, notify the requester and the customer.