Daily Log of Tasks

Instructional Video on How to Write a Work Log:

Work Log Checklist

• Did you link to your work product?
• When listing items that you have done, did you write down a complete list to avoid potential redundancy with other collaborators working in parallel?
• Did you include a link to your email that you copied on the wiki?
• Is your log for that day self contained (ie, do not say something like, "finish goals of last week", but instead, list them explicitly)?
• Is the entry specific, so others could help?
• Is the entry self-verifiable?
• Did you write no more than 3 goals in your weekly planning?
• Did you bold your weekly planning and review?
• Are you keeping your log compact?
• Is continuity/progress from the former's week work clear in the weekly planning and review?

Introduction

A Log is a concise summary of tasks done with numerous hyperlinks to work product. It is intended to be used primarily for planning, review, and coordination. It is different than a regular Blog in that it focuses on access to work product, while minimizing philosophy and cute comments - for which a personal blog should be used.

Key Points

• Update log daily
• Add most recent update on top of page
• Link directly to new results every day so that result can be viewed in one click from your log
• Log items that have been logged previously, if updates have been made to those links
• If you are linking to an update on a page and only a small item has changed on that page, link to that specific item that has been changed - if possible.
• Keep log tight and short. Put all results on other pages, and link to those pages - so that a comprehensive picture of one's work is seen immediately. See Marcin Log as an example.
• At best, the Work Log should consist mostly of hyperlinks, with short description of what the hyperlink is.

Design Rationale

Log of progress should include who was contacted, resources found, links to work product generated, comments on what is working and not working, and any insights on the organizational process. See Marcin Log for an example. Tasks shall be logged as soon as they are completed. This is intended for:

• Organizational learning - to assess and review the duration of tasks, scope of tasks performed, what worked and what didn’t. Future team members can look at the log, learn from the tasks done, and assess the time that it takes to do certain tasks.
• Team coordination and project status- Work logs are universally identified within the team as a location for logging activity, and have a unique URL that any other team member can access, as in opensourceecology.org/wiki/Name_Log - with the name corresponding to the team member’s name. Any team member can view another person’s log. Since the log is done on a continuous basis as soon as tasks are comppleted, anyone can find out what has been done as soon as it has been done.
• Transparency. This allows other team members to see what is happening for purposes of transparency. Credit can thus be given properly to those who log tasks. If a task is not logged, others can not learn more about that task. Such trasnparency promotes autonomous operation within OSE.
• Management scalability - Work logs provide universal indexing of a person’s work. Once there is a large number of people working on a project, an easy way to access a person’s work product is through the person’s log. The log is intended to be accessible with zero access barriers, an essential part of an open, collaborative organization. A log allows indexing of large amounts of disperse content from an unlimited number of people.
• Open culture - Work Logs are visible to the world, and thus promote working openly and collaboratively.

Effective Communication

To facilitate effective communication via the Daily Log, keep the following points in mind in order to help others learn rapidly from and assess your work.

• First and foremost - log your work in a concise paragraph instead of spreading it over a number of pages, and link to work product on other pages instead of embedding work product on the Work Log. This allows one to see daily work and weekly work product readily.
• Critical insights should be captured in the log. If a link is simply posted, one cannot tell what to expect from the link.
• The power of the wiki lies in using wikiwords - ie, a word or phrase in double brackets in edit mode allows you to link directly to any other page or subheading on the wiki. This way, you can build on former work without having to explain each time. Any wikiword becomes its own page on the wiki.
• Communicate as much as possible like you are commuinicating to the first-time reader in order to provide perspective. This means for concepts or formerly entered concepts or pages - link to those pages in your explanations as wiki words.
• Feel free to create pages that are simply definitions of words or phrases that you are using - so you can refer to that page any time in the future by putting the link in double brackets.
• Do not overwrite wikiwords that are already used if you are documenting a different usage of that wikiword, just start a page with a different wikiword. This is because any other pages that link to that page would then be pointing to the wrong definition.
• To inform the reader more fully, try to provide context as relevant. For example - if a link is a new entry in the wiki, write 'Started page so and so'.
• Always try to inform the reader about the context and perspective of your work. Useful work could be finding, sourcing prices, finding an online design calculator, reading, reviewing, starting wiki pages, editing a wiki page, continuing on work from another day, making video, taking pictures, writing an instructional, conference calling, getting something reviewed, picking up where someone else left off, etc... Please make a note of such activity and include a link to anything online, and for something that you generated (picture, document, video), upload it and link to it.
• If you want to upload an unsupported file format to the wiki which the wiki does not allow you to upload - compress it to a zip or other format and upload it then. The wiki supports uploads of compressed files such as .zip.
• If you are adding to an existing page, think of creating a subsection so that you can link to it directly as a wiki link. Otherwise, the only way for the reader to see what you have contributed is to look at the page history, which takes more time.
• If you are reporting a physical result, you should include a picture or video.
• If you are reporting a concept design, link to a google doc drawing or other diagram .
• If you are doing conceptual design - use google docs - so others can view and download the source. Set up sharind accordingly.
• If you are embedding google docs, paste a link to the actual document so others can access it directly to view, comment, or edit. This allows global collaboration to happen.
• When posting pictures or files - do not just put them on your log - but also on the related wiki page for that particular project.
• If you are uploading pictures as a zipped file - embed at least some of the pictures or thumbs themselves for viewing - for easy access - especially if the file is large and it takes a long time to download just to view the pictures.

Guidelines

To make the most use of the log as a cloud platform:

• Keep track of and coordinate with other core developers. Take any name - and you should be able to find their log: ex: Marcin Log, Gabi Log, Yoonseo Log, Lenny Wayne Log.
• There are also project based logs - Guatemala Log, Power Cube Log - in addition to personal logs - for tracking projects which have multiple participants.
• Any documentation relevant to GVCS technical deployment - video, pictures, diagrams, reeviews, etc - should be copied to or linked to the wiki. For example, a picture of a build should be embedded in a wiki procedure, and if there is a relevant album of images, that link should be placed on the wiki.
• Google Docs should be embedded and an Edit link should be added for easy access.
• Iframes and other embeds should be taken advantage of - to make the Wiki a central repository of all project-related material.

Standards

• Document any work relevant to critical path as discussed in Executive Director's Statement for deploying the GVCS and building the world's first, post-scarcity, open source, global village.
• Write a Weekly Milestones plan for review on Monday noon daily coordination meeting.
• Use hyperlinks for work product. Do this by putting hyperwords in double brackets. See Wiki Instructions.
• Make every day indexable by entering it as a heading, such as =Thu Oct 11, 2012=, such that any day can be accessed from an automatically-generated index on top of wiki page.
• Use Weekday, Month, Day, Year as standard headings, such as =Thu Oct 11, 2012=
• Roll up entries into a single link on a monthly basis, see bottom of Marcin Log for example.

How To

For a log to be effective it should provide on a daily basis:

1. Tasks done
2. Comments on important learnings
3. Links to all work product that took more than 15 minutes to complete. All work should be documented on wiki
   1. This is easy for organizational work: start a wiki page with what you did with links
   2. For physical work, take pictures and vlogs, link to them as your work product
4. Do this on a running basis to allow the log to serve as a monitor of progress that other team members can use to facilitate coordination on a sub-hour timescale

On a weekly basis - the Log should provide a Weekly Assessment- including Planning and Review:

1. At the beginning of the week, list your goals for the week
2. At the end of the week, assess:
   1. Did you meet your milestones?
   2. If not, why not, and how you can do better?

Execution

Make it really simple. Start a wiki page named Name_Log, such as Marcin Log. Add new posts on top of page. Every two weeks, roll up the entries into a 2 week history - so the Index doesn't get too lengthy. Repeat for every month, quarter, and year.

1. Log tasks in an ongoing fashion.
2. Week plan due Monday: what do you intend to do this week (in your own words)
3. What did you in fact do this past week? What unplanned items?
4. What is your own assessment of that / your progress?

1. Share it with each other - over Monday dinner?
2. Sharing it means, if you didn't do it, you at least have to think about it while being shared.
3. You want to write things down, because then it'll be hard to think of things you did, and it'll look to the group like you didn't do anything.

Explanation of Daily Log

The purpose of the Daily Log is to facilitate organizational learning and performance management by promoting feedback, assessment, and transparency. The Daily Log is required for people at Factor e Farm.

A Log allows others to access quick links to review work - which is highly relevant when working on a distributed team where many people provide feedback. This assumes that links must be explicit - we do not assume that someone knows how to find a link online.

When people log their work - this work can be evaluated and assessed for efficiency, direction, and prioritization. Without a task log, it is not possible to evaluate and learn about what a person is doing.

Further, OSE is an organization that incubates other OSE Incubators. For organizational learning across these Incubators and other OSE Chapters, it is important to document what people are doing to clarify expectations/process/etc.

Further, the weekly Log serves as the basis for Monthly Planning and Review:

1. What were the major milestones reached?
2. What were the major milestones missed?
3. What did you learn this month?
4. What could you have done better?
5. What are your milestones for next month?

See sample Daily Log - Marcin Blog

Comments

From Colby: Have a process where people set their own goals and timeline and present them to the group and file them on a wiki. Then meet weekly and have them add a status update with what they accomplished over the week (or even daily).

Each month, have them present to the group the summary of their accomplishments each week, lessons learned, how they are on schedule, what "unplanned items" came up that delayed the schedule.

Keep track over time, the number of weeks in which they hit their own goals and didn't. Offer each time they don't hit their goals that they can come for you for advice.

The same thing applies to under and over budget, etc.

Once a month or week, take part of a day and sit down with each person for 10-15 minutes to discuss what is going well and isn't... and look at their progress reports and schedule.