Clarification of project space request process

What would you like to see added?

Below is a very rough template for proposed changes. The language needs cleaning up, my brain is a bit short on cognitive power at the moment.

1. When requesting new /data/project and /data/project/sloss directories, groups must use the following process to streamline activity:

   • Owner must initiate the request from an email associated with their UAB identity. Requests from non-owners will be closed with a message requesting resubmission by the owner. Emails must come from @uab.edu or @uabmc.edu, so that we can identify the owner as a UAB identity in ServiceNow.
   • They should send the information in the existing documentation (folks are doing a great job of this, but the requests are coming from non-owner people like students and staff).
   • If any of the blazerids to be added do not exist, they will be ignored when we create the directory. We will create the directory and leave a message noting which blazerids do not yet have a Cheaha account before we close the ticket.
   • Adding missed blazerids will require a separate ticket.
   • The project directory must follow this naming rule: $givenname_$lastname_lab, and all characters must be lowercase.

2. We will need to develop policy around who we allow to be an owner. This requires internal discussion and we have a separate issue associated with this: https://gitlab.rc.uab.edu/rc-data-science/policies/resource-sharing

3. The content at https://docs.rc.uab.edu/help/support/#how-do-i-request-or-change-a-project-space may need to be moved to
   https://docs.rc.uab.edu/data_management/storage/#project-directory.

4. We must carefully correct and refine the information surrounding project spaces. We can no longer grant storage space increases, but if the need is pressing they can contact us so we can navigate a path forward.

5. Document the path forward:

   • Discuss the need for a designed Data Management Plan (we don't fully know what this looks like but we have some general outlines). Point out that research data will only ever grow in size and scope as time goes on, so a Data Management Plan is critical to mitigate recurrent storage discussions, saving everyone time.
   • Researchers can identify data that can be reasonably moved to LTS. We can assist with transfer facilitation (cross-link to transfer pages and LTS page)
   • Researchers may need to identify one or more people who can take on the role of "Data Steward(s)" to determine what data to place in what storage device, how to tag and track it, manage permissions, and so on. We do not have great experience with this, this is part of the DMP.
   • Please contact support for more information.

Review the current project-space guidance at the two linked documentation pages, then read the associated resource-sharing policy issue before changing policy language. Consolidate and clarify the request process, naming rules, storage guidance, and Data Management Plan path; done means the documentation reflects the agreed process and links readers to support and related guidance.