On Tue, Aug 7, 2018 at 1:17 PM, Tymoteusz Motylewski <t.motylew...@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æ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 n...@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
