Work Log Guidelines

From Open Source Ecology
Jump to: navigation, search


See also Work Log

The Work Log is intended to be the main log of progress for any OSE contributor. In order to facilitate coordination across a globally-distributed team, a Work Log is key. This log should include hyperlinks to all work product - such that contributions are absolutely transparent to the world. This applies to volunteers to inform team members on progress, and it is useful for staff for planning, evaluation, and review purposes. We require that staff keep a daily log according to these guidelines. As an open organization, we are exploring how we could operate with full transparency - with minimum effort. A work log should take no more than 15 minutes per day if a person gets into a regular pattern of logging - and the positive effects of transparency far outweigh the cost of this effort. If this process is carried out diligently - even a quarterly report can be produced in no more than 15 minutes (how? see below.).



  1. Use frequent hyperlinks to work product - Place or embed all work product, such as wiki pages, Google Docs, videos, images, spreadsheets, diagrams on the wiki itself. If you are choosing another web location as a repository, link to that repository. We like to have all material posted on the wiki to minimize broken links if content goes off-line at other web locations. The Log is intended to be a hyperlinked index to work product more than an actual repository of work product. So in short: put all your work on the wiki. Our motto is, "If it's not documented on the wiki, it doesn't exist" (as far as the collaborative intent of this project).
  2. Log all relevant tasks as soon as they are done - If your contribution is relevant - log it. If it is not logged, it will be more difficult to provide you with attribution. Log right after you do something, otherwise it is easy to forget. This does not mean that you have Bookmark your log page and go to it after every task. Staff, volunteers, and remote collaborators are encouraged to keep a work log. Log everything that you do, on the same day that you do it. If you do not log it after task completion, you are less likely to remember what you did. Use our Date Format Convention. Roll up entries into a single link on a monthly basis - see links at bottom of Marcin Log for an example.
  3. Set weekly milestones and evaluate their completion - Every Monday, write down 3-5 milestones for the week. At the beginning of the next week, go back to this entry and document: (1) what you actually accomplished in the past week; and, if what you actually accomplished is different than what you promised, please explain the discrepancy. Then describe: (2) What worked for you? (3) What did not work for you, and how could that be improved? (4) Your plan for the coming week. This is for organizational learning and performance development purposes.
  4. Set monthly milestones and evaluate - See Review Process.
  5. Write a quarterly report - a quarterly report can be as simple as taking the Monthly Milestones and their Evaluation from the last 3 months - and compiled. Any extra comments on emergent patterns and point of improvement should be noted. Goals for the next quarter should also be listed, and these goals should be evaluated as part of the next quarter's report.
  6. Formatting - For the logs to be easily understandable and effective in communicating work product succinctly, we are suggesting a particular format that emerges from our practical experience. Make every day indexable by entering it as a heading, 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=. This makes it easy to identify the Monday entry - which contain Weekly Milestones and their Review, which are written down by the person who is logging for self-evaluation, and others can assist in this evaluation as part of an open learning organization. Document in paragraph format, don't sprawl your log as long lists or subheadings - for compactness and ease of visual navigation. Avoid lists whenever possible - and use a paragraph format instead. If you cannot resist using a list, use * instead of using a blank line - for compactness. Roll up entries into a single link on a monthly basis. See Marcin Log as an example, and see bottom of Marcin Log as an example of rolling entries up.


After you follow the General Guidelines - here are further guidelines for effective communication and accelerated technical development.

  • Embed images, diagrams, videos. This makes pages jump to life.
  • Whenever possible, include source code. This applies to word documents, designs, CAD, calculations, spreadsheets. For example - if you post an image, upload the original file so someone else can work with it. If you upload a PDF of CAD drawings, upload the original CAD file. If a file format is unsupported, compress it first and upload as the supported .zip format.
  • For Google doc embeds, embed the actual document and a link to that document. See Google Doc Embed example.
  • For images such as Gimp - upload original file.
  • Start a video sharing channel (such as YouTube) so you can share vidoes and vlogs.
  • For Bills of Materials, link to online sources
  • Embed media in iframes, and embed all kinds of applcations within the wiki. Start windows such as at Flashy XM. See How to Create Frames and Windows in Media Wiki.


The Work Log is proving to be an effective organizational tool for OSE. The core team can observe and evaluate each other's work - and improvements can be made. Since this is posted openly on the wiki and is transparent to the world - any other global collaborator can assess the state of project activity, and be on-boarded effectively.

The key to making this work is to be regular and link to work product. While this may seem like organizational overhead - the potential benefit of increased collaboration outweighs the time cost of documenting. Further - if done conscientiously - and entry in the log takes seconds. We have seen a number of cases where improvements, offers, suggestions, and new collaboration sprouted because of our extensive documentation.

By doing this, we are pushing the limits to open collaboration and sound governance.