Welcome! Log In Create A New Profile

Advanced

[PHP-DEV] bugs.php.net usability, migration to a different tool

Posted by Tymoteusz Motylewski 
Tymoteusz Motylewski
[PHP-DEV] bugs.php.net usability, migration to a different tool
August 07, 2018 08:40PM
Hi,
Thank you all for the great work you do for PHP!
I would like to raise a concern regarding the usefulness of the
current PHP issue tracker - bugs.php.net.

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.

I'm presenting a PHP user/reporter point of view, I'm not much into
developing PHP interpreter itself. However often I have to use
bugs.php.net when debugging issues or checking security reports.

In the 1-10 scale I give bugs.php.net grade "2", meaning it's almost not usable.

Issues I have:
- the UI is terrible (not useful, confusing, misleading)
- it's really hard to find what person is looking for
- data quality is low (many duplicated reports, lot of old reports
cluttering the list, information gathered is not reliable)
- the tool blocks community in helping managing the issue list and triaging bugs
- Its not possible to log in, be notified when sth change on issues
I'm interested in (created, commented, voted or just watching)

Examples:
- Its not possible to link issues which are related/duplicated (when
you're not power user)
- its not possible to state PHP version or OS you're reproducing the issue in
- the search is not indexing comments (so the place where most
important information is stored)
- 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? how can I get it back once I
forgot?
- 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.
- I can't change the voting once it's done
- 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
- 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.
- 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

There are of course many more, I haven't even started with UX ;)

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?
2. Do you consider that it's important and high priority to have a
better, more collaborative tool there?
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?

Cheers
Tymoteusz

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Tue, Aug 7, 2018 at 1:17 PM, Tymoteusz Motylewski
<[email protected]> 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 ([email protected] 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æsar'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 triaging 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 issue 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=$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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Christoph M. Becker
Re: [PHP-DEV] bugs.php.net usability, migration to a different tool
August 07, 2018 11:10PM
On 07.08.2018 at 22:10, Sara Golemon wrote:

> On Tue, Aug 7, 2018 at 1:17 PM, Tymoteusz Motylewski
> <[email protected]> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Tymoteusz Motylewski
Re: [PHP-DEV] bugs.php.net usability, migration to a different tool
August 08, 2018 11:40AM
wt., 7 sie 2018 o 22:10 Sara Golemon <[email protected]> napisał(a):
>
> On Tue, Aug 7, 2018 at 1:17 PM, Tymoteusz Motylewski
> <[email protected]> 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 ([email protected] 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?

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Johannes Schlüter
Re: [PHP-DEV] bugs.php.net usability, migration to a different tool
August 08, 2018 04:20PM
On Di, 2018-08-07 at 15:10 -0500, Sara Golemon wrote:
> On Tue, Aug 7, 2018 at 1:17 PM, Tymoteusz Motylewski
> <[email protected]> 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 ([email protected]
> 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


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hoffman, Zachary Robert
Re: [PHP-DEV] bugs.php.net usability, migration to a different tool
August 08, 2018 06:10PM
On Wed, 2018-08-08 at 16:14 +0200, Johannes Schlüter wrote:
> On Di, 2018-08-07 at 15:10 -0500, Sara Golemon wrote:
> On Tue, Aug 7, 2018 at 1:17 PM, Tymoteusz Motylewski
> <[email protected]> wrote:
>
> - 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)

While we are talking about the "package affected" dropdown, one
accessibility issue is that the package names are indented by category,
which makes it impossible to autocomplete a package name using your
keyboard.

The correct way to do this is to surround each category in an
<optgroup> tag, which distinguishes category names from package names.

--
Zach Hoffman
Johannes Schlüter
Re: [PHP-DEV] bugs.php.net usability, migration to a different tool
August 08, 2018 06:10PM
On August 8, 2018 5:59:51 PM GMT+02:00, "Hoffman, Zachary Robert" <[email protected]> wrote:
>On Wed, 2018-08-08 at 16:14 +0200, Johannes Schlüter wrote:
>> On Di, 2018-08-07 at 15:10 -0500, Sara Golemon wrote:
>> On Tue, Aug 7, 2018 at 1:17 PM, Tymoteusz Motylewski
>> <[email protected]> wrote:
>>
>> - 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)
>
>While we are talking about the "package affected" dropdown, one
>accessibility issue is that the package names are indented by category,
>which makes it impossible to autocomplete a package name using your
>keyboard.
>
>The correct way to do this is to surround each category in an
><optgroup> tag, which distinguishes category names from package names.

That sounds good. Could you create a patch? - The list is generated here: https://github.com/php/web-bugs/blob/master/include/functions.php#L726

johannes


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hey Zach

> Am 08.08.2018 um 17:59 schrieb Hoffman, Zachary Robert <[email protected]>:
>
>> On Wed, 2018-08-08 at 16:14 +0200, Johannes Schlüter wrote:
>> On Di, 2018-08-07 at 15:10 -0500, Sara Golemon wrote:
>> On Tue, Aug 7, 2018 at 1:17 PM, Tymoteusz Motylewski
>> <[email protected]> wrote:
>>
>> - 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)
>
> While we are talking about the "package affected" dropdown, one
> accessibility issue is that the package names are indented by category,
> which makes it impossible to autocomplete a package name using your
> keyboard.
>
> The correct way to do this is to surround each category in an
> <optgroup> tag, which distinguishes category names from package names.
>
> --
> Zach Hoffman

Feel free to open a PR against https://github.com/php/web-bugs
Hoffman, Zachary Robert
Re: [PHP-DEV] bugs.php.net usability, migration to a different tool
August 08, 2018 06:20PM
On Wed, 2018-08-08 at 18:06 +0200, Johannes Schlüter wrote:
> On August 8, 2018 5:59:51 PM GMT+02:00, "Hoffman, Zachary Robert" <
> [email protected]> wrote:
> On Wed, 2018-08-08 at 16:14 +0200, Johannes Schlüter wrote:
> On Di, 2018-08-07 at 15:10 -0500, Sara Golemon wrote:
> On Tue, Aug 7, 2018 at 1:17 PM, Tymoteusz Motylewski
> <[email protected]> wrote:
>
> - 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)
>
> While we are talking about the "package affected" dropdown, one
> accessibility issue is that the package names are indented by
> category,
> which makes it impossible to autocomplete a package name using your
> keyboard.
>
> The correct way to do this is to surround each category in an
> <optgroup> tag, which distinguishes category names from package
> names.
>
> That sounds good. Could you create a patch? - The list is generated
> here:
> https://github.com/php/web-bugs/blob/master/include/functions.php#L726
>
> johannes

Okay. I'll submit it when when it is made.

On Wed, 2018-08-08 at 18:08 +0200, Andreas Heigl wrote:
> Hey Zach

Hi

--
Zach Hoffman
Johannes Schlüter
Re: [PHP-DEV] bugs.php.net usability, migration to a different tool
August 08, 2018 06:20PM
On August 8, 2018 6:06:00 PM GMT+02:00, "Johannes Schlüter" <[email protected]> wrote:
>
>
>On August 8, 2018 5:59:51 PM GMT+02:00, "Hoffman, Zachary Robert"
><[email protected]> wrote:
>>On Wed, 2018-08-08 at 16:14 +0200, Johannes Schlüter wrote:
>>> On Di, 2018-08-07 at 15:10 -0500, Sara Golemon wrote:
>>> On Tue, Aug 7, 2018 at 1:17 PM, Tymoteusz Motylewski
>>> <[email protected]> wrote:
>>>
>>> - 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)
>>
>>While we are talking about the "package affected" dropdown, one
>>accessibility issue is that the package names are indented by
>category,
>>which makes it impossible to autocomplete a package name using your
>>keyboard.
>>
>>The correct way to do this is to surround each category in an
>><optgroup> tag, which distinguishes category names from package names.
>
>That sounds good. Could you create a patch? - The list is generated
>here:
>https://github.com/php/web-bugs/blob/master/include/functions.php#L726


When sending the mail I hoped this to be a more or less trivial change, I now noticed that it's not completely trivial as the list data is prepared in
https://github.com/php/web-bugs/blob/master/include/functions.php#L203

The hackish way is to check for &nbsp; when creating the HTML ... or look for a better structure for the list of "pseudo packages" and refactor all consumers of that global variable ... :/

Still it would be great and really appreciated if you are willing to look into it!

johannes

>johannes
>
>
>--
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit: http://www.php.net/unsub.php

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hoffman, Zachary Robert
Re: [PHP-DEV] bugs.php.net usability, migration to a different tool
August 09, 2018 02:00AM
On Wed, 2018-08-08 at 18:16 +0200, Johannes Schlüter wrote:
>
> On August 8, 2018 6:06:00 PM GMT+02:00, "Johannes Schlüter" <
> [email protected]> wrote:
> >
> >
> > On August 8, 2018 5:59:51 PM GMT+02:00, "Hoffman, Zachary Robert"
> > <[email protected]> wrote:
> > > On Wed, 2018-08-08 at 16:14 +0200, Johannes Schlüter wrote:
> > > > On Di, 2018-08-07 at 15:10 -0500, Sara Golemon wrote:
> > > > On Tue, Aug 7, 2018 at 1:17 PM, Tymoteusz Motylewski
> > > > <[email protected]> wrote:
> > > >
> > > > - 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)
> > >
> > > While we are talking about the "package affected" dropdown, one
> > > accessibility issue is that the package names are indented by
> >
> > category,
> > > which makes it impossible to autocomplete a package name using
> > > your
> > > keyboard.
> > >
> > > The correct way to do this is to surround each category in an
> > > <optgroup> tag, which distinguishes category names from package
> > > names.
> >
> > That sounds good. Could you create a patch? - The list is generated
> > here:
> >
https://github.com/php/web-bugs/blob/master/include/functions.php#L726
>
>
> When sending the mail I hoped this to be a more or less trivial
> change, I now noticed that it's not completely trivial as the list
> data is prepared in
>
https://github.com/php/web-bugs/blob/master/include/functions.php#L203
>
> The hackish way is to check for &nbsp; when creating the HTML ... or
> look for a better structure for the list of "pseudo packages" and
> refactor all consumers of that global variable ... :/
>
> Still it would be great and really appreciated if you are willing to
> look into it!

Okay, I think this is done.

https://github.com/php/web-bugs/pull/43

Modifying other parts of the project ended up not being necessary.

--
Zach Hoffman
On Thu, Aug 9, 2018 at 1:54 AM, Hoffman, Zachary Robert <[email protected]>
wrote:

>
>
> On Wed, 2018-08-08 at 18:16 +0200, Johannes Schlüter wrote:
> >
> > On August 8, 2018 6:06:00 PM GMT+02:00, "Johannes Schlüter" <
> > [email protected]> wrote:
> > >
> > >
> > > On August 8, 2018 5:59:51 PM GMT+02:00, "Hoffman, Zachary Robert"
> > > <[email protected]> wrote:
> > > > On Wed, 2018-08-08 at 16:14 +0200, Johannes Schlüter wrote:
> > > > > On Di, 2018-08-07 at 15:10 -0500, Sara Golemon wrote:
> > > > > On Tue, Aug 7, 2018 at 1:17 PM, Tymoteusz Motylewski
> > > > > <[email protected]> wrote:
> > > > >
> > > > > - 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)
> > > >
> > > > While we are talking about the "package affected" dropdown, one
> > > > accessibility issue is that the package names are indented by
> > >
> > > category,
> > > > which makes it impossible to autocomplete a package name using
> > > > your
> > > > keyboard.
> > > >
> > > > The correct way to do this is to surround each category in an
> > > > <optgroup> tag, which distinguishes category names from package
> > > > names.
> > >
> > > That sounds good. Could you create a patch? - The list is generated
> > > here:
> > >
> https://github.com/php/web-bugs/blob/master/include/functions.php#L726
> >
> >
> > When sending the mail I hoped this to be a more or less trivial
> > change, I now noticed that it's not completely trivial as the list
> > data is prepared in
> >
> https://github.com/php/web-bugs/blob/master/include/functions.php#L203
> >
> > The hackish way is to check for &nbsp; when creating the HTML ... or
> > look for a better structure for the list of "pseudo packages" and
> > refactor all consumers of that global variable ... :/
> >
> > Still it would be great and really appreciated if you are willing to
> > look into it!
>
> Okay, I think this is done.
>
> https://github.com/php/web-bugs/pull/43
>
> Modifying other parts of the project ended up not being necessary.
>
> --
> Zach Hoffman
>

I'm getting some spurious changes on the category now, see the history in
https://bugs.php.net/bug.php?id=76725&edit=1 for an example. The current
category is no longer correctly selected in the dialog, so it switches to
something else on every edit.

Nikita
Johannes Schlüter
Re: [PHP-DEV] bugs.php.net usability, migration to a different tool
August 09, 2018 03:50PM
Hi Nikita,

thanks for the heads-up. I committed a potential fix (untested) hope it
works once deployed in an hour or so.

Zachary, you might review my fix http://git.php.net/?p=web/bugs.git;a=c
ommit;h=5d86832595a5e694859f45aaaf554cf24a24af39

johannes

On Do, 2018-08-09 at 15:26 +0200, Nikita Popov wrote:
> On Thu, Aug 9, 2018 at 1:54 AM, Hoffman, Zachary Robert <[email protected]
> .edu>
> wrote:
>
> >
> >
> >
> > On Wed, 2018-08-08 at 18:16 +0200, Johannes Schlüter wrote:
> > >
> > >
> > > On August 8, 2018 6:06:00 PM GMT+02:00, "Johannes Schlüter" <
> > > [email protected]> wrote:
> > > >
> > > >
> > > >
> > > > On August 8, 2018 5:59:51 PM GMT+02:00, "Hoffman, Zachary
> > > > Robert"
> > > > <[email protected]> wrote:
> > > > >
> > > > > On Wed, 2018-08-08 at 16:14 +0200, Johannes Schlüter wrote:
> > > > > >
> > > > > > On Di, 2018-08-07 at 15:10 -0500, Sara Golemon wrote:
> > > > > > On Tue, Aug 7, 2018 at 1:17 PM, Tymoteusz Motylewski
> > > > > > <[email protected]> wrote:
> > > > > >
> > > > > > - 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)
> > > > > While we are talking about the "package affected" dropdown,
> > > > > one
> > > > > accessibility issue is that the package names are indented by
> > > > category,
> > > > >
> > > > > which makes it impossible to autocomplete a package name
> > > > > using
> > > > > your
> > > > > keyboard.
> > > > >
> > > > > The correct way to do this is to surround each category in an
> > > > > <optgroup> tag, which distinguishes category names from
> > > > > package
> > > > > names.
> > > > That sounds good. Could you create a patch? - The list is
> > > > generated
> > > > here:
> > > >
> > https://github.com/php/web-bugs/blob/master/include/functions.php#L
> > 726
> > >
> > >
> > >
> > > When sending the mail I hoped this to be a more or less trivial
> > > change, I now noticed that it's not completely trivial as the
> > > list
> > > data is prepared in
> > >
> > https://github.com/php/web-bugs/blob/master/include/functions.php#L
> > 203
> > >
> > >
> > > The hackish way is to check for &nbsp; when creating the HTML ...
> > > or
> > > look for a better structure for the list of "pseudo packages" and
> > > refactor all consumers of that global variable  ... :/
> > >
> > > Still it would be great and really appreciated if you are willing
> > > to
> > > look into it!
> > Okay, I think this is done.
> >
> > https://github.com/php/web-bugs/pull/43
> >
> > Modifying other parts of the project ended up not being necessary.
> >
> > --
> > Zach Hoffman
> >
> I'm getting some spurious changes on the category now, see the
> history in
> https://bugs.php.net/bug.php?id=76725&edit=1 for an example. The
> current
> category is no longer correctly selected in the dialog, so it
> switches to
> something else on every edit.
>
> Nikita

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hoffman, Zachary Robert
Re: [PHP-DEV] bugs.php.net usability, migration to a different tool
August 09, 2018 04:30PM
On Thu, 2018-08-09 at 15:46 +0200, Johannes Schlüter wrote:
> Hi Nikita,
>
> thanks for the heads-up. I committed a potential fix (untested) hope it
> works once deployed in an hour or so.
>
> Zachary, you might review my fix http://git.php.net/?p=web/bugs.git;a=c
> ommit;h=5d86832595a5e694859f45aaaf554cf24a24af39
>
> johannes

Tested locally. Your fix works for me!

--
Zach Hoffman

>
> On Do, 2018-08-09 at 15:26 +0200, Nikita Popov wrote:
> > On Thu, Aug 9, 2018 at 1:54 AM, Hoffman, Zachary Robert <[email protected]
> > .edu>
> > wrote:
> >
> > >
> > >
> > >
> > > On Wed, 2018-08-08 at 18:16 +0200, Johannes Schlüter wrote:
> > > >
> > > >
> > > > On August 8, 2018 6:06:00 PM GMT+02:00, "Johannes Schlüter" <
> > > > [email protected]> wrote:
> > > > >
> > > > >
> > > > >
> > > > > On August 8, 2018 5:59:51 PM GMT+02:00, "Hoffman, Zachary
> > > > > Robert"
> > > > > <[email protected]> wrote:
> > > > > >
> > > > > > On Wed, 2018-08-08 at 16:14 +0200, Johannes Schlüter wrote:
> > > > > > >
> > > > > > > On Di, 2018-08-07 at 15:10 -0500, Sara Golemon wrote:
> > > > > > > On Tue, Aug 7, 2018 at 1:17 PM, Tymoteusz Motylewski
> > > > > > > <[email protected]> wrote:
> > > > > > >
> > > > > > > - 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)
> > > > > >
> > > > > > While we are talking about the "package affected" dropdown,
> > > > > > one
> > > > > > accessibility issue is that the package names are indented by
> > > > >
> > > > > category,
> > > > > >
> > > > > > which makes it impossible to autocomplete a package name
> > > > > > using
> > > > > > your
> > > > > > keyboard.
> > > > > >
> > > > > > The correct way to do this is to surround each category in an
> > > > > > <optgroup> tag, which distinguishes category names from
> > > > > > package
> > > > > > names.
> > > > >
> > > > > That sounds good. Could you create a patch? - The list is
> > > > > generated
> > > > > here:
> > > > >
> > >
> > > https://github.com/php/web-bugs/blob/master/include/functions.php#L
> > > 726
> > > >
> > > >
> > > >
> > > > When sending the mail I hoped this to be a more or less trivial
> > > > change, I now noticed that it's not completely trivial as the
> > > > list
> > > > data is prepared in
> > > >
> > >
> > > https://github.com/php/web-bugs/blob/master/include/functions.php#L
> > > 203
> > > >
> > > >
> > > > The hackish way is to check for &nbsp; when creating the HTML ...
> > > > or
> > > > look for a better structure for the list of "pseudo packages" and
> > > > refactor all consumers of that global variable ... :/
> > > >
> > > > Still it would be great and really appreciated if you are willing
> > > > to
> > > > look into it!
> > >
> > > Okay, I think this is done.
> > >
> > > https://github.com/php/web-bugs/pull/43
> > >
> > > Modifying other parts of the project ended up not being necessary.
> > >
> > > --
> > > Zach Hoffman
> > >
> >
> > I'm getting some spurious changes on the category now, see the
> > history in
> > https://bugs.php.net/bug.php?id=76725&edit=1 for an example. The
> > current
> > category is no longer correctly selected in the dialog, so it
> > switches to
> > something else on every edit.
> >
> > Nikita
Sorry, only registered users may post in this forum.

Click here to login