public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
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



  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