Subject:
Re: Beginning of outline for policies
From:
Charles Curley ####@####.####
Date:
16 May 2002 00:24:47 -0000
Message-Id: <20020515182306.F22602@trib.com>
On Wed, May 15, 2002 at 03:04:05PM -0700, David Lawyer wrote:
> On Tue, May 14, 2002 at 04:09:01PM -0400, Tabatha Persad wrote:
> > Hi there everyone,
> >
> > I've started a rough sketch. Of course, there could be more issues that we
> > need addressed and added, but I wanted to throw something out there and see
> > what comes back!
>
> Since we already have the Manifesto, we might work on revising it. I'll
> shortly make a post regarding this.
Manifestos should be short and sweet -- certainly shorter than the
Communist Manifesto (probably the best known), but then Karl Marx
always did use four words where one would do.
A policy manual is a more detailed document, and more concerned with
implementation rather than goals. Consider the U.S. Declaration of
Independence as a manifesto, the U.S. Bill of Rights as a policy
manual.
>
> The situation with the LDP is that we've always been short of people to
> do the work and thus we must have flexible policies which permit the
> highest priority jobs to be done first. Giving definite answers to many
> to the questions poised below for certain policies, would interfere with
> the required flexibility. So I think that it would in some cases be
> counterproductive to establish many of the policies listed below.
I disagree. A policy should be hortatory, not mandatory. I.e.:
"Do this unles you have a really good reason to do otherwise."
>
> One item that needs doing is to have a webpage for docs that need
> maintainers. We really have no such page now because the "unmaintained"
> page includes obsolete docs that need no maintainer. Also, some
> maintained docs need a new maintainer. So I would say that it's high
> priority to discuss this and do something about it.
OK, why not separate out the obsolete and mothball them?
>
> Another comment is that I'm not sure if LDP should have any "editors".
> Most of them could be called "reviewers". The word "editor" sounds too
> dictatorial. What about saying that Joy is the "quality control" person.
> Her title would just be "quality control". What else could we call
> her besides editor?
David, I've been writing for more than 30 years, and one of the things
Ive learned is that good editors are not dictators, they are
teachers. The bad editors say (if anything), "Do it my way or hit the
road." The good ones say, "Here's something you ought to do, and
here's why." Case in point, John Campbell.
Joy, I think, is one of the good ones.
>
> >
> > Here's a start:
> >
> > 1. Overview of Editing Processes * Introduction - This could contain
> > some information about the fact that the LDP has a team of editors to
>
> What team? If we had such a team, why would Joy need to try to recruit
> someone for the PHP-HOWTO.
>
> > assist, and an overall picture of what service editors are trying to
> > provide to authors. It might take the scare out of the process to
> > know that editors are working to help improve quality and readability,
> > not hack apart the author's work. A good area to establish the
> > mission of the LDP and why this is beneficial to the community.
> Just have no editors. Problem solved.
Then we're back to the QC issue, which is where we came in to this
discussion.
>
> > * Language Review - This will be a broad description of the sentence
> > level editing performed by editors, and examples of other things that
> > may be recommended or changed by editors. This should outline what
> > types of changes the editor would make, as well as when author
> > consultation would and would not be necessary.
>
> This can often be combined with Technical Review. We could just call
> it review for short. There's also a brief review by sampling parts of the
> doc. Since we are lucky if we can get any kind of review on all the
> docs, we should not worry too much about classifying reviews by type.
> There's a whole gamut of types of reviews.
What Tabatha calls "language review" I would call "editorial review",
but no matter.
Language and techical review are two very different things, and are
often done by different people. Techical review ought to be done,
ideally, by someone familiar with the content, to make sure the
document is technically correct. The language review should be done by
someone familiar with technical language and the human language in the
document to make sure the document is clear and concise.
Occasionally, you can combine the two by handing them to the same
person, but people competent to do both are very rare! Even so, they
are different functions. I find when I have to do both, I do one at a
time, in separate passes as much as a week apart, precisely because
they are so different.
> >
> > * License Review - Many existing and new documents come into the LDP
> > without a license, sometimes without even a copyright. Although
> > publication of the author's work can probably constitute as copyright,
> > without the license, either LDP or GFDL in place, this results in a
> > document that no one effectively has permission to change. The
> > license protects the author and this should be stressed. It should be
> > included in their work - being implied because it simply resides in
> > the LDP repository is not sufficient.
>
> It doesn't have to be a separate License Review.
>
> > 2. Procedure for New Submissions
> > * How long does the review take once I submit my document?
> This will vary, but if it's too long, then the doc is published with
> only a cursory review. No need to specify this.
> > * How are editors assigned?
> reviewers
> > * What type of content should be submitted?
>
> Again, we don't need any definite rules on this. It's obvious from our
> Manifesto that the docs need to relate to Linux. The details of just
> how closely they must relate to Linux is decided on a case by case
> basis.
This is the sort of thing where a policy manual would help. The author
of a candidate document could review the policy, and if the author
thinks it is suitable in spite of the manual, the author could appeal
to the list. This is a very simple process which minimizes traffic on
the list.
>
> > * What type of text formats should be submitted?
> Specified in the Manifesto.
> > * Where can authors obtain help to format their text?
> They can look at my mini-HOWTO on LinuxDoc :-)
Or other resources specified in the Authors' Guide. Not everyone works
in LinuxDoc. :-)
> > * Discussing recommendations with your editor.
> Presently, we have no editor for each doc.
Maybe we should. It works very well for on-going documentation in
large companies like HP or M$.
> > * What you can do if you object to recommendations.
>
> If we only have a reviewer, then it's understood that you don't really
> have to follow the recommendations. But if the resulting doc is poor,
> then the staff can reject the doc. It's kind of negative to even
> mention what happens in extreme cases where the author is unreasonable.
> But it might be mentioned somewhere that in extreme cases the LDP has
> been known to reject documents.
I would say here something like, "If you disagree with an editor's
proposed change, say why and work with the editor. Only if you believe
you aren't getting a fair hearing from the editor should you appeal to
the list. One remedy you can seek is to request another editor.
>
> > * What if you have not responded to the review?
> I think that since almost all authors will respond to a review, this
> needs to be handled on a case by case basis. Before any review is even
> started, it must be ascertained that the author can be reached and
> responds to emails.
The point of a policy manual is to minimize case-by-case
adhocracy. Perhaps the manual or the manifesto should make clear that
the LDP may reject or cease to publish any document for cause,
including failure to follow through on LDP processes such as technical
or editorial review.
>
> > 3. Procedure for Existing Documentation
> > * When do documents come up for review?
> > * How does the review differ from a new submission?
> > * How are editors assigned, and how long will it take?
> > * Discussing recommendations with your editor.
> > * What you can do if you object to recommendations.
> > * What if you have not responded to the review?
>
> My comments here are similar as in 2. above.
> >
> > 4. Procedure for Unmaintained Documentation
> > * How does the LDP determine a document is unmaintained?
> > * What steps are taken to contact an author who has not responded?
> > * Where can a list of unmaintained documentation be found?
> You mean docs that need a maintainer
> > * How do I volunteer to take responsibility for an unmaintained
> document?
> This should be on the same webpage with the list to docs that need a
> maintainer
Or apointer on that page to the appropriate section of the Policy
Manual, to simplify maintenance.
> > * Will the LDP review or maintain the document in any way until there is a volunteer?
> The LDP is itself volunteers, so nothing gets done unless someone
> volunteers.
>
> > _______________
> >
> > I realize that a couple of sections are the same in 2 and 3, but I took into
> > consideration the process might be different with two different types of
> > documentation, new vs existing.
> >
> > Feedback, propose your changes, tell me if it's in the wrong order, you name
> > it! (ducking)
> >
> > Tab
> >
> >
> >
> > --
> > Tabatha Persad
> > Web: http://www.merlinmonroe.com
> > The Linux Counter Project Area Manager US:wa (http://counter.li.org)
> > Linux Documentation Project Editor (http://www.tldp.org)
> > Gnu Writing Movement Project Developer (http://savannah.gnu.org/projects/gwm)
> >
> > ______________________
> > http://lists.tldp.org/
> >
> >
> >
> David Lawyer
>
> ______________________
> http://lists.tldp.org/
--
Charles Curley /"\ ASCII Ribbon Campaign
Looking for fine software \ / Respect for open standards
and/or writing? X No HTML/RTF in email
http://w3.trib.com/~ccurley / \ No M$ Word docs in email
--> -->
<type 'exceptions.IOError'> | Python 2.5.2: /usr/bin/python
Wed Jul 3 15:53:12 2024 |
A problem occurred in a Python script. Here is the sequence of
function calls leading up to the error, in the order they occurred.
| /opt/ezmlm-browse-0.20/main.py in main() |
424
|
425 if path is not None:
|
426 main_path(path)
|
427 else:
|
428 main_form()
|
| global main_form = <function main_form at 0x83bec6c> |
| /opt/ezmlm-browse-0.20/main.py in main_form() |
378 except ImportError:
|
379 die(ctxt, "Invalid command")
|
380 module.do(ctxt)
|
381
|
382 def main():
|
| module = <module 'commands.showmsg' from '/opt/ezmlm-browse-0.20/commands/showmsg.pyc'>, module.do = <function do at 0x841b224>, global ctxt = {'cmd': 'showmsg', 'threadidx': 3, 'HTTP_X_FORWA...HTTP_ACCEPT_ENCODING': 'gzip, br, zstd, deflate'} |
| /opt/ezmlm-browse-0.20/commands/showmsg.py in do(ctxt={'cmd': 'showmsg', 'threadidx': 3, 'HTTP_X_FORWA...HTTP_ACCEPT_ENCODING': 'gzip, br, zstd, deflate'}) |
18 write(html('msg-pager') % ctxt)
|
19 write('<hr>')
|
20 sub_showmsg(ctxt, ctxt[MSGNUM])
|
21 write('<hr>')
|
22 write(html('msg-pager') % ctxt)
|
| global sub_showmsg = <function sub_showmsg at 0x83be1ec>, ctxt = {'cmd': 'showmsg', 'threadidx': 3, 'HTTP_X_FORWA...HTTP_ACCEPT_ENCODING': 'gzip, br, zstd, deflate'}, global MSGNUM = 'msgnum' |
| /opt/ezmlm-browse-0.20/globalfns.py in sub_showmsg(ctxt={'cmd': 'showmsg', 'threadidx': 3, 'HTTP_X_FORWA...HTTP_ACCEPT_ENCODING': 'gzip, br, zstd, deflate'}, msgnum=3090) |
229 format_timestamp(ctxt, ctxt)
|
230 write(html('msg-header') % ctxt)
|
231 rec_showpart(ctxt, msg, 0)
|
232 write(html('msg-footer') % ctxt)
|
233 ctxt.pop()
|
| global rec_showpart = <function rec_showpart at 0x83be1b4>, ctxt = {'cmd': 'showmsg', 'threadidx': 3, 'HTTP_X_FORWA...HTTP_ACCEPT_ENCODING': 'gzip, br, zstd, deflate'}, msg = <email.message.Message instance at 0x8437e8c> |
| /opt/ezmlm-browse-0.20/globalfns.py in rec_showpart(ctxt={'cmd': 'showmsg', 'threadidx': 3, 'HTTP_X_FORWA...HTTP_ACCEPT_ENCODING': 'gzip, br, zstd, deflate'}, part=<email.message.Message instance at 0x8437e8c>, partnum=1) |
205 else:
|
206 for p in part.get_payload():
|
207 partnum = rec_showpart(ctxt, p, partnum+1)
|
208 else:
|
209 write(html('msg-sep') % ctxt)
|
| partnum = 1, global rec_showpart = <function rec_showpart at 0x83be1b4>, ctxt = {'cmd': 'showmsg', 'threadidx': 3, 'HTTP_X_FORWA...HTTP_ACCEPT_ENCODING': 'gzip, br, zstd, deflate'}, p = <email.message.Message instance at 0x843d24c> |
| /opt/ezmlm-browse-0.20/globalfns.py in rec_showpart(ctxt={'cmd': 'showmsg', 'threadidx': 3, 'HTTP_X_FORWA...HTTP_ACCEPT_ENCODING': 'gzip, br, zstd, deflate'}, part=<email.message.Message instance at 0x843d24c>, partnum=2) |
208 else:
|
209 write(html('msg-sep') % ctxt)
|
210 sub_showpart(ctxt, part)
|
211 return partnum
|
212
|
| global sub_showpart = <function sub_showpart at 0x83be144>, ctxt = {'cmd': 'showmsg', 'threadidx': 3, 'HTTP_X_FORWA...HTTP_ACCEPT_ENCODING': 'gzip, br, zstd, deflate'}, part = <email.message.Message instance at 0x843d24c> |
| /opt/ezmlm-browse-0.20/globalfns.py in sub_showpart(ctxt={'cmd': 'showmsg', 'threadidx': 3, 'HTTP_X_FORWA...HTTP_ACCEPT_ENCODING': 'gzip, br, zstd, deflate'}, part=<email.message.Message instance at 0x843d24c>) |
164 type = ctxt[TYPE] = part.get_content_type()
|
165 ctxt[FILENAME] = part.get_filename()
|
166 template = html('msg-' + type.replace('/', '-'))
|
167 if not template:
|
168 template = html('msg-' + type[:type.find('/')])
|
| global template = <function template at 0x83b6e9c>, global html = <function html at 0x83b6ed4>, type = 'application/pgp-signature', type.replace = <built-in method replace of str object at 0x843c7c8> |
| /opt/ezmlm-browse-0.20/globalfns.py in html(name='msg-application-pgp-signature') |
40
|
41 def html(name):
|
42 return template(name + '.html')
|
43
|
44 def xml(name):
|
| global template = <function template at 0x83b6e9c>, name = 'msg-application-pgp-signature' |
| /opt/ezmlm-browse-0.20/globalfns.py in template(filename='msg-application-pgp-signature.html') |
31 except IOError:
|
32 if not _template_zipfile:
|
33 _template_zipfile = zipfile.ZipFile(sys.argv[0])
|
34 try:
|
35 f = _template_zipfile.open(n).read()
|
| global _template_zipfile = None, global zipfile = <module 'zipfile' from '/usr/lib/python2.5/zipfile.pyc'>, zipfile.ZipFile = <class zipfile.ZipFile at 0x834fa7c>, global sys = <module 'sys' (built-in)>, sys.argv = ['-c', '/opt/ezmlm-browse-0.20'] |
| /usr/lib/python2.5/zipfile.py in __init__(self=<zipfile.ZipFile instance at 0x83cb36c>, file='-c', mode='r', compression=0, allowZip64=False) |
337 self.filename = file
|
338 modeDict = {'r' : 'rb', 'w': 'wb', 'a' : 'r+b'}
|
339 self.fp = open(file, modeDict[mode])
|
340 else:
|
341 self._filePassed = 1
|
| self = <zipfile.ZipFile instance at 0x83cb36c>, self.fp = None, builtin open = <built-in function open>, file = '-c', modeDict = {'a': 'r+b', 'r': 'rb', 'w': 'wb'}, mode = 'r' |
<type 'exceptions.IOError'>: [Errno 2] No such file or directory: '-c'
args =
(2, 'No such file or directory')
errno =
2
filename =
'-c'
message =
''
strerror =
'No such file or directory'
