WIP: Full doc proposal for Campus VCS Service
Long overdue uploading this, here is the full proposal document Andy, Bryan, and myself worked on since the end of last year. The cost section still needs to be completed, rephrased, or otherwise smoothed out. The hope was to find enough units paying licensing for their version control systems, that it would largely mitigate the cost of an enterprise license, but so far we were only able to find the library spending any money on VCSs. However, if we can't showcase that, I'm unsure of how to approach the cost section, or maybe it should be removed entirely.
Document:
Merge request reports
Activity
I added a couple of typo fixes and updated the service table at the bottom.
The sample data doesn't make a strong case for git. If anything, it seems to support sticking with Subversion, which most groups are already using. I think there are a few contributing factors: 0. The table doesn't distinguish between service hosts (e.g., Engineering) and service users (e.g., Beckman). The result is that we have two lines showing no cost, when in fact Engineering IT bears the full personnel, hardware, and support cost. 0. The table doesn't highlight disparities between units in the same department. For example, Beckman's admin units are using 2-3 solutions that I'm aware of, and that is not an exhaustive inventory. 0. The table doesn't include tech services, which both licenses a service and (I think) has the same unequal coverage mentioned in the previous bullet. 0. The data doesn't cover units that want a solution but don't have one, or that would prefer a different solution than what's available.
On reread, I can't tell if this doc is trying to do too much or not going far enough. To me it seems like the focus should be on investigation--you understand what VCS is, but need to know what the real world impact will be to campus. In that light, I would expect details like campus service coverage, suboptimal arrangements, and the like to be in scope, without getting way into the weeds on supported APIs and the like.
Edited by areynold
