Tool for collaboration:
Not for file storage and enormous file sharing solutions. There will be a limit of 10 M per file, and a soft quota of 1 GB per space. The 1 GB quota is not enforced by the server, but will be checked from time to time by Systems-OIT-UNIX.
Accounts are self provisioning:
Anyone with a NetID and password can login, and if an account does not exist it is created when they first log in without them knowing it. This does mean that if someone is trying to add someone to their space, that person needs to already have an account.
ONLY NetID users can create accounts:
If people wish, they can set their space to be viewable by anonymous, which means anyone can go look at it without logging in. However these people cannot edit the wiki. There is an option to turn on anonymous commenting, which would allow anonymous viewers to make comments on pages. This is about as close as you can come right now to letting a non-netid user work with you on a project. Possibly in the future this will change, but not in phase 1. Commenting is secured by character recognition to attempt to prevent spam.
To request new spaces:
*see Student Group Requests and Faculty Request for Courses below on formatting and procedure
There is a form inside the wiki. Being inside the wiki prevents people who don’t have accounts from requesting spaces. The Service Desk will receive these requests through Support@Duke, and it will be our job to verify it is a legitimate request, and create the space.
Spaces should only be for official courses, departments, and student organizations. If faculty/staff member wants a space for a group or such, verify it sounds like a real group in some way, and create it for them. Systems-UNIX-OIT is not particularly worried about us policing staff/faculty requests as long as it’s for a group and not a single user, and does not get abused. If it does this may change.
For student groups, we DO need to verify they are a REAL group. This will be done in conjunction with OSAF, and OSAF will be added as an administrator on all student organization spaces created. This will solve our current problem in AFS such as when presidents/webmasters of clubs graduate and leave. OSAF will be able to identify who left, and give permissions to the correct new students for that group. Do not create a student group space based only on their word, it must be verified as an official group.
Can still be done by individual user or group. Space Admins (people who own/administrate a space) can now manage/create their own groups. This means we won’t have to add/remove people from groups all the time for people anymore. There are lots of new links and tools for creating and managing groups, please get familiar with them by exploring wiki-test.oit.duke.edu.
Problems for individual users go through remedy to OIT-SSI-T4-SysInfra-UNIX
Student Group Requests
1) Student groups will request DukeWiki spaces via the standard OIT online form.
2) The Service Desk will validate that a student group is Duke-recognized using the OSAF web page: http://osaf.studentaffairs.duke.edu/studentorgs/stuorgs/index.html
3) The Service Desk will create the space, adding both the requesting student and a new group (“osaf-admins”) as space administrators.
4) The Service Desk will email OSAF a notification about the space creation: firstname.lastname@example.org and email@example.com
5) The requesting student and/or OSAF will be able to import content into this new space, if they desire, using an XML template. The decision as to whether to import this content lies in the hands of OSAF (should they make it a standard workflow) or the student requester/student group (via documentation/training.)
6) To join a group, students will first have to self-provision for DukeWiki. Then, the student space admin (or OSAF) can add them as a member, via either NetID or searching for the student.
7) Space expiration notices will be sent to all space admins, which will include the osaf-admins group. This will help guard against deletion of inactive spaces. OSAF and/or the student lead can choose to export the space if desired at that point.
Faculty Requests For Courses
If a faculty member requests a space it must be named after the course. Use the STORM listing as a general guide line for naming convention. So for Space Name you can use the Course Name in STORM. For Space Key you can use the Course ID in STORM. Remember, the Space Key also ends up being part of the URL for the web page. Also, you may want to drop the term if they plan to use the space successively.
General Naming Guidelines
The OIT Service is the primary contact for customers regarding DukeWiki.
If the Service Desk is unable to resolve an issue, it will escalate a Support@Duke ticket to Systems-UNIX-OIT for further assistance. Depending on the issue, that group will either send the ticket back to the Service Desk containing information that will allow the Service Desk or the customer to resolve the issue, or contact the customer directly to resolve the issue. A walkthrough for SD Analysts to set up a wiki space can be found here
If DukeWiki is unavailable, the OIT Service Desk will send an urgent ticket to the SOC, following established escalation procedures.