Hi Walter,

do you see it possible to give some more feedback on reported bugs?

There are quite many bug reports (some of them are fairly old) left without any comment, confirmation/rejection. This leaves the reporter in uncertainity (will it be fixed?, how long will it take?), which isn't really inspitring.

IMO the following would greatly improve the process:

1. If a new bug is reported, it should be confirmed or rejected shortly after it's been reported. This is also a good occasion to ask the reporter for further information or action, if they are needed. This makes a good impression on the reporter, that the bug is taken care of.

2. If the bug is confirmed it should be also (re)prioritised. This helps the reporter to estimate how long will it take to fix the bug. Is it due in one of the following releases or maybe someday?

3. Special attention to older bug reports or reconsidering the priorities from time to time may help not to have these aging bugs around.


I hope that the above ideas may be applied for your day to day work without major effort.


Regards,
David

Maybe because the current bug-tracking system is a bit messy and not very user-friendly. (or is it just me?)

David Ferenczi wrote:
> Hi Walter,
> 
> do you see it possible to give some more feedback on reported bugs?
> 
> There are quite many bug reports (some of them are fairly old) left without
> any comment, confirmation/rejection. This leaves the reporter in
> uncertainity (will it be fixed?, how long will it take?), which isn't
> really inspitring.
> 
> IMO the following would greatly improve the process:
> 
> 1. If a new bug is reported, it should be confirmed or rejected shortly
> after it's been reported. This is also a good occasion to ask the reporter
> for further information or action, if they are needed. This makes a good
> impression on the reporter, that the bug is taken care of.
> 
> 2. If the bug is confirmed it should be also (re)prioritised. This helps the
> reporter to estimate how long will it take to fix the bug. Is it due in one
> of the following releases or maybe someday?
> 
> 3. Special attention to older bug reports or reconsidering the priorities
> from time to time may help not to have these aging bugs around.
> 
> 
> I hope that the above ideas may be applied for your day to day work without
> major effort.
> 
> 
> Regards,
> David
> 
> 
> 
> 
> 
> 

Hasan Aljudy Wrote:

> Maybe because the current bug-tracking system is a bit messy and not very user-friendly.  (or is it just me?)
<snip top of upside-down reply>

Would you care to elaborate on what you think is wrong with the system?

Stewart.

Stewart Gordon wrote:
> Hasan Aljudy Wrote:
> 
>> Maybe because the current bug-tracking system is a bit messy and not very user-friendly.  (or is it just me?)
> <snip top of upside-down reply>
> 
> Would you care to elaborate on what you think is wrong with the system?

I think he is targetting the system's user interface, not the actual system itself, which might be quite good in general. I have to admit, though, it doesn't feel too intuitive to me, either.

Best regards,
Alex

Alexander Panek wrote:
> Stewart Gordon wrote:
>> Hasan Aljudy Wrote:
>>
>>> Maybe because the current bug-tracking system is a bit messy and not very user-friendly.  (or is it just me?)
>> <snip top of upside-down reply>
>>
>> Would you care to elaborate on what you think is wrong with the system?
> 
> I think he is targetting the system's user interface, not the actual system itself, which might be quite good in general. I have to admit, though, it doesn't feel too intuitive to me, either.
> 
> Best regards,
> Alex

Yes, I'm talking about the interface (hence user friendliness).

It seems that this request has been silently ignored. Rejecting would be ok, but ignorance is more than disappointing.

I would like to understand the reasons.

Could anybody give me some short explanation on this?

Regards,
David

David Ferenczi wrote:
> It seems that this request has been silently ignored. Rejecting would be ok,
> but ignorance is more than disappointing.
> 
> I would like to understand the reasons.
> 
> Could anybody give me some short explanation on this?

It's a one-man project, so the reason there's not much feedback is shortage of manpower.  It's just the way it is, we've all had to get used to this fact.  A one-man project that creates free products can't provide the same level of customer support that a commercial project can.  Hope this explains it.

>> It seems that this request has been silently ignored. Rejecting would be ok, but ignorance is more than disappointing.
>> 
>> I would like to understand the reasons.
>> 
>> Could anybody give me some short explanation on this?
> 
> It's a one-man project, so the reason there's not much feedback is shortage of manpower.  It's just the way it is, we've all had to get used to this fact.  A one-man project that creates free products can't provide the same level of customer support that a commercial project can.  Hope this explains it.

Thanks, I agree. But I think it somehow also lies on the topic. There are topics, which get attention immediately, and there are others, which never.

The point is, just like in case of bug reports, to get some feedback. Let it be even a single line.

If you have a community around your project, it is necessary to communicate with them. Or just define some rules, if you don't have time for it. E.g. I don't answer mails, newsgroup post, except for...

The worst can happen to enthusiast users that they get ignored. This makes also the recommendation of D questionable.

My suggestion addressed this kind of situation at bug reports. And the impression is (maybe the truth is totally different) that nobody cares.

David Ferenczi wrote:
>>> It seems that this request has been silently ignored. Rejecting would be
>>> ok, but ignorance is more than disappointing.
>>> 
>>> I would like to understand the reasons.
>>> 
>>> Could anybody give me some short explanation on this?
>> 
>> It's a one-man project, so the reason there's not much feedback is
>> shortage of manpower.  It's just the way it is, we've all had to get
>> used to this fact.  A one-man project that creates free products can't
>> provide the same level of customer support that a commercial project
>> can.  Hope this explains it.
> 
> Thanks, I agree. But I think it somehow also lies on the topic. There are
> topics, which get attention immediately, and there are others, which never.
> 
> The point is, just like in case of bug reports, to get some feedback. Let it
> be even a single line.
> 
> If you have a community around your project, it is necessary to communicate
> with them. Or just define some rules, if you don't have time for it. E.g. I
> don't answer mails, newsgroup post, except for...
> 
> The worst can happen to enthusiast users that they get ignored. This makes
> also the recommendation of D questionable.
> 
> My suggestion addressed this kind of situation at bug reports. And the
> impression is (maybe the truth is totally different) that nobody cares.

I fully agree with you.  I expect the situation will improve sooner or later, forced by increasing adoption of D.  How it's going to happen remains to be seen.

torhu wrote:
> David Ferenczi wrote:
>>>> It seems that this request has been silently ignored. Rejecting would be
>>>> ok, but ignorance is more than disappointing.
>>>>
>>>> I would like to understand the reasons.
>>>>
>>>> Could anybody give me some short explanation on this?
>>>
>>> It's a one-man project, so the reason there's not much feedback is
>>> shortage of manpower.  It's just the way it is, we've all had to get
>>> used to this fact.  A one-man project that creates free products can't
>>> provide the same level of customer support that a commercial project
>>> can.  Hope this explains it.
>>
>> Thanks, I agree. But I think it somehow also lies on the topic. There are
>> topics, which get attention immediately, and there are others, which never.
>>
>> The point is, just like in case of bug reports, to get some feedback. Let it
>> be even a single line.
>>
>> If you have a community around your project, it is necessary to communicate
>> with them. Or just define some rules, if you don't have time for it. E.g. I
>> don't answer mails, newsgroup post, except for...
>>
>> The worst can happen to enthusiast users that they get ignored. This makes
>> also the recommendation of D questionable.
>>
>> My suggestion addressed this kind of situation at bug reports. And the
>> impression is (maybe the truth is totally different) that nobody cares.
> 
> I fully agree with you.  I expect the situation will improve sooner or later, forced by increasing adoption of D.  How it's going to happen remains to be seen.

I was watching this Google Tech talk:
http://video.google.com/videoplay?docid=-4216011961522818645&q=poisonous+people
from the guys who run Subversion.

One of the things they mention in there is the importance of responsiveness, and they suggest that some member of the project should be made responsible for addressing all issues that come into the mailing lists that seem to get dropped.

That's great for a truly open-source project, but the problem with that suggestion for D is that no-one besides Walter, and maybe now Andrei, is really a "member" of this project.  No one besides Walter has any ownership, so nobody really has any more obligation (or authority) to respond to posts than anyone else.  There probably are people here who would step up to the plate and take on such responsibility if they were given some authority, but no-one has such authority now.  Especially if you want to know "why isn't bug 2345 being fixed?".  No-one knows that besides Walter.  So if someone is going to communicate that to you it has to be someone who has Walter's ear.

As it is, only Walter (and maybe Andrei) really know what's going on, and it mostly goes on behind closed doors.  That's another thing that the subversion guys talk about in that video -- they say that wherever decisions are made in the svn project --- irc, face-to-face meetings, wherever --- they aren't ever considered "official" until they've been posted to the mailing list for all to see.

The upshot is that D just isn't really an open source project.  The source part (to the front end) is open, but the project part is not. And that's fine.  Stuff still gets done.  If you don't like it that way, then it's certainly something to consider when deciding whether to base your future on D.  It doesn't bother me too much because even if Walter got hit by a bus, D 1.009 works pretty well for what I need, and I'm not basing any sort of commercial venture on D.  Though if Walter did get hit by a bus I'd probably stop writing D code pretty soon after, because without Walter, D doesn't have much future.

--bb