I haven't spoken up because there are already enough voices in the conversation. But to the extent that a Georgia Tech's perspective is needed, we don't expect this to have a serious impact on our piloting for the next six months, and so are more concerned with a long-term solution.
FWIW, getting a timely and sound answer in these kinds of situations is what I think we wanted a product owner for. The product owner would have to seek out other input (like the URG) as needed, but I would recommend using that role as a way to get to a reasonable result without either holding up the team or confusing stakeholders with overlapping threads. ~Clay On Mon, Jul 16, 2012 at 2:45 PM, Nate Angell <nang...@rsmart.com> wrote: > agreed on the calculus > > it might be good if the project team could give an idea of how long they > think world deletion might be out of service until it came back all > fully-implemented and shiny ;) > > I think we've heard from CSU, UCB, and rSmart (tho I'm seeing if Lance and I > can agree ;), GA Tech? NYU? I'm not sure where Cambridge landed on the > underlying issue. > > Maybe Nico has a synthetic view that can point the best path forward. > > = nate > > > On Mon, Jul 16, 2012 at 11:41 AM, Jon Hays <jonmh...@media.berkeley.edu> > wrote: >> >> I'm not quite ready to assume that the proposed solutions have equal costs >> (as measured by effort, time, and risks associated to the build-up of "crud >> data") and was purposely vague in defining solutions as I am expecting the >> project team to offer those up. The calculus before the project at the >> moment seems to be: >> >> Immediacy & intensity of the need for world deletion functionality by >> piloting institutions as expressed by URG members balanced against the >> relative costs to the project for the various possible remedies. >> >> For Berkeley's part, we can live without the delete functionality in the >> short term, which is why we would error toward the least "costly" route. I >> agree, it will be important to hear from other piloting institutions so the >> team can quickly assess how great the need actually is for deleting worlds. >> >> >> Jon Hays >> 510-672-5493 >> CalCentral Team >> Educational Technology Services >> University of California, Berkeley >> >> On 7/16/12 10:46 AM, Nate Angell wrote: >> >> Careful Jon: if we follow that logic, who knows where it might end? ;) >> define "partially implemented" ;) >> >> I agree that the main goal should be maintaining release velocity (for 1.4 >> and beyond). But more than one choice here supports that goal. At this point >> I fear it is the continued discussion that is getting in the way (mea culpa) >> as much as the actual work. >> >> But, I think this issue of world deletion points to something key: we must >> plan for fully implementing already-released capabilities in releases as >> much (or more) as for developing and releasing new capabilities. Otherwise, >> we run the risk of releasing a platform that does a lot of cool stuff, but >> none of it well or completely. Some would argue that's exactly where we are. >> It seems totally appropriate to me that groups like the URG and TRG should >> face the tradeoff questions for decisions like this. >> >> So here's a slightly different perspective on world deletion, that IIUC, >> still supports a timely 1.4 release: >> >> Users in various deployments have already been deleting worlds (in a >> broken way), and so there is likely already a bit of a mess to clean up for >> most production implementations. I would assume that cleaning up would be a >> part of any later solution for also making world deletion work right. So, we >> already have to do that work and therefore perhaps the urgency not to make >> any more messes is lessened. >> >> The worse mess to avoid is to ensure new worlds are not made with the same >> ID as a previously-deleted world and a low-effort proposal on how to deal >> with that has already been proposed. >> >> So, continuing to allow world deletion (which has a real value for users), >> but blocking world creation for IDs matching a deleted world maintains the >> status quo while ensuring bigger messes are avoided, even if some more >> smaller messes continue to build up (which the already have and are). >> >> Is anyone thinking we wouldn't have to clean up the smaller messes we have >> already made? >> >> It would be good if the other project institutions could weigh in. I'll >> see if rSmart can at least start to speak with one voice. ;) >> >> = nate >> >> On Mon, Jul 16, 2012 at 10:02 AM, Jon Hays <jonmh...@media.berkeley.edu> >> wrote: >>> >>> point taken. It does raise a couple of questions for me... >>> >>> Is partially implemented functionality that slips through the process >>> without being completed actually a feature? The fact that it ever made it >>> into a release seems to be a mistake or oversight in the QA process. >>> >>> Most importantly from a URG perspective, does any piloting school >>> actually rely on the delete option? Berkeley doesn't, but I agree that the >>> project should weigh the piloting schools needs against any decision around >>> how to remedy this issue. >>> >>> Berkeley's priority would be to do the most expedient thing that gets us >>> safely to a 1.4 release without further delay. >>> >>> >>> Jon Hays >>> 510-672-5493 >>> CalCentral Team >>> Educational Technology Services >>> University of California, Berkeley >>> >>> On 7/14/12 3:19 PM, John Norman wrote: >>> >>> As described, the serious flaw has a simple fix. But that was not my >>> point. Unless the feature was included at the whim of the dev team (in which >>> case it can be removed at the whim of the dev team), a decision to remove it >>> should involve the URG. What if an institution depended on it for some >>> reason and was capable of dealing with the problem arising from re-use of >>> the ID? My concern is not about the detail of this issue, it is about the >>> prospect of user-facing features disappearing without consultation with URG. >>> >>> John >>> >>> On 14 Jul 2012, at 22:27, Jon Hays wrote: >>> >>> I don't think that anyone is disputing that we need it, but rather that >>> we figure out what to do until we have a delete feature that actually works. >>> In my opinion, no delete option is better than a seriously flawed one >>> assuming that the project circles around to fixing this feature for the next >>> release. >>> >>> Jon >>> >>> Sent from my iPhone >>> >>> On Jul 14, 2012, at 3:03 AM, John Norman <j...@caret.cam.ac.uk> wrote: >>> >>> I would put this more strongly than Nate. I assume the delete function >>> was put in as a response to some important user need identified by the URG. >>> As such it should not be removed without consultation with URG. >>> >>> John >>> >>> On 13 Jul 2012, at 19:17, Lance Speelmon wrote: >>> >>> +1 turn it off for now. Thanks, L >>> >>> On Jul 13, 2012, at 10:54 AM, Zach A. Thomas <zach.tho...@gmail.com> >>> wrote: >>> >>> I like Ray's proposal, and removing the delete button is certainly lower >>> risk than adding the new code right at the end of the release cycle. >>> >>> >>> Is it a deal-breaker for anyone if we turn this off? >>> >>> >>> Zach >>> >>> On Jul 12, 2012, at 3:15 PM, Ray Davis wrote: >>> >>> >>> Answering Zach's main question as the original complainant: >>> >>> >>> Here's is my main question (thank you for your patience!): I think I >>> >>> need more time to build a proper cleanup solution than we have left for >>> >>> the upcoming release (1.4.0). Should I >>> >>> a) just defer this work until post-1.4.0, leaving everything as >>> >>> broken as it is now >>> >>> b) Implement the "on hold" list now to prevent names of worlds which >>> >>> have been deleted from being reused >>> >>> c) Something else I haven't thought of >>> >>> >>> c) Disable the UX for World deletion but continue to make Group >>> >>> Authorizable deletion available through Curl for essential >>> >>> administrative tasks or scripts which can deal with the consequences. >>> >>> Leaving the current UX in front of (a) or (b) seems to promise things >>> >>> that won't be delivered. >>> >>> >>> Best, >>> >>> Ray >>> >>> >>> On 7/12/12 11:29 AM, Zach A. Thomas wrote: >>> >>> Hi, all. I've been working on >>> https://jira.sakaiproject.org/browse/KERN-2586 which is about what happens >>> (or doesn't happen) when we delete a world. >>> >>> >>> This turns out to be pretty convoluted, so I'd like some feedback on it. >>> >>> >>> Here's the basic problem: in the current OAE release, you can delete a >>> world using the little gear menu. It produces a command similar this curl >>> statement: >>> >>> >>> curl -u admin:password -F:applyTo=somegroup >>> http://example.com/system/userManager.delete.json >>> >>> >>> But all that happens is we remove the Authorizable for somegroup. >>> somegroup's home folder and everything within it is intact, all the access >>> controls that somegroup was ever granted are still in place, and everywhere >>> that somegroup is mentioned (such as in the membership lists of content and >>> groups) remains unchanged. >>> >>> >>> If someone comes along later and creates a new world and they happen to >>> use the old name, they'll have the old world's library, home folder, etc. In >>> short, it's an awful mess. >>> >>> >>> We don't have the ability to do a cascading delete, as we would do in a >>> relational database. For a proper delete, we're going to want to crawl >>> through every bit of data and remove references to the former world. Since >>> this is time-consuming, we would want this to happen asynchronously in a >>> background operation (think of a Roomba, slowing scooching around your >>> house). >>> >>> >>> While we're waiting for a proper cleanup, I think we're going to want to >>> put a "hold" on that id for any future world creation. We can do this by >>> just storing a simple list of ids somewhere, and consulting that list when >>> creating new worlds. >>> >>> >>> Here's is my main question (thank you for your patience!): I think I need >>> more time to build a proper cleanup solution than we have left for the >>> upcoming release (1.4.0). Should I >>> >>> a) just defer this work until post-1.4.0, leaving everything as broken as >>> it is now >>> >>> b) Implement the "on hold" list now to prevent names of worlds which have >>> been deleted from being reused >>> >>> c) Something else I haven't thought of >>> >>> >>> I have almost finished the "on hold" functionality. We just need an >>> endpoint like the "user exists" servlet for usernames. >>> >>> >>> thanks, >>> >>> Zach >>> >>> _______________________________________________ >>> >>> oae-dev mailing list >>> >>> oae-dev@collab.sakaiproject.org >>> >>> http://collab.sakaiproject.org/mailman/listinfo/oae-dev >>> >>> >>> >>> >>> _______________________________________________ >>> >>> oae-dev mailing list >>> >>> oae-dev@collab.sakaiproject.org >>> >>> http://collab.sakaiproject.org/mailman/listinfo/oae-dev >>> >>> >>> _______________________________________________ >>> >>> oae-dev mailing list >>> >>> oae-dev@collab.sakaiproject.org >>> >>> http://collab.sakaiproject.org/mailman/listinfo/oae-dev >>> >>> >>> _______________________________________________ >>> oae-dev mailing list >>> oae-dev@collab.sakaiproject.org >>> http://collab.sakaiproject.org/mailman/listinfo/oae-dev >>> >>> >>> John Norman >>> Director - CARET >>> University of Cambridge >>> j...@caret.cam.ac.uk >>> +44-1223-765367 >>> >>> _______________________________________________ >>> oae-dev mailing list >>> oae-dev@collab.sakaiproject.org >>> http://collab.sakaiproject.org/mailman/listinfo/oae-dev >>> >>> >>> John Norman >>> Director - CARET >>> University of Cambridge >>> j...@caret.cam.ac.uk >>> +44-1223-765367 >>> >>> >>> >>> >>> _______________________________________________ >>> oae-dev mailing list >>> oae-dev@collab.sakaiproject.org >>> http://collab.sakaiproject.org/mailman/listinfo/oae-dev >>> >> >> >> > > > _______________________________________________ > oae-urg mailing list > oae-...@collab.sakaiproject.org > http://collab.sakaiproject.org/mailman/listinfo/oae-urg > _______________________________________________ oae-dev mailing list oae-dev@collab.sakaiproject.org http://collab.sakaiproject.org/mailman/listinfo/oae-dev
