Sage Days 26 - How Sage development tends to be done

This talk will be an informal overview of how Sage development is currently done.  It's not necessarily how you should do Sage development.  We want to foster creative new ideas and approaches to how to make Sage more powerful and useful.   

1. Who works on Sage?: developer map
2. Super important: The Sage Developer's Guide  -- a quick spin/tour through this.
3. Trac: the trac page  -- when you work on something, create a ticket, post code, change the status to "needs review", referee other people's code, etc.     Mention Bradshaw's buildbot.
4. Purple Sage -- example of writing a big package of code outside of Sage. 
5. What to work on?   

• Search Google putting something like "site:trac.sagemath.org <your terms>" in the box to see if somebody else is working on something.
• Post on sage-devel.  But don't take responses too seriously!    (a) you can work on anything you want, though maybe what you do won't ever go into Sage.  So what, you could put it on your webpage.   (b) Feedback can be useful for avoiding duplicating work.  (c) Duplicating work isn't necessarily bad -- if you learn something well, then you win.