New issue without a web form
Backround
- As we move toward a web app approach, we should minimize web forms when they are unnecessary. Now that we don't have an edit issue web form for issues, let's get rid of the new issue web form.
Design
- When you click New issue (or initiate a new issue anywhere in GitLab), an issue for that project is automatically created and persisted. The title for the issue is:
Enter titleas stored in the database. - GitLab navigates you to the new issue's page right away, and it immediately goes into Edit mode, highlighting the title, beckoning you to update it, add a description, change the template, etc.
- With this design, we are blurring the lines of new/edit, which is good, because it reduces friction.
Activity
added ~874211 UX ~14281 labels
@smcgivern @sarrahvesselov @dimitrieh : What do you think about this design?
I can anticipate some pushback because now creating issues is literally one-click. Do we want to make it that easy? I say yes! I'd rather people keep creating issues, and if they have to, they can close them afterward. And it may be jarring for users at first, because clicking that New button now stores something in the system right away. It's a different paradigm and it is certainly a risk to throw this at users. But I think it's a good feature in the long run, and it aligns with our goal of encouraging more issue creation/usage and helping users get everything written down as soon as possible.
The UX fails if we don't have good performance. Right now, when you click New issue, you get a web form, so it's quick, as users expect it to be. But in the proposed design, you have to do persistence first, and that takes some finite time. So I can see that being a blocker to this design if that time is very long.
changed milestone to %Next 3-6 months
Confidential issues need to be considered carefully here.
In the current paradigm, the user goes through this in their brain:
- I want to create a confidential issue.
- I don't want anybody public to ever ever know I even had this thought in my brain.
- I click New issue.
- I check the confidential checkbox.
- I submit.
With this change, the fact that an issue was created and visible to the public for all of ~30 seconds (however long it takes them to do that initial edit) means that some information is leaked. So we are pushing people to think:
- I want to create a confidential issue.
- I clicked New issue
- The public sees that I created a New issue titled "Enter title". That fact is leaked.
- I toggle confidentiality on.
- I enter the title and description.
- I save the changes.
- Public no longer see the issue
I can see some people complaining about this, even though so little information is leaked.
If this is problem we are deeply concerned about (I would want to wait for feedback before taking action), I would suggest that you when you create an issue in the GitLab UI with a button, we re-design it as a combo button, and the secondary click says
New confidential issue, and when you click it, it creates an issue with the confidential flag already toggled on.Edited by Victor Wuchanged milestone to %Next 2-3 months
@victorwu I like this a lot, but do worry about performance as you pointed out. I think we should do some user testing on it to get feedback before moving too far forward on it.
Edited by Sarrah Vesselovadded UX research label
We can also check how often people currently 'abandon' issues (rates of visiting the new issue form and submitting it). I think I do this reasonably often - maybe 10% of the time I visit the new issue page I am still figuring out if it is a real issue, and if I'm creating a duplicate, and then I realise I don't need to create an issue at all.
@smcgivern @victorwu I don't think we have to persist the issue at all. Just keep it in local storage right now. Only assign it a db entry / id when you submit it. I'm also an abandoner of issues.
Edited by 🚄 Job van der Voort 🚀@smcgivern : Yep, I was referring to that exact behavior of abandonment. I definitely do that a lot myself. I start creating an issue, and then cancel the web form after starting to type. I maintain this is okay though. Like I think we should encourage this behavior and we shouldn't limit our users. Again, this is more of the paradigm shift, influencing user behavior, moving more toward web-apps instead of website mentality. My main argument is that it's okay to abandon issues. In fact, we could build some UI to do so. But there's nothing wrong inherently with saving "abandoned" issues in the database. As a user, I shouldn't care. Now if there's a concern with users wanting to type in a box before it is "saved" and shown to the world, that's a different problem imo. But to me, this abandoning use case is just an artifact of old technology and paradigms. Definitely open to discussion regarding this. I think this is great design discussions!
@JobV : I've also thought about loading the issue page without actually persisting the issue. You would essentially be in "draft" mode for the entire issue. That is possible (and you can have fun with the UI design!). But I think that unnecessarily complicates the UX (drafts?) and also adds more complexity to be be implemented and maintained.
mentioned in issue #34330 (moved)
@victorwu I think I'd agree in most cases with you, but considering our immense pile of issue on .com, I think that even for just our own usage, having these 'abandoned' issues is not acceptable.
Alternatively we'd save it in the db as draft, but why not just local storage (like now) and optionally exposing that?
mentioned in issue #36015
marked this issue as related to #36015
mentioned in issue #36230
changed milestone to %Next 3-6 months
moved to gitlab#10629
Hey!
GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current
gitlab-cerepository will become a read-only mirror, without any proprietary code. All development is moved to the currentgitlab-eerepository, which we will rename to justgitlabin the coming weeks. As part of this migration, issues will be moved to the currentgitlab-eeproject.If you have any questions about all of this, please ask them in our dedicated FAQ issue.
https://gitlab.com/gitlab-org/gitlab-ee/issues/13855You can also find more information here:
https://gitlab.com/gitlab-org/gitlab-ee/issues/13304- https://about.gitlab.com/2019/08/23/a-single-codebase-for-gitlab-community-and-enterprise-edition/
Frequently Asked Questions
For an up to date list of questions and answers, please take a look at
https://gitlab.com/gitlab-org/gitlab-ee/issues/13855What will we do with the repository names?
https://gitlab.com/gitlab-org/gitlab-ee/ will become https://gitlab.com/gitlab-org/gitlab, and https://gitlab.com/gitlab-org/gitlab-ce will become https://gitlab.com/gitlab-org/gitlab-foss.
Why rename gitlab-ce to gitlab-foss?
Using "gitlab" and "gitlab-ce" would be confusing, so we decided to rename gitlab-ce to gitlab-foss to make the purpose of this FOSS repository more clear
I created a merge requests for CE, and this got closed. What do I need to do?
You will need to create a merge request at https://gitlab.com/gitlab-org/gitlab-ee/. This link will eventually redirect to https://gitlab.com/gitlab-org/gitlab.
How does the licensing work in this new setup?
Everything in the
ee/directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in theee/directory, the process of contributing changes is the same as when using the gitlab-ce repository.Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed?
No. Merge requests submitted to this project will be closed automatically.
Will I still be able to view old issues and merge requests in gitlab-ce/gitlab-foss?
Yes.
How will this affect users of GitLab CE using Omnibus?
No changes will be necessary, as the packages built remain the same.
How will this affect users of GitLab CE that build from source?
Once the project has been renamed, you will need to change your Git remotes to use this new URL. GitLab will take care of redirecting Git operations so there is no hard deadline, but we recommend doing this as soon as the projects have been renamed.
Where can I see a timeline of the remaining steps?
https://gitlab.com/gitlab-org/gitlab-ee/issues/13304Will community contributions submitted to the new "gitlab" repository be available in the new gitlab-foss repository?
Yes, these changes will be synced to gitlab-foss automatically, several times per day.
