savannah-hackers-public
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Savannah-hackers-public] Any paid volunteering service opportunity


From: Bipul Kumar
Subject: Re: [Savannah-hackers-public] Any paid volunteering service opportunity
Date: Sat, 3 Sep 2022 03:16:09 +0530

Hello,

I would like to know that is there any paid volunteering service or project
inside or outside of this organisation available?

Kindly let me know

Regards
Bipul
Please excuse brevity and typos

On Sat, 3 Sep, 2022, 2:56 am G. Branden Robinson, <
g.branden.robinson@gmail.com> wrote:

> [groff list CCed]
>
> Hi folks,
>
> I've had this problem for a long time...
>
> If I want to review the bugs for the groff project, for example, I can
> go to the Savannah ticket tracker, and load a URL like the following.
>
> https://savannah.gnu.org/bugs/?group=groff&func=browse&set=open
>
> (in fact, that link comes from https://savannah.gnu.org/projects/groff/)
>
> Right now, that gives me 271 tickets.
>
> Then, I click open the "Display Criteria" widget, and change the "Browse
> with the" list box control from "Basic" to "Enhanced", because I want to
> filter items by "Planned Release", and even the "Advanced" query
> interface doesn't enable that.  I then click the "Apply" button to
> submit the form.
>
> I get back a new screen showing 271 items, with more fields displayed
> (that's fine).
>
> My URL is now:
>
>
> https://savannah.gnu.org/bugs/index.php?go_report=Apply&group=groff&func=browse&set=custom&msort=0&report_id=223&advsrch=0&status_id=1&resolution_id=0&assigned_to=0&category_id=0&bug_group_id=0&history_search=0&history_field=0&history_event=modified&history_date_dayfd=2&history_date_monthfd=9&history_date_yearfd=2022&chunksz=50&spamscore=5&boxoptionwanted=1#options
>
> If I _make no changes_, but just click "Apply" again, I get:
>
> "No matching items found.  The display criteria may be too restrictive."
>
> Inspecting the URL, I see that it has grown longer.
>
>
> https://savannah.gnu.org/bugs/index.php?go_report=Apply&group=groff&func=browse&set=custom&msort=0&report_id=223&advsrch=0&bug_id=&details=&summary=&submitted_by=0&resolution_id=0&assigned_to=0&vote=&privacy=0&bug_group_id=0&status_id=1&severity=0&category_id=0&close_date_op=%3E&close_date_dayfd=2&close_date_monthfd=9&close_date_yearfd=2022&date_op=%3E&date_dayfd=2&date_monthfd=9&date_yearfd=2022&plan_release_id=0&discussion_lock=0&sumORdet=0&history_search=0&history_field=0&history_event=modified&history_date_dayfd=2&history_date_monthfd=9&history_date_yearfd=2022&chunksz=50&spamscore=5&boxoptionwanted=1#options
>
> Apparently, new "Closed on" ("close_date_op") and "Submitted"
> ("date_op") filters have been applied.
>
> There are several problems with these features.
>
> 1. Once the "Enhanced" form has been presented, there's no way via the
>    controls on the page to omit them.  The filter always applies.
>
> 2. The dates always default to the current date and the _greater than_
>    operator.  This is guaranteed to fail.  No bugs are ever submitted or
>    closed in the future.
>
> 3. There's no option in the controls to disable these two filters.
>
> 4. There's no "None" option available as an ordering operator for these
>    two filters.  (Items 1, 3, and 4 are probably tightly coupled.)
>
> 5. Even if I change the operators from "greater than" to "less than", I
>    _still_ get no results.  This is because the "Open/Closed" control is
>    still on "Open", and the "close_date_op" filter is still applied.
>    Perhaps this filter should be disabled by default in this
>    circumstance.
>
> 6. To really use the filtering-by-date feature, you have to edit the URL
>    by hand.  This is tedious.
>
> 7. Erasing the operator from the chunk of the HTTP GET query doesn't
>    work, possibly because there's no empty or null option for the date
>    ordering operator.  It defaults to the first item in the list, which
>    is "<".  (This appears to be true for both "date_op" and
>    "close_date_op".)  You have to remove these chunks entirely.
>
> I suggest:
>
> A. Giving each of these filters an independent check box-like control to
>    disable them; or, adding an empty list box item and using that for
>    filter disablement.
>
> B. Disabling them by default.
>
> C. Changing the default ordering operators to, if not empty or
>    inapplicable, "less than".
>
> I reiterate that this is not a recent problem; it has affected Savannah
> for as long as I've used the system--about five years.  For a long time
> I thought my own ignorance was the problem.  But that does not appear to
> be the term of highest order here.
>
> I apologize if some of my Web jargon is antiquated.  So am I.
>
> Thank you for your attention.
>
> Regards,
> Branden
>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]