Add an organization input field to the group creation step within the signup form users/sign_up/groups/new.
When this solution is shipped on the users/sign_up/groups/new page we will provide the user with the ability to edit the default organization name. The user should also create a Group and Project.
We need to guard this somehow so we can show/hide for test purposes to begin with. Eventually we will show/hide for release purposes too. For test purposes there's no obvious actor. Maybe a GET query param is good enough?
Copy changes
Current
Proposed design
Project creation step - create
Previous copy:
Create or import your first project
Projects help you organize your work. They contain your file repository, issues, merge requests, and so much more.
Copy update:
Set up your account
[remove second line entirely]
Project creation step - import
Previous copy:
Create or import your first project
Projects help you organize your work. They contain your file repository, issues, merge requests, and so much more.
Copy update:
Set up your account
[remove second line entirely]
Organization popover
Copy:
What is an organization?
An organization is the umbrella term for one or more top-level groups. For example, this could be your company or department name. Learn more about organizations.
N/A
Group popover
Copy:
What is a group?
A group is used to manage one or more related projects at the same time. You can use groups to manage permissions for your projects. For example, a group may be a sub-department or team name. Learn more about groups.
N/A
Project popover
Copy:
What is a project?
A project helps you organize your work. It contains your file repository, issues, merge requests, and so much more. Learn more about projects.
If you are unsure about the correct group, please do not leave the issue without a group label, and refer to
GitLab's shared responsibility functionality guidelines
for more information on how to triage this kind of issue.
@poffey21@lohrc Following up on our growth call, this form field should be added to the Group creation step within the signup flow so it's supports both free and trial signups that go through the path of creating new organizations which is now documented in this issue #442100 (closed)
@s_awezec@p_cordero to be clear we are definitely targeting the users/sign_up/groups/new page, mentioned in the description and seen below),for adding a field here to edit the already existing (created before this step) organization name and any other details?
Your answer does not affect the weight here that much, which I gauge at around a 3 as I assume we'll have a bit of frontend work and some backend layer work to handle the submission and any failure path work.
However, this does not cover the eventual working in of the uniqueness service(yet to be created) that will likely need worked in in a more wholistic way to any organization update/creation.
we are definitely targeting the users/sign_up/groups/new page
@dstull I'm going to assume this meant to be 'are we' and you're asking @s_awezec and I's opinion on this! Correct me if I'm wrong.
I'd be interested to get @jhalloran's take but there will definitely be a need to ask a user what they want to name their organization if they've indicated their intent for signing up on step 1 is to setup a new team or personal account (and thus creating a new organization)
Because both of these users do eventually get exposed to this step of registration this seems like the logical step to add it to.
I'd be interested to get @jhalloran's take but there will definitely be a need to ask a user what they want to name their organization if they've indicated their intent for signing up on step 1 is to setup a new team or personal account (and thus creating a new organization)
Because both of these users do eventually get exposed to this step of registration this seems like the logical step to add it to.
I agree, this seems like the logical place. I do wonder though—especially for first time GitLab users—if we need to add some info tips to explain the differences between organization, group, and project?
@s_awezec@dstull I mocked up some ideas on adding this "Organization" field onto the group/project creation step of registration. Made some best guesses with help copy. That will definitely need to be reviewed, but wanted to check on the direction first. Let me know if you have any feedback.
@dstull thanks for bringing up the import tab! I've been looking through old files trying to find a screenshot of that tab but so far no luck. Any chance you are able to easily produce one?
Thanks @dstull! Looking at this screen shot I have a few questions...
Are those numbers ("127.0.0.1:53999" IP address maybe?) the default URL name on the "Import" tab? For the "Create" tab I believe we default to "GitLab.com" in that same space.
Do you know why we say "export" on the GitLab button for this import tab?
Are those numbers ("127.0.0.1:53999" IP address maybe?) the default URL name on the "Import" tab? For the "Create" tab I believe we default to "GitLab.com" in that same space.
yeah, you can assume that part will look same as the create tab - I took this screenshot during a browser test as that was quicker.
Do you know why we say "export" on the GitLab button for this import tab?
Yes, that button is for exporting a project from another GitLab instance. So in that sense you would be exporting from that instance and then importing to this instance.
Gotcha, thanks @dstull! With that in mind, here's the updated import tab. We'd use the same popovers. I'd also suggest removing the word "export" on the GitLab CTA, but that's a nice to have. @s_awezec
sorry - one thing I failed to mention was that there are likely more sources on Gitlab.com as we have more possible sources enabled (I think)
For easy explanation of what I mean, see the project create area. We should probably keep the GitLab button language the same between these pages if we decide to change it.
@dstull hmm, took this from a different website, let me know if it fits here:
"Migrate" means importing data from another app
"Import" means importing a previously exported file
So is the issue that you need to first export the GitLab data/file before then importing it back to GitLab? Looking at the info banner, sounds like migration of GitLab is still a WIP?
What are we doing with say GitHub or BitBucket...migrating or export/import?
@jhalloran the legacy method is to export to a file from a different GitLab, yes and then import into this one.
The bit about beta means the new method to do this will be a live streaming model. From my time in the import group about 2 years ago, it was started around that time. I'm not sure when it will ever be removed(the export to data model) as support uses this for on prem instances that are air-gapped.
I believe the word export they may have been used to denote the file piece of it and that it isn't the same GitLab instance you are on.
The GitHub and others use those respective API endpoints to perform the actual import(so more of what our beta concept is right now). They are migrating I'd say.
Ok, this sounds like a can of worms I probably don't want to open, so I'll just leave it as is for now. May want to review this in the future though if we do a bigger registration update.
yeah...I doubt many who signup actually import...maybe some of the wording and how intimidating this page is, is a reason(would like to see data on it)
@jhalloran the structure and hover over content looks great. One thought, should we consider changing the page title/description so it's more broad and not specifically speaking to just creating their project?
I'd also suggest removing the word "export" on the GitLab CTA
^ I agree this language seems really strange, feels more like "import an existing GitLab project" vs export.
And we don't have to solve this in this iteration but does it make sense to have GitLab and GitHub listed on the Create tab when we have a dedicated Important tab? Is it clear, that these are import option and/or that their are additional import options available. Maybe it should be something around popular imports so it alludes to their purpose without them appearing to be the only options.
does it make sense to have GitLab and GitHub listed on the Create tab when we have a dedicated Important tab? Is it clear, that these are import option and/or that their are additional import options available. Maybe it should be something around popular imports so it alludes to their purpose without them appearing to be the only options.
if you click on GitLab or GitHub does it take you to this page? If so, I agree that it could be displayed better. There's no indication that you have other options as it currently is.
@jhalloran it does not... It is a pain to get local dev up and running to show this for more choices and then to do it on .com it would mean I have to register... so I took a shortcut in both cases to show the design easily I guess.
@s_awezec In terms of the original scope of this issue, I think we are good to go. I ran copy by the docs channel, and I just updated the description with their suggestions. If you have any other feedback let me know otherwise I think we can move this into engineering.
@lohrc@dstull The field that is added in this issue, is this what determines if a new user is created on the primary cell or if they go into the secondary cell and therefore in the more isolated use case? Or is there more to it than just this field?
I ask because I am thinking about the user who may be like sure let's add an organization, but may not realize the impacts of that decision. Do we maybe need to clarify that somehow if that is the case or add something to inform the user?
The field that is added in this issue, is this what determines if a new user is created on the primary cell or if they go into the secondary cell and therefore in the more isolated use case?
Wether or not the user is created on the secondary cell will be determined on the very first page in registration, so that when the user and org(depending on the form entry) is created, they are on the correct cell.
We are exposing on this page as a means to allow editing of the already created organization name. (we plan to create it for the user after they click register on the first page with a standard name)
Welcome to the refinement stage for this issue. During this stage, engineers will ensure that this issue meets our criteria for issues ready for development.
Please follow these guidelines to ensure a thorough refinement:
Verify the issue description and check that the requirements are present and well-defined
Evaluate risks and dependencies
Uncover blind spots if possible
Outline possible technical solutions for the problem
Make sure every outcome of the refinement discussion is included in the issue's description. We want to avoid needing to go over multiple comments and threads to figure out what is the decision or additional requirement. The description should be the single source of truth when it comes to implementation details.
As an engineer, please:
Discuss and update the issue description (if needed)
Apply a weight estimate by voting or (if above 5) - means it's likely too big and needs splitting into smaller issues (also please suggest how by starting a discussion)
Ensure the issue has a ~type label
This issue will be considered as completed with refinement if it receives 3 unique weight estimations, and moved to workflowscheduling afterwards.
Need to be done after some of the work in &12898 is in place, or in concert with. I.e. basically the organization needs to be created on sign up page submission first.
For this part...
We need to guard this somehow so we can show/hide for test purposes to begin with. Eventually we will show/hide for release purposes too. For test purposes there's no obvious actor. Maybe a GET query param is good enough?
Maybe? ...but that question will likely answered by #4 work as we will be triggered by it here I think. That can be figured out later though.
I'm not sure what the right label is here, but I am thinking due to #3 I might put this under workflowsolution validation and/or block it by an issue from #4.
Apologies @dstull you're right, more context here would be very helpful/benificial. I agree lets move this back to workflowsolution validation for now. Maybe it's worth a sync as a team but my thinking was we could still develop these elements individually behind a larger feature flag allowing us to break the work out and assign to different team members. For example, do we create this page and associated fields and have a separate backend issue that grabs the values and does the required work to update the related organization?
I think that is hard to know right now until some of the directional questions from business/implementation are answered and the picture is clearer.
After that, yeah - maybe feature flags or something like that.
Since growth is fullstack, I far prefer not to separate frontend and backend across separate issues as then there is a chance of introducing out of sync code. Just a preference that I think if it could be avoided, it should be.
Until then, my initial thoughts are we could separate the work based on screens if desired in a vertical implementation manner and gate by feature flags if desired until it is fully implemented in onboarding.
I think we should eventually to dig into the reasons for testing in production as well as that seems to be the crux of why we need to figure out something more complex than all on/all off feature flags. Perhaps a lot of the testing could/should be achievable in staging-ref/staging.
@s_awezec once #442418 (comment 1819340826) is resolved, I think we may need to comeback to this convo and figure out some requirements around the rollout.
I'm thinking of concepts of how to perhaps:
leveraging GLEX concepts of using feature flags in non-logged in user with redis and how this could be leveraged here.
Forcing unsigned in user(actor) into candidate or control in GLEX with some concepts like you mention with a URL parameter(that depends on how secure it needs to be around an organization being created), etc.
I think we should spawn a different issue for that discussion, but I'm not sure we need to have it yet. Thoughts?