Daily Log of Tasks

From Open Source Ecology
Revision as of 22:39, 30 November 2012 by Donovan (talk | contribs)
Jump to navigation Jump to search

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.

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 Strategic Plan 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.