On Thu, Aug 21, 2003 at 04:04:00PM -0500, Branden Robinson wrote: > On Wed, Aug 20, 2003 at 04:12:17AM -0400, Anthony DeRobertis wrote: > > I am not a developer, and thus can not propose this amendment. I would > > still like to suggest it, however, in hopes that either Branden Robinson > > will accept it, or that some other developer will sponsor it: > > > > In the Robinson amendment's changes to (5), replace "modify" > > with "supersede." > > Both of the original GRs have Expired per the Standard Resolution > Procedure. > > However, in the event I re-propose my GR, I'll gladly make this change. > If we feel the need to update a non-technical position statement such as > the DFSG, I do believe it is important that try not to give any > appearance of sweeping the old one under the rug. > > Now that our Constitution has been amended, I hope the original version > will be archived in an easily accessible place; we should do the same > for documents that we supersede or withdraw under 4.1.5.
Hmmm. A few practical thoughts on the question - not that I disagree
with the intent, mind you.
First, superceding RFCs is relatively easy because they re clearly
numbered, straightforward texts which are regularly released. Doing this
wiht the DFSG or Social Contract or Constitution makes little sense; it
isn't DFSG 1 (.. 2, 3, 4), and even if it were, those are versions of a
single document, not a numbering system for various documents (which woudl
have the Constitution as DebianDoc 1, Social Contract as 2, DFSG as 3,
amended Constitution as 4, etc....)
Somewhat more clear, given the way things are structured, would be
versioning (either by version number or date) any modifications, with later
versions superceding earlier ones (but all good version tracking keeps
older versions easily fetchable, right? *couch*).
My personal favorite would require some (relatively minor) effort from
someone (probably the Secretary); a document which has sidenotes or
footnotes/references stating when sections have been elided, what the
origional section was, the rationale for change, the date of confirmation
(or end of vote?), etc. Though, really, this could always be reconstructed
from a versioned arrangement.
I do fully agree, however, that 'supercede' is a better way to deal with
things; it's just that in some cases, 'modify' can have the same end
results (is a new version a supercedement that matches 99% of the wording
of the old document, or a modification that preserves historic data? Etc).
--
Joel Baker <[EMAIL PROTECTED]> ,''`.
Debian GNU NetBSD/i386 porter : :' :
`. `'
`-
pgpAFQ1IegwLe.pgp
Description: PGP signature
