Arun Isaac <arunis...@systemreboot.net> writes: > Hi Noé, > >> Seeing closed issues is very important depending on what I’m looking >> for. How about having a colored « open » indicator next to the tags (or >> as a tag)? > > Yes, we could have an "open/closed" indicator badge similar to the tag > badges. I'll implement that. >
Cool! > I also think we should make search queries only list open issues unless > an explicit "is:closed" or "is:done" is added to the query. When > "is:closed" or "is:done" is part of the query, we only list closed > issues. WDYT? > > We could also try to somehow hint at this in the UI. Perhaps by having > separate nav links for open and closed issues. But, that requires some > careful consideration. > In that case, I think it should be done the GitHub way: A search is either is:open or is:closed and you can switch with two tabs, or remove the is: to get all results regardless of open or not. I do think its important to have a way to just show all matching issues, if you want to see previous work for something. >>> We could bring back the sorting. But first, could you help me understand >>> what you use the sorting for? Would maybe, narrowing down your search >>> using a more targeted query suffice? Perhaps the "date:" or "mdate:" >>> search prefix is what you need? >> >> I use it to see if there are previous/pending patches for a given >> package. Having it sorted is very useful, for example I wanted to see >> the latest work on the package « discover ». > > I see that https://issues.guix.gnu.org/search?query=discover does not > produce good search results. Sorry about that. But, how does sorting by > date help with that? Have you tried adding something like > "date:1y..now", etc. to your search query? > Well, I can say that if there are no results in the first 3 years or so then no patches have been made on that package, your solution works :) >>> What's more, suppose you sort search results by date, this might >>> actually be putting a very low relevance search result on top. And, a >>> low relevance search result is probably not what you're looking for. The >>> sort feature from earlier was really a client-side hack. It ignored >>> things like pagination on the server-side. See >>> https://git.savannah.gnu.org/cgit/guix/mumi.git/tree/mumi/xapian.scm#n252 >> >> That’s only a problem if there are many low relevance results, but for >> package names that is rarely the case. > > If https://issues.guix.gnu.org/search?query=discover were sorted by > date, a likely low relevance result would be arbitrarily put on top. > That's probably not the behaviour we want. > For something with 10-30 results, that would be the behaviour I’m looking for as I can look through the title of each of them and see if its what I’m looking for, and just stop on the first good result. > Also, implementing sorting on the list is difficult to do, especially > with the new relative dates that we have. And, I don't have much time to > hack on it at the moment. However, I'm happy to accept patches if you'd > be willing to write them. :-) I don’t understand how relative dates block sorting, I would think they are only made relative when rendering the page? Maybe I can find some time to hack on mumi, that would be nice. Oh and by the way, is it normal that recent issues only show from two weeks ago on issues.guix.gnu.org? Have a nice day, Noé
signature.asc
Description: PGP signature
