The patch to do this is easy enough:

diff --git a/ pagure/static/pagure.css b/ pagure/static/pagure.css
index 5c430ad..d17354b 100644
--- a/ pagure/static/pagure.css 
+++ b/ pagure/static/pagure.css 
@@ -560,7 +560,12 @@ th[data-sort] {
 }
 @media (min-width:1200px) {
 .pr_comment_form .card, .inline-pr-comment .card{max-width:680px}
+}
 #watch_project a {
   cursor: pointer;
 }
+
+#metadata_block {
+  position: fixed;
+}
diff --git a/ pagure/templates/issue.html b/ pagure/templates/issue.html
index f6d2f90..3bbeb11 100644
--- a/ pagure/templates/issue.html      
+++ b/ pagure/templates/issue.html      
@@ -93,7 +93,7 @@
   </div>
   <div class="col-md-4">
-    <div class="card">
+    <div class="card" id="metadata_block">
       <div class="card-block">
           <fieldset class="form-group issue-metadata-display">

@ryanlerch, what do you think of it/the idea?

Hmmm, not 100% sold on the scrolly-ness -- me is just not a big fan of that kind of behaviour (that is personal preference though)

The question I do have is this though, is knowing the metadata of a bug important as you are scrolling down through all the comments?

The question I do have is this though, is knowing the metadata of a bug important as you are scrolling down through all the comments?

I think it'll be quite useful if one can easily see who the ticket has been assigned to, or who's part of the conversation, of if the issue is fixed or still open - without having to scroll up and then come all the way down to find where in the conversation they were and all that?

one small benefit that i can see is that when you want to mention which pr addresses the issue and then want to close the issue. I tried position: fixed on the day this issue was opened, but the metadata somehow overlapped with the footer once you scrolled till the bottom of the page :/

but the metadata somehow overlapped with the footer once you scrolled till the bottom of the page :/

I have seen this but seems to depend on the size of the screen :-S

Hmmm, not 100% sold on the scrolly-ness -- me is just not a big fan of that kind of behaviour (that is personal preference though)
The question I do have is this though, is knowing the metadata of a bug important as you are scrolling down through all the comments?

Agreed , I really don't feel the need , once you land up on the page first thing you notice is metadata, and then you scroll down , so I doubt it's required.

Agreed , I really don't feel the need , once you land up on the page first thing you notice is metadata, and then you scroll down , so I doubt it's required.

And what happens when you follow a link that takes you directly to a comment further down in the page so that you don't land on the page and "notice the metadata"? ;)

To me, this is a no brainer - this doesn't adversely affect user experience at all. At the moment, I've got free, unused white space on the right - I'd rather it be used to show me metadata so that I can focus on the work being done in the ticket and not have to remember the metadata.

@ankursinha I think I am convinced enough for this :smile: so yeah :thumbsup: from myside

OKay, but we need to make sure that it doesnt ever get chopped off at the bottom on smaller screenheights.

I checked to see how Github handles it - they don't show the metadata bar at all on mobiles. They probably have a different theme for mobile devices (which I expect covers "smaller screens").

If people want to poke at this, it can be tested in the branch scroll_metadata of this repo: https://pagure.io/pagure/commits/scroll_metadata

Let's give this a few days and either merge or close this ticket as invalid depending on what people think :)

@pingou looking at your commit https://pagure.io/pagure/commits/scroll_metadata the metadata sidebar kinda clashes with the subscribers sidebar.

I guess this idea was a good one before we had a subscribers list. I just like it the way it is now (that is my opinion though, i could be completely wrong about it). :)

a big -1 for this RFE from me,

the amount of effort required to get this working properly (especially when the sidbar content is longer than the height of the page) is just not worth it for the payoff in the end IMHO.

Considering the way the side bar has grown since this ticket was opened, while I was originally potentially interested with the idea, I now agree with @ryanlerch.

Let's close this ticket