When I respond to previous comments in issues, I frequently use > to quote their comment. I find myself doing this frequently, which involves highlighting the text I'm interested in, scrolling back down to the comment box, pasting, and appending it with >. This is tedious.
Proposal
When I highlight comment or description text, display a tooltip on the highlighted text with a "reply" option.
When I click reply, add the highlighted text to the comment box appended with > and snap my view down to it.
@jeremy_ Ohhhh I love this. This has been one of those ideas that has stuck in the back of my head but never created an issue for it. Thanks!
If it's the issue description, we can have it say just “Quote” since it may have been edited by multiple people. If it's a comment we can have it as “Quote and reply”, which will also mention the quoted user. WDYT?
I definitely can relate to the use case here, thanks for this proposal @jeremy_!
Thanks for sharing your thought here, @annabeldunstone and @pedroms. I feel that getting the micro interaction right is key between making this potentially annoying and a great experience. Let's involve Engineering early for feasibility.
On a first look, "Quote and reply" sounds very absolute to me since I expect that this auto-comments the highlighted quote, instead of pasting this into the comment field for a draft first. Might be me.
@pedroms Do you see a good reason for addressing object descriptions and comments separately?
On a side note, I just learned that you can do this now by highlighting text in an issue and pressing r. Yay for hotkeys, but I had no idea until I read about it in https://gitlab.com/gitlab-org/gitlab-ce/issues/43716
This is also available in discourse forums. Afaik they only have the text "Quote" which seems good to me. The quote will then get inserted into the reply field including some code to link to the relevant comment.
@akaemmerle I do not see a reason why to treat description and comments differently, maybe only if the quote has additional info like linking the user who wrote it. But still this can be handled pretty much the same way I guess.
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.
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?
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?