[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: scope creep in DDP Policy



Adam,

Scope creep: good word to describe situation :-)

Just thinking out loud usually does not accomplish things.

I am with you for the tasks needed for DDP policy.  But let me first
reflect where this all started and how it get to come here.  And then
let me state how we should get to reachable goal.  

It all started with 3 basic questions:

 Q1) How should we publish the web page for DDP documents.
 Q2) How should we get DDP documents included in the CD image.
 Q3) How should we package DDP document.

When I say "How should we", this includes format of documents, encoding
of documents, filename choice of documents, directory structure of
documents, and tool chain of document, and repository of documents.

I thought that that the most natural method to reach "policy" was to
identify "best practices" and choose key part of "best practices" as
policy.  Without knowing generally "what is good", it is difficult to
define "what must be done for DDP."

This is why currently so-called "ddp-policy" is in this shape and I did
not oppose Javi's writing on very inclusive attitude and comprehensive
policy.  I think we accomplished "thinking out loud" successfully through
this.

I think this document as it is now should have been titled as "DDP Best
Practice Reference" or so.

IMHO, DDP policy should focus on question Q1 and Q3.  But consideration
to the question Q2 is very important too.

Let me explain my previous comment:
When I said "most of idea was summarized within debian-doc folks.  I
think this content has to be review by following people in the order",
I was not rushing down to get all the things done in short period.  My
intent was to say that it needs more review before proposing to policy.
Here is what the order and expectations of the future process in my
thought.

(1) Getting comment from debian-www and debian-sgml folks
   In this process, we present "best practice ideas" and get feed back
   for issues which this practice may cause.  Then come back here to
   finalize what should be included in DDP policy.  Maybe asking d-i
   folks may also be desirable.

   I think we need to narrow scope of proposed policy after this
   process.

(2) Getting general support from debian-devel
   By the time we present any thing to here, DDP policy should be very
   tight.

(3) Getting approved by debian-policy
   It should be complete policy proposal.

After thinking again about the state of DDP policy, I had to agree with
Adam that we need to narrow our scope of this proposal now before going
even to step (1) above.

In order to narrow scope of discussion, we should separate general
policy issues related to generic documents which comes with packages
and their manual pages and info pages.  Let's keep them separate.

DDP policy should be policy on the document specifically written for
"Debian" as discussed in Chapter 3.

It should define,
 1] Accepted copyright types (GPL, GFDL w/o invariant)
 2] Recommended copyright (GPL or GFDL w/o invariant, need to decide)
    (I am GPL proponent)
 3] Accepted source formats (debiandoc-sgml, docbook-sgml, docbook-xml,
    ...)
 4] Recommended source format (docbook-xml)
 5] Minimum publish format (html/multi-page, txt/single file)
 6] Recommended publish format (above plus PS and PDF)
 7] State SGML source not to be included in binary
 8] Formalize use of document install directory as package
    /usr/share/doc/Debian/refarence-name/*.LANG.FORMAT
    or 
    /usr/share/doc/Debian/FULL-LOCALE/*.txt etc.
 9] Formalize use of document install directory as web page
 10] Formalize use of standard document directory as source ("should")
 11] Formalize CD document directory tree (if it can be included here.)

8]-11] needs some good review.

> I think we need to step back and make a policy just for ourselves
> (DDP) and then add from there.  Starting with the scope being too
> large is perhaps why the DDP policy is stalled?
> ...Adam Di Carlo..<adam@onshore-devel.com>

True.  Reachable but challenging goal is the key for success.

First discussion point before going to the step (1) is narrow the scope.
Let's focus on Chapter 2 and Chapter 3.  Can we agree?

Let's us think again the question of "directory structure".  I do not
think we had any major discrepancy between us on other issues.

Should we conclude here on "directory structure" or ask opinion from step
(1)?

Osamu

PS: Since Adam retracted source only distribution model, last part of
3.5.2 can be removed, I think.

-- 
~\^o^/~~~ ~\^.^/~~~ ~\^*^/~~~ ~\^_^/~~~ ~\^+^/~~~ ~\^:^/~~~ ~\^v^/~~~ +++++
        Osamu Aoki <osamu@debian.org>   Cupertino CA USA, GPG-key: A8061F32
 .''`.  Debian Reference: post-installation user's guide for non-developers
 : :' : http://qref.sf.net and http://people.debian.org/~osamu
 `. `'  "Our Priorities are Our Users and Free Software" --- Social Contract



Reply to: