*We are currently experimenting with this* New design documents should be created as Google Drive documents. They should be placed into the shared folder "HTCondor Design Documents." If you don't have edit access, contact someone who does to get added. You can {link: https://drive.google.com/folderview?id=0BzI9lgnIwjpLaXFwOTRKTTlsanM&usp=sharing#list browse existing design documents}. {section: How to log in} 1: If you want to simultaneously be logged into a personal account, _do so first_. If you use the UW login first, it is difficult to later log into your personal account. 2: https://apps.google.wisc.edu/ - Log in as usual. 3: If you logged into a personal account first, going to Google addresses will be your personal account; but following links from the UW login will be your UW account. (You can log in from any Google login page; just omit your password when you click "Sign In" to be taken to the UW's login page. This doesn't work if you're already logged into a personal account.) {section: Working Offline} If you want to be able to read or edit documents while not online, you will need to use Google Chrome and {link: https://kb.wisc.edu/googleapps/page.php?id=31141 enable offline mode}. You should only edit documents offline if you are reasonably sure that you are the only editor; Google does silent merges which can lose data with no history about the lost data! Adding comments offline should be safe. {section: Secret documents} You probably don't need a secret document. Really, you probably don't. But just in case... If you place a document into a folder, permissions granted by the folder will be added to the document. Even if you carefully remove people from the document after adding it to the folder, new people will be added to the folder will be added to your document. This means you should _never move a "secret" document into the shared folder_. ---- ---- ---- {section: Rationale and Research} The UW pays for access to Google Apps, including, notably, Google Drive (formerly Google Docs). We have special terms of service for privacy. You don't need a Google account; your UW NetID is good enough. Note that the privacy protects are limited to Drive, Sites, Groups, and Contacts. You can use other Google services with your UW NetID, but you don't get any special protections. The Flightworthy team is considering using Google Drive to store design documents. Benefits *: Eliminates download/upload step in editing or commenting on a design document *: Multiple people can edit or comment on a design document simultaneously *: Eliminates formatting wonkiness from using a mix of MS Word and OpenOffice. Costs *: We become reliant on Google (and the UW to keep paying Google) *: Offline access requires Google Chome *: Offline editing is not risk free. You're at the mercy of Google's merge algorithm, and changes may be lost. (See "Offline support" below.) Probably not costs *: We lose advanced formatting; Google Drive is a simple word processor. But do we really need it? {subsection: Proposal: shared folder} We create a shared folder into which new design documents are placed. Proposed permissions are: *: HTCondor dev team: Can Edit - This is full access; people can create documents, delete them, and modify the permissions (although the latter can be removed?). Should only be given to people we trust with similar access to the Wiki and AFS. *: Close collaborators: Can Edit *: Public: Can View It is not possible to set "Can Comment" on a folder, you need to set it on a file-by-file basis. So if comments are desired from people without edit access, it will be need to be added for each file. The SWAMP team are using this solution. On the up side, access is centrally controlled. Adding a new team member is easy. There is also a single place to find all new design documents (but does anyone care?). On the down side, permission to create or edit documents is very chunky. Settings to the folder override settings on individual documents, so it's possible to add someone to the folder permissions and accidentally grant access to a file contained inside that should have more restricted distribution. But, is this a problem in practice? It's similar to the current permissions system on the wiki. {subsection: Proposal: individual file management} Individuals just create their own design documents, perhaps with a title prefix of "Design Document:" so they are easy to find. They are marked as "Public: Can Comment" (risk of abuse is low). If other people need edit access, it's granted on an as-needed basis. (We can also only grant comment access on an as-needed basis in a pinch.) The very rare design document with security ramifications won't be public; people are added as needed. On the up side, eliminates challenges of the folder being removed, and it's very hard to accidentally or intentionally damage a design document unless you're the original author or were very explicitly granted edit access. On the down side, there is no single place to find all new design documents. Does anyone care? They'll be linked from the individual tickets, similar to how it is today. {subsection: Challenges and Questions} {subsubsection: Offline support} Around June 28th, 2013, DoIT enabled Offline support. You'll need to explicitly enable it, and be sure connect online before going offline so you'll have the most recent versions. {link: https://kb.wisc.edu/googleapps/page.php?id=31141 How to enable offline mode} Offline support is Chrome only. Merging of offline and online charges are automatically resolved by Google without any notification. Conflicts are silently resolved _which means work could potentially silently disappear._ A quick test merged pretty well, but if an offline user added a sentence to the middle of a paragraph and an online user deleted the paragraph, the paragraph will be gone, including the new sentence. The history will contain no evidence of the lost content. The actual risk is hard to guess. If most people are just adding comments, I'm betting it's extremely safe. If two people are making heavy edits, the risk is probably high. {subsubsection: Backups} To reduce our dependency on Google, we can keep local, exported copies as a backup. Google drive can export docx, odt, rtf, pdf, txt, and html. We can manually make backups. You can export documents individually using File > Download as. You can download a batch in a zip file. {link: http://googlesystem.blogspot.com/2009/10/export-google-docs.html It looks like this}, although the menu option is now "Download" not "Export": We can automate the backups using the Google Drive API. It would probably involve {link: https://developers.google.com/drive/v2/reference/files/list enumerating the files} then {link: https://developers.google.com/drive/manage-downloads exporting them} {subsubsection: Google Drive Desktop} Google Drive Desktop nearly useless for our purposes. For native Google Drive formats, the "file" that ends up on disk is just a link to the web site. {subsubsection: How do permissions interact?} Changes to the shared's folder's permissions are pushed down to the contained files, even if those files have had their permissions set specially. If you create a file outside of the folder, then move it into the folder, it will add the permissions that the folder grants to itself. If you move it back out, it reverts to its previous permissions. There may be a several second lag before the change in permissions is visible. (All verified by testing.) {subsubsection: What if someone leaves the UW?} DoIT Help Desk said, in a June 19th, 2013 message to Alan ("Subject: Re: UW Madison Google Apps: ensuring documents survive a team member leaving(Case 618712)"): {blockquote} If a file owned by the user who leaves (we'll continue with your "bucky" example), is saved in the google group, the file will remain, even after bucky has left the University. The other team members won't be able to edit this document, unless they were given editing privileges before bucky left. Alternatively, if you need to give people editing privileges, you can copy the document and another member of the team can just recreate it with themselves as the owner, adding in editors as needed. Folders shared by bucky will also remain even after he leaves. {endblockquote} {subsubsection: What if someone closes their non-UW account?} Probably unlikely; how often does someone close their Google account? But there is a risk we'd lose the documents. Proposed: documents must be owned by someone using a UW account. Likely flow: non-UW member creates the file and works on it. Eventually someone from the UW copies the file and that becomes the official copy. {subsection: Links} UW's sites/information *: {link: https://kb.wisc.edu/googleapps/page.php?id=31141 How to enable offline mode} *: {link: https://kb.wisc.edu/googleapps/page.php?id=19067 Benefits of Use} *: {link: https://kb.wisc.edu/googleapps/top.php?limit=120 Knowledge Base} *: {link: http://www.doit.wisc.edu/googleapps/faq/ FAQ} *:http://www.doit.wisc.edu/googleapps/ *:https://apps.google.wisc.edu/mailplus