On Mon, Nov 26, 2012 at 9:46 AM, kcrisman <kcris...@gmail.com> wrote: > > 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.
+1, for sure. And we have many other great sage communities. Of course communities are hard to "engineer" compared to tools or policies. But I think having good technology, conventions, and practices can be conducive (or not) to community collaboration as well as allowing individuals to spend their limited time more productively. In particular, moving code from "I hacked something up to write a paper" to "I wrote something I feel comfortable sharing with my colleagues" is a huge step forward, and research-y communities are a good stepping stone between the former and inclusion into Sage (as well as being a source of users (aka testers), developers, and peer reviewers of code that requires a high degree of expertise). > 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? It'd be interesting to get William's take on it, but https://github.com/williamstein/psage/graphs/contributors is informative. (Of course the salv.us effort started up this summer.) > In sage-combinat, > again, the queue seems to solve this, and there is a lot of impressive > teamwork. Yes, and I think it'd be really interesting to get one of them to understand outline their goals (and how well the queue meets them) rather than just their methods. Then we can either come up with something even better, or make sure we support queues really well :). > 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... ? Yep. - Robert -- 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.
