### Problem to solve Today, in order to clone multiple repositories within a group, one must type out all the repository names by hand, or drop into each repository and obtain its clone URL. As the number of repositories increases this becomes more like busy work, increasingly tedious and error prone. ### Intended users Developers or anyone else who may have a need to clone repositories, e.g.: * [Rachel (Release Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#rachel-release-manager) * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead) * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) * [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer) * [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator) ### Further details None. ### Proposal To improve user experience for cloning groups, consider a Clone UI element placed at the group level that's similar to (if not exactly like) the repository level UI element. Instead of copying a single URL, it would be a list of URLs. The list would be space separated, ssh or https. The idea would be to keep the UI just like it is at the repository level, so that there's nothing new to learn. If a newline separator would also be useful, perhaps offer that as a checkbox, though this would affect UI consistency. This could live as a preference in Settings, but there doesn't seem to be much there in the way of git-facing preferences, so that may also not be the best place. Perhaps A/B testing can help determine if there is a strong preference for one or the other as a default. ### Permissions and Security Same permission/security requirements as for each repository within the group. ### Documentation None. Uses existing/known UI elements. ### Availability & Testing No known risks. Keeping comment for future reference, if needed. <!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier. What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance. * Unit test changes * Integration test changes * End-to-end test change See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning --> ### What does success look like, and how can we measure that? Saves users from extra busy work cloning multiple repositories within a group. The more repositories within a group, the more efficiency is realised. Perhaps measure with A/B testing offering the feature to some users: one way with a space separator and one way with a newline separator, eliminating the checkbox mentioned earlier and keeping the UI exactly the same as within each repository. Ask inline for quick feedback if they use the feature and just take their temperature, on a scale of 1-5 or colour-coded red to green, asking "Was this helpful?" ### What is the type of buyer? No buyer. ### Links / references None.