5662
Comment:
|
8413
|
Deletions are marked like this. | Additions are marked like this. |
Line 3: | Line 3: |
For information about the other sprints going on at ["PyConDC2004"], please see SprintPlan2004. |
For introductory information and information about the other sprints going on at ["PyConDC2004"], please see SprintPlan2004. |
Line 6: | Line 6: |
For introductory information, please see the 2003 SprintPlan. | Also see the [http://docutils.sourceforge.net Docutils home page] and the [http://docutils.sourceforge.net/rst.html reStructuredText home page]. |
Line 12: | Line 12: |
through March 23 (Tuesday), totalling 4 days. How long should the Docutils sprint be? It probably depends on the participants, so please voice your opinions here or [mailto:goodger@python.org email me]. |
through March 23 (Tuesday), for a total of 4 days. I'm going to be there for all 4 sprint days, so I invite sprinters to join in. How long should the Docutils sprint be? It depends on the participants and the other sprints. How about separate Saturday/Sunday and Monday/Tuesday sprints? |
Line 16: | Line 17: |
I'm going to be in DC for all 4 sprint days, so I invite sprinters to join in. Perhaps separate Saturday/Sunday and Monday/Tuesday sprints? |
Please voice your opinions here or [mailto:goodger@python.org email me]. |
Line 36: | Line 36: |
* Ollie Rutherfurd [mailto:oliver@rutherfurd.net email] * Fred Drake [mailto:fdrake@acm.org email] (Saturday and Sunday) * Ian Bicking [mailto:ianb@colorstudy.com email] (but I'm not really sure which sprint I will attend) |
|
Line 66: | Line 68: |
* Python source reader (autodocumentation subsystem). Ideas: | * Python source reader (autodocumentation subsystem). There's a lot of support for this. Ideas: |
Line 68: | Line 70: |
* [http://docutils.sf.net/spec/pysource.html detailed exploration of some ideas] | |
Line 70: | Line 73: |
* [http://docutils.sf.net/sandbox/sandbox/davidg/pysource_reader DavidG's sandbox code (incomplete)] * [http://docutils.sf.net/sandbox/sandbox/tibs/ Tibs' sandbox code (incomplete)] |
* [http://docutils.sf.net/sandbox/davidg/pysource_reader DavidG's sandbox code (incomplete)] * [http://docutils.sf.net/sandbox/tibs/ Tibs' sandbox code (incomplete)] * [http://docutils.sourceforge.net/sandbox/ianb/extractor/ IanB's sandbox code (hack)] |
Line 77: | Line 81: |
* HTML fragment writer -- establish API (useful for ht2html and templating systems). ([http://docutils.sf.net/spec/notes.html#html-fragments Notes], and [http://docutils.sf.net/sandbox/oliverr/ht/ related work].) | * HTML fragment writer -- establish API (useful for ht2html and templating systems). ([http://docutils.sf.net/spec/notes.html#html-fragments Notes], and [http://docutils.sf.net/sandbox/oliverr/ht/ related work].) Fred Drake and Mike Orr are both interested in this. * [http://www.w3.org/TR/2003/WD-xhtml2-20030506/ XHTML 2.0] writer. Though the spec is in the "working draft" stage, it would be nice to start experimenting with it. -- ''Fred Drake'' |
Line 108: | Line 114: |
(One just slightly off-topic idea would be to extend and existing documentation generator, such as EpyDoc, to support Zope-style interfaces. This would be especially nice since EpyDoc already supports reStructuredText. -- ''Fred Drake'') |
|
Line 116: | Line 124: |
I'd be very interested in working on the/a Python source code reader -- it seems like the giant missing piece of docutils. -- ''Ian Bicking'' Two 2-day sprints would be better for me. I wasn't planning to attend any sprint, but Docutils is tempting me. I'd most likely attend Monday-Tuesday. I'm not that good at understanding intricate parser code, but perhaps I can work on some other aspect. My wishlist item is for the HTML generator to just produce an HTML fragment I can plug into a larger page, rather than all the header/footer/style stuff it adds. There has also been much interest in our local Python user group about having a ReST syntax in MoinMoin. -- ''Mike Orr'' An enhanced client API with better support for [http://docutils.sf.net/spec/notes.html#html-fragments writing fragments] would be ''really'' nice to have; I'd be willing to spend some time on that as well. Each time I have tried to make a simple script that used docutils in some way, the API has been difficult to figure out. It may be that documentation is all that's needed, or just a more-visible entry point into existing documentation, but I know how hard that is to do. I think it would be worth having at least a little brain-storming session to figure out where people are getting hung up on the API and letting you tell us how much of it is there in some form already, and guiding an effort to make it more effectively exposed. Whether that's documentation, a little code, or a pile of new stuff, I don't know, but my past explorations make me think there's some limited amount of "API stuff" that needs to be done. I don't know whether I'll be able to sprint on Monday/Tuesday though. -- ''Fred Drake'' |
Preliminaries
For introductory information and information about the other sprints going on at ["PyConDC2004"], please see SprintPlan2004.
Also see the [http://docutils.sourceforge.net Docutils home page] and the [http://docutils.sourceforge.net/rst.html reStructuredText home page].
Duration
The sprints at ["PyConDC2004"] are to be held from March 20 (Saturday) through March 23 (Tuesday), for a total of 4 days. I'm going to be there for all 4 sprint days, so I invite sprinters to join in. How long should the Docutils sprint be? It depends on the participants and the other sprints. How about separate Saturday/Sunday and Monday/Tuesday sprints?
Please voice your opinions here or [mailto:goodger@python.org email me].
Cost
There is no cost to attend the sprints beyond registering for PyCon (and being present, of course).
Sprinters
Everyone is welcome! No prior Docutils hacking experience is required. Participants should either be experienced Python programmers, or interested in documentation.
Please [mailto:goodger@python.org email me] or edit this page directly if you'd like to participate.
David Goodger (coach) [mailto:goodger@python.org send me email]
Ollie Rutherfurd [mailto:oliver@rutherfurd.net email]
Fred Drake [mailto:fdrake@acm.org email] (Saturday and Sunday)
Ian Bicking [mailto:ianb@colorstudy.com email] (but I'm not really sure which sprint I will attend)
Sponsorship
This sprint and my participation at ["PyConDC2004"] are being sponsored by Silver Sponsor [http://WingIDE.com Archaeopteryx Software], the [http://www.python.org/psf Python Software Foundation (PSF)], and individual contributors. Thank you all!
In order to minimize expenses, I'm hoping to find someone willing to put me up in a spare bed, sofa, or patch of floor, from March 19 to March 27. If you can help, please [mailto:goodger@python.org send me email] as soon as possible. Thanks!
Sprint Topic Ideas
What would participants like to accomplish? Choose from among the ideas below or add new ones. Register your votes below, and feel free to comment.
The sprint should begin with an introduction to Docutils and reStructuredText: their purpose, future direction, and current implementation. How long should it be? Should there be a long preliminary lecture covering a lot of ground, or a minimal overview (with the possibility of further dicsussions as needed)?
Here are ideas for the sprint, in no particular order:
- Python source reader (autodocumentation subsystem). There's a lot of support for this. Ideas:
[http://docutils.sf.net/spec/pep-0258.html#python-source-reader PEP 258]
[http://docutils.sf.net/spec/pysource.html detailed exploration of some ideas]
[http://docutils.sf.net/spec/notes.html#python-source-reader notes]
[http://docutils.sf.net/docutils/readers/python/ DavidG's module parser code (incomplete)]
[http://docutils.sf.net/sandbox/davidg/pysource_reader DavidG's sandbox code (incomplete)]
[http://docutils.sf.net/sandbox/tibs/ Tibs' sandbox code (incomplete)]
[http://docutils.sourceforge.net/sandbox/ianb/extractor/ IanB's sandbox code (hack)]
Test framework -- extend unittest with support for packages of test modules (i.e., integrate [http://docutils.sf.net/test/package_unittest.py this] into unittest.py).
DocPy (Python's dialect of LaTeX) writer completion -- would allow easier entry for documentation newbies, "make authorship more accessible" ([http://docutils.sf.net/sandbox/dkuhlman/ initial implementation]).
HTML fragment writer -- establish API (useful for ht2html and templating systems). ([http://docutils.sf.net/spec/notes.html#html-fragments Notes], and [http://docutils.sf.net/sandbox/oliverr/ht/ related work].) Fred Drake and Mike Orr are both interested in this.
[http://www.w3.org/TR/2003/WD-xhtml2-20030506/ XHTML 2.0] writer. Though the spec is in the "working draft" stage, it would be nice to start experimenting with it. -- Fred Drake
- Other writers:
OpenOffice.org ([http://docutils.sf.net/sandbox/aahz/OO/ Aahz's sandbox] & [http://docutils.sf.net/sandbox/pobrien/OpenOffice/ Patrick O'Brien's sandbox]; which is based on which?)
DocBook ([http://docutils.sf.net/sandbox/oliverr/docbook/ Oliver Rutherfurd's sandbox])
- RTF
Interpreted text [http://docutils.sf.net/spec/notes.html#role-bindings role bindings].
[http://docutils.sf.net/spec/notes.html#large-documents Large document] issues, including [http://docutils.sf.net/spec/notes.html#object-numbering-and-object-references formal elements].
Nested inline markup -- may require new inline markup parser with proper tokenization & lexing. Or stack-based. Currently under discussion on the [http://lists.sourceforge.net/lists/listinfo/docutils-develop docutils-develop mailing list].
[http://docutils.sf.net/spec/notes.html#math-markup Math markup].
Complete [http://docutils.sf.net/spec/doctree.html "The Docutils Document Tree"] reference doc.
Wikis ([http://docutils.sf.net/sandbox/ianb/wiki/ Ian Bicking's sandbox], [http://docutils.sourceforge.net/FAQ.html#are-there-any-wikis-that-use-restructuredtext-syntax FAQ entry]). If MoinMoin is python.org's official wiki, it would be nice if it fully supported reStructuredText ;-).
[http://docutils.sf.net/spec/notes.html#bugs Squash bugs]
Add internationalization to [http://docutils.sf.net/spec/notes.html#footer-boilerplate-text footer boilerplate text].
[http://docutils.sf.net/spec/notes.html#adaptable-file-extensions Adaptable file extensions].
[http://docutils.sf.net/tools/editors/emacs Emacs reStructuredText mode].
[http://docutils.sf.net/spec/semantics.html Docstring semantics].
There are more ideas in the [http://docutils.sf.net/spec/notes.html#to-do Docutils to-do list].
(One just slightly off-topic idea would be to extend and existing documentation generator, such as EpyDoc, to support Zope-style interfaces. This would be especially nice since EpyDoc already supports reStructuredText. -- Fred Drake)
Comments
Please feel free to add any comments you like. Include your name for feedback; anonymous comments OK too. I hope to see you at PyCon! -- David Goodger
I shan't be able to make PyCon (no surprise there), but I hope the sprint goes really well. I have no objection at all if one of the items of work is the pysource reader, whether based on my work or not - indeed, I'd love to see a working implementation out there. -- Tibs
I'd be very interested in working on the/a Python source code reader -- it seems like the giant missing piece of docutils. -- Ian Bicking
Two 2-day sprints would be better for me. I wasn't planning to attend any sprint, but Docutils is tempting me. I'd most likely attend Monday-Tuesday. I'm not that good at understanding intricate parser code, but perhaps I can work on some other aspect. My wishlist item is for the HTML generator to just produce an HTML fragment I can plug into a larger page, rather than all the header/footer/style stuff it adds. There has also been much interest in our local Python user group about having a ReST syntax in MoinMoin. -- Mike Orr
An enhanced client API with better support for [http://docutils.sf.net/spec/notes.html#html-fragments writing fragments] would be really nice to have; I'd be willing to spend some time on that as well. Each time I have tried to make a simple script that used docutils in some way, the API has been difficult to figure out. It may be that documentation is all that's needed, or just a more-visible entry point into existing documentation, but I know how hard that is to do. I think it would be worth having at least a little brain-storming session to figure out where people are getting hung up on the API and letting you tell us how much of it is there in some form already, and guiding an effort to make it more effectively exposed. Whether that's documentation, a little code, or a pile of new stuff, I don't know, but my past explorations make me think there's some limited amount of "API stuff" that needs to be done. I don't know whether I'll be able to sprint on Monday/Tuesday though. -- Fred Drake