> I was not suggesting anyone spend 10,000 hours studying the subject of > software engeering. I'm not suggesting people need to be experts. But > perhaps spending 20-50 hours on it is not unreasonable. I don't know > about you, but I've probably devoted 1000 hours to working on Sage, so > 20-50 is a small percentage. I think 20-50 hours would be for you > too.
It's not clear to me that without a specific time and place to do so, that it would be particularly effective to spend 20-50 hours reading books about this. Software seems to be one of those things that is hard to really learn how to do without actually doing it. 10-20 hours spent trying to do some Sage development, but with a couple quality software engineers looking over your shoulder the whole time, might do it. The idea of having one piece of a Sage days devoted to people sharing ideas from books they read in a coordinated way sounds plausible as well, though probably it would really depend on the Sage days in question. > "I personally have been burned enough times now by obvious bugs that > have shown up when I try to demonstrate what > I'm doing in sage, that I hesitate now to shares things readily." This probably depends a lot on what mathematics you are doing with Sage, of course. > Currently one person with poor Python skills can review the work of > another with poor Python skills, and the code get committed to Sage. > There's little filtering. Condensed version of much longer response I started with: I often find that people who contact us (and even contact me personally) about this are more likely to not want to contribute *anything*, even very minor bugfixes or documentation improvements, because they are not confident in their skills. Most people who feel confident enough to review are confident enough to point out things that look bad, and those who don't still will often point out something wrong/suboptimal. What happens more often, I think, is that someone with decent/good Python skills is tired or lackadaisical and reviews something they want to get in without spending the 1+ hours it takes to really test edge cases and so forth of a patch also written by someone with decent/ good Python skills who is tired or lackadaisical... etc. Since such a person also contributes and reviews in quality ways most of the time, it's much harder to filter for that. Finally, I think that MANY of the new bugs in Sage are *not* a result of someone destroying old code, but rather of a bug appearing where before there was no functionality! I think that to most Sage developers, it is better to have 99 out of 100 cases give the right answer, and have it tested out and hopefully fix the bug soon that surely is there, than to have a NotImplementedError for years and years. Stagnation is the way to not attract the new developers we would need (for time's sake) to improve our software engineering practice, indeed. To be sure, this is a design decision of sorts, and one at odds with your books, perhaps. But unless we also can operate under the implicit assumptions of them (which probably include things like actual employers, or perhaps a pool of developers who all have similar skill sets - neither of which is the case here, in a project which is monstrously diverse in terms of skill needs and obviously very non- hierarchical), I don't see how it's feasible to implement your ideas on this, other than the reminders of good practice you give in public fora such as this and on Trac tickets. Which I think that is having a positive impact, incidentally! :) - kcrisman -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
