Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103049
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.220.177 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <CABphOUd3T6=KSKrH71HBYcMZMDwYeDPBDUwqnBsv2BG9FFpp4w@mail.gmail.com>
References: <CABphOUd3T6=KSKrH71HBYcMZMDwYeDPBDUwqnBsv2BG9FFpp4w@mail.gmail.com>
Date: Tue, 7 Aug 2018 15:10:37 -0500
Message-ID: <CAESVnVoKNC-033UaY_Oonbz9R6S3xPQ=bvD1XkKdeCMWL_tt=A@mail.gmail.com>
To: Tymoteusz Motylewski <t.motylewski@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] bugs.php.net usability, migration to a different tool
From: pollita@php.net (Sara Golemon)

On Tue, Aug 7, 2018 at 1:17 PM, Tymoteusz Motylewski
<t.motylewski@gmail.com> wrote:
> tl;dr
> In my opinion:
> Current bug tracker is terrible. Moving to a better/modern bug tracker
> should be a high priority of the PHP community.
>
That's a bit harsh, but I get your point, it's a getting to be... long
in the tooth, shall we say.

> To make the discussion constructive please answer following question
> first, before we jump into details.
> 1. Do you agree that current issue tracker needs a change, or it's ok for=
 you?
>
Yes, though I'd say "deserves" a change, not "needs"..  That change
may be improving the current tracker in place, or it may mean
evaluating and migrating to a new tool. See comment in #3 btw.

> 2. Do you consider that it's important and high priority to have a
> better, more collaborative tool there?
>
Important, yes.  High priority, no.  What we have may not be ideal,
but it works, and you don't up-end a 20-year old project's database of
over seventy six thousand bug reports without *careful* consideration.

> 3. As stated on twitter
> (https://twitter.com/official_php/status/1024658601770668033 ) there
> are some specific needs which make the move to different tool harder.
> What are they?
>

At a start (non-exhaustive):
1. Need for integration with PHP's dev login database (x@php.net people)
2. Ability to import and index ALL existing bug reports.  You may have
trouble parsing it, but it's most certainly of value to those of us
fixing these bugs.
3. Support for existing bug reports still being editable by their
original posters (requiring them to create a new account tied to their
original email is acceptable)
4. Support for private bugs only visible to a small subset of devs (
https://github.com/php/web-bugs/blob/master/include/trusted-devs.php
).  Security vulnerability reports shouldn't double as zero-day
announcements.

Beyond that there are some unexpected requirements.  For example, did
you ever wonder why php.net doesn't use any frameworks?  Partly it's
because of its age, but it's also because the minute we do, we
implicitly endorse that framework and that upsets the balance of the
ecosystem.  We don't want one framework or another to win by default,
we want the best solutions to rise up and excel in their ideal space
on their merits (as much as that's possible).  As a result, all of
PHP's website code is artisanal, hand-written, and in some areas, a
bit crap.  That same guideline would certainly apply to any
off-the-shelf bug tracker.  Does this make replacing bugs.php.net
100,000% more difficult? Yes, yes it does. However, C=C3=A6sar's wife must
be beyond reproach.

What this all ends up meaning is that the best way forward is small
(read: reviewable), incremental improvements to the bug tracker we
have.

Now, to your specific points (and I'll be a bit defensive here):

> - the UI is terrible (not useful, confusing, misleading)
>
UI is harsh and a bit 90s in styling, but I have a hard time agreeing
with the rest of that statement.  What is confusing to you?

> - it's really hard to find what person is looking for
>
Fair point, the search is... rudimentary.

> - data quality is low (many duplicated reports, lot of old reports
>
In fairness, you'll find this in every bug system for any project with
even moderate popularity.

> - the tool blocks community in helping managing the issue list and triagi=
ng bugs
>
Citation needed.

> - Its not possible to log in, be notified when sth change on issues
>
Incorrect. Any issue you comment on will email you (assuming you've
provided a valid email address) on any change.
I'll grant that you shouldn't need to put your email address in a
public place (the obfuscation is a joke) just to subscribe to updates,
but subscribing is possible.

> - Its not possible to link issues which are related/duplicated (when
> you're not power user)
>
Is our hypothetical volunteer somewhere between "wanting to help" and
"not wanting to get a php.net account"? Because that's the user who's
unable to link issues.
Also, comments make for lovely links.  The bug ID urls are 100%
restful permalinks.

> - its not possible to state PHP version or OS you're reproducing the issu=
e in
>
The voting functionality is a relatively recent addition.  I agree
it'd help to expand its scope.

> - the search is not indexing comments (so the place where most
> important information is stored)
>
Fair point. As I said above, the search functionality is naff.

> - some actions like trying to edit an issue don't always return a
> result/information/feedback to the user, and once they do it's not
> helpful e.g. "The password you supplied was incorrect." -> what is the
> password all about? where do I get it?
>
The password you created when you reported the original bug.  On the
bug reporting form.

> how can I get it back once I forgot?
>
That, funnily, is a bug.  There should be a link to
https://bugs.php.net/bug-pwd-finder.php?id=3D$bugid next to the password
field.  I'll fix that in a moment.

> - voting has some radio buttons selected by default, so I'm sure many
> users just submits wrong data, because they just want to vote and
> haven't check e.g. OS radio.
>
You're sure about that?  I'll grant that removing the default
selection makes sense, but to say that "many users just submit wrong
data" is blind conjecture, and insulting to PHP bug submitters.

> - I can't change the voting once it's done
>
Fair. The concept of a non-@php.net user is weak and would be well
replaced by a more robust login functionality.

> - The "Same OS" stats are not really helpful, it doesn't even help to
> know whether it's windows only issue or also linux related, it's not
> really possible to filter issues related to some system
>
It absolutely does help to know if it's OS specific.  That points to
cause, and ultimately solution.

> - there are still open issues for long not supported versions like 4
> or 5, and you never know whether they are still valid because nobody
> updates the affected versions. You need to go inside to see activity
> and maybe you'll deduce sth from it.
>
Blame the original poster?  Again, the quality of open bug reports
isn't a function of the bug reporting tool, it's a function of the
triage and maintenance of the data in that tool. ((Yes, I know, triage
and maintenance of data is a side-effect of the usability of the
tool.))

> - there are tons of stale issues even from over 10 years ago. With
> better issue tracker people from community would be able to help
> triaging these bugs, confirming them, setting correct statuses,
> finding duplicates and so
>
Are you suggesting that arbitrary users be allowed to alter bug report
status without authentication?  If you think the data is worthless
now, you'll love what happens when anyone can edit anything without
limitation.

Many of the above can be fixed, and the entire site is in PHP and on
github.  I encourage you to offer pull requests!

-Sara