Board refresh dynamically

Description

• Refresh the issue board dynamically.
• Suppose a user has a browser tab open with an issue board displayed. Any changes to the board should be dynamically refreshed. Need UX and development input and a lot more discussion to to know how we should slice and dice this goal into multiple issues.

Why do we need this?

• People expect modern web apps to be dynamic and refresh automatically. Gmail pioneered this and popularized this notion and the modern frameworks support this. So GitLab should be dynamically refreshed in the places that make sense to the user.
• It makes total sense in the board feature. In a typical use case, a user has a browser tab open all the day. There may be a tab open in a dedicated monitor in the office for one user, or maybe a big wall monitor where the board is open. (Think about how users have whiteboards with stickies. This is one of those use cases.) Users expect that page to be refreshed automatically as people work and make changes to issues all day.

Mentioned in issue #21264 (closed)

Added frontend ~19492 labels

@JobV @regisF @markpundsack @awhildy : Do you folks know / have an opinion / have context on what we are doing in terms of dynamically refreshing the components of pages in GitLab? I've noticed that some components are dynamically refreshed, some are not. Some components have a loading mask. Some do not. (I believe comments in discussion threads just appear.) Any guidelines or general thoughts on what we should do holistically?

As for boards, my feeling is that this should definitely have all components refreshed dynamically because of the use cases I outlined above.

@jschatz1 : There's a lot of data that's shown in the board here. I can count: Issue existence, order, label, title, assignee, the controls for the lists themselves. Would we have one issue to make everything dynamic? (This one) Or would these be multiple issues?

this can be seen as part of our efforts on making gitlab real time: https://gitlab.com/gitlab-org/gitlab-ce/issues/24429

Thanks @dimitrieh. This definitely falls within that meta issue. Glad to know that it's already being addressed site-wide. I'll link this issue to that one if it makes sense.

Mentioned in issue #24429 (closed)

thanks @victorwu I created that issue with that intent, great!

@victorwu Just to give you a context. We recently migrated to VueJS and I think it's almost all over the place now. We do long polling on the Issue and MR pages for new comments and other stuff. We talked about using websockets, but we are not there yet (unfortunately). And likely won't in the near future - that means, updating everything dynamically might be difficult or too costly at the moment.

Ideally we would have real time everywhere, so we can collaborate on GitLab in real time (the possibilities are basically endless and super excited), but in practice, we can't do it yet. That being said, we should totally aim for it and I applause @dimitrieh's initiative.

Thanks for creating this issue, @victorwu! Overall, I agree that we need more components to refresh dynamics, and issue boards is a great place to start. I think starting by focusing on experiences that are targeted towards people managing a project make sense, for the reasons you listed above. This could also include burn down charts, and the milestones page. Not sure how the priority of this ranks with the rest of our work -- but could be considered important for large teams which require more management (i.e. enterprises).

Mentioned in issue #24344 (closed)

Added ~122770 label

Agreed that we should start doing this. Asked @jschatz1 for some insights in when and how.

We have recently begun the work of building components that will automatically poll. we have now done this on the pipelines. There are many things we would like to be real time and we have to decide which is the most important. I was thinking the merge request page would be a good next step but it would be good to figure out what is most important.

@victorwu @JobV Can we make a list of those most important things. In the meantime. I think we can put this as a stretch for this release. @iamphill may be able to hit this up if he finishes up his Deliverable s.

@brycepj has written a class to create a subbable resource. And @selfup has recently finished up the pipelines to make them realtime so we are completely capable of making this real time. There is also the question of what this will do to the server when we poll it this much. For that we have to have a discussion with @northrup.

Thanks @jschatz1. @victorwu can you work together with @dimitrieh, who made the excellent list above to work on these priorities?

Boards are a good place to start, but I agree that merge requests are maybe even better (!).

My first thoughts UX wise towards this is, making the cards either pop in from the bottom (as from the top, this can become to distracting with a lot of people moving issues?) of each list or grow between two other cards in for example the middle of a list (if we support sorting). Except for that let's see how it works while its real time.. I think this is one of these things we really want to have just real time..

The other thing is with lists with more than 20 items.. will it even change? as these new items would be one the next 20 or so cards.. (aka pagination)

ah well, lets see how this works of the batch

@dimitrieh the only problem I see with adding to the bottom is that the priority of the new issue might mean the sorting of the lists put the new issue at the top, so it would automatically change the order when we receive a new issue.

I think the pagination shouldn't be an issue, new issues would have a higher ID so should therefore be top (or close to top dependant upon priority of other issues).

@jschatz1 + others: Let's move the convo over to https://gitlab.com/gitlab-org/gitlab-ce/issues/24429

Reassigned to @iamphill

Based on this conversation, I'm making this 8.15 and stretch. Please update if that is wrong. Removing UX because it seems like we have it figured out, but @iamphill - please reach out to UX if there are any questions or things we can help with. Thanks!

Added Stretch and removed ~19492 labels

Milestone changed to %8.15

Mentioned in commit 458d67e6

Mentioned in merge request !7782 (closed)

mentioned in commit a8188b64

changed milestone to %8.16

removed milestone

We should make this part of the realtime stuff @victorwu we can do this later.

Shall we say ~"coming soon" @victorwu ? Since we want to make this realtime?

removed assignee

removed Stretch label

@jschatz1 done

changed milestone to %Next 2-3 months

added Discussion label

mentioned in issue #31634 (moved)

moved to gitlab#7010

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