>> What is even more important is to do the work for the main features, >> i.e. the Sage Release Tour in the wiki during development and not as >> an afterthought. The best results there have always been had when the >> patch authors did the changes themselves. It would also be great to >> clean up the old release tours since many of them are rather >> rudimentary. > > So here Minh could bug the relevant people, ask questions, etc. For > example, Minh might directly email me and say -- Ok, explain what > "sage -only_optional" is all about, in case trac and the relevant help > in Sage isn't very helpful, and I'll answer, and he can proofread and > post the result into the tour. (?)
To this end, why don't we make this another criteria for a positive review? I'm proposing that our criteria for a positive review be raised to something like: 1. Patch that works (of course) 2. Doctests that document the function or show that the bug is fixed 3. If a (major?) feature is added or changed, a short paragraph is posted to trac describing the addition or change. This goes in the release tour (or a high-level API changelog, if it is a change of behavior). Thanks, Jason --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
