On Sun, Dec 27, 2009 at 9:08 PM, mhampton <[email protected]> wrote: > I'd like to object to the policy you are proposing. I would like to > first emphasize that I completely support the goal of having functions > include INPUT and OUTPUT blocks. But the policy you are proposing is > far too rigid. > > As one example, imagine that a Sage user finds a documentation error. > The user wants to file a bug report. They are then encouraged to get > a trac account and post a patch. Imagine that they do so. Then a > reviewer flags the patch as "needs work" because the function in > question doesn't have INPUT/OUTPUT blocks. I think this would be very > discouraging. > > Perhaps you meant your policy to only apply to new code, or to > functions (rather than modules) that have been revised. I think it is > worthwhile for you to clarify exactly what you mean. > > In general I would like to point out that such policies can make it > unlikely that new people will become Sage developers. It is a > delicate balance between encouraging new effort and maintaining > quality. At the moment I think the current policies are quite good, > but if they became more rigid it would turn new people off. > > -
We aren't writing enough INPUT/OUTPUT blocks to describe the input and output of functions. I want to encourage this very, very strongly since I think it will make Sage much more usable, and many other people have requested it. I don't care about "policies" with respect to this particular discussion at this point. However, if you are refereeing some code and you see that the INPUT/OUTPUT blocks are generally lacking, I hope you will feel confident in complaining about this. I certainly will. -- William -- To post to this group, send an email to [email protected] To unsubscribe from this group, send an email to [email protected] For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
