Re: Hard-coding release names in policy (was Re: [PROPOSED} delay the /usr/doc transition)
Manoj Srivastava <srivasta@debian.org> writes:
> Hi,
> >>"Chris" == Chris Waters <xtifr@dsp.net> writes:
> Chris> Sorry, I'm not saying the latter is an inherently bad thing to
> Chris> do, I'm saying that if that's our *only* option, then we may
> Chris> have a problem. I *do* think it's bad to have "this may be
> Chris> amended in the future" as our only way to embed strategy in
> Chris> policy.
> It is not the only way, but should only be used sparingly
> (given the loss of flexibility that the fuzzy end state
> provides). You have not convinced me that this is such a time.
Well, when I made the proposal that started this thread, I was
thinking in terms of a freeze date of Sept. 1. Apparently, we're not
going to freeze quite that soon, which does change things, and I'm
willing to be a lot more flexible at this point, since we
(unfortunately, IMO) have more time than I thought.
> Chris> Again, I think we need a way to describe our longer-term strategies
> Chris> somewhere.
> How formal do you want this to be? I would not make such
> strategy documents static, nor a part of policy. What about a file in
> the doc directory, to be removed when we are done? What about a fixed
> bug in the bts?
Hmm, interesting. I haven't really thought that far ahead.
Basically, I saw this situation where we have long range plans, but no
place to clearly document them, and it occured to me that maybe what
we need is a "strategy document" to complement and guide our policy.
I haven't really worked out the details, but your suggestions seem
excellent.
> I think this is too heavy wieght a process. I would rather
> that the control be in the hands of a human, and not institute new
> rules like that. The file I propose above would only serve to refresh
> our memory, and so we do not run through all the old arguments again.
Simple is fine, I'm all in favor of simple.
> I think there is an advantage to not putting the policy list
> in a strait jacket.
Well, I was thinking that a strategy document should, of course, be at
least as open to change as policy is. Perhaps even more so, as long
term strategy is even more subject to change than existing policy.
> Why do you have so little trust in the future policy decision
> makers? I would seriously object to any body who tries to reach out
> of the past and tell me that they knew back then the right thing to
> do better than we do now, knowing the ground and the current
> situation.
No, no, no, it's not a lack of trust at all. It's more, as you
mention, for documention, so that we don't have to rehash old
arguments, or lose track of details when a key player disappears. A
strategy document that says, "here's where we're trying to go, and
here's how we're currently planning to get there", will help us keep
our plans in mind, and (especially for long-term changes) help ensure
that important details don't slip between the cracks.
I'm not saying that the strategy we decide on this week is going to be
immutable forever -- just that it would be nice to have a clear record
of the strategy we *do* have planned. If we want to change our
strategy in the future, that's fine too. But as it is, all we have is
a fixed policy, which only describes one snapshot of what is, in fact,
frequently an evolving strategy.
> I would agree to keeping notes, and rationales, and what we
> think should be done, and take the final decision later (which may be
> to accept the old decision ``since nothing has changed''). Not
> automatically.
Yes, that sounds just fine. Although, in most cases, I suspect that
acceptance will (or certainly *should* be) all-but-automatic. Unless
our strategy has suddenly changed (in which case, we should change the
strategy document). :-)
But fully-automatic changes of policy might be a bit much, I agree.
At least until we have some experience with the whole concept and see
how it works. And maybe, indeed, ever.
cheers
--
Chris Waters xtifr@dsp.net | I have a truly elegant proof of the
or xtifr@debian.org | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
Reply to: