Great thoughts, Robert; I don't know if it will go anywhere, but it's worth revisiting every so often.
> > Raising the bar on Sage code quality creates this limbo area of code > that's good enough to be shared/built upon, but not good enough to be > included in Sage. The combinat folks seem to have realized this from > the beginning (hence the combinat queue) and this was also the > motivation for psage http://purple.sagemath.org/goals.html (see > especially "Change the development model") I don't see this changing > anytime soon. > > Right. > nights and weekends between teaching and research. (Of course it would > also be nice of the academic landscape shifts to give credit to these > worthwhile endeavors but that's not going to happen overnight.) > > Yes; the places where this is most likely to change (like where I teach) are also least likely to have enough time to do it right - at which point I apologize for not dealing with many, many bugs I probably could but simply don't have the time to currently fix :( > bugfixes not go in for ages due to trivial documentation issues... > (being able to *easily* make trivial chances or build upon the work of > You are so right here, and I'm sure I've been guilty of some of them. The GUI model on Github is good here (the rest of Github I could do without). The effort to make those trivial changes is often not worth it. > others will help here)) Decorators for "alpha-quality" methods that > don't exist in the "stable" model? Any other ideas? > > Honestly, I think that what makes sage-combinat work is not the queue, but the community. Perhaps because of the very high bar of correctness mathematics has (or attempts to have), potential Sage developers are reluctant to review code that they don't 100% understand. Then that goes double for the research-y ones. Probably the best thing any research-y code developer could do is to train two colleagues/grad students/whatever somewhere on Earth to really understand their code, *even if in a separate email and not on Trac*. Otherwise what I've observed is patches languishing because someone (again, often me) doesn't have time or energy to do that last 2% of verification that takes 98% of the review time, and once a few weeks have passed since the initial post of code, the original author has often moved on to something else for the time being. Conversely, when people are together, lots of stuff happens, and even often after the initial Sage Days or what have you, because you feel more of a personal responsibility for seeing the project through. That's a long way of saying maybe we need to encourage people posting this type of code (or any, really) to make the effort to identify people, whether current Sage developers or not, to work alongside - people who will have enough motivation to use the new code that they will care, but who aren't so invested in it that things like documentation or edge cases will seem pointless to check. How does this piece work in psage? In sage-combinat, again, the queue seems to solve this, and there is a lot of impressive teamwork. I know that for my own research code I know of no one else in this category, so I haven't bothered, but presumably people with grad students or postdoc colleagues or faculty mentors or coauthors will have people to identify for this... ? - kcrisman -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
