From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: [RFC] Features and documentation
Date: Thu, 29 Nov 2007 05:04:20 +0000 (UTC) [thread overview]
Message-ID: <pan.2007.11.29.05.04.19@cox.net> (raw)
In-Reply-To: 20071128213319.09f73e89@blueyonder.co.uk
Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk> posted
20071128213319.09f73e89@blueyonder.co.uk, excerpted below, on Wed, 28 Nov
2007 21:33:19 +0000:
> On Wed, 28 Nov 2007 13:14:05 -0800
> Donnie Berkholz <dberkholz@gentoo.org> wrote:
>> Many of the replies keep asking for details -- details that don't
>> exist. Apply the concept abstractly: things that need to be documented
>> must have documentation available in the appropriate form at the time
>> they're committed.
OK, I can accept that details don't (yet) exist, but that's why the
discussion. =8^) Hopefully it'll flesh out some of these details.
> A large part of why many things aren't documented is that people have
> very different ideas about what level of documentation is required;
> this does nothing to affect that.
Agreed. The current discussion on the metadata changes is a prime
example. Obviously, there was disagreement on the level of documentation
needed. A nebulous "document before change" policy can't help in such
cases, as one side or the other's going to get very frustrated, either by
"extreme" enforcement (seen by the one side), or lack of enforcement
(seen by the other). The /best/ that could come out of such would be
that it's as if there were no policy at all. The worst... people leaving
because of "unfair" enforcement of a policy so nebulous they never saw
the action coming, or OTOH, because Gentoo refuses to enforce its own
policies.
>> What remains unclear about this principle?
>
> It has an unpleasant smell of something a Dilbert-esque manager would
> introduce after having read a "Project Management for Dummies" book
> full of slogans and generalities.
Leave it to ciarnm to be so direct, amusing tho it is, but that pretty
much nails it. I've seen it said by some that Gentoo's no longer "fun".
I disagree but honestly, ask yourself if there's a better way to ruin the
fun remaining than by instituting policies so nebulous they simply /beg/
for argument over their application. The idea sounds so nice, something
everybody should be able to agree to in principle, but that's precisely
the problem, there's no specifics, so no practical way to tell where or
how it applies, or what changes (if any) it would bring. Pardon my
saying so but at least in the US, it's the season of politics, and we're
seeing a lot of this vague "big stroke" pie in the sky painting right
now. Unlike most of those, there's a chance with this one to get it
nailed down to the point it's actually practical.
(Bullet point suggestions for tightening down the spec to something
"workable" omitted for brevity. Ciarnm put them well enough.)
> You know... Practical things, rather than things that make you feel
> good but go nowhere.
=8^)
As an alternative or adjunct to Ciaran's suggestions, perhaps this will
be easier, tho not immediately as complete. Self-evidently if you are
making the proposal, you believe there's a need for it and that it would
change the outcome in one or more events in the recent and possibly less
recent past. What about listing them, and how you see your proposal
changing the outcome thereof. At least that would give us some concrete
examples to apply the policy to in our heads as we discuss it. As I
said, it's not as complete as the thorough evaluation Ciaranm proposed,
but one has to start somewhere, and this would be one way to do it.
OTOH, it's also getting very specific about perhaps sensitive events,
while Ciaran's proposal would avoid singling out such events and
therefore people by name, thus having the advantage there as well as in
ultimate wholeness, once it's done.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
--
gentoo-dev@gentoo.org mailing list
next prev parent reply other threads:[~2007-11-29 5:08 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-27 19:21 [gentoo-dev] [RFC] Features and documentation Donnie Berkholz
2007-11-27 19:25 ` Ciaran McCreesh
2007-11-27 19:36 ` Donnie Berkholz
2007-11-27 19:41 ` Ciaran McCreesh
2007-11-27 19:31 ` Doug Klima
2007-11-28 3:10 ` Alec Warner
2007-11-28 6:56 ` Rémi Cardona
2007-11-28 18:12 ` Zhang Le
2007-11-28 21:15 ` Donnie Berkholz
2007-11-29 0:43 ` Alec Warner
2007-11-29 1:01 ` Donnie Berkholz
2007-11-29 2:25 ` Alec Warner
2007-11-29 8:58 ` [gentoo-dev] " Christian Faulhammer
2007-11-29 13:57 ` [gentoo-dev] " Santiago M. Mola
2007-11-29 14:47 ` Doug Klima
2007-11-28 11:40 ` Marijn Schouten (hkBst)
2007-11-28 12:38 ` [gentoo-dev] " Duncan
2007-11-28 21:14 ` Donnie Berkholz
2007-11-28 21:33 ` Ciaran McCreesh
2007-11-29 0:29 ` Donnie Berkholz
2007-11-29 5:04 ` Duncan [this message]
2007-11-29 5:38 ` Donnie Berkholz
2007-11-29 18:06 ` Duncan
2007-11-29 19:29 ` Santiago M. Mola
2007-11-30 17:50 ` Duncan
2007-11-30 10:42 ` Steve Long
2007-11-30 17:42 ` Duncan
2007-11-28 19:02 ` Christian Faulhammer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=pan.2007.11.29.05.04.19@cox.net \
--to=1i5t5.duncan@cox.net \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox