On Wednesday, September 4, 2002, at 07:33 PM, s wrote:
>> cooker. cooker is not an 3r33t or exclusive list only to people >> that are developers, coders, or technically competent, no matter >> how much easier this would make our lives. > > Oh, I was under the impression it was, hence the root of our > disagreement. If this statement is accurate, then any further > discussion is moot. Have you discussed with warly, pixel or others > and find they agree? If so, then please excuse my interference. I haven't, but common sense should prevail here. If it is generally acceptable for posts on beta testing (comments, problems, questions, etc.) to be sent to the MandrakeExpert website, which is in turn forwarded to cooker by Alan, why would it be any less acceptable for these people to post to cooker directly? The end result is the same... the information is being sent to the cooker list. What do we eliminate by asking people to post to cooker directly? Congestion on MandrakeExpert. Alan's time by sorting through reports and forwarding it to cooker. What advantages do we see? A post to cooker can be replied to with the submitter able to respond in a timely fashion; the developers also see these reports in a timely fashion. I'm sure Alan is forwarding stuff to the list in a timely manner, but unless he is monitoring MandrakeExpert 24/7, it's not as fast as it could be. If this is an acceptable proposition (and it must be according to our own website), then cut out the "middle-man", eliminate the MandrakeExpert option for reporting bugs, and post to cooker directly (the first option on the list of three avenues to report bugs). For this reason alone, I don't think it's necessary to get some sort of "vote" by the developers... the end result is the same, but the method of accomplishing it is more efficient. >>> of the consequences if too many laypersons start posting to >>> cooker. >> >> What consequences are you afraid of? > > Well, as stated earlier, if too many useless, uninformative, false bug > reports start showing up, then the list may become unavailable for > the average joe or the developers will move to another list or just > email directly. Something like that. It's an informative list for > interested parties to lurk on as it is now, but I can imagine it > becoming chaotic and testing the patience of developers. I don't think this will ever be the case. The only way the cooker list would ever become "non-public" or shut down is if cooker itself went non-public. The simple fact of running an open cooker system as we currently do, has it's benefits and drawbacks. Irrelevant posts is a drawback, but not enough to obsolete the whole idea behind cooker. >> Side-effects not withstanding, posting bug reports (real or >> otherwise) to cooker is much preferred to posting to expert/newbie >> lists and not having the real bugs dealt with. > > I hope you're right and it all works out okay. I think it will. I can't see any drawbacks of that scenario compared to the current situation. By centralizing bug reports in one forum, there are only benefits. >>> I think we should be cautious of telling too many people to do >>> that. > >> I don't. <snipped> We should >> not discriminate against people because we don't think they are as >> intelligent as you or I, <snipped> But this is no basis to tell >> the technically incompetent or misguided to post to an inappropriate >> list and have some valid reports or missed and/or force developers >> to spend their time reading a forum they shouldn't have to read in >> order to do their job. > > You make a compelling argument and I even agree to a point, especially > with making things more difficult for developers. No one wants that. > In fact, that was the motivation for my argument as well. You make > valid points and are of course in a better position to know. I just > hope the list doesn't become too congested with useless posts and end > up wasting time and patience that you too are trying to avoid by > directing them there. Our goal is the same, but differ in the > ideology for implementation. It might become congested... I'm not saying it won't. I'm not saying it will be easier to read, or have less traffic. It won't. It's not a 100% ideal situation, but it's better than the current situation of bug reports scattered all over the place, forcing developers to pay attention to various lists to catch everything. Or, even worse, wasting people's time to forward pertinent messages (like Alan). I'm all for ideas on how to improve things... I don't think it's the perfect situation. I think a number of things need to change, and no one will ever agree on the best implementation. Some will say that a web-based system, like Forum, is the best method. I personally disagree. Others might say usenet is the way to go. Some, mailing lists. There are different methods. I think mailing lists are the best way because developers can filter what is important to them. Keeping it centralized on one list, however, keeps the developers focused on what they need to be focusing on because it reduces the time they need to manage their email. That benefits every one. I also think Bugzilla needs to be leveraged more. And one thing I would like to see is a copy of every bugzilla report automatically cc'd to the cooker list. This allows everyone to see what bugs are open and, I think, would help to eliminate multiple posts on the same bug (or multiple bug reports on the same bug). I think it would also help people visualize open bug reports better, making for a more effective means of handling bugs. Of course, this needs to be implemented over time and I'm not the one who can make these changes, although I will certainly recommend them. One thing we are most criticized for is our beta cycles, so we must (all of us) do what we can to make it better. Some of the criticism isn't valid to me, but some of it is, and those issues need to be addressed. All I'm attempting to do is get the ball rolling in the right direction. -- MandrakeSoft Security; http://www.mandrakesecure.net/ "lynx - source http://linsec.ca/vdanen.asc | gpg --import" {FE6F2AFD: 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD}
PGP.sig
Description: PGP signature
