Den 19. aug. 2009 kl. 16.30 skrev David Crossley:
General note:
This is an excellent example of the flexibility and usefulness of
Forrest. We (a project team geographically distributed) have regular
meetings using voicechat software + a collaborative editor (usually
SubEthaEdit because we are on Macs, but Gobby will do fine), we write
in jspwiki format, ie structured, plain text (the KISS principle),
which is transformed by Forrest to online meeting memos (pdf, html)
and task lists in iCal format using the plugin described above.
This is very interesting. Thanks so much for sharing a
situation for how you use Forrest. That should encourage.
:)
This is very timely for me. I need to help with forming a
co-operative and they will need to conduct their first meeting
of distributed members.
I did a net search and found some of your explanations
at divvun.no ...
Nice to know that our documentation is being read by someone:)
will see what tips i can glean. Thanks.
You are welcome:)
One reason I'm turning this local adaption of Forrest into a plugin is
that it needs improvements. I had hoped that the improvement process
would benefit from feedback from the community - and this has already
happened in the form of the suggestion from Ross about using our xml
properties system (see the other reply in this thread). Also the
encouragement I get from the above comments helps a lot:)
Presently the ical plugin presupposes that all tasks are summarised in
the last section of the document. This makes it easy to parse, xml-
wise, but it has turned out to not work that well in the meetings. We
basically have to maintain a status of each task at two places: under
each topic we discuss, and at the end of the document.
I will try to enhance the plugin to be able to automacially extract
and collect all tasks for the relevant person directly from the
topics' todo lists. This will make the task summary at the end
superfluous - it is really only a reflection of my xsl capabilities
(and time constraints) at the time when I wrote the original code.
This enhancement will of course make the xsl code more complicated,
but it will support a more logical meeting flow, and also encourage
the use of the ical task lists by the team members. Up until now
several team members have just copied the list at the end of the
document, instead of using the ical feature. When there is no list to
copy, they *have to* use the ical task list;)
Another enhancement I plan is to add support for explicit deadlines
for each task. At the moment each task is given a default execution
time of one week, ie until the next meeting, which isn't very flexible.
Finally, I would like to be able to generate some sort of stable ID,
to make it possible to update tasks imported into calendaring apps. As
it is now, each time an ical task list is imported, all tasks are
added as new tasks, even though the majority of them are only updates
(or even copies) of already existing tasks. I'll see what is possible
within the limits of of the ical format.
Best regards,
Sjur
