Home > documentation, open source software, programming, Sage, symbolic computation > Getting started with developing Sage

Getting started with developing Sage

At Sage Days 16, Martin Albrecht gave a talk on how to start with developing Sage. Like any free open source software project, there are numerous ways in which you could help out with developing Sage. Not only am I talking to folks out there who already know how to program, but I’m also appealing to non-programmers. In this post, I’ll concentrate on the non-programmers or people who are not comfortable with or have little experience with programming.

First thing first: if you can speak, read, and write in another (natural) language, there are many ways you can help out. Say you know Italian. Then you can write a Sage tutorial in Italian, or help out with translating the official Sage tutorial to Italian. I know this is an obvious point. However, sometimes it’s an obvious point that we usually leave out.

For the graphics designers or artistically creative, you can help out with improving the design of the Sage website. Or you can cast your critical artistic eyes over the Sage notebook interface and find out where it needs improvement.

Many people like writing technical tutorials. One of the joys of doing so is that you also learn something new in the process. At the same time, you communicate your knowledge to beginners, a skill which is useful in fields other than technical writing. A main point about technical writing is that you communicate a technical subject to beginners, so keep technical jargons to a minimum. Darrell Anderson has written some tips on technical writing. I highly recommend you go over those tips, or search the net for more information.

I first started contributing to Sage by proofreading its websites and the Sage standard documentation. That was way back in late 2007. Whenever I found some typos, I would report it to the Sage development mailing list. But over the months, I learned how to use the trac bug tracking system to report the typos. Open tickets on trac usually have patches. Pick a patch, read through it, and ask yourself if the documentation for a particular function makes sense. Here are some tips for proofreading. I usually download a patch, run it through an English spell checker, and report any typos on the corresponding ticket. At one stage earlier this year, I ran about 30 source files through a spell checker, note all the typos I found in their documentation, and reported those typos. That is tedious work, I admit, but it’s a good way to improve your English skills. In the course of spell checking the Sage standard documentation, I learned a lot about how Australian, British, and US programmers write their documentation. George Bernard Shaw once said that England and the USA are two countries separated by a language.

The above is a very short list. I’m sure there are many, many more ways in which you can help out.

Advertisements
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: