What do you want to see for a mature DLang?

IM 3di at gm.com
Sat Dec 30 02:37:24 UTC 2017


On Saturday, 30 December 2017 at 01:40:39 UTC, Adam D. Ruppe 
wrote:
> On Friday, 29 December 2017 at 23:24:45 UTC, Walter Bright 
> wrote:
>> That's been closed for a while now.
>
> Well, take your pick:
>
> https://issues.dlang.org/show_bug.cgi?id=12694
> https://issues.dlang.org/show_bug.cgi?id=13340
> https://issues.dlang.org/show_bug.cgi?id=16059
>
> You always tell people to post to bugzilla, but many of these 
> things have been posted over and over again. Bugzilla search is 
> terrible, so it is frequently hard to find, but there are many 
> examples there.
>
> The benefit though of watching support requests is you see what 
> people actually deal with day-to-day, and error messages, 
> especially multiple overload matches of functions and templates 
> and no template matches ones come up all the time. ALL THE 
> TIME. From new users and experienced users alike. Most won't 
> put it in bugzilla though: they just see it as their own 
> personal failure instead of a technical problem we can fix.
>
> But any repeated support request should be seen as a user 
> experience problem that we try to fix. This is where we'd get 
> the most productivity - taking little bumps out of the road. D 
> has no roadblocks; we can get a lot of stuff done with it 
> exactly the way it is, but if you watch users actually try to 
> use it, you'll see the road isn't as smooth as it could and 
> should be.

Just curious, why Bugzilla and not something else? I can guess 
the following:
- A centralized place for all dmd, druntime, and phobos was 
needed.
- GitHub issues are probably more limited in features and 
functionality than Bugzilla.

But think about it. Filing a bug on Bugzilla is not 
friction-free. One has to create an account, if s/he has one 
already, good luck remembering the username and password for 
something you rarely use, so spend sometime trying to remember 
and when you fail, spend time resetting your account or creating 
a new one. Finally file a bug and pray that someone will actually 
notice it and triage it to the appropriate owner! Not to mention 
that Bugzilla's UI is not pleasant.

For GitHub issues, most probably you already have an account 
there that you use often. Issues are close to where the code is. 
It's easy to see potential owners from the code's blame or git 
log. .. etc.

For better community participation, friction needs to be 
minimized as much as possible.


More information about the Digitalmars-d mailing list