November 1998
- ADMIN: Unsubscriptions J C Lawrence
- ScryMUD [CUSTOM] Code release. Ben Greear
- Designgoals for CoolComponentCore(Was MUD-Dev's...) Ola Fosheim Grøstad
- Designgoals for CoolComponentCore (Was MUD-Dev's...) Niklas Elmqvist
- Designgoals for CoolComponentCore (Was MUD-Dev's...) Ola Fosheim Grøstad
- DevMUD: CVS Tree is ready. Are your sources? J C Lawrence
- DevMUD considerations and the Halloween article J C Lawrence
- DevMUD considerations and the Halloween article Jon Leonard
- DevMUD considerations and the Halloween article Adam J. Thornton
- DevMUD considerations and the Halloween article J C Lawrence
- DevMUD considerations and the Halloween article Chris Gray
- DevMUD considerations and the Halloween article Jon Leonard
- DevMUD considerations and the Halloween article David Bennett
- DevMUD considerations and the Halloween article Alex Oren
- DevMUD considerations and the Halloween article Chris Gray
- DevMUD considerations and the Halloween article Marc Hernandez
- DevMUD considerations and the Halloween article Chris Gray
- DevMUD considerations and the Halloween article Vadim Tkachenko
- DevMUD considerations and the Halloween article Jon Leonard
- DevMUD considerations and the Halloween article Alex Oren
- DevMUD considerations and the Halloween article Alex Oren
- DevMUD considerations and the Halloween article Ola Fosheim Grøstad
- DevMUD considerations and the Halloween article Chris Gray
- Designgoals for CoolComponentCore (Was MUD-Dev's...) Chris Gray
- Fallacy Watch and DevMUD Vision (was ... CoolComponentCore) Hal Black
- Fallacy Watch and DevMUD Vision (was ... CoolComponentCore) Ola Fosheim Grøstad
- Fallacy Watch and DevMUD Vision (was ... CoolComponentCore) Jon Leonard
- Fallacy Watch and DevMUD Vision (was ... CoolComponentCore) Ola Fosheim Grøstad
- Flamebite of the day Vadim Tkachenko
- META: DevMUD, MUD-Dev, and (list) futures J C Lawrence
- META: DevMUD, MUD-Dev, and (list) futures Jon Leonard
- META: DevMUD, MUD-Dev, and (list) futures James Wilson
- META: DevMUD, MUD-Dev, and (list) futures J C Lawrence
- META: DevMUD, MUD-Dev, and (list) futures J C Lawrence
- DevMud RFC #1 - Was DevMUD considerations and the Halloween article James Wilson
- My vision for DevMUD Jon Leonard
- My vision for DevMUD Niklas Elmqvist
- My vision for DevMUD Jon Leonard
- My vision for DevMUD Thandor
- My vision for DevMUD Robert Woods
- My vision for DevMUD ApplePiMan@aol.com
- My vision for DevMUD Thandor
- My vision for DevMUD Jon Leonard
- My vision for DevMUD Adam J. Thornton
- My vision for DevMUD Jon Leonard
- My vision for DevMUD Adam J. Thornton
- My vision for DevMUD Caliban Tiresias Darklock
- My vision for DevMUD ApplePiMan@aol.com
- My vision for DevMUD James Wilson
- My vision for DevMUD ApplePiMan@aol.com
- My vision for DevMUD James Wilson
- My vision for DevMUD Jon A. Lambert
- My vision for DevMUD Darrin Hyrup
- My vision for DevMUD Jon Leonard
- My vision for DevMUD J C Lawrence
- My vision for DevMUD ApplePiMan@aol.com
- My vision for DevMUD ApplePiMan@aol.com
- My vision for DevMUD ApplePiMan@aol.com
- My vision for DevMUD Jon A. Lambert
- My vision for DevMUD Hal Black
- My vision for DevMUD ApplePiMan@aol.com
- My vision for DevMUD Jon A. Lambert
- My vision for DevMUD Chris Gray
- My vision for DevMUD Chris Gray
- My vision for DevMUD Ben Greear
- My vision for DevMUD Jo Dillon
- My vision for DevMUD Ben Greear
- DevMUD Prototyping (was META: DevMUD, MUD-Dev, and (list) futures) Jon Leonard
- DevCore Project Management Ola Fosheim Grøstad
- DevCore Project Management Adam Wiggins
- DevCore Project Management Ola Fosheim Grøstad
- DevCore Project Management Simon Duggan
- DevCore Project Management Jon Leonard
- DevCore Project Management Chris Gray
- DevCore Project Management Darrin Hyrup
At 03:57 PM 11/3/98 +0100, Ola Fosheim Grøstad wrote:
>Jon Leonard wrote:
>> 1) Is there a better choice for "dictator" (project maintainer)?
>
>Who knows?
There is also no reason to automatically bundle the project leader
(benevolent dictator) with the project maintainer role. In fact, in some
ways it is probably better that they be seperate so they can concentrate on
their 'jobs' more effectively. But, either way could work if that person
has a lot of free time.
>First of all there are (at least) two ways to manage a project:
>
>1) a manager who gets to decide
>2) a coordinator who makes sure that questions get asked and decisions get
> made(but doesn't neccessarily contribute to the decision)
>
>General american business management seems to go with 1. Modern flat
>organizations seems to go with 2. 2 is judged to be the better approach
>with "smart" people for a number of obvious reasons I shall not get into. I
>assume 2 would work best with volunteers, and is what "project maintainer"
>indicates.
I prefer #2 influenced by #1. I suggested a more 'team oriented' approach
like this a week ago or so. In this approach, each major area of the
project is broken up into groups which are connected together like spokes
in a wheel (or leaves of a tree), which may have other sub-teams within
them which specialize in particular elements of a project area. (i.e., the
team that handles i/o interfaces may have a sub-team which oversees telnet,
another one that deals with custom protocols and works with the UI group to
create a graphical FE, etc.) Each group (team) has a lead who's job it is
to keep the team on target, and moderate discussions relating to their part
of the project. When a team cannot make a decision, the team lead can
either make a spot decision, or the problem can be sent up one level to the
team which oversees them (which could be the top node, which means the
whole project) so it can be deliberated on.
I think something like that would be the ideal solution. Each group could
elect their own lead (or it could rotate) to insure there was no ego bruising.
>What are then the duties that follows being a coordinator? This is
>something one should get to an agreement on.
>
>This is what I see as some duties:
>
>- control progress (and make sure changes are made if progress is low)
>- predicting and resolving upcoming conflicts among team members
>- sweet talking volunteers into doing the boring jobs
>- being able to redistribute jobs and making sure that the general attitude
>is "this is ours" rather than "this is mine". (why did you throw out MY
>superior code)
>- keeping track of the missing bits
>- making sure that the bigger picture is taken into account
>- quitting when one realize that coordinating takes too much time
>- keeping a record which ensures that somebody else can step in
I agree with this completely.
>Here are some properties which I think makes a good coordinator:
>
>- he has an interest in seeing the project done, but has no rigid opinions
>on it
>- he is prepared to spend most of his time doing coordination rather than
>coding
>- he is good at keeping people happy even when they have good reasons for
>not being happy
>- he is capable of making sure that the project doesn't suffer from keeping
>everybody happy
>- he is generally being a picky and annoying person, without being perceived
>as one
>- he is not afraid of asking the stupid questions, and prefer asking rather
>than assuming "I think I understand/know".
>- he is not afraid of asking how things are going, when they are expected to
>be done, and if somebody else perhaps should help out
>- he is more interested in organizing other people's opinions rather than
>stating his own
>- he is more inclined to make sure that people have what they need to be
>productive rather than to do things himself
>- he is willing to do the boring bits that nobody wants to do
>- he loves bookkeeping
>- he loves people
>- he knows a lot about groups of people...
>- he knows and admits that he doesn't know...
>- he is more concerned about progress and QA than becoming a leader
And with this as well. ;)
>Just to illustrate, here are some reasons for why I would make a lousy
>coordinator:
>- I am uneccessarily sarcastic
>- I get too many new ideas and loose interest too quickly
>- I find it easier to do everything myself than to get other people to do it
>- I enjoy playing the game "defending my opinion"
>- I don't admit what I don't know
>- I don't communicate a love for everybody
>- I don't record and investigtate everybody's opinon
>- I prefer doing creative work
>- I don't have enough time
I also would not wish to be coordinator for many of the same reasons. Plus
I really would like to code and I don't want to get bogged down with
administrative work. I already manage 2 design teams and just took over as
technical manager for another huge project, so I think that is enough
management work for me. :) But, as I said before, I volunteer to help out
with the coordination if it is needed.
>Just some more illustration. If people are to be judged by their activities,
>here are some related to coordination which have been spotted in mud-dev:
>
>- JCL provides structures which allows other people to be productive
>- Chris G makes sure he understand by asking questions where other people
>are afraid of loosing face.
>- Raph organize a statements taken from mud-dev and put words on his
>experience
>- Marian follows discussions even though she has little interest in
>programming, and she openly admits what goes "over her head".
>
>I don't know of any obvious coordinator in mud-dev, if I were to vote (which
>I am not) I probably would have voted for Chris Gray.
I have to admit, that I also agree with this. Although I suspect Chris is
probably too busy to do this either. :)
Best,
Darrin
- Fallacy Watch and DevMUD Vision (was ... CoolComponentCore) Chris Gray
- Drama Theory Ling
- Moral license (My vision for DevMUD) Ola Fosheim Grøstad
- Moral license (My vision for DevMUD) ApplePiMan@aol.com
- Moral license (My vision for DevMUD) Ola Fosheim Grøstad
- Fwd: My vision for DevMUD Jon Leonard
- DevMUD Prototyping Niklas Elmqvist
- Altima... Thandor
- Fwd: My vision for DevMUD Darrin Hyrup
- Tim O'Reilly's "Open Letter to Microsoft" ApplePiMan@aol.com
- Tim O'Reilly's "Open Letter to Microsoft" Adam Wiggins
- [DevMud] quick question... Franklyn Colebrooke, Jr.
- signal to noise... Andrew Wilson
- "knights and merchants" - NYTimes review James Wilson
- ADMIN: DevMUD posting authority promotions J C Lawrence
- A Small Conceptual Object System For MUDs Ola Fosheim Grøstad
- A Small Conceptual Object System For MUDs Emil Eifrem
- A Small Conceptual Object System For MUDs Mark Gritter
- A Small Conceptual Object System For MUDs Ola Fosheim Grøstad
- A Small Conceptual Object System For MUDs Jon A. Lambert
- Random Quest Generation chris@realm.zfn.uni-bremen.de
- Random Quest Generation Chris Gray
- Random Quest Generation Michael.Willey@abnamro.com
- Random Quest Generation J C Lawrence
- Random Quest Generation J C Lawrence
- Quick socket question Dr. Cat
- Quick socket question Jon Leonard
- Quick socket question Ben Greear
- Quick socket question Chris Gray
- Quick socket question J C Lawrence
- Quick socket question J C Lawrence
- Quick socket question Adam Wiggins
- Quick socket question Petri Virkkula
- ScryMUD [CUSTOM] Released under GNU General Public License Ben Greear
- Quick socket answer Dr. Cat
- Rebol Ling
- Spell components, chemistry, and the like... quzah [sotfhome]
- Spell components, chemistry, and the like... Chris Gray
- Spell components, chemistry, and the like... quzah [sotfhome]
- Spell components, chemistry, and the like... JavaAl@aol.com
- Spell components, chemistry, and the like... Adam Wiggins
- Spell components, chemistry, and the like... quzah [sotfhome]
- Spell components, chemistry, and the like... Nathan F Yospe
- Spell components, chemistry, and the like... quzah [sotfhome]
- Spell components, chemistry, and the like... Hal Black
- Spell components, chemistry, and the like... Ling
- Spell components, chemistry, and the like... Caliban Tiresias Darklock
- Spell components, chemistry, and the like... Ben Greear
- Spell components, chemistry, and the like... Caliban Tiresias Darklock
- Spell components, chemistry, and the like... quzah [sotfhome]
- Spell components, chemistry, and the like... Caliban Tiresias Darklock
- Spell components, chemistry, and the like... quzah [sotfhome]
- Spell components, chemistry, and the like... Hal Black
- Spell components, chemistry, and the like... Peck, Matthew x96724c1
- Spell components, chemistry, and the like... Nathan F Yospe
- Spell components, chemistry, and the like... Ben Greear
- Spell components, chemistry, and the like... JavaAl@aol.com
- Spell components, chemistry, and the like... Chris Gray
- Spell components, chemistry, and the like... Nathan F Yospe
- Spell components, chemistry, and the like... Adam J. Thornton
- Spell components, chemistry, and the like... Franklyn Colebrooke, Jr.
- Spell components, chemistry, and the like... Emil Eifrem
- Spell components, chemistry, and the like... Nathan F Yospe
- ADMIN: Attributions J C Lawrence
- AMIN: Unsubscriptions J C Lawrence
- OO Design Question Brad Leach
- OO Design Question J C Lawrence
- Chemistry [Warning, scientific content] Peck, Matthew x96724c1
- MUD clients, testing Chris Gray
- MUD clients, testing Scatter
- MUD clients, testing J C Lawrence
- JOB: Project manager and scaling/networking guru needed for game project J C Lawrence
- More module ideas Mark Gritter
- The Innerworld Project Niklas Elmqvist
- META: FAQ's bios. Ling
- Mage 2 Mage 0.89 J C Lawrence
- Game library notes J C Lawrence
- World Building Page Ling
- ScryMUD [CUSTOM] Code release 1.8.1 Ben Greear
- DIS: Client-Server vs Peer-to-Peer Niklas Elmqvist
- DIS: Client-Server vs Peer-to-Peer J C Lawrence
- DIS: Client-Server vs Peer-to-Peer Niklas Elmqvist
- DIS: Client-Server vs Peer-to-Peer J C Lawrence
- DIS: Client-Server vs Peer-to-Peer Ling
- DIS: Client-Server vs Peer-to-Peer Niklas Elmqvist
- DIS: Client-Server vs Peer-to-Peer Ling
- DIS: Client-Server vs Peer-to-Peer Nathan F Yospe
- DIS: Client-Server vs Peer-to-Peer J C Lawrence
- DIS: Client-Server vs Peer-to-Peer Niklas Elmqvist
- DIS: Client-Server vs Peer-to-Peer Ola Fosheim Grøstad
- DIS: Client-Server vs Peer-to-Peer Marc Hernandez
- DIS: Client-Server vs Peer-to-Peer Caliban Tiresias Darklock
- DIS: Client-Server vs Peer-to-Peer Marc Hernandez
- DIS: Client-Server vs Peer-to-Peer Caliban Tiresias Darklock
- DIS: Client-Server vs Peer-to-Peer Mik Clarke
- DIS: Client-Server vs Peer-to-Peer Adam Wiggins
- DIS: Client-Server vs Peer-to-Peer Jon Leonard
- DIS: Client-Server vs Peer-to-Peer Niklas Elmqvist
- DIS: Client-Server vs Peer-to-Peer Greg Underwood
- DIS: Client-Server vs Peer-to-Peer Greg Underwood
- DIS: Client-Server vs Peer-to-Peer Marc Hernandez
- DIS: Client-Server vs Peer-to-Peer Greg Underwood
- DIS: Client-Server vs Peer-to-Peer Niklas Elmqvist
- DIS: Client-Server vs Peer-to-Peer Greg Underwood
- Ruminations on CVS and developing in the Bazaar Ben Greear
- Ruminations on CVS and developing in the Bazaar Chris Gray
- Ruminations on CVS and developing in the Bazaar greear@cyberhighway.net
- Ruminations on CVS and developing in the Bazaar J C Lawrence
- Ruminations on CVS and developing in the Bazaar greear@cyberhighway.net
- Ruminations on CVS and developing in the Bazaar J C Lawrence
- Ruminations on CVS and developing in the Bazaar Petri Virkkula
- DevMUD: List data, subscription, and the rest J C Lawrence
- DevMUD: List data, subscription, and the rest J C Lawrence
- Atention SSH/Java-developers (MindTerm update) J C Lawrence
- ScryMUD/Hegemon code Release Ben Greear