9854
Comment:
|
10522
|
Deletions are marked like this. | Additions are marked like this. |
Line 1: | Line 1: |
(For the Docutils sprint at PyCon2007, see ["PyCon2007/DocutilsSprint"]. For the Docutils sprint at PyCon2006, see ["PyCon2006/Sprints/DocutilsSprint"].) |
|
Line 2: | Line 5: |
PyConDC2004 is over. See [http://starship.python.net/~goodger/pycon_dc_2004/ A Week at PyCon DC 2004] for a narrative account of events. |
|
Line 5: | Line 10: |
We also had a birds-of-a-feather session; see DocutilsBof. |
|
Line 11: | Line 18: |
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? |
The sprints at ["PyConDC2004"] were held from March 20 (Saturday) through March 23 (Tuesday), for a total of 4 days. I was there for all 4 sprint days, and sprinters joined in as they were able. |
Line 17: | Line 22: |
Please voice your opinions here or [mailto:goodger@python.org email me]. | Please feel free to comment here or [mailto:goodger@python.org email me]. |
Line 22: | Line 27: |
There is no cost to attend the sprints beyond registering for Py``Con (and being present, of course). |
There was no cost to attend the sprints beyond being present. |
Line 28: | Line 32: |
Everyone is welcome! No prior Docutils hacking experience is required. Participants should either be experienced Python programmers, or interested |
Everyone was welcome! No prior Docutils hacking experience was required. Participants were either experienced Python programmers, or interested |
Line 32: | Line 36: |
Please [mailto:goodger@python.org email me] or edit this page directly if you'd like to participate. |
Here are the sprinters who attended: |
Line 36: | Line 39: |
* [mailto:oliver@rutherfurd.net Ollie Rutherfurd] * [mailto:fdrake@acm.org Fred Drake] (Saturday and Sunday) * [mailto:ianb@colorstudy.com Ian Bicking] (but I'm not really sure which sprint I will attend) * [mailto:mso@oz.net Mike Orr] (Monday and Tuesday, and maybe part of the weekend) |
* [mailto:oliver@rutherfurd.net Ollie Rutherfurd] (Saturday and Sunday) * [mailto:fdrake@acm.org Fred Drake] (Saturday) * [mailto:ianb@colorstudy.com Ian Bicking] (Saturday, Monday, & Tuesday) |
Line 41: | Line 43: |
* [mailto:edloper@gradient.cis.upenn.edu Edward Loper] (All four days?) * [mailto:tracer@axiomfire.com Tracy Ruggles] (mon & tue, maybe sat and sun) |
* [mailto:edloper@gradient.cis.upenn.edu Edward Loper] (Sunday through Tuesday) * [mailto:tracer@axiomfire.com Tracy Ruggles] (Sunday & Tuesday?) |
Line 44: | Line 46: |
* [mailto:sholden@holdenweb.com Steve Holden] (Saturday and Sunday) * Bill Sconce (all four days) * Andrew Kuchling (Saturday) * Reggie Dugard (Sunday through Tuesday) * Mike Orr (Monday) * Lloyd Kvam (Tuesday) * Laura Creighton (Sunday through Tuesday) * Jacob Hallen (Sunday through Tuesday) |
|
Line 48: | Line 58: |
This sprint and my participation at ["PyConDC2004"] are being sponsored by Silver Sponsor [http://WingIDE.com Archaeopteryx Software], the |
This sprint and my participation at ["PyConDC2004"] were sponsored by Silver Sponsor [http://WingIDE.com Wing IDE (Archaeopteryx Software)], the |
Line 52: | Line 62: |
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! |
|
Line 62: | Line 66: |
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. |
Each sprint day began with an interactive overview of the Docutils architecture and codebase. |
Line 66: | Line 68: |
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)? |
I will update this page with actual results from the sprint. For now, here is the original list of ideas for the sprint, in no particular order: |
Line 72: | Line 71: |
Here are ideas for the sprint, in no particular order: * Python source reader (autodocumentation subsystem). There's a lot of support for this. Ideas: |
* '''PROGRESS!''' Python source reader (autodocumentation subsystem). There's a lot of support for this. Ideas: |
Line 86: | Line 83: |
* Doc``Py (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]). | * '''PROGRESS!''' Doc``Py (Python's dialect of LaTeX) writer completion -- would allow easier entry for documentation newbies, "make authorship more accessible" ([http://docutils.sf.net/sandbox/edloper/docpy/ initial implementation]). ''This would be a major interest for me, I would like to make the Python docs more accessible to new authors -- SH'' |
Line 88: | Line 85: |
* 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. | * '''DONE!''' Add an [http://docutils.sourceforge.net/sandbox/edloper/epytext epytext parser] (requires [http://epydoc.sourceforge.net epydoc]). * '''DONE!''' 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. Reggie Dugard implemented a new docutils.core.publish_parts() convenience function, with Mike Orr's initial help. |
Line 97: | Line 98: |
* Doc``Book ([http://docutils.sf.net/sandbox/oliverr/docbook/ Oliver Rutherfurd's sandbox]) | * '''PROGRESS!''' Doc``Book ([http://docutils.sf.net/sandbox/oliverr/docbook/ Oliver Rutherfurd's sandbox]) |
Line 100: | Line 101: |
* Aahz will be running a sprint to create a base protocol for binary | * '''PROGRESS!''' Aahz will be running a sprint to create a base protocol for binary |
Line 108: | Line 109: |
* 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]. | * 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]. David Abrahams has checked in an initial implementation to the "nesting" branch under CVS. |
Line 112: | Line 113: |
* Complete [http://docutils.sf.net/spec/doctree.html "The Docutils Document Tree"] reference doc. | * '''PROGRESS!''' Complete [http://docutils.sf.net/spec/doctree.html "The Docutils Document Tree"] reference doc. |
Line 114: | Line 115: |
* 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 ;-). | * '''PROGRESS!''' 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 ;-). |
Line 116: | Line 117: |
* [http://docutils.sf.net/spec/notes.html#bugs Squash bugs] | * '''PROGRESS!''' [http://docutils.sf.net/spec/notes.html#bugs Squash bugs] |
Line 132: | Line 133: |
* (One just slightly off-topic idea would be to extend an existing documentation generator, such as EpyDoc, to support Zope-style interfaces. This would be especially nice since EpyDoc already supports reStructuredText. -- ''Fred Drake'') * (EpyDoc *should* already support Zope-style interfaces. If not, then please let me know where it needs to be extended for proper support. -- ''Edward Loper'') * '''DONE!''' implemented a directive to embed the ABC music notation in reStructuredText. |
|
Line 134: | Line 140: |
* (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'') * (EpyDoc *should* already support Zope-style interfaces. If not, then please let me know where it needs to be extended for proper support. -- ''Edward Loper'') |
|
Line 150: | Line 153: |
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'' | 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. It is unlikely I'll be able to sprint on this topic Monday/Tuesday though. -- ''Fred Drake'' |
Line 154: | Line 157: |
I use EpyDoc quite a bit, and would like to help with it's docutils support. And, just in general, would like to help out the docutils project. -- *Tracy Ruggles* | I use EpyDoc quite a bit, and would like to help with it's docutils support. And, just in general, would like to help out the docutils project. -- ''Tracy Ruggles'' I'd love to get the Doc``Book writer finished up -- I think it's pretty close. It needs tests, better bibliographic field handling, and probably a bit of polishing. -- ''Ollie Rutherfurd'' |
(For the Docutils sprint at PyCon2007, see ["PyCon2007/DocutilsSprint"]. For the Docutils sprint at PyCon2006, see ["PyCon2006/Sprints/DocutilsSprint"].)
Preliminaries
PyConDC2004 is over. See [http://starship.python.net/~goodger/pycon_dc_2004/ A Week at PyCon DC 2004] for a narrative account of events.
For introductory information and information about the other sprints going on at ["PyConDC2004"], please see SprintPlan2004.
We also had a birds-of-a-feather session; see DocutilsBof.
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"] were held from March 20 (Saturday) through March 23 (Tuesday), for a total of 4 days. I was there for all 4 sprint days, and sprinters joined in as they were able.
Please feel free to comment here or [mailto:goodger@python.org email me].
Cost
There was no cost to attend the sprints beyond being present.
Sprinters
Everyone was welcome! No prior Docutils hacking experience was required. Participants were either experienced Python programmers, or interested in documentation.
Here are the sprinters who attended:
[mailto:goodger@python.org David Goodger] (coach)
[mailto:oliver@rutherfurd.net Ollie Rutherfurd] (Saturday and Sunday)
[mailto:fdrake@acm.org Fred Drake] (Saturday)
[mailto:ianb@colorstudy.com Ian Bicking] (Saturday, Monday, & Tuesday)
[mailto:aahz@pythoncraft.com Aahz] (All four days)
[mailto:edloper@gradient.cis.upenn.edu Edward Loper] (Sunday through Tuesday)
[mailto:tracer@axiomfire.com Tracy Ruggles] (Sunday & Tuesday?)
[mailto:gilbert@voxmea.net Matt Gilbert] (All four days)
[mailto:sholden@holdenweb.com Steve Holden] (Saturday and Sunday)
- Bill Sconce (all four days)
- Andrew Kuchling (Saturday)
- Reggie Dugard (Sunday through Tuesday)
- Mike Orr (Monday)
- Lloyd Kvam (Tuesday)
- Laura Creighton (Sunday through Tuesday)
- Jacob Hallen (Sunday through Tuesday)
Sponsorship
This sprint and my participation at ["PyConDC2004"] were sponsored by Silver Sponsor [http://WingIDE.com Wing IDE (Archaeopteryx Software)], the [http://www.python.org/psf Python Software Foundation (PSF)], and individual contributors. Thank you all!
Sprint Topic Ideas
Each sprint day began with an interactive overview of the Docutils architecture and codebase.
I will update this page with actual results from the sprint. For now, here is the original list of ideas for the sprint, in no particular order:
PROGRESS! 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)]
Extending EpyDoc with python source parsing (this has been on the todo list for a while now).
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).
PROGRESS! DocPy (Python's dialect of LaTeX) writer completion -- would allow easier entry for documentation newbies, "make authorship more accessible" ([http://docutils.sf.net/sandbox/edloper/docpy/ initial implementation]). This would be a major interest for me, I would like to make the Python docs more accessible to new authors -- SH
DONE! Add an [http://docutils.sourceforge.net/sandbox/edloper/epytext epytext parser] (requires [http://epydoc.sourceforge.net epydoc]).
DONE! 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.
- Reggie Dugard implemented a new docutils.core.publish_parts() convenience function, with Mike Orr's initial help.
[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 (original hack in [http://docutils.sf.net/sandbox/aahz/OO/ Aahz's sandbox] & mods in [http://docutils.sf.net/sandbox/pobrien/OpenOffice/ Patrick O'Brien's sandbox])
PROGRESS! DocBook ([http://docutils.sf.net/sandbox/oliverr/docbook/ Oliver Rutherfurd's sandbox])
- RTF
PROGRESS! Aahz will be running a sprint to create a base protocol for binary writers, leading to a reactoring of the OpenOffice.org writer and a new MIFWriter for Frame.
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]. David Abrahams has checked in an initial implementation to the "nesting" branch under CVS.
[http://docutils.sf.net/spec/notes.html#math-markup Math markup].
PROGRESS! Complete [http://docutils.sf.net/spec/doctree.html "The Docutils Document Tree"] reference doc.
PROGRESS! 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 ;-).
PROGRESS! [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].
Extend EpyDoc support for ReStructuredText (e.g., for LaTeX output).
- Auto-numbering syntax.
- The ability to reference (internal link) an auto-numbered section sans the number.
(One just slightly off-topic idea would be to extend an existing documentation generator, such as EpyDoc, to support Zope-style interfaces. This would be especially nice since EpyDoc already supports reStructuredText. -- Fred Drake)
(EpyDoc *should* already support Zope-style interfaces. If not, then please let me know where it needs to be extended for proper support. -- Edward Loper)
DONE! implemented a directive to embed the ABC music notation in reStructuredText.
There are more ideas in the [http://docutils.sf.net/spec/notes.html#to-do Docutils to-do list].
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. It is unlikely I'll be able to sprint on this topic Monday/Tuesday though. -- Fred Drake
I'll probably be there for all four days. Anyone who's interested in automatic API documentation generation might want to take a look at EpyDoc, which currently supports reStructuredText. I'd like to work on extending it with better docutils support, and improve it in other ways. -- Edward Loper
I use EpyDoc quite a bit, and would like to help with it's docutils support. And, just in general, would like to help out the docutils project. -- Tracy Ruggles
I'd love to get the DocBook writer finished up -- I think it's pretty close. It needs tests, better bibliographic field handling, and probably a bit of polishing. -- Ollie Rutherfurd