From owner-freebsd-doc  Mon Nov 13  7:13:42 2000
Delivered-To: freebsd-doc@freebsd.org
Received: from spammie.svbug.com (mg136-070.ricochet.net [204.179.136.70])
	by hub.freebsd.org (Postfix) with ESMTP
	id 13DB137B4C5; Mon, 13 Nov 2000 07:13:35 -0800 (PST)
Received: from spammie.svbug.com (localhost.mozie.org [127.0.0.1])
	by spammie.svbug.com (8.9.3/8.9.3) with ESMTP id HAA05727;
	Mon, 13 Nov 2000 07:15:35 -0800 (PST)
	(envelope-from jessem@spammie.svbug.com)
Message-Id: <200011131515.HAA05727@spammie.svbug.com>
Date: Mon, 13 Nov 2000 07:15:34 -0800 (PST)
From: opentrax@email.com
Reply-To: opentrax@email.com
Subject: Re: docs/22042: spelling error
To: nik@freebsd.org
Cc: keichii@peorth.iteration.net, freebsd-doc@freebsd.org
In-Reply-To: <20001112124429.E1752@canyon.nothing-going-on.org>
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Sender: owner-freebsd-doc@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org



On 12 Nov, Nik Clayton wrote:
> On Sun, Nov 12, 2000 at 03:32:31AM -0800, opentrax@email.com wrote:
>> I  don't concur. "Seperation of tasks" usually involve
>> tasks that don't merit replication. Certainly FreeBSD can
>> gain by providing a response that is much more pro-active.
> 
> There is no "FreeBSD" in this context.  Just people.  In this case, 
> time is a resource that we don't have enough of.  Rather than have a 
> committer spend the five minutes composing an e-mail to the XFree86 folk,
> it is a better use of resources if the original PR sender does so.  The
> committer can then concentrate on working through the rest of the PR 
> database.
> 
I'm not suggesting by any means suggesting the that the comitter 
take any more time than has been wasted up until now. What I am
suggesting is a change in the way business is done. PRs have many 
points of growth. Certainly, this PR is slowly growing out of
bounds. :-)

My point is that we can cut our PRs by making an effort to
find the root of some issue. I think many of us can recall
features that somehow overwhelm projects. These features
many times stem from a mis-understanding of the problem.

In our case, bug reporting/tracking is hogging the wheel
from things like troubleshooting, customer feedback, education 
and customer response. Least of all, if a user has real 
problem, ie. they have a server break-in -- all we
can do is react.

At this time, *BSD has had no means to measure customer
approval. That is, if *BSD moves on a new feature, and
that feature is bad, there is NO way to back out.

By the same token, if a popular application on *BSD,
fails we will feel the response - NOT the app. developer.
Many developers are responsible and create good Apps.
However, just as many are irresponsible and create bad Apps.

Should we continue supporting bad Apps?
Should we continue adding features that prompt bad Apps?

*BSD has never taken a role in creating or prompting
Cobol, but sure as there is a day, there are companies that 
build, charge for, and support it. 

> Yes, in an ideal world we would be able to shepherd PRs about non-core parts
> of FreeBSD to the appropriate third party.  However, it's much more effective
> if people like you take up the baton to help.
> 
The ideal world starts by you and I building it.

				best regards,
				Jessem.




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-doc" in the body of the message