ORG: comments

Kyle Hayes kyle@putput.cs.wwu.edu
Tue, 1 Nov 1994 10:28:58 +0800


Luke made some recommendations:
> This group. For this to work we need some structure both centralized and
> decentralized. The centralized structures:
> 
> 	1. Centralized communications. We need one remailer. Second we need
> 	   a topics moderator. Someone who will pick the current topic
>  	   to discuss and only forward mail along those topics. We are currently
> 	   as a group suffering from brain diarrhea. That is we have too 
> 	   many good ideas oozing out of our brains. Lets agree to each
> 	   keep a record book that we can jot down our ideas in, so that we
> 	   can present those ideas in a concise and appropriate manner.
> 	   Also we need to take time to mull over peoples ideas so that
> 	   we can "work through them".
> 
> 	2. We also need someone who will volunteer to be the central workbook
> 	   keeper. In other words they are willing to keep a central design
> 	   document that we submit our work to...
> 
> The decentralize structures:
> 
> 	1. Eventually we need to form groups that are working on common pieces.
> 	   These groups must have team leaders, et cetera.
> 
> 	2. We also need to have some formal processes to support our independent
> 	   work.
> 
> Sorry that the above is brief, but I am not a good process person, I just 
> can identify what is missing. I beleive before we tackle any of the project
> we need to tackle the above...

I think he has some very good points here and I would like to argue
for this kind of organization.

Due to the limited/scattered time most people have, it is not reasonable
to be able to organize as a project group would in a company.  People
are not going to be able to deal with things like deadlines effectively.
This is not necessarily a problem.  Rather than trying to micromanage
everything, I think that Luke's proposal be used as a basis for project
work.  

There needs to be enough centralization that people are kept aware of
what others are doing and have some sense of progress.  At the same
time, the constraints imposed by the 'net (time zones), work, school,
play, etc. require that people be able to work on projects fairly
independently.

The centralized part should be able to set goals and project tasks
while individuals will carry out these tasks pretty much on their own.
I don't really see much of a way to handle closely coupled collaborative
work with the wide range of places and external work that people have
to do.

Johan van Schalkwyk (echt wel SchalwIJk, nee?) wrote:
> Organisation. If we don't get this right, we might as well pack up and
> go home. [can't keep up with traffic easily]
>
> Is it not possible for someone originating a new idea/section to send,
> as the first part of the title, the following:
> 
>   (?)
> 
> Let the TUNES@ENS.FR mailer identify this as being a request for a new
> theme, stamp it with the next number in sequence, AND THEN PASS IT ON
> TO EVERYONE. (1) would be the first ever theme, (2) the second, and so on..
> [snip, thread extension ideas]

I like the idea, but I think that this might place a bit of a strain
on Francois-Rene to set this up.  It looked like he was using one of
the "standard" list servers.  Anyone familiar enough with these to say
if adding such functionality is feasible.

Actually, Johan describes the numbering/annotation system that is used
by SCCS for source code control.  I have used this in a couple of projects
(for source code) and it works well, but you need to have a sort of
glossary that translates the number schemes back into something vaguely
human understandable.  I.e. "what does 1.2.16(32) mean?"  "Hmm, 1 is
the low level topics, 2 is the VM, 16 is the register allocation recompiler
stuff, OK..."

My guess is that if it could automatically generate numbers, the list
server could work with arbitrary text strings.  I would prefer this as
I found it annoying to constantly look up what these codes mean.  If
possible (a big if), it would be nice if we could use a more USENET
approach to topic naming.  My above example could be 
lowLevel.VM.RegAlloc(32) instead of 1.2.16(32).

I am just burbling in my beer on this one, but it would be nice to
have things recognizable at a glance.

One part of Johan's idea I think would be really great would be the
idea of sequence numbers.  I am getting stuff completely out of order
and I have to wait and look at stuff that is a few hours old just to
make sure that I have the entire thread at that point.  Even if only
sequence numbers could be prepended to the subject line, I think that
would be great.  It would give me a chance to figure out the order
in which things should be read.

Best,
Kyle