Allow old default project view instead of the new one since 9.0

The default project view has been changed recently and there is no way to keep the old one.

• Before: only the readme is shown as default project view, hiding a potentially large amount of files until the user clicks at Repository tab. I find this representation really neat and clean.
• After: We have two options: either to show activity or readme and files. The problem here is that the files are shown before the readme, so to see the readme the user must scroll past all the files.

Proposal

Return the third option of Readme only. This would mean we have three options:

• Activity
• Readme
• Files and Readme

changed title from Allow old project view instead of the new one since 9.0 to Allow old default project view instead of the new one since 9.0

@zabugr This was removed by the following Merge Request:

• https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9744

@annabeldunstone Is there an associated issue to provide context for the removal of this option?

added frontend ~65372 settings labels

Thanks @markglenfletcher for the fast response and for pointing out the merge request with the change.

Briefly looking over the merge request it seems that it is really simple to return the option.

I would ask you guys to consider returning this as this is a deal breaker for me and my team. I kept praising Gitlab for keeping the project pages so clean and not following the way GitHub does it (which it does now). This change is clearly a regression for me.

@markglenfletcher the original issue is https://gitlab.com/gitlab-org/gitlab-ce/issues/27882

@annabeldunstone reading through the original issue, I must agree, that on some projects people don't need to see the readme ever so often. However, there are projects, that are used mostly as a reference and the readme there is one of the main parts of the project. In this case it would be nice to be able to see the readme straight away.

Thanks for your input @zabugr. Maybe @sarahod & @tauriedavis could weigh in here.

I agree that having just the readme view is perferable for some users who do not interact with the repo often. I have no problem including just the readme as an option. Cc @dzaporozhets

I have no problem including just the readme as an option

@tauriedavis I believe we removed it originally since expect not much people need it with new files+readme default. So basically we can return it if proven that a lot of people actually need readme over files+readme.

@dzaporozhets adding this as a third option to the existing two doesn't seem to hurt anybody, while still allowing people using it if they like. We use gitlab in a university lab and there is a lot of (potentially inexperienced) students looking at the repositories here. Readme serves a small tutorial on how to use the software and will be viewer much more often than the files will be edited. Therefore, the need to have it as the first thing people see if they prefer to.

@zabugr adding another option is actually hurt from code support perspective. Adding is cheap, making sure it works correctly over years is not

Ok @dzaporozhets this is true.

I do understand the hassle of supporting more options. However, you have just added two options instead of having one default one ("activity + readme and files" versus "just readme" before), and I hope you will either consider reverting the "files + readme" to "just readme" or adding the latter as a new option, as this breaks our workflow here and is definitely a regression in usability from my point of view.

I also understand, that you have changed the behavior based on UX research. The problem here, is that this research does not cover my usecase 😄

@zabugr so before 9.0 we had 3 options: readme, files+readme and activity. Now its 2 options: files+readme and activity.

Hm. Thanks for clarifying, I was not aware of it. I thought there was one default behavior - readme only. At least that is what I saw in all projects and I don't remember seeing a setting to change this. In any case, I hope this option will be available again.

mentioned in issue #26878 (moved)

In the linked thread there were people who also wanted the "Just Readme" option back. Can anyone update us on the current status? Is this going to happen or will we have to get used to seeing all the repository before we get to the readme 😅?

Thanks @zabugr - My assumption is still that the repo isn't needed by a portion of users and therefore the readme is a viable option on its own for the project home page. As @dzaporozhets mentioned, we have to get some data to support this in order to add this as a third option.

cc @sarahod

Thanks. I do hope the option returns. To be honest, I don't see how this feature can be a burden as the readme is definitely there in every project and is the part that is least likely to change.

Just ping me if you need something else from me.

mentioned in issue #19002 (closed)

mentioned in merge request !11425 (merged)

We currently have a lot of projects where issues are submitted by a large group of non-technical users, so we need the readme front and center, and do not want to distract users with the project files.

We have some procedures that are documented in the readme that are accessible by visiting the home-page of each project. Not having this feature has broken a number of our workflows. I would love to see this implemented again 👍🏼

@tauriedavis @dzaporozhets what do you think about re-implementing readme only?

This is exactly my original concern. Thanks @Tuckie and @Bramanga for putting it up again.

This is exactly the usecase. Some projects are mostly opened not to be developed but to be used. It is very clean to see a readme when opening the project. For example, we have students, who use the projects a lot but rarely must contribute to them.

And another thing is that, arguably, the files view does not bring much value in web interface anyway as people tend to just clone the project and navigate it with other methods they are used to. At least that is my experience and what I have observed in our lab.

Overall, I really don't understand why this is being forced upon us to have the files before the readme. Original argument of @dzaporozhets was that supporting any feature is hard, and I understand that logic, but currently it seems (e.g. from discussion in !11425 (merged)) that there is actually more work needed for cleaning the old setting out than it would be needed should you decide to leave it be as it was before. The users would still have readme in their preference and no change would be needed for whoever would have had no intention on changing it.

There is clearly a demand for the feature. Do you guys have data to back up the decision that the readme view is indeed as useless as you assume?

I would like to re-implement the readme only option @annabeldunstone.

I feel from our research, we know that the readme view is preferable for first time users. We also have had several responses and issues made to add it back. The reasoning is clear: not every user is technical and needs to view the repo.

@annabeldunstone @tauriedavis only if data says so. And files view must stay default.

Sounds like the research does support the fact that users feel the Readme option was useful. We can keep the default as it is, and users can select the view that works best for them.

I think getting rid of the README only option is penny-wise, pound-foolish.

It's the same as the Files + README, only the Files section is style="display: none". Feels light-weight, maintenance-wise to me and easily worth it for different types of projects that are not repo oriented. Those projects are trying to leverage the "I don't like having so many systems to login to and work with, so let's put this project into GitLab, too". Documentation projects, experimental results from another project, test input data project, etc.

Most of people visiting a project are NOT developers (Project Managers, Team Managers, Testers, ...).
Not having the README only view available (by default) is killing yourself: that's these non technical peoples (managers) in big compagnies that have the money to buy licences and can fund infrastructure to host our Gitlab instances.
Most of the latest changes in UI, and particularly this one, make them feel Gitlab is just a gadget for geeks they don't need to put money in. It ruins all our long efforts to persuade them that Gitlab deserves a line in the next budget.

Thanks @orobardet. As stated before, we are planning to add the Readme option back. I'm not sure who to tag for scheduling... @victorwu is this your area?

It sounds like it will require some backend work cc @dzaporozhets

@dzaporozhets I'm sorry, but I have to agree with @orobardet about this. Given the project management aspects added to GitLab, it now has to support many non-technical folks and they can hinder adoption which should be considered anathema to anyone at GitLab, Inc.

@gsmethells sure, lets do https://gitlab.com/gitlab-org/gitlab-ce/issues/30140#note_31415963

mentioned in issue #33783 (closed)

@victorwu can this at least be moved to the %Backlog since it has approval from @dzaporozhets above? This seems to have gotten lost in the shuffle.

added Platform label

added UX ready and removed awaiting feedback labels

Thanks @gsmethells for bringing this back to our attention!

@mydigitalself @sarrahvesselov This would just be adding back what we already had before so the effort is probably minimal.

changed the description

@jramsay : Can you help with the putting this issue in the right milestone (if applicable)? Thanks!

@gsmethells : Feel free to take a look at here to see who to ping for help: https://about.gitlab.com/handbook/product/#who-to-talk-to-for-what.

changed milestone to %10.2

added Deliverable label

assigned to @jramsay

moved to gitlab#8999

Hey! 👋

GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current gitlab-ce repository will become a read-only mirror, without any proprietary code. All development is moved to the current gitlab-ee repository, which we will rename to just gitlab in the coming weeks. As part of this migration, issues will be moved to the current gitlab-ee project.

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/13855

You 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/13855

What 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 the ee/ 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/13304

Will 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.

locked this issue