GitLab 12.6 introduced soft deletion of projects for Silver/Premium and higher tiers. In those tiers the "remove project" flow only schedules a project for deletion after a period of time (the default is 7 days). Currently in those tiers it is not possible to delete projects immediately. This has resulted in a some complaints (in order of oldest to newest):
There should be a group-level configuration option to "Enable delayed project removal", with explanation text: "Projects will be permanently deleted after a 7-day waiting period. This period can be customized by an admin in instance settings."
Projects should not be soft deleted on removal unless that option is enabled.
The project removal confirmation modal should say: ""This group has enabled a project deletion delay. Your project will be recoverable for X days."
@mjang1 earlier today I chatted with @mattgonzales about not using the term "soft delete" anymore. Our thinking is that this isn't really soft delete, because that suggests the record will continue to exist indefinitely. It's more like delayed delete. Instead of "Enable project soft delete" (the current proposal in this issue), what do you think about "Enable delay on project removal"? (Because we currently use the term "remove" instead of "delete".)
I feel like this issue reverts the behavior that MR speaks to, so I'm not sure we should make that particular change. But I did just update the proposal in this issue to note that API documentation should be updated.
Probably not within the scope of this issue - should we make the Waiting period Setting (deletion_adjourned_period) configurable at the group level and fallback to Instance level?
It might especially be helpful in gitlab.com, where users outside of GitLab do not have control over Application Settings.
should we make the Waiting period Setting (deletion_adjourned_period) configurable at the group level
@asubramanian1 you must be able to read minds! I was just talking with @mattgonzales about this on the "final planning" call for 13.2. We agree with you so I just created a new issue for that
@mattgonzales, cross-posting this question from @jrreid: "What customer-facing communication has the team planned outside of the release post to inform our users of this change in behaviour on .COM? Will the UX be sufficiently different so that it's intuitive for those not reading through our release posts in detail?"
My thinking is: yes, the UX will be sufficiently different, specifically because of increasing the scariness of the confirmation modal (also scheduled for %13.2). That probably solves the problem. But to be certain, what if we create an alternative confirmation, "which might only be slightly different, to be used when delayed removal is enabled"? I'm thinking we would execute that as a follow-up issue, but try to get it into %13.2 as well.
@jeremy I'd love your opinion on this. Summary: we're reverting project deletion behavior to be immediate and would require a group owner enable "project deletion delay". This standardizes the behavior across all pricing tiers and clears up a UX issues that's problematic for many users (unable to use the same project name when previous one is pending deletion). Should we communicate this change? If so, how should we do that?
@djensen I'm not entirely sure what the "alternative confirmation" would be when delayed removal is enabled How would that differ from the current planned experience? I may have just been away from this for more than 10 seconds and lost my footing
@mattgonzales ah, yes - I just caught back up from my own 10 seconds away
I'm concerned if soft-delete is enabled, the scary confirmation for immediate delete could cause unnecessary anxiety for users. "It looks like I'm deleting it immediately, isn't it supposed to be delayed? Am I going to get in trouble if I click this button?" I was thinking it would be nice to indicate that soft-delete is enabled. Specifically, the confirmation modal could say something like "Deletion will be delayed by X days" and/or "This project will be deleted 2020-07-06." I expect that change would be made under a follow-on issue after this and #220243 (closed) have been both been executed. But I'm not sure if it's a nice-to-have or something more important. What do you think?
I'd say it's likely more important though we wouldn't need a major change for the first iteration. Maybe we can just add a callout of some sort (similar to info boxes in docs?) at the top to say "This group has enabled a project deletion delay. Your project will be recoverable for X days." or something.
Even though this conflicts with the current copy of the modal, it seems like the "less bad UX" of two wonky options
Then our follow-on iteration could be re-working the copy and render the "deletion delay" copy if that setting is enabled or... something?
@mattgonzales we will make the change clear in the API documentation, but I feel like it's difficult for us to communicate more directly than that. But at the same time, my perception is that this is not a breaking change, because it only changes the timing of the action (not the action itself). So I'm thinking changing the API documentation is sufficient. Does that sound alright to you?
@djensen I think that's ok, between updating docs and the release post to mention the change. I'm not sure what other mechanisms or channel would be best for this Maybe an in-app notification?
If we can fit this into the current proposal, that would be my vote. I think this change is important enough to call it out in the same update as reverting this behavior