Sage Documentation Project

This is the main community website of the Sage Documentation Project. This page is used as a central point to organize the efforts to create new help pages, tutorials, examples and similar documentation efforts. To add a documentation page to this category, add a link to this page on the last line of the page. Click on "subscribe" above to be posted about changes.

Published Documents

Pages in this wiki (should belong to the category "DocumentationProject").

External Documents

Not in this wiki (i.e. PDF or website).

Documents in the Work

Wish List

This is a list of requested documentations.

Types

Some definitions on what is what in the list above. (If someone has better definitions, please edit!)

• Howto: Basic step-by-step guide with screenshots, easy to use, straightforward, probably often updated.

• Tutorial: Explain a topic, how to do something, similar to howto...

• Guide: More general than howto and tutorial. For example, explain background knowledge and connect the dots.

• Examples: List examples on a particular topic. The levels "beginner", "advanced" and "pro" can be used to indicate the level of prior knowledge, where "pro" involves knowledge about programming with Sage, i.e. also Python, while "advanced" only requires an understanding of Sage's basic functionalities and an implicit knowledge about Python programming.

• Teaching: Material used in teaching.

Writing Great Documentation

Jacob Kaplan-Moss has written a series of three articles on how to write great documentation for any open source project. Here is a list of his articles:

1. What to write --- Various types of documents that a project should have, including reference manual, tutorials, brief feature tours, development guidelines, etc.

2. Technical style --- good technical styles to follow.

3. You need an editor -- on the importance of having an editor to look after the project's documentation.

Darrell Anderson has some tips on technical writing that are well worth a read:

1. Bigshot Words --- some words to avoid. Dilbert also has some tips.

2. A Proofreader’s Checklist --- common grammatical and spelling mistakes to look out for.

3. Technical Writing Tips --- numerous points to keep in mind in technical writing.

Other resources

1. It also helps to use a spell checker.

2. Documentation issues in open source from OSS Watch.

3. How to Write Documentation that Will Lead to New Users by Jack Herrington.

4. Open-source documentation: in search of user-driven, just-in-time writing by Erik Berglund and Michael Priestley. In "SIGDOC '01: Proceedings of the 19th Annual International Conference on Computer Documentation", ACM, pages 132--141, 2001.

5. S Van der Walt. The SciPy Documentation Project (Technical Overview). In Proceedings of the 7th Python in Science conference (SciPy 2008), G Varoquaux, T Vaught, J Millman (Eds.), pp.27--28.

6. J Harrington. The SciPy Documentation Project. In Proceedings of the 7th Python in Science conference (SciPy 2008), G Varoquaux, T Vaught, J Millman (Eds.), pp.33--35.

7. J Harrington et al. Progress Report: NumPy and SciPy Documentation in 2009. In Proceedings of the 8th Python in Science conference (SciPy 2009), G Varoquaux, S van der Walt, J Millman (Eds.), pp.84--87.

8. Documentation by [insert doc type] covers what isn't documentation.

Worst-case scenario

Avoid the following scenario as much as possible. This is taken from "Lecture 12: FOSS Culture" of the ANU course COMP8440:

From: xxxxx
Date: Fri, 9 Feb 2001 21:07:09 +0900
To: [email protected]
Subject: Dear Sir,

I have always wanted to flame you, however I never really had any good reason
to do so. While your software creations were always egoistical and
underdocumented, nothing really pushed the mark, yet. Until today, when I
downloaded your "Linux 2.4" call graph utility. So, when is your next absolute-
next-to-worthless but oh-so-cool-because-it's-from-rusty-russell piece of software
coming out? Why the f*** don't you focus on documenting things instead of
writing useless shit that "takes about 8 hours to run on my mobile pII laptop" or
"generates about 180mb of vector postscript". How about another example. I
heard you were involved with that atrocity called "netfilter". Sure, it might have
nice features and I am still considering using it, but WRITE SOME F***ING DOCS
before you release complex shit like this for people to use! When I goto that
netfilter site, I don't give a flying raging f*** who submitted 31337 lines of code to
whatever f***ing netfilter module. That's your egoistical shit, and I could care less
about it.
...... (more rants delted)
... Uhm, that's all I can think of right now.

xxx (name deleted)

Documents by Category

• DocumentationProject