Re: Brainstorming features for issues.guix.gnu.org

["Björn Höfling" <bjoern.hoefling@bjoernhoefling.de>]

[-- Attachment #1: Type: text/plain, Size: 6288 bytes --]

On Wed, 01 Apr 2020 04:05:13 +0200
Ricardo Wurmus <rekado@elephly.net> wrote:

> Hi Björn,
> 
> thanks for the list of suggestions!
> 
> > * First of all, I find this mixture very confusing: Is this about
> > bugs or is this about patches? I really don't know, and the start
> > page is ambigious about it too:
> >
> > "Guix /patch/ tracker
> > This is a web frontend to the Guix /issue/ trackers.
> > /Issues/ of interest
> > Priority /bugs/"  
> 
> I updated the text, but I think it’s not a good idea to have two
> separate trackers, because bug reports can have patches.

OK. I understand.

What about adding a syntax like "source:bugs", "source:patches"? I
would like to have something like this in order to compare my emails
with Mumi (at least to easier show you that there is again something
missing :-))

> > * Is it intentionally that there still is a http site? I would have
> > expected a redirect onto https.
> >
> > * http[s]://issues.guix.info/ is also still alive. Shouldn't it
> > redirect to http[s]://issues.guix.gnu.org/?  
> 
> This should be changed in maintenance.git.  I would like a redirect to
> https://issues.guix.gnu.org/.  I haven’t done this yet as I’m only
> focusing on mumi itself at this point.

OK. I looked into the nginx config in the maintenance repository. I was
surprised how complex this already is.

> 
> > * If you search for something, you get away from the homepage and
> > tips are missing. There should be a "help/tooltip" button near the
> > search input that explains the query language.  
> 
> The search results page now also has the search input widget with
> hints. Not sure how to handle the little search field in the menu
> bar, though.

Looks much better now, thanks :-)

 
> > * If you enter a query, that query should be kept in the input
> > field. Currently, it is discarded. That would make it more easy to
> > update your query.  
> 
> Yes, this has annoyed me too.  The query is now kept.

Very nice :-)

 
> > * It is not clear to me how long a closed issue is still visible on
> > the home-page. Is it still an "Issue of interest" if it is closed?  
> 
> The idea was that you may want to look at issues that have just been
> closed to catch up (or to reopen them).  But I guess closed issues
> could just be hidden.
> 
> > * Sorting issues by columns would be cool.  
> 
> Done.

Wow.

> 
> > * Mumi has no paging: It only presents one page of issues, but it
> > doesn't say how many are there in total nor does it page through all
> > other pages of issues.  
> 
> Yes, this is a restriction due to debbugs.  We can’t ask it for all
> issues and implementing paging is a little annoying.  I think this
> will change as I’m making more and more features independent of
> debbugs requests.

OK, I understand that limitations.

 
> > * In that list, it is not clear what a red/orange colored bug-number
> > means: A tool-tip would be nice.  
> 
> I never liked those colors.  There’s a little icon now with a
> tool-tip.

Good.

> > * I still don't see that all bugs and patches from the mailing list
> > are part of the mumi issues list?  
> 
> There was a problem with the worker process that fetched and indexed
> messages from Debbugs.

Is it broken again? I don't see any messages from April.
 
> > * The HTML could be responsive.  
> 
> It should be responsive with recent changes.

You are right. I meant it could be "more" responsive: When I use the
site with my mobile phone, I have to scroll horizontally to see the
"Done" column.

One idea would be to not use a <table> but <div class="container"> and
make use of the bootstrap 12-cells grid layout. In that way, some
columns could be removed and/or shown in smaller versions in the mobile
version. Also we don't need to stick to exactly one line but could wrap
it in the mobile version.

I wanted to try that out, but failed to set up mumi. I will write about
that in its own message.

Maybe it would also help to have the date formated in ISO-format?
 
> > * The query syntax examples are only on the home page. Please repeat
> > them also on the help page.  
> 
> That I don’t understand.  The help page has *more* examples, no?

Definitions: Directly under the search input field are the "Hints".
From there, you can open the "Help" page.

The "Help" page contains the full syntax definitions. But it contains
less examples than the "hints" :-)

In the "hints", I directly find and can copy the example "date:2d..now"
or "date:2018-04-01..2018-04-02". On the help page, the full syntax is
explained, but these examples are no longer there to copy. I have to go
back to the hints.
 
[..]

> mdate no longer exists (it was a debbugs search filter), but maybe
> it
> should be added again to distinguish between message dates and
> submission dates.  I’ll add this to my list.

That would be a good idea. I thought that "date" is the submit-date
whereas "mdate" would be the date of the last post (and not any
technical synchronization thing).

There are two things wrong with the dates that could have the same
cause: The order doesn't match and there are issues with no post at
all within the specified date range:

http://issues.guix.gnu.org/search?query=date%3A2020-03-30..2020-03-31

If I order that by "date submitted", I see that the order is broken many
times.

For example this issue is from 2018 but is ordered somewhere in the
middle:

http://issues.guix.gnu.org/issue/33507

Next thing: The following issue has its last post from 2020-03-20 and
thus should not be within the search range:

http://issues.guix.gnu.org/issue/37266

Only when you switch to Debbugs you see an obscure control message "Did
not alter fixed versions and reopened" which was from 2020-03-30:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=37266

This message is neither understandable nor shows it up in MuMi. Either
the message does not show up in Mumi (which I would prefer) or the
technical messages should also show up in MuMi such that for the user
it is clear why this issue is part of the search result.

> Thanks again!

Thanks to you for the improvements!

Björn

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]