Community
Participate
Working Groups
I was searching related issues and history for submitted bug in hope to find successive/continuous solution. Then I discovered that there are 500 or more unclosed bugs Equinox \ p2 in Component: p2 Product: Equinox https://bugs.eclipse.org/bugs/buglist.cgi?product=Equinox&component=p2&resolution=---&list_id=6016596 At first I thought "does this project or Eclipse in general doesn't care to have all those issues solved & closed?", then I played a bit with Bugzilla and now say, that the reason is human nature & Bugzilla itself. If there is no quick & easy way to see all bugs in the same category (or it requires clicking inside several pages, then maybe waiting 2-5 seconds (general user don't wait more than 2 seconds) ), then this long way feature will not be used. The result is that nobody pays attention to number of unclosed bugs (as it is time consuming, and there is no priority to fix/close every bug submitted). SOLUTION: The solution is that there must be quick (maybe only small set) and convenient (with 1 click) way to see bugs in the same category (the same component), for example link near selected component name. ( I personally believe that number of unclosed bugs should be shown next to every project name. For example of the page https://bugs.eclipse.org/bugs/enter_bug.cgi?classification=__all ) More detailed: if I have a bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=381763 I should see list of all bugs via quick link on the bug page https://bugs.eclipse.org/bugs/buglist.cgi?product=Equinox&component=p2&resolution=---&list_id=6016596
Hi Paul, I'm not sure I fully understand what it is you're requesting. Showing the number of open bugs is not a way to determine whether or not a project "cares". Platform has 14,000 open bugs. What does that mean? They've closed almost 80,000. This is an Open Source community. We shouldn't be looking at ways to put projects to shame by pointing out how many open bugs they have, but instead focusing on what we can do to close more of those bugs.
In any event, you can use Bugzilla's reports to chart/table that data: https://bugs.eclipse.org/bugs/report.cgi?x_axis_field=bug_status&y_axis_field=product&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&deadlinefrom=&deadlineto=&bug_id=&bug_id_type=anyexact&votes=&votes_type=greaterthaneq&emailtype1=substring&email1=&emailtype2=substring&email2=&emailtype3=substring&email3=&chfieldvalue=&chfieldfrom=&chfieldto=Now&j_top=AND&f1=noop&o1=noop&v1=&format=table&action=wrap
(In reply to comment #1) > Hi Paul, > > I'm not sure I fully understand what it is you're requesting. Showing the > number of open bugs is not a way to determine whether or not a project > "cares". Platform has 14,000 open bugs. What does that mean? They've > closed almost 80,000. My initial idea is that if information is further, harder to reach people tends to less care about its meaning. Putting number of open bugs on visible place, should tell everybody, that it should be taken into account. More interesting may be actually dynamic (whether number of open bugs in increasing or going down arrow up/ arrow down). Or number added bugs minus number of closed bugs within last 30 days. But I don't know if these metrics has been calculated. > > This is an Open Source community. We shouldn't be looking at ways to put > projects to shame by pointing out how many open bugs they have, but instead > focusing on what we can do to close more of those bugs. The important is managing users expectations: so if user adds new bug to a project with 100+ open bugs (and he sees that), than he doesn't expect his bug to be solved quickly. And having thing more transparent is good thing for any organization seeking to improve. Thanks for report link. I wish it was accessible with 1 click from project link. 1 click rule should be applied for everything that is important or used everyday. Bottom line: I suggest solution that I believe doesn't require a lot of changes, just adding some useful links. 1. Add number of open bugs (or other similar metric) to the full list of projects https://bugs.eclipse.org/bugs/enter_bug.cgi?classification=__all (Note that some users won't see it if they select project from previous shorter list.) 2. Add number of open bugs (or other similar metric) next to the component name on bug view. If this data is periodically stored in project list table as some new column, then it will not affect performance when showing every bug. Example. GitHub shows number of open bugs on every repository page, https://github.com/jquery/jquery-mobile It may be not the best metric, but the easiest to get (in clear way that everybody understands)
(In reply to comment #2) > In any event, you can use Bugzilla's reports to chart/table that data: I wish it was accessible with 1 click from project list.
I understand what you're suggesting. Providing some numbers, similar to what we can see at GitHub, can provide some users clues. I'd suggest that a better place for these are on our project pages: http://projects.eclipse.org/projects/eclipse.platform
(In reply to comment #5) > I understand what you're suggesting. Providing some numbers, similar to > what we can see at GitHub, can provide some users clues. Exactly > > I'd suggest that a better place for these are on our project pages: > > http://projects.eclipse.org/projects/eclipse.platform I don't know who is using http://projects.eclipse.org/projects every day. The information seems partial. (But if we add, then it will be more full) However this list https://bugs.eclipse.org/bugs/enter_bug.cgi?classification=__all is essential. And also inside bug. Most people don't create bugs, just browse when they come via Google search, stackoverflow.com or some blog.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
Reading again, I agree with Roy, that the best place would be https://projects.eclipse.org/projects/* - Add button to quickly create new bug, - show some stats, at least number of current open issues - awesome would be to have diagram for time (numbers per months: open, closed)
Created attachment 257982 [details] example 1
Created attachment 257983 [details] example 2 (bugs new vs resolved/closed)
It's difficult to come up with a manner of representing activity metrics in a consistent manner that makes everybody happy. The dashboard [1] provides a set of very dynamic tools for investigating activity in all sorts of ways. The commit activity charts are all that we're going to put on project pages (at least for now). WONTFIX. [1] https://eclipse.biterg.io
