bugs.php.net usability, migration to a different tool

On Tue, Aug 7, 2018 at 1:17 PM, Tymoteusz Motylewski
t.motylewski@gmail.com wrote:

• 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.

To clarify: you are supposed to be emailed on new comments, if you have
reported the bug (i.e. opened the ticket), are assigned to the ticket,
or if you have subscribed (Add comment → subscribe). The latter appears
to be broken since a while (likely since the tracker has moved to
another machine).

• 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.

Even better: just write “bug #12345”, and the other ticket also gets a
comment “Related to bug #54321”.

• its not possible to state PHP version or OS you're reproducing the issue in

The voting functionality is a relatively recent addition. I agree
it'd help to expand its scope.

I'm not sure whether this voting is actually useful. Otherwise
https://bugs.php.net/54632 would probably already have been addressed.

--
Christoph M. Becker

wt., 7 sie 2018 o 22:10 Sara Golemon pollita@php.net napisał(a):

On Tue, Aug 7, 2018 at 1:17 PM, Tymoteusz Motylewski
t.motylewski@gmail.com wrote:

That's a bit harsh, but I get your point, it's a getting to be... long
in the tooth, shall we say.

Sorry for that, got too passionate about PHP ;)

At a start (non-exhaustive):

1. Need for integration with PHP's dev login database (x@php.net people)

Do you have some auth with API already in place (ldap, oauth, ...)?

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.

2,3,4 require work of course, but is nothing unexpected when migrating
issue tracker.

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æsar's wife must
be beyond reproach.

I would look not for a framework to build new issue tracker on top, but rather
an out of the box products, so not every framework is a candidate at all.
Do I read you correctly, that the new issue tracker has to be written in PHP?
What about a SAAS platforms like github, gitlab and so? Can they also
be considered?

Imagine you will implement a login to bugs.php.net consuming github or
gmail oauth,
will you then also write oauth library yourself, or use any existing
one, from the
PHP community?

What this all ends up meaning is that the best way forward is small
(read: reviewable), incremental improvements to the bug tracker we
have.

I'm not against it, however I imagine that the PHP maintainers have
better things
to do than to build yet another bug tracker.

• 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?

I'm sure it's clear for you, as you're used to the system and know the
internals.
However try putting a regular user in front of it and ask him to do
some action ;)
e.g.

• how to get back to the filtered list, from single issue?
• What filters are enabled on the list (seems you have to brain-parse
  url to check it)?
• comment form being on top, far away from the last comments on the
  longer threads
• "Developer" tab is useful only for php.net users, so it should be
  visible only when they log in,
• labels of the input fields are not much helpful without additional
  explanation/help,
  like "Return bugs assigned to" - what should I put inside? email address, nick?
  "Return bugs updated" - will selecting 90 return me issues older than
  90 days or younger?
• and the winner of the confusion context - the comment form - what should I
  do to both send a comment and be notified? should I first subscribe
  and then comment,
  or is subscription done automatically when you submit a comment?
  "Subscribe to this entry" - does "entry" means issue in this case? ;)

• 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.

yes an no, it's true that every bigger project has the same problem,
but the difference is in the scale.
I did a quick grasp and I see more than 1k issues which were not
updated since some years and were reported to not maintained versions.
My argument is that if regular logged in users were able to e.g.
set/add newer affected PHP version,
os system (but please a list, not an input), relate issues together
(related, duplicated),
then it will be much easier for PHP maintainers to close old,
unrelated or duplicated issues.

Many other opensource systems managed to gather people who are not in
the maintainer group/core team,
but who has higher permissions (like edit issue, change status, etc).
In other words people who you trust enough to be able to clean issue
tracker a bit.

• the tool blocks community in helping managing the issue list and triaging bugs
  Citation needed.

Here I am ;) I'm involved in many OSS communities, like TYPO3 (I'm a
core dev there),
Magento, etc. I see PHP issue tracker being the least pleasant to use.
One recent example - when investigating security issues related to
phar archives before our last
security release for TYPO3 I spend some hours using bugs.php.net,
reading issues, trying to find sth related. I saw many issues which
were duplicated,
or at last very related but there was no way for me to connect them -
thus helping
managing the issue queue.
I'm pretty sure if you ask regular PHP developers, you will hear
similar opinions.
People are used to features and ease of use provided by e.g.
github/gitlab/bitbucket....

• 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.

Interesting. I dont recall getting an any email from bugs.php.net, and
I'm pretty sure
I was involved in some issues with different emails. But maybe they
were not modified?

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.

Is it possible to register on php.net and get an account? Where? How?

Also, comments make for lovely links. The bug ID urls are 100%
restful permalinks.

I would expect that putting an issue number (or the full link) in the comment
would also result in listing the issue in the "Related reports" tab.

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=$bugid next to the password
field. I'll fix that in a moment.

thanks :)

• 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.

Sorry, I was not clear enough. I agree that the field is important.
I wanted to say that the data quality we currently have
in bugs.php.net for the OS field is low (because of issues described above).
As a user how can I filter issues only related to linux?

((Yes, I know, triage
and maintenance of data is a side-effect of the usability of the
tool.))

That's what I'm trying to say ;)

• 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.

No, please see my comments above.

1. we need login, and everything even comments have to be made by logged in user
2. authenticated users should be able to set basic things like issue relations
3. there might be a group of user with higher rights (but not as high
   as maintainers)

Many of the above can be fixed, and the entire site is in PHP and on
github. I encourage you to offer pull requests!

Where? How can I setup a local dev environment with current issue tracker?
Is there a demo/stripped db dump available?

On Tue, Aug 7, 2018 at 1:17 PM, Tymoteusz Motylewski
t.motylewski@gmail.com wrote:

 

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.

There is a key feature I really like about the PHP bug tracker: No need
to register for an account just to report a bug. Just give a mail
address and go.

• 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?

My biggest issue with the UI is the selection of category when
reporting/editing bugs. That lst is huuuuge. Other than that I'm happy
it's no JavaScript overloaded thing, but simply works.
(room for improvement exits)

• 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.

For subscriptions etc. it is possible to translate all searches and
many other things (i.e. individual reports) into rss feeeds, i.e.
https://bugs.php.net/rss/search.php?limit=30&order_by=id&direction=DESC
&cmd=display&status=Open&bug_type=All
Basically just put an "/rss/" into any URL. This might need better
linking, though.

• its not possible to state PHP version or OS you're reproducing
  the issue in

The voting functionality is a relatively recent addition.  I agree
it'd help to expand its scope.

The version thing is especially bad with PECL modules. That needs work.
here it is unclear which version to use (PHP version, pecl ext version,
..)

Many of the above can be fixed, and the entire site is in PHP and on
github.  I encourage you to offer pull requests!

+100

(while we rejected quite a few contributions, sometimes for better,
sometimes for worse reasons in the past, and sometimes plainly ignore
them ....)

johannes