I sort of feel that issues.dlang.org is an unmaintained mess. Anyone has access to it every aspect of editing anyone else's issue, so anyone could be added really without any oversight. There's no editing one's comments so I often see people making multiple posts to themselves to add more information or to correct themselves. That's just a minor issue. There are 16k issues (I'm guessing every ID basically means a unique issue) for DMD alone. It has some issues where an individual made a comment, no tags or anything was set, and then 2-3 years later its remained like that til someone reserves it with a change or comment Only for there only to be that one additional comment then the issue gets buried for another year or so. There are so many like this and it is unclear what exactly the issue is or what needs to be done with it. Almost every issue is like this as well. There are some discussions in some of the issues but a lot of the times nothing seems to be done about them.

Anyways for the site itself, it seems to be lacking features. When viewing issues as a list there isn't that much information about the issue, other than the summary. Things that are listed with an issue: The ID, it's alright I guess can be useful from the list, knowing the issue number to reference it in a pull request or other issue. The "Product", completely useless, is D for everything on the site essentially. The "Comp", that's fine for searching for errors across multiple but kind of useless when viewing the issue list for a single project. The "assignee", kind of useless and it's never used, only every seen it set to "nobody". The "Status", kind of useless don't need to know that information, just need to know if it is open or closed and that shouldn't really be part of the list ; if I search for issues I should just specify if I want them to be open or not. The "Resolution", only ever seen it as "---", maybe it means something for closed issues but I haven't seen any closed issues. So what is the point of the list if it doesn't display any useful information. There's no, "needs work", or "enhancement" or any other description that can add to what the issue is or what it needs to have done to it. When there are 16k+ issues, having better information in the list view is desired. To make searching for an issue easier, rather than having to click on each one individually item to get more information from it. There's no lack of space, especially when almost every column could be removed for something with more useful information.

So now there are this many issues and it probably won't be an easy task to go through all of them and determine which ones are actually valid. To weed out all the issues that can simply be deleted. It would be nice to know what needs to be done for an issue, if it is a small enhancement and can simply get a PR to add the functionality. If it is a bit bigger of an enhancement and needs a DIP to add the functionality. Or whether an issue exists and how the issue needs to be handled. Is it a feature that was implemented incorrectly and needs to be reworked. Or was it possibly an oversight of a combination of features and a more thought out solution needs to be created, which might involve something more extreme as removing a previous feature.

Well wrote more than I planned to, didn't re-read it though, probably should considering I won't be able to edit it. Oh well.

TLDR; The issue system in place right now needs to be removed and a better system with oversight put in place. Rather than the wildwest it is now, with no oversight and issues existing for years before anyone looks at them. If anyone even ever looks at them. Some of them aren't even real issues and they just end up clogging the pipes, so to speak.

On Tuesday, 25 October 2016 at 03:17:02 UTC, Jacob wrote:
> ...

1. The vast, vast majority of problems attributed to collaboration software are actually the fault of a lack of communication skills. This situation is no different. Changing the software will not fix any problems in organization or curation. Most the features you call useless are not useless in of themselves, but are "useless" because people don't use them.

99% of all collaboration could be done in excel if you have good communication skills.

2. We don't have the manpower to have a completely curated system. Any energy spent curating would be better spent fixing bugs.

3. It serves its purpose well in that very bad bugs that are reported with detail are fixed quickly.

4. Many people follow the bug feed on the forum, so a bug is almost always looked at at least once. Most bugs are usually considered not very high in priority, and so it's up to the volunteers to come in and fix them. Core team members are focused on regressions, new issues, and really bad bugs. Most of them don't have time for enhancements.

5. If you see an issue that doesn't have enough detail to be fixed, then close it.

6. No one is stopping you from putting together a better idea. I look forward to your DIP on the subject.

On Tuesday, 25 October 2016 at 03:17:02 UTC, Jacob wrote:
> I sort of feel that issues.dlang.org is an unmaintained mess.

I don't think its state is much worse than that of a typical bugtracker for projects of this scale.

> Anyways for the site itself, it seems to be lacking features.

It is a standard Bugzilla instance. We do not develop the software.

> When viewing issues as a list there isn't that much information about the issue, other than the summary.

You can create custom views for whatever task you have at hand.

> The "Product", completely useless, is D for everything on the site essentially.

We do not use many of Bugzilla's features. Support for multiple products is one of them. (Also is it lacking features or having too many?)

> The "Resolution", only ever seen it as "---", maybe it means something for closed issues but I haven't seen any closed issues.

If something is unclear, please refer to the Bugzilla manual.

> There's no, "needs work", or "enhancement" or any other description that can add to what the issue is or what it needs to have done to it.

The severity field has "enhancement" as an option.

> If it is a bit bigger of an enhancement and needs a DIP to add the functionality.

Feature requests that require a DIP do not belong on Buzilla.

> TLDR; The issue system in place right now needs to be removed and a better system with oversight put in place.

Err, no. Just because you haven't seen a Bugzilla instance elsewhere doesn't mean we should replace it. The UI is a bit 90's, but otherwise it has served us well.

On 10/25/2016 05:17 AM, Jacob wrote:
> I sort of feel that issues.dlang.org is an unmaintained mess. Anyone has
> access to it every aspect of editing anyone else's issue, so anyone
> could be added really without any oversight.

Yet there's very little vandalism going on, aside from the occasional spam. We have oversight in the form of people watching every change that happens on the bug tracker.

> There's no editing one's
> comments so I often see people making multiple posts to themselves to
> add more information or to correct themselves. That's just a minor
> issue.

I don't think that's really an issue. Bugzilla sends out notification emails. An edit feature would complicate that. You'd have to read diffs instead of a human-written correction. I think that might be more annoying than having multiple comments. If any kind of discussion happens you're going to have many comments anyway.

> There are 16k issues (I'm guessing every ID basically means a
> unique issue) for DMD alone.

That's not for dmd alone, it's for all components: dlang.org, dmd, druntime, installer, phobos, tools, visuald. The 16000 issues also include fixed and otherwise closed ones.

Just dmd has about 3000 open issues at the moment [1]. If we filter out enhancements (so we have just actual bugs), the number goes down to about 2000 [2]. That's still a lot, but way less than 16000.

> It has some issues where an individual made
> a comment, no tags or anything was set, and then 2-3 years later its
> remained like that til someone reserves it with a change or comment Only
> for there only to be that one additional comment then the issue gets
> buried for another year or so.

Well, that's because there are not enough people to fix the issues. I think especially the compiler team could use more hands.

> There are so many like this and it is
> unclear what exactly the issue is or what needs to be done with it.

If the issue description is lacking, ask for clarification. If the submitter doesn't respond and it's really not clear what the issue is about, close it. Leave comments explaining your actions.

> Almost every issue is like this as well. There are some discussions in
> some of the issues but a lot of the times nothing seems to be done about
> them.

Sadly, yeah. But that's not an issue with Bugzilla, but an issue of too many bugs for too few developers.

> Anyways for the site itself, it seems to be lacking features. When
> viewing issues as a list there isn't that much information about the
> issue, other than the summary.

You can change the columns by clicking on "change columns" below the list.

[...]
> So now there are this many issues and it probably won't be an easy task
> to go through all of them and determine which ones are actually valid.

Yeah, one at a time. Baby steps.

> To weed out all the issues that can simply be deleted.

I don't think there actually are that many. I would guess that most bugs are actually bugs and most enhancement requests probably need a decision by Walter or Andrei.

> It would be nice
> to know what needs to be done for an issue, if it is a small enhancement
> and can simply get a PR to add the functionality.

Easy bugs are usually fixed quickly. Maybe there are some (or many) open easy bugs, but when someone can figure that they're easy, that person can probably also quickly fix them. So there's not really a list of simple stuff.

However, Andrei has recently made an effort tagging issues with "bootcamp" [3]. He deems those issues to be fit for newcomers to D. But they're not necessarily simple. Might be small or medium sized projects of themselves.

For enhancements, you might want to get confirmation first that it's going to be accepted, before jumping in and implementing them. I.e., you need Walter or Andrei on board. There's a keyword for that: "preapproved" [4]. The "bootcamp" issues obviously also have been approved by Andrei.

> If it is a bit bigger
> of an enhancement and needs a DIP to add the functionality.

If that's so, I think it gets closed in Bugzilla. At least, that's what Andrei has done recently, if I remember correctly.

> Or whether
> an issue exists and how the issue needs to be handled. Is it a feature
> that was implemented incorrectly and needs to be reworked. Or was it
> possibly an oversight of a combination of features and a more thought
> out solution needs to be created, which might involve something more
> extreme as removing a previous feature.

The "severity" field covers this partially:

* enhancement: Not a bug, but a request for an additional feature or such.
* trivial: A bug that should be easy to fix (typos and such).
* minor, normal, major, critical: Greater levels of bugs.
* blocker: Mostly misused as far as I know. Should be blocking a release, is often used to indicate that the submitter's work is being blocked.
* regression: A new bug in an old feature.

Further than that, the submitter of a bug doesn't usually know how it came about. And working out the details is a large part of fixing a bug. So once someone has done that work, they can often also fix it. I'd say that's why you don't see many open bugs with details on how to fix them.

> Well wrote more than I planned to, didn't re-read it though, probably
> should considering I won't be able to edit it. Oh well.

Off topic: I consider editing to be an anti-feature in discussion software. In the worst (and most common) implementations, I just don't get an email update when someone edits their posts (looking at you, GitHub). Can be confusing when a larger correction or amendment is being done by edit. And small typos that don't affect the meaning of the message don't really need fixing, anyway.

> TLDR; The issue system in place right now needs to be removed and a
> better system with oversight put in place.

No. If anything, we need to tweak the process and/or Bugzilla.

> Rather than the wildwest it
> is now, with no oversight and issues existing for years before anyone
> looks at them. If anyone even ever looks at them. Some of them aren't
> even real issues and they just end up clogging the pipes, so to speak.

You can't implement oversight in software, you need more people. Bugzilla is ok as the software. Putting a moderation system in place would just mean that the moderation queue gets clogged instead of the issue list.

We could maybe make use of a "VERIFIED" status, different from "NEW". But the usefulness of that depends on how many unverified issues we have. And we don't know that because we don't have that status ;) If you care about this, you will probably have to champion the effort and go through lots of issues to apply the new status.

I think you're mistaken in thinking that no one looks at issues. I usually at least glance over newly filed ones, and often check if they're valid.


[1] https://issues.dlang.org/buglist.cgi?component=dmd&limit=0&list_id=211365&order=bug_status%2Cpriority%2Cassigned_to%2Cbug_id&product=D&query_format=advanced&resolution=---

[2] https://issues.dlang.org/buglist.cgi?bug_severity=regression&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial&component=dmd&limit=0&order=bug_status%2Cpriority%2Cassigned_to%2Cbug_id&product=D&query_format=advanced&resolution=---

[3] https://issues.dlang.org/buglist.cgi?keywords=bootcamp%2C%20&keywords_type=allwords&list_id=211370&query_format=advanced&resolution=---

[4] https://issues.dlang.org/buglist.cgi?keywords=preapproved%2C%20&keywords_type=allwords&list_id=211371&query_format=advanced&resolution=---

On Tuesday, 25 October 2016 at 12:48:48 UTC, Vladimir Panteleev wrote:
> I don't think its state is much worse than that of a typical bugtracker for projects of this scale.

What projects are those? For ones of similar size at the very least all issues get tagged. There are a bunch of issues that have nothing done with them.

>> Anyways for the site itself, it seems to be lacking features.
>
> It is a standard Bugzilla instance. We do not develop the software.

That doesn't make the point any less valid. If something is broke you fix it or replace it.

>> When viewing issues as a list there isn't that much information about the issue, other than the summary.
>
> You can create custom views for whatever task you have at hand.

Didn't know that, the setting was buried at the bottom of the page past the hundreds of errors.

>> The "Resolution", only ever seen it as "---", maybe it means something for closed issues but I haven't seen any closed issues.
>
> If something is unclear, please refer to the Bugzilla manual.

Not unclear so much as the feature is there and is never used.


>> If it is a bit bigger of an enhancement and needs a DIP to add the functionality.
>
> Feature requests that require a DIP do not belong on Buzilla.

Who is to determine that? I see a lot of Buzilla reports that are large enhancements that should need a DIP. But they stay as open issues flagged enchancement. That's the point. There's no, or at least no one does say, this needs a DIP, closes the issue to remove it from sight.

>> TLDR; The issue system in place right now needs to be removed and a better system with oversight put in place.
>
> Err, no. Just because you haven't seen a Bugzilla instance elsewhere doesn't mean we should replace it. The UI is a bit 90's, but otherwise it has served us well.

Umm, who said I haven't seen it elsewhere? If a system is un-maintainable that doesn't mean it's ok and should just be overlooked.

On Tuesday, 25 October 2016 at 13:04:22 UTC, ag0aep6g wrote:
> On 10/25/2016 05:17 AM, Jacob wrote:
> I think you're mistaken in thinking that no one looks at issues. I usually at least glance over newly filed ones, and often check if they're valid.

Let me rephrase that then, no one does anything about the issues. I look at a lot of issues to, some that can easily be answered and the issue closed. But that's the problem, everyone is just an observer and no one does anything.

On 10/29/2016 07:14 PM, Jacob wrote:
> On Tuesday, 25 October 2016 at 13:04:22 UTC, ag0aep6g wrote:
>> On 10/25/2016 05:17 AM, Jacob wrote:
>> I think you're mistaken in thinking that no one looks at issues. I
>> usually at least glance over newly filed ones, and often check if
>> they're valid.
>
> Let me rephrase that then, no one does anything about the issues. I look
> at a lot of issues to, some that can easily be answered and the issue
> closed. But that's the problem, everyone is just an observer and no one
> does anything.

Of course, I also close them if they're invalid, add tags, minimize test cases. And sometimes I can even just fix the issue. You're very welcome to do the same. If you see issues that can be answered and closed, please do so. This is a problem of manpower.

That said, if you want to help out, fixing compiler bugs would probably be more effective than doing janitor's work on Bugzilla issues. It's also a lot harder, as far as I can tell.

On Saturday, 29 October 2016 at 17:14:20 UTC, Jacob wrote:
> Let me rephrase that then, no one does anything about the issues.

you are plainly wrong. this is as right as your "noone does anything". it is especially fun considering that "ag0aep6g" often provides clarifications and further sample minimization for alot of bugs (it is alot for one man). and other people watching bugs too via rss or email subscriptions. DFeed also reports new bugs to IRC, so some IRC people are watching too.

but if what you really complaining about is "bugfix rate"... this is completely different thing, and it has nothing to do with bug tracking software.

p.s. and "resolution" feature *is* used. Vladimir is right about reading manuals.

Am Sat, 29 Oct 2016 17:12:54 +0000
schrieb Jacob <noreply@noreply.com>:

> That doesn't make the point any less valid. If something is broke you fix it or replace it.

I agree with Vladimir and cannot really understand your urge to completely replace it. As long as people don't abuse their editing abilities it can be fine to make a title more specific, add a tag and so on. And the custom views help in getting the desired information out of it. It is extremely flexible in that aspect; more than I would expect from a much more modern and younger project.

-- 
Marco

On Tuesday, 25 October 2016 at 13:04:22 UTC, ag0aep6g wrote:
> On 10/25/2016 05:17 AM, Jacob wrote:
>> There's no editing one's
>> comments so I often see people making multiple posts to themselves to
>> add more information or to correct themselves. That's just a minor
>> issue.
>
> I don't think that's really an issue. Bugzilla sends out notification emails. An edit feature would complicate that. You'd have to read diffs instead of a human-written correction. I think that might be more annoying than having multiple comments. If any kind of discussion happens you're going to have many comments anyway.

One thing I miss is the ability to preview posts on Bugzilla, like our forum software. I know there's not much markup that happens for bugzilla posts, but somehow seeing the post rendered helps me to think whether I've forgotten anything or need to make some edits. Not huge but would be nice.