Daily Log of Tasks

Last updated Nov 1, 2018

Introduction

OSE promotes the use of a Log by all individuals and projects because the key to effective global collaboration is transparency and awareness of what any other individual or team is doing. A Log is a concise summary of tasks done with numerous hyperlinks to work product. It is intended to be used primarily for documentation, planning, review, and coordination.

It is different than a regular Blog in that it focuses on access to work product as opposed to a narrative. Logs are intended to be quick notes, which take a few seconds of time and are therefore not a chore. They should not be as refined as Blog or some other piece of formal writing - the goal is to simply keep a record of ongoing activity with intent of maximizing collaboration. The simple theory behind a Log, and behind documentation in general - is that if it is not documented, it effectively does not exist - from the standpoint of potential collaboration on the internet. One should keep in mind that a log is a permanent record, and as such, if nobody reads it today or tomorrow, it does not mean that someone won't see it next year - if the content is relevant from a long-term perspective.

Once you set up a Work Log, you can request a timesheet (graph of your work hours) by using the Time Log Request.

The work logs are a critical tool that enables large teams, up to 1000s of people, to inspect readily what any other contributor is currently doing. Combined with Special:RecentChanges, one can get self-oriented on the progress of the project.

Sample Work Logs

You can see a full list of personal and project logs at Logs. Here are some examples:

1. Marcin Log
2. Michel Log
3. Jessica Log
4. William Log
5. Michael Log
6. Abe Log

When we do group design work, we post many log links on the same page so people can cross reference each others' work - see J for an example.

Instructions Summary

To start a work log, set up an account and log in to the Wiki - see Instructions. Then create a page titled Your_Name_Log - such as Marcin Log. Keep daily entries for every day Monday-Friday, and record entries with a date. The format for the dates should be placing the date in between = signs (this is a heading in Wiki language). The proper heading format is, for example, "Tue Apr 8, 2014". Then, record newer entries on top, so that one does not have to scroll down a page to see your latest work. When recording entries, you should have a link or picture embed to all that you have done.

Format

• Include timesheet on top
• Links to work product, without content
• Organize by Date. See Marcin Log for example. Key point - use every day as top level heading
• Log daily as soon as you work on something
• One click access to work use
• Use common terms for work product that can be used as wiki words
• Fold up by Month - such as [ [ MJ Log June 2018 ] ]
• Make it Ctrl-F for findability

More

• Folded up quarterly into links (quarterly development cycles)
• Content does not go on log, bit on linked wiki pages
• Remember - main purpose is coordination. Therefore links to content - not content. The log is not a blog.
• Use page names according to Development Template convention.

List of Logs

• See Logs for project-based and person-based logs.

Work Log Checklist

Log your work for learning purposes - so you can learn to do it better the next time. This is a list of best practices for logging work for OSE:

1. Did you link to your work product?
2. When listing items that you have done, did you write down a complete list to avoid potential redundancy with other collaborators working in parallel?
3. Is the entry specific, so others could help?
4. Is the entry self-verifiable? That is, is there a link to work product or other evidence that the work has actually been done, or that you and not someone else did it?
5. Are you keeping weekly planning goals on your log?
6. Are you formatting your log with the latest entry on top, and date formatted as in Marcin Log as an example?
7. Is continuity/progress visible in your log?
8. Are you using the versioning capacity of the wiki to upload new files?
9. Work publically as much as possible. For email - send a link to wiki - don't write a private email. If it's not shareable - why are you writing an email? We think of global replicability.
10. Are you using clear wikiwords?
11. Is work product 1-click accessible?
12. Are you keeping 1-click accessibility for 2 months back, and folding older work into new wiki pages.
13. Do you understand naming convention?
14. Are you owning the wiki with redirects?
15. Are you addressing difficulty with links by setting up wiki words.

Key Points

• Update log daily or as relevant work is done. Presumption of non-logging in a given time period is that no work has been done.
• 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.
• Self-Verifiability. Self-verifiability is an aspect of Transparency. Self-verifiability of the work log can be achieved by linking directly to work product - so that credit can be given for work done.
• 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 sharing 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, reviews, 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 on the Critical Path for deploying the GVCS and building the world's first, post-scarcity, open source, global village.
• Weekly project meetings are logged at the D3D Log for the 3D printer.
• 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.

Links

• See list of logs - Logs