Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 28 Mar 2002 13:34:52 -0500
From:      "Yeasah Pell" <yeasah@apocalypse.org>
To:        <stable@FreeBSD.ORG>
Subject:   the law of the list
Message-ID:  <00c501c1d688$6d0401c0$0200a8c0@gauss>
References:  <OFFE95F10D.874B634B-ON88256B8A.003EC7EF-88256B8A.00401376@wr.usgs.gov>

next in thread | previous in thread | raw e-mail | index | archive | help
> These whiners, who constantly moan for code while never contributing any,
> should contribute the code if they want it changed.

If you hadn't noticed, many of the changes being discussed involve a large
amount of work. It is unreasonable to expect somebody to do the work with
the hope that it will be accepted it without first even attempting to
discern if it is a good idea.

Most importantly, this is not a productive attitude, and will not encourage
contribution. But sadly enough, it is a common sentiment on this list.

In my mind, steps toward solving a problem like this one go something like
this:

1. [ Identify problem ]
2. [ Enumerate possible solutions, and determine cost and impact of them ]
3. [ Choose solution or decide to not implement ]
4. [ Implementation (of course, there can be lots of substeps here) ]

It's true that for many simple problems, there is one obvious solution, and
one can just go ahead and implement it, and show up on your doorstep
tomorrow with code. There are also problems of medium scope for which it is
possible for one person to make these decisions quickly in their own mind.
This problem does not fall into either of those categories.

I'd say we're on step 2.

Now all this said, I understand that there is a history of these sorts of
discussions coming to a decision point, whereupon no person (including, to
the annoyance of everybody on the list, the originator of the thread) steps
up to the implementation plate. Avoiding this will not be accomplished by
browbeating anybody who appears to fit the profile, though.

One possiblity would be to have a system that maintains a pool of problems
that don't yet have defined solutions. Maybe file a PR of sorts, and then
qualified coders with available time who want to tackle a more architectual
problem could fish in that pool. That effectively inserts a step 1.5. [
Choose implementor ] between steps 1 and 2. (It would be nice to at least
discuss the problem before doing that, to avoid peppering GNATS with
duplicated and/or ill-defined problems.)

Create some FreeBSD document that tells people to follow these steps, and
"annoying" discussions like this could be avoided. "It is freebsd-stable (or
whatever) policy that problems may be discussed if and only if an individual
with a proven track record of successful code submissions is signed on to
implement a solution if one is chosen. If you wish to discuss something and
are not yourself a proven submitter with available time, we suggest you
submit a PR with this special format (or whatever), and wait for an
appropriate sympathetic individual to take ownership of the problem."

Ending "annoying" threads would be a simple matter of pointing the offending
people at the document. Perhaps such a document exists! If so, would
somebody please point me at it before I annoy the whole of the known FreeBSD
world?? :-)

>Also I shudder to think that those who customize their systems would
>actually learn how to use all the tools available to them to prevent a
>makeworld from overwriting or undoing their customizations. :)

This is a good point, but it doesn't mean the system must avoid doing
anything helpful at all. If you are referring to my suggestion that a
default make.conf be made based on a user's installer choices, I concede
that it is probably not worth doing (I think I even qualified it as such
when I made the suggestion), and it might even lull people into thinking
things are easier than they are. The motivation for that suggestion,
however, was consistency of the system (especially in the context of other,
more important suggestions), not coddling users.

>I wish that we could assign a bitch rating to some of these emails.  Say a
>sliding bitch scale depending on how much code the bitchee has
>contributed.  Then they could easily be filtered to /dev/null.
>Waddayathink? ;)

I assume that this is said tongue-in-cheek. Ideas are best judged on the
strength of the idea alone, not the credentials of the one who advances it.
While relying on credentials serves as a good crutch for those unable to
make their own determination of the value of an idea, I believe this list is
home to many people able to make that call.

I understand that this is an idealistic view of the way things work; in
practice, the charisma of the person behind an idea has a lot to do with how
well it is received, and their credentials factor into that. But we don't
need to go about making this effect any stronger than it already is.

/y



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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?00c501c1d688$6d0401c0$0200a8c0>