emacs-wiki-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[emacs-wiki-discuss] Re: Collaborative Planning


From: Sacha Chua
Subject: [emacs-wiki-discuss] Re: Collaborative Planning
Date: Thu, 03 Jun 2004 12:40:26 +0800
User-agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux)

address@hidden writes:

(Cc: reply from a private message)

Hiya, Jorge!

> -- This was originally ment to go to the emacs wiki mailing list, but I
>    got not through the subscription process, yet.... hope you find it
>    useful anyway. Thx.

I've directly subscribed you. I'm curious about what problems you
encountered with the subscription, though. Do you think your mail
server is blocking subscription confirmations?

> Recently I had to start to systematize and *share* my planning.
> Luckily I stumbled over Planner.el! Excellent Work! Thank you all.

Thanks! If you share your planning, you might be interested in what
David O' Toole has been doing. He uses planner to maintain schedules
for other people as well.

> I am using a Debian/GNU/Linux System, unstable, and installed
> planner-el from there, so I think, that it may be somewhat out of
> date.

planner-el in Debian tracks the stable version. If you want to try the
development version, you can find instructions at
http://www.emacswiki.org/cgi-bin/wiki/PlannerModeQuickStart . Features
and bugfixes get merged into stable when other people confirm that
they work, which could take a while.

> writing this post I realize, that there exists an Info File for
> Planner Mode, however I hope that my (still rudimentary) document is
> a usefull complementation.

I'd love to add your notes to the quick start guide and other docs on
the Emacs Wiki.

> While using Planner for about two weeks now, it has been dificult
> for me, to integrate and configure all the parts I need.
> Especifically it is important for me to interchange and share
> contacts, appointments, etc. It seems that one has to be an Elisp
> programmer and long-time Emacs user to be able to make fluyent use
> of Planner et al. That's sad, because the concept of Planner is
> nice, fuzzy and gives you a warm feeling ;)

Basic planner usage should be easy even if you don't know Emacs Lisp,
although the collaboration you're thinking of seems a bit
complicated... <muses>

How can we make this simpler?

> The "emacs-wiki-directories" variable (or an underlying concept)
> could be abused to sectionate information inside a Emacs Wiki
> Project in me/team/world realms. All pages of a Emacs Wiki can be
> distributed over several directories, suppose (at first) they are:

If I had a lot of information that I'd like to keep separated, I'd
probably handle this with separate emacs-wiki-projects instead.
emacs-wiki-projects requires some Lisp hacking to understand, but the
example created by planner.el (WikiPlanner) might be a good place to
start. ~/Plans is already part of the WikiPlanner project. You can
create other emacs-wiki projects for ProjectA and ProjectB. These
would be plain emacs-wiki projects, not planner projects.

I'm not sure what an elegant way of using planner for different
projects would be like. You'd probably need to set planner-project,
planner-directory and planner-publishing-directory as part of the
variables in emacs-wiki-projects.

I haven't played around with this very much because I find that plan
pages inside my main planner project cover everything I need when it
comes to keeping information on separate projects.

> However, when it comes to publishing, the headache begins - I tried
> it out: If two pages in different directories have the same name,
> one of them is published, and the WikiIndex page has two entries
> pointing to it. This of course is not what would be wanted.

You'll probably want separate wiki projects for that.

> nicer aproach could be, that the emacs-wiki-directories in reality
> is a three-segmented list of directories:

emacs-wiki-directories is simply supposed to be a list of directories
that have emacs-wiki files. You might want to check out Gary Vaughan's
code that allows multiple subdirectories, but he needs to specify
relative paths in order to link.

> Maybe the InterWiki feature is more fit for creating the solution to
> my problem, or can be interspersed with the other actually existing
> features to create a yet usable solution to colaborative planning

InterWiki looks like it might do the job.

> with Planner Mode - I haven't seen through it. However I foresee at
> least the problem, that it is currently very complicated to set up
> new Emacs-Wiki-Projects when using Planner Mode, because Planner
> Mode updates dinamically the emacs-wiki-projects variable heavily,
> and we would have to set up several emacs-wiki-project as Planner
> Mode...

You need to make it planner-mode only if you heavily use the task and
notes functions. I don't think those survive well under collaboration.
<muses> Perhaps you can keep a planner-mode wiki for personal use, and
then use a more multi-user-oriented wiki like Twiki or Oddmuse to work
with others?

> [1] Team planning
>
> To set up team planning we distinguish three diferent realms: me, the
> team and the rest of the world.  We need to set up our Project in a
> way, that
>
> 1. our private information remains visible when visiting the project:
>    notes, contacts, appointments, etc. so we can take them into
>    account when planning events.
> 2. Team relevant information is inmediatly available to us, and we can
>    contribute information to the team
> 3. The world can get to the relevant information about the project.

Yes, this sounds like more of a job for a web-based wiki like Oddmuse.
<sheepish grin> planner.el so far has been intended for personal use,
and isn't quite equipped to handle working with others. We have no
syncing/locking mechanisms, for example...

-- 
Sacha Chua <address@hidden> - Ateneo CS faculty geekette
interests: emacs, gnu/linux, making computer science education fun
http://sacha.free.net.ph/ - PGP Key ID: 0xE7FDF77C




reply via email to

[Prev in Thread] Current Thread [Next in Thread]