Top

GrowingGreenIvy

GreenIvy, an envisioned collaborative tool for the Dartmouth community, must plant its roots somewhere (so to speak :).

As we build the (database) software to hold the information, and as we build an interface for people to access and add to the GreenIvy system, we must take into account all aspects of the project, including:

• powerful searching and linking,
• ownership of and access to nodes,
• revision control,
• privacy and respect of personal information,

and many other important aspects of a community-wide information-database tool.

So, ... here goes:

General Ideas

Permissions

• Login
  • Mostly done through LDAP, with individuals being able to turn on/off their signature on anything that they write (with it turned off, no one could track them without direct access to the database).
  • "AnonymousCoward" posting allowed so that people could enjoy complete anonymity.
    • Perhaps this could be just allowed for the 129.170.xxx.xxx IP range. That way other people couldn't use this "AC" system, but students could use it if they felt that they had a good reason.
  • For outside world, people could sign in as a "Guest"
    • they'd have access to read pretty much everything.
    • i'm not sure about write access. perhaps they could contribute to nodes or make new nodes, but the nodes/comments would be flagged as created by a person not connected to Dartmouth.
    • users not on campus could get accounts for the GreenIvy system (not part of LDAP), especially if they were interested in making major contributions or they were just a cool person at another university, etc...

Revision Control

• The TWiki uses an rcs system, which is probably going to be a good start. Perhaps there might be other ways to deal with changes.
• Who gets to change what is going to be a big issue. Perhaps some students will go through and "vandalize" certain sections of the wiki.

Governing Committee

• There will have to be some kind of committee that controls the wiki and has "deputies" that can do some moderation of the content on the nodes.

• Probably, this committee should accept input from anyone (primarily undergrads and alums) through phone, fax, email, and even a node structure on the GreenIvy system itsself (like a suggestion box).

• The committee should be comprised of administrators, faculty, and students.
  • It is important to get input from administrators and faculty, but this tool is for the undergraduate population. Therefore, students should probably have a majority on the committe at all times.

• I suggest that we try to keep the system as open as possible, but have some basic guidelines for use of node names and appeal to change the content on nodes:
  • If the name of the node does not apply to the content, please try to choose a different name.
    • For example, the node entitled "The Bema" should not be about someone's china cat that they named "Bema" after the grassy field. Perhaps they could use "My Cat Bema" or "My Cat Named The Bema".
    • On the other hand, perhaps we can design the system so that people can call their nodes whatever they want, but then ranking and META-tag systems can appropriately sort the relevant pages from the huge pile of nodes.
  • No ad-hominem nodes, at least not directly on the GreenIvy
    • try not to make personal attacks, because that's not what the collaborative tool is for
    • if someone really wants to make a statment (esp. on that might be libel), then they can put it on their personal webpage on Webster, than point to it from their personal node on the GreenIvy.
  • Please mark opinion, researched information, widely accepted fact, etc... as appropriate. Try to avoid opinion on a node about the primary subject.
    • For example, putting pro- or anti-war information on pages discussing war or current news is probably not appropriate. Put a link in to a "why war is needed" or "why we shouldn't go to war" page.

User Interface

• Browser-based
  • pretty much hands-down it would be web-based, for cross-platform compatibility, and the reason that we're trying to make something that will be a good solution for people putting content up on the web.

• Bookmarks -- it would be nice for users to be able to maintain a sidebar or such (like a personal node) that would appear along the top or side of the GUI that they used to interact with GreenIvy. That way they could put their classes there, etc...
  • History -- if the user wanted to keep track of the last 10 nodes that they had edited, they could have a "history" personal node as well.

Privacy?

• Personal nodes
  • are we going to allow people to make restricted-content nodes so that only a specified group of people can view the content? this might be nice sometimes, but it won't necessarily help grow the contents of the information system, and it might also make teachers restrict nodes to just their class (which is not what we want).
    • perhaps we could make is so that teachers could restrict the write access to a subnode for a class so that only students in the class could post comments. THat might make some sense...

Something else that the GreenIvy system can provide:

• importance of a public forum free of adminstrative censorship.

Implementation Details

• Base the GUI on the interface for the wiki -- so that people can go in and edit the pages.
  • maybe we'd have a markup language like the TWiki formatting (that would make it easier for people to create content quickly.

• Each node is stored in the database
  • On idea is to have parents and children of nodes. Some nodes might not follow that structure, but perhaps we could specify a NULL parent/child field for those particular nodes.
  • Nodes could have META fields, some of which could be strict categories, and others would be more general (to allow for searching).
    • for example, a node could have a flag for ComputerScience if it was about a computer science class, a node could have a flag for Dick's House if it was about getting a flu shot, etc...

• • Each node could figure out what it pointed to, and what pointed to it (easy to do w/ the database).
  • Nodes would have date fields
    • date of creation
    • date of last edit
    • date of event or importance (for example a festival might have Feb 20, 2003; The Birthday of Hotdogs page might have November 22 (no idea what day it really is :))

RobinsonTryon - 03 Feb 2003